is there any way the .net 4 debugging api can somehow corrupt the state of an application during startup?
the issue i have is the following:
- if i start my application from within a debugger using the .net debugging api (visual studio 2010, sharp develop 4, mdbg), i get various random access violations.
- if i start my application from within a debugger not using the .net debugging api (delphi 2007, windbg with sos extension) everything works fine.
- if i start my application directly and later on attach a debugger to it (like visual studio 2010, sharp develop 4, mdbg, delphi 2007, windbg), everything works fine.
- if i move back to .net 3.5 and clr 2.0 i have no problems at all.
so what changed from .net 3.5 to 4.0 in the managed debugging api causing my application to throw access violations if started with it?
the application is written in delphi (unmanaged) and c# (managed) using managed vcl to do the interop.
i can hardly give any example to reproduce this issue so i’m aware that answering this question might be impossible, but if someone with more insight to the debugging api can give me a hint in the right direction or could help me narrow it down i’d be very thankful.
Just for fun try and disable the Visual Studio hosting process. In Visual Studio right click on the project, go to the ‘Debug’ tab, and uncheck the “Enable the Visual Studio hosing process” check box.
We’ve seen some strange stuff in the managed/unmanaged land on 64 bit systems running 32 bit apps.