Reporting Uncaught Exceptions (SEH)
Author
As the first step in actually coding my engine, I thought a good thing to do would be to log all fatal exceptions to a log file before letting the application crash. Digging through the PSDK docs, I found a couple functions that seemed to do what I want: SetUnhandledExceptionFilter, and Add/RemoveVectoredExceptionHandler. For C++ exceptions, I'm using set_terminate and set_unexpected to log those exceptions before killing the app.
The problem is, I'm not completely sure what I'm doing with SEH is right. Do I need to use both SetUnhandledExceptionFilter() and vectored exceptions? Is this going to trap every possible exception (BSOD notwithstanding)?
Great book which talks about it is "Debugging Apllications for Microsoft .NET and Microsoft Windows" by John Robbins. ISBN: 0-7356-1536-5.
It's not only for .NET, it covers Win32 in general. It will give you all the info, including source code and extra lib to make your job ALLOT easier.
It's not only for .NET, it covers Win32 in general. It will give you all the info, including source code and extra lib to make your job ALLOT easier.
Author
I haven't looked at the book yet, but I'm not sure I want to go to anything close to a debugger, just something that will let me try and log the error before dying. Plus, this is in unmanaged C++, so I'm not sure how helpful a .NET book would be; I'm sure the concepts are just as valid though, so I'll see if it's worth buying.
You didn't read my responce very well. I said that is not only for .NET, but covers Win32. Even as simple task as logging errors it will show how and EVEN provides code to do it, source and lib. Again, read the post, it covers C/C++.
You know: give the man fish and...
You know: give the man fish and...
The MSDN contains everything you need to know about Structured Expection Handling (a.k.a SEH). It should be noted that SEH is different to C++ exceptions
Vectored exceptionhandling is only supported in WinXP and later, and for what you're doing there's absolutely no need for it. VEH is only working on a per-thread basis, while UnhandledExceptionFilter() is used on a per-process basis.
So just use SetUnhandledExceptionFilter() for the logging.
So just use SetUnhandledExceptionFilter() for the logging.
Quote:Original post by Bugdude
The MSDN contains everything you need to know about Structured Expection Handling (a.k.a SEH). It should be noted that SEH is different to C++ exceptions
Not really. SEH is still what's actually used through the C++ exceptionhandling intrinsics.
Edit: Under win32 that is, ofcourse :)
Author
Well, it may be implemented that way, but getting the two to cooperate successfully is a huge pain. I was browsing through MSDN earlier (yes, I was bored), and I came across a function called SetErrorMode. Do I need to call this function to set my application to catch certain exceptions?
SetErrorMode is a hold over from the early days of Windows, but it's still useful to surpress the system error popup that results from an exception.
SetUnhandledExceptionFilter installs a global exception handler function. There is an excellent MSJ article by Matt Pietrek from 1997 about using this API to log exceptions (Under the Hood, MSJ April 1997). There are a couple of follow up articles that are useful too. Search for additional information under "imagehelp.dll" and "dbghelp.dll".
SEH is a Windows only approach. The classic starting point for grokking the implementation is another Pietrek article: A Crash Course on theDepths of Win32 Structured Exception Handling .... That may be more info than you need.
There is a follow up article that addresses vectored exception handling. I don't have the url for that.
SEH is useful for dealing with expected exceptions moreso than unexpected exceptions. In general, SetUnhandledExceptionFilter will trap every exception, but it won't do much good with BSODs. No user mode exception handler will (assuming your target OS is NT/2k/XP - I don't imagine that there is a lot of work done targeting W98 these days - but BSODs are rare in user mode on W2K/XP anyway so ... ). There are situations where SetUnhandledExceptionFilter won't catch some exceptions, but this depends on the startup code used by your compiler. Without going into the nitty gritties, if SetUnhandledExceptionFilter doesn't trap it, than the startup code does and you shouldn't have to worry about it.
The Robbin's book - any edition - is an excellent resource on the subject. It sounds like the "Crash Handler" module that he details will provide the functionality that you seek.
SetUnhandledExceptionFilter installs a global exception handler function. There is an excellent MSJ article by Matt Pietrek from 1997 about using this API to log exceptions (Under the Hood, MSJ April 1997). There are a couple of follow up articles that are useful too. Search for additional information under "imagehelp.dll" and "dbghelp.dll".
SEH is a Windows only approach. The classic starting point for grokking the implementation is another Pietrek article: A Crash Course on theDepths of Win32 Structured Exception Handling .... That may be more info than you need.
There is a follow up article that addresses vectored exception handling. I don't have the url for that.
SEH is useful for dealing with expected exceptions moreso than unexpected exceptions. In general, SetUnhandledExceptionFilter will trap every exception, but it won't do much good with BSODs. No user mode exception handler will (assuming your target OS is NT/2k/XP - I don't imagine that there is a lot of work done targeting W98 these days - but BSODs are rare in user mode on W2K/XP anyway so ... ). There are situations where SetUnhandledExceptionFilter won't catch some exceptions, but this depends on the startup code used by your compiler. Without going into the nitty gritties, if SetUnhandledExceptionFilter doesn't trap it, than the startup code does and you shouldn't have to worry about it.
The Robbin's book - any edition - is an excellent resource on the subject. It sounds like the "Crash Handler" module that he details will provide the functionality that you seek.
I'd say you're on the wrong track. Step back, do some reading and try again :)
Setup dr watson to create a dump file, that way you'll get a .dmp file with all data about the crash that you can load into the debugger and get a stack trace and possibly a memory dump at the time of the crash.
http://www.codeproject.com/Purgatory/automemorydump.asp
http://www.codeproject.com/debug/moomoo.asp
Setup dr watson to create a dump file, that way you'll get a .dmp file with all data about the crash that you can load into the debugger and get a stack trace and possibly a memory dump at the time of the crash.
http://www.codeproject.com/Purgatory/automemorydump.asp
http://www.codeproject.com/debug/moomoo.asp
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
