Andre's Blog
Perfection is when there is nothing left to take away
Break, break, dammit!

A couple of days ago a developer asked me why their Visual Studio 2005 debugger no longer breaks when a C++ exception is thrown, even though C++ exceptions were not suppressed in the exception configuration and the debugger was attached to an IIS worker process to debug native code.

Thinking that something might be wrong with how C++ exceptions were handled, I stuck a statement dereferencing a NULL pointer into the code:

*(char*) 0 = 0;

, which, much to my surprise, didn't break in the debugger and was silently handled by the catch(...) handler. Location breakpoints, however, worked just fine.

Slightly puzzled by this, I started a remote debugger and connected to the broken environment from another box. Remote debugger worked properly and I could see exceptions, as expected. I was also able to break on exceptions using windbg on the same machine, which pretty much narrowed it down to the Visual Studio itself.

After about an hour of troubleshooting, I noticed that data breakpoints were disabled, which put me on the right track. Shortly after I finally found the problem and when I did, I couldn't help but laugh out loud - I spent over an hour looking for something broken in the development environment and it turned out that even though I was debugging native code, another project, completely unrelated to the one I was debugging, was selected as a startup project within the solution. That project just happened to be a managed project, which, effectively disabled all C++ and Win32 exceptions, as well as data breakpoints. Go figure!

Comments:
Name:

Comment: