How does a .NET program behave differently when run with and without debugging in Visual Studio?

Question

I'm getting an Access Violation in DBEXPSDA40.DLL (Dev Art MS SQL Server dbexpress driver) on closing down my .NET application. My application (VB.NET) calls a Delphi written COM Server which uses dbexpress to connect to SQL Server.

If I do the same thing, but my host application is a native Delphi application, or Excel VBA, then I do not see the A/V. I also do not see it if I run the VB.NET application in the VS IDE with debugging.

I have tracked down the A/V to a finalization clause in a dbexpress unit, which takes care of closing down the drivers (in this case two, one for SQL server and the other for SQL Server Compact)

If I can figure out what the difference is between with debugging and without in the .NET environment, I can perhaps know where to look further.

Answer 1

It is possible that the host application is hiding the exception from you. Shutdown errors are the hardest. Add some logging to see if the exception occurs when the debugger is detached.

Answer 2

Your difference is memory layout.

There is a lot of subtle factors that influence the process. For one, under debugger, the JIT generates slightly different code (to accommodate the debugger). Depending on your debugger settings, the Visual Studio may also inject some other code in your process (like the .vshost.exe, for example). The debugger can also affect the timing and that may in turn expose race conditions and/or change how memory is allocated.

Long story short, by the time of application closing, you end up with [slightly or significantly] different memory layout. And same goes for a different host application, obviously.

But that's only one side of the story. The other side is that there is a bug in dbexpress. Or maybe some other module causes memory corruption in dbexpress's data. Either way, dbexpress ends up accessing some random address.

And that address just happens to be on an unallocated memory page in one case, but happens to be on an allocated one in other cases (because the memory layout is different, remember?). And in the latter case, dbexpress just reads the value from memory, does something with it, apparently gets satisfied with the result, and gracefully exits.

This (along with untraceable race conditions) is a very common problem with immaturely written non-managed code (which, my experience shows, is very often the case where Delphi is involved).

The solution? Change conditions. You can try on a different machine. Or on the same machine, but under heavy load. Or load some more modules. Or do not load some modules that you usually do. Play with it.

That being said, yours truly personally never goes that way. It just becomes searching for a pin in a haystack, never ending, emotionally draining kind of adventure. Plus, you have a high chance of getting an AV in some other place (but because of the same root cause).

Another (and better) option would be debug print. That is, in case you have source code of dbexpress (sorry, I'm not familiar with it).

Otherwise, I would start with a very careful code review for the Delphi component. And probably debug print there as well.

Good luck.