"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 (8)

  1. Mike Dimmick says:

    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!

  2. Mike Dimmick says:

    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.

  3. Bharath says:

    .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.com

  4. jmstall says:

    Mike – thanks for the link!

  5. Jack Kordas says:

    Since I am running my component in a service application via Component Services / COM+, I tried updating my applications Application.config in the application root directory with the v 1.1 config information above. This did not solve the problem.

    Since the components are hosted in dllhost.exe, I next tried to add a config file in the system folder next to dllhost.exe. This did work! While not an ultimate solution since everything loaded by dllhost.exe will want to use v1.1 of the framework, it suits my debugging needs for the time being.

    Thanks much!

    Jack

  6. John Martelli says:

    It worked for me. Thanks!

  7. "Which versions of a managed debugger (eg, Visual Studio) can debug which versions of the CLR? And How?"

  8. I&#39;ve had enough &quot;Debugger + Versioning&quot; posts to go back and create a versioning category