1

A variety of other questions hint that it is possible to continue debugging past an "Exception Unhandled" popup like this:

Exception Unhandled popup

This is the popup from Visual Studio 2019, but VS 2015 gives similar behaviour. In both cases, for all combos of Win32/x64 and Debug/Release I have tried, the debugger refuses to go past the point that throws the unhandled exception - the same popup pops up again on each attempt to continue. I would like to push past this point and continue into the code I have set up via SetUnhandledExceptionFilter(). Is that possible?

This strongly upvoted answer suggests that it might be, via an option under Tools -> Options then Debugging -> General regarding unwinding the stack... but a comment on the answer suggests the option may have disappeared from VS2017. I found the option in VS 2015, but it does not have the desired effect. Is the accepted answer to that question therefore correct despite fewer votes - that continuing to debug past an unhandled exception is not possible by design?

omatai
  • 3,448
  • 5
  • 47
  • 74
  • Are you looking to have your program ignore the exception and keep going (difficult in general), or something you can do in the debugger to fix/ignore the problem and keep going? – 1201ProgramAlarm Aug 14 '20 at 00:47
  • 1
    I get what you mean. You want to debug your unhandled exception filter. This actually feels like a VS bug. Under 'Exception settings' there is a box labelled 'Break on this exception' but unchecking it seems to have no effect. – Paul Sanders Aug 14 '20 at 01:05
  • As I said, I want to push past the exception because I want to test the unhandled exception handling. I have inherited this code; I don't understand it. Being able to step through it in the debugger would be helpful if it is possible. – omatai Aug 14 '20 at 01:05
  • So regarding the first three comments: I want to DELIBERATELY cause an unhandled exception and debug what follows. Because in the real world, unhandled exception handling follows. In Visual Studio, it seems I meet a stone wall :-( – omatai Aug 14 '20 at 01:08
  • "_I want to test the unhandled exception handling_...", It's unhandled what exactly do you want to test? – Enosh Cohen Aug 14 '20 at 01:14
  • With the debugger running, open the "Exception Settings" tab and uncheck the exception for integer division by zero (under Win32 exceptions). That should allow your exception handler first crack and handling the exception. If it does not, the debugger will handle it. – 1201ProgramAlarm Aug 14 '20 at 01:18
  • @1201ProgramAlarm - see the upvoted comment - it doesn't work. – omatai Aug 14 '20 at 01:37
  • @EnoshCohen - see the upvoted comment and take 2mins to read docs for SetUnhandledExceptionFilter – omatai Aug 14 '20 at 01:38
  • 1
    @omatai If you have the exception *un*checked under Exception Settings and it still breaks into the debugger then that's a [second chance exception](https://stackoverflow.com/questions/4070040/first-chance-vs-second-chance-exception), meaning *un*handled. If you believe the code should have caught it, then show the exception context and the code. – dxiv Aug 14 '20 at 03:42
  • Show the code where you set up your exception handler, and the exception handler itself. Perhaps the problem lies there. Including a bare-bones example to recreate the problem would be a big help. – 1201ProgramAlarm Aug 14 '20 at 04:01
  • Ah - the problem is that the exception handling I believed was taking place was not the exception handling that was actually taking place... So the comment from Paul Sanders that I upvoted, and the answer to the question I referenced stating it was not possible by design, both led me astray :-( – omatai Aug 14 '20 at 04:11

1 Answers1

1

Yes - it's possible. If you get to that pop up repeatedly, and the exception settings are such that the exception is NOT intercepted by the debugger (and therefore passed to the application's own exception handling), then it could be that your "unhandled" exception handling has already run, or does not exist in the form you think it does. Double-check where you have set breakpoints and make sure they are ones that stand to be hit.

Note also that if you have something like this to catch SEH exceptions (such as integer divide by zero):

__try
{
    // set up and run the application
}
__except( RecordUnhandledException( GetExceptionInfo() ) )
{
}

... then the debugger can hide RecordUnhandledException() from you. That is, if you set a breakpoint on the line where the exception is (deliberately) thrown, and try to step into it, the debugger may step straight back to that point by executing the handling code in a single step that makes it invisible to you. However, if it produces other output, you should be able to see that output. If not, it may take an explicit breakpoint within RecordUnhandledException() to reveal that it exists and step through its logic.

omatai
  • 3,448
  • 5
  • 47
  • 74
  • I am glad you have got your solution and thanks for your sharing, I would appreciate it if you mark them as answer and this will be beneficial to other community. – Barrnet Chou Aug 14 '20 at 05:09
  • I cannot mark as an answer yet - it's my question, my answer - I need to wait. And I've probably only described the tip of a larger iceberg here... – omatai Aug 14 '20 at 05:12