Odd problem with System.AccessViolationException

I have an asp.net (3.5) web application. In one page i use an unmanaged C library (a simulator) that produces a set of results based on some input.

When i've set the debug="false" in web.config (Release mode) that call will result in a System.AccessViolationException. If i am in the debugger, or at least set debug="true" in web.config, that exception will never appear.

Because of开发者_JAVA技巧 the nature of the bug i placed the call inside a try-catch to log the exception and then the exception does not appear!

Is there some magical work on protected memory space when in debug mode and/or in a try-catch?

AccessViolationException in this context probably means your unmanaged C code is screwing up. It's overwriting the heap or something.

Keep in mind that many pieces of code were never written to be run in a multi-threaded environment like that of ASP.NET. They were never even tested in such an environment, or were only tested using some "desktop" form of multi-threading that does not apply to ASP.NET.

I had a problem like this once. A third-party DLL which claimed to be thread-safe was very unsafe. By attaching an unmanaged debugger to the ASP.NET worker process, it was possible to see that the application was writing all over the C runtime library heap, and the heap was complaining bitterly about it. And nothing was listening to the complaints.

It was necessary to wrap calls to this code in a lock block - to ensure that only one thread could call it at a time. This was sufficient to prevent all of the crashes, even under load.

This still might not suffice for all unmanaged code. A piece of code that assumes all calls will occur on the same thread, or that all calls from the same "session" occur on the same thread, will be disappointed, and may very well crash or do something worse. In that case, you might need to move that code into a separate Windows Service which only allows one single thread to access that library, ever.