I have a weird issue with VS.2005 Pro. JIT debugging seems broken. An executable crashes, I get the OK/CANCEL and click CANCEL. I then get the choice of a debugger and select a new instance of VS. The new instance starts, I see it loading and preparing like it did with VS.2003. And then instead of displaying the dialog box about the exception that occured and offering me to "break", the output window simply shows the application exited. I get no opportunity to break on the exception which occured.
What could be wrong

VS.2005 native C++ app : jit debugger takes hand, start loading, then app exits - no break on the exception
MD2000
By the way, what registry keys should hold what settings for the JIT debugging to take place correctly with VS.2005 It shouldn't be that badly configured on my system since at least VS.2005 starts on JIT debugging sessions, but I wonder if something might be wrong anyway there. This machine, as well as the other 2 I could test and reproduce on, have had VS.2003 installed before, as well as Borland C++ Builder 6. Maybe something to check in the registry (VS.2005 would be started with a wrong set of switches )
arke
Does this only affect one project, or does it also repro for a simple test case
robcol
I can think of lots of possible explanations for how this could happen in a complex application. But I am bewildered by how this could happen for a simple "hello world" sized application.
What OS are you running
Do you have any 'strange' libraries loaded into the debuggee process Check the output window to see what loaded.
What happens if you start the application under the debugger Does the debugger then stop on the exception
rzeineh
The exception configuration shouldn't be the problem -- your exception is unhandled, so the debugger will always break on it.
I agree, it should. It just doesn't when the debugger is started as JIT debugger by the system. If I run the very same executable, not even relinked right from the IDE, I have absolutely no problems : the debugger takes hand on exceptions without any issue.
In another project, which uses dbghelp.dll to emit .dmp files in cases of unexpected exceptions at runtime (in the field), when trying to open these .dmp files I see the very same problem than when JIT debugging. The IDE opens the .dmp, I click the run button which typically triggers the exception dialog. And here : nothing happens. It looks exactly on screen as if the debugged exe had started, ran, and normally exited. Not even mention of an exception in the output window. What's more, on another XP SP2 PC where I tested it this morning (because that hardware is MUCH slower), I can clearly see the debug session starts setting itsefl up on screen. I briefly see the UI changing to the typical debug session, with stack trace window filling up, and so on, and then woops, it turns back to the no-debug in-progress view which you get after an application has finished executing.
OS on the machine I first saw this : XP SP2 1GB ram. Since them I reproduced on a Server 2003 SP1 and on Windows 200 SP4 (the slower machine I mentionned).
No strange libraries loaded : nothing different than usual at least.
All these projects are pure native C++ projects.
The only thing I just thought about minutes ago (which I should experiment a bit), is that those projects are all compiled with /EHa instead of /EHsc.
With VS.2003 that had no side-impact on the behaviour of the JIT debugger though.
Samuel.Suarez
I can reproduce very easily.
Something more : when the debugger loads and seems not to break on the exception, I am left with an opened .exe solution where I can see the application has exited (in the output window). If I go to Debug - Exceptions menu I see that C++ exception and system exceptions are not set to break on throw. That is a constant, I have not found a way to force the IDE to be configured by default as to break on exceptions. When I create a new solution/project, it is always off by default until I change it. Since the just-in-time debugging basically auto-creates a solution when lauching, couldn't my problem be that these exceptions are not set to be catched by default
This issue looks very strange, especially since I don't see reports by many other people about this same thing.
iturner100
I really hate to say so but a full product (VS.2005) uninstall followed by a full re-install on the same machine fixed it. Weird, but fixed.