Sign in to follow this  

Reporting Uncaught Exceptions (SEH)

This topic is 4858 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I'd say you're on the wrong track. Step back, do some reading and try again :)


I'd say he's on the right track indeed.
The reason for having the logfile is probably so some user that has the game crash can send him the logfile.

Getting SEH to work with the intrinsics shouldn't be a problem at all, as long as you make sure you actually tear down your exceptionhandler when you're done with it.

Anyway, SetUnhandledExceptionFilter() is the way to go, as I and others already told you. It's not global, like someone said, it's per-process. UnhandledExceptionFilter() should work in all cases, no matter what the startup-code. If someone's written exceptionhandlers for every single exception, and isn't reporting them back to you (in their CRTStartup that is) they should have their hands cut off so they can't code any more.
And i don't think i know of a CRT that does this either...

Share this post


Link to post
Share on other sites
Quote:
Original post by tok_junior
It's not global, like someone said, it's per-process.

I wrote that. I meant it in the sense that it's global in the process (like a global variable) and not global to the system.

Quote:
Original post by tok_junior
UnhandledExceptionFilter() should work in all cases, no matter what the startup-code. If someone's written exceptionhandlers for every single exception, and isn't reporting them back to you (in their CRTStartup that is) they should have their hands cut off so they can't code any more. And i don't think i know of a CRT that does this either...


Just because you don't know of it, doesn't mean it's the case. I know of an example where the UnhandledExceptionFilter does not work in all cases otherwise I wouldn't have wrote what I wrote. If it's something that you're truly interested in send me an email and I'll provide you with the details.

Share this post


Link to post
Share on other sites
Actually, i've spent quite a lot of time reversing the entire exceptionhandling-system under Windows 2000/XP, and I think i've got most of the details figured out.
The only reason for UnhandledExceptionFilter() not to get called is if there exists a handler that handles every single exception. Or if it doesn't handle it, atleast claims it's handled it.
This is vile coding indeed, and what i wrote in the last post still stands: people who does this should have their hands cut off. Ignorant bastards shouldn't be allowed to release trash like that, and people who knows it for what it is, and still use it, well... They can suit themselves when things aren't working the way they're supposed to.
The KiUserException*-functions are still called, even if you don't have a single handler registered in the TIB, and it's the job of these to call UnhandledExceptionFilter() if it reaches the end of the handler-chain.

Share this post


Link to post
Share on other sites
Sounds like someone knows how to use SoftIce. :)

The Robbins book is second-to-none and available very cheap on Amazon. I posted a link to get it for $5 in The Lounge awhile back but got like two responses, seems like everyone would rather BS about their CSingleton class...

Share this post


Link to post
Share on other sites
Most of the stuff i do at work relies heavily on kernelmode code, and the only things im doing with the computer on my sparetime is coding and reversing. So yes, i'd say i know sice pretty well ;)
People here are usually not interested in anything that doesn't involve drawing cool things on the screen, preferably stuff that involves heightmaps and bumpmapping it seems. And they're not likely to go anywhere near systemlevel programming ;)

Share this post


Link to post
Share on other sites

This topic is 4858 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this