Win32 Programming

Win32 Programming Lesson 25: Unhandled Exceptions Bet you’ve never encountered one of those, eh?

Where are we? • Covered exception handling in depth… • But there’s more! Yay! And an assignment, how lucky you are!

Applications don’t have to handle • What happens if the outermost exception handler returns EXCEPTION_CONTINUE_SEARCH? • Well, then you have an unhandled exception • Handled by the OS… • But you have one last chance to catch it before this… it’s a million to one shot, but it just might work!

SetUnhandledExceptionFilter • PTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter(PTOP_LEVEL_EXCEPTION_FILTER pTopLevelExceptionFilter); • Usually called during initialization • Function called declared like this: • LONG WINAPI TopLevelUnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo) • Note returns address of previously installed filter

Return Values • EXCEPTION_EXECUTE_HANDLER: Terminate, executing finally blocks • EXCEPTION_CONTINUE_EXECUTION: Continue at the instruction that raised the exception • EXCEPTION_CONTINUE_SEARCH: Really don’t handle the exception…

UnhandledExceptionFilter • Called automatically when we return EXCEPTION_CONTINUE_SEARCH • Turns things over to Windows Error Reporting (WER) eventually… • But first, it does the following in order

Steps • Allow write access to a resource (EXE and DLL) and continue • Notify the debugger of an unhandled exception • Notify your global filter function • Notify the debugger of an unhandled exception (again!) • Terminate the process

WER Linkage • When the exception is passed to Windows WER gets a call from an Advanced Local Procedure Call (ALPC) • Blocks all local thread execution • Passed to a dedicated service WerSvc… spawns WerFault.exe • This executable handled the functionality of reporting etc. • Configurable behavior via Registry

Just In Time Debugging • Nice, because we can debug without restarting our application and reproducing the fault in a debugger • Configured through the registry • Called CreateProcess (How? Anything we should think about?) • Aside: don’t have to wait for a blowup… can always call vsjitdebugger.exe –p PID

Vectored Exception Handling • SEH has one fundamental structural property… • PVOID AddVectoredExceptionHandler( ULONG bFirstInTheList, PVECTORED_EXCEPTION_HANDLER pfnHandler); • Called before SEH handling • Remove by ULONG RemoveVectoredExceptionHandler(PVOID Handler)

Vectored Continue Handler • Called when we’re continuing up *after* everything else • Can return EXCEPTION_CONTINUE_EXECUTION

C++ try and catch • Suddenly, we should think back about C++ SEH • That is, try/catch blocks • Internally implemented by __try and __except blocks… • Should use the C++ mechanism whenever possible, as it knows about the underlying language issues

Exceptions and the Debugger • Let’s look at the options…

Assignment • Construct an “error handling experimenters lab” that lets you combine these things together in a GUI and tells you what order things get processed in. • Output should show me how things get executed… there’s room for some *very* imaginative programming here

Win32 Programming