Letting the debugger pick a debugging mode – Be cautious

The “Auto” feature in the Visual Studio debugger guesses (based on the EXE used to launch the process) whether your app is managed or not. Based on this, it decides whether to turn on either managed or native debugging, as appropriate.

If your C# (or other managed language) EXE uses native C++ DLLs, *AND* if you want to be able to debug your native code, it’s a good idea to explicitly set the debugger to use “mixed” mode beforehand. Ditto for the inverse scenario.

I’ve lost a lot of time wondering why my breakpoints weren’t firing, or why I couldn’t step into certain functions, only to find out that the debugger hadn’t inferred the mixed native/managed nature of my program. I wouldn’t call this a bug. Rather, it’s a difficult problem to solve 100% without knowing the user’s true intent.


Comments (5)

  1. Matt,

    as a sidenote to breakpoints not working correctly. incase you have (at least) two files with the same name, the debugger tends to get all mixed up. very often, trying to place a breakpoint in one of the files, will place the breakpoint at the same line number in the other file… 🙂

    took me _quite_ some time to figure this out…


    thomas woelfer

  2. Andy Pennell says:

    Actually Auto also looks at your Project settings, to see if you have the /CLR switch thrown anywhere. However as many folks dont use the project system in the IDE, this wont help them.

  3. Andy Pennell says:

    Thomas, this is much harder problem than you may think. We fixed it in VS2005 by checksumming source files: the debugger will never again get the wrong version of a source file. C++, C# and VB compilers all create checksums.