Share via

Unmanaged Debugging vs. Managed Debugging vs. Mixed Debugging.

  • Article

All versions of VS support debugging both managed and unmanaged code.  However there is a big difference between doing one or the other and doing both. GreggM has written about some of the reasons interop debugging is difficult.  Here I will refer to debugging both managed and unmanaged at the same time as Mixed debugging.

 

If you are having stability problems when debugging, one reason may be you are doing Mixed debugging without realizing it.  If you have a C# or VB project that uses unmanaged COM objects, at some point you may have wanted to debug into the COM object.  Somewhere along the line someone right clicked on the project in the Solution Explorer, went to properties, then “Configuration Properties/Debugging/Enable Unmanaged Code”, and set it to true.  If you did this, you enabled Mixed debugging.  There are some cool features you get with that, and some features you lose.  On balance Mixed debugging is almost never worth it.  Mixed is more intrusive, and less stable then either approach alone.  If you are debugging a Managed Application you should not turn on ‘unmanaged debugging’ unless you have a specific need for it.  One great feature of using managed or native debugging alone is you can attach and detach at will.  One of the features you lose with Mixed is the ability to detach.

 

If you attach to a process it will default to debugging all program types in the process.  Don’t accept this default!  If you attach in Mixed mode “Common Language Runtime” and “Native” are both checked. Pick one, if you don’t like what you picked, detach and reattach with the other.  Your life will be much easier.

 

C# and VB projects do not have a way to turn off managed debugging.  If you want to native debug a application that starts from a managed exe, my suggestion is to leave the original project as managed only, and create an additional project to do your native debugging. The most versatile way is to create an empty VC++ makefile project. Right click on the solution, Add/ New Project/ Visual C++/Makefile Project.  Right click on the new project Properties/Debugging/Debugger Type.  There are 4 choices: “Native only”, ”Managed Only”, “Mixed”, and “Auto”.  Use Native only.  Never use Auto.  A few rows up is “Command”, left click to get a dropdown with Internet Explorer, ActiveX container, regsvr32 and browse.  Pick browse and find the .exe output of your current startup project.  Finally in the top right of this property dialog is a button “Configuration Manager”.  Click on it and you will see a list of the projects in the Solution with configuration, platform, and check box on whether it should build.  Uncheck the build box for the makefile project you just created.  At this point you can set the makefile project to be the startup project: Right click on the Project /Set as Startup Project.  You will now launch in native debugging mode.  You can either switch statup projects or switch the Debugger Type setting in the makefile project to switch back and forth.  You can also detach when debugging this way and reattach with the other debugger type.  This is typically more flexible, stable, and productive.

Comments