Take the 2-minute tour ×

I am running an application in Debug mode but I noticed after a few seconds, a First Chance Exception of type 'System.UnauthorizedAccessException' was being thrown very often and continuously. While this didn't prevent my application from running, I still wanted to understand what was going on and resolve the issue to help with performance.

It turns out the exception is "Access to the path 'XXX.dll' is denied". This baffles me as it must be coming from windows when the application is attempting to access the DLL, which it must have already done successfully.

Running the application multiple times will cause the error to occur on different DLLs so the exact position in the application where this occurs is not deterministic or repeatable.

Is there a way to resolve this issue? Why is it occurring?

share|improve this question
I don't know about resolving it - it may be completely benign - but you can have Visual Studio stop when it happens so that you can review the call stack by selecting 'thrown' for all exception types in in Debug | Exceptions.... –  500 - Internal Server Error Jun 19 '13 at 16:40
@galford13x: Does your application crash after this happens? –  Dominic Zukiewicz Jun 19 '13 at 16:43
@500 - That is exactly what I did, was enable Break on Thrown so that I could analyze it. It does appear to be benign from a functional sense. But I'd like to understand what is causing it so that I could resolve the issue if/when performance problems occur. –  galford13x Jun 19 '13 at 20:01
@Dominic - It doesn't crash, it runs as I would expect functionally. Although as far as performance issues go, I haven't done that analysis yet. My application is timing sensitive so there could be some impact there. –  galford13x Jun 19 '13 at 20:02
What does the call stack look like when this happens? –  500 - Internal Server Error Jun 19 '13 at 21:08
show 1 more comment

1 Answer

Assembly Binding Logs

If you think it might be related to assembly binding, use Scott Hanselman's instructions to enable FusionLog and view the assembly binding logs.

It will probably help you find and solve your problem, if it is related to assembly binding.

Alternatively, just set the Registry keys your self. (I just memorized them, as I set them all the time.) Set HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 and HKLM\Software\Microsoft\Fusion\LogPath registry value to C:\FusionLogs or some path that exists.


FusionLog Enabling

share|improve this answer
fuslogvw.exe from the command line –  Dominic Zukiewicz Jun 19 '13 at 16:43
Yes! ...with the appropriate path (use the Visual Studio Command prompt). –  Chris Benard Jun 19 '13 at 16:46
This doesn't appear to be the issue. I am sure the binding is working fine as the application executes correctly. And if I hadn't looked at the output while the application was executing I would have never realized an exception was being thrown. I'm just not sure why there would be access issues (which appears to have no effect logically) regarding the .DLL –  galford13x Jun 19 '13 at 19:59
Oh ok @galford13x. Sorry that didn't help, but I've had issues with assembly binding many times in the past, so hopefully it'll help someone. :) If the application is executing normally, try setting visual studio to break on all errors. Maybe that'll help you figure out what the problem is (if the errors are not benign). –  Chris Benard Jun 19 '13 at 20:24
add comment

Your Answer


