"Visual Studio 2003 Mixed Mode Debugging Crash"
It's great that 2005 has shipped. I personally enjoy using it for my own pet projects and I'm very pleased. But shipping a V2 also means exposing versioning problems in the V1 design. Such an issue came up on the forums, which basically boils down to: VS 2003 crashes when:
1. I install VS2005
2. I'm interop (aka mixed-mode) debugging
3. The main executable is some win32 (unmanaged) app.
4. That executable then loads managed code.
A common case of this would be using VS2003 to interop-debug a VB.Net COM-object, which is hosted by an unmanaged container.
Why?
The reason for the crash is very likely a collision of 2 things:
1. In the absence of any configuration settings, unmanaged apps that load the runtime will "float up" to load the latest runtime version. (This was a very difficult decision to make and there were strong pros and cons on both sides. I'm not the expert here, so I can't really comment on this decision one way or the other. ) It's important to have a completely unmanaged app here because managed apps (eg, C#) have some markings in them hinting at what runtime version to use.
2. VS 2003 can't debug an app that loads the 2005 CLR (V2).
In this case, the unmanaged app was properly running against VS2003 / CLR V1.1. The unmanaged app loaded V1.1 because there were no other runtimes installed on the box. But then installing VS2005 / CLR V2.0, meant that the app now could float up against V2. Which meant that now VS2003 was accidentally debugging a V2 CLR. And this lead to a crash.
The workaround:
The workaround for the crash is to just put a config file on the unmanaged app to force the debuggee to load V1.1 CLR, which is the version of the CLR that VS2003 is capable of debugging. Config files live next to the app and has the same name but prepended with ".config". Eg, if you app is "c:\dir\subdir\MyApp.exe", then the config file is "c:\dir\subdir\MyApp.exe.config"
<?xml version ="1.0"?>
<configuration>
<startup>
<requiredRuntime version="v1.1.4322"/>
</startup>
</configuration>
The significant thing is the requiredRuntime element. I must warn: I'm not an expert in Config files and I think I've just said everything I know about them.
I believe (no promises) that the VS folks are also adding better error detection here so that it will at least warn you of this issue and advise you to put a config file down.
Comments
Anonymous
December 05, 2005
You should use <supportedRuntime> rather than <requiredRuntime> for all .NET 1.1 or later apps. The documentation for <supportedRuntime> (http://msdn.microsoft.com/library/en-us/cpgenref/html/gngrfrequiredruntime.asp) makes this clear but unfortunately the documentation for <requiredRuntime> doesn't even mention it!Anonymous
December 05, 2005
Note to self: remember to 'sync toc' before copying a link from MSDN Online. The link should have been http://msdn.microsoft.com/library/en-us/cpgenref/html/gnconSupportedRuntimeElement.asp.Anonymous
December 06, 2005
.Net 2003 installed in win xp pro with sp2 and having 512 MB RAM with 2.6Ghz. I have updated the latest patch file in the system. It will run fast for the day. Then After the next day when I switch on the comp, it work for a half day. Again the .Net 2003 will run slow. The application used to take more than 3 hours to run or some time it will be hanged. Even though I tried to set the background application higher values. It runs very slow. Is there anything to do with that.
Please mail me immediately.
Bharath.shesh@gmail.comAnonymous
December 07, 2005
Mike - thanks for the link!Anonymous
December 21, 2005
The comment has been removedAnonymous
January 16, 2006
It worked for me. Thanks!Anonymous
April 20, 2007
"Which versions of a managed debugger (eg, Visual Studio) can debug which versions of the CLR? And How?"Anonymous
July 05, 2007
I've had enough "Debugger + Versioning" posts to go back and create a versioning category