How can a Windows application handle segmentation faults? By 'handle' I mean intercept them and perhaps output a descriptive message. Also, the ability to recover from them would be nice too, but I assume that is too complicated.
+4
A:
Let them crash and let the Windows Error Reporting handle it - under Vista+, you should also consider registering with Restart Manager, so that you have a chance to save out the user's work and restart the application (like what Word/Excel/etc.. does)
Paul Betts
2010-01-02 20:59:41
How does one register with this Restart Manager?
George Edison
2010-01-02 21:05:17
@George, it's extremely easy, check out http://msdn.microsoft.com/en-us/library/aa373347(VS.85).aspx
Paul Betts
2010-01-02 21:42:43
It IS easy! Thanks.
George Edison
2010-01-02 21:53:21
+1
A:
Use SEH for early exception handling, and use SetUnhandledExceptionFilter to show a descriptive message.
whunmr
2010-01-02 21:04:02
Do the __try and __except blocks work with other Windows compilers like mingw32? (Not just vc++)
George Edison
2010-01-02 21:27:56
You can go down this route (though I'd encourage you to check out what WER can do for you, you *can* register to get the reports / provide problem links!) - remember that your app will be in a very hosed state in the filter, you will be pretty limited as to what you can safely do ; anything involving new/delete is out for example.
Paul Betts
2010-01-02 21:45:57
After learned what WER is, it's really convenient to handle application crash. I also recommend WER now. But when tried the sample of WER is not support Windows XP.
whunmr
2010-01-02 22:25:58
Check out libSEH for (MINGW32, CYGWIN) http://www.programmingunlimited.net/siteexec/content.cgi?page=libseh and http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh
whunmr
2010-01-02 22:31:32
A:
What you want to do here depends on what sort of faults you are concerned with. If you have sloppy code that is prone to more or less random General Protection Violations, then @Paul Betts answer is what you need.
If you have code that has a good reason to deference bad pointers, and you want to recover, start from @whunmr's suggestion about SEH. You can handle and indeed recover, if you have clear enough control of your code to know exactly what state it is in at the point of the fault and how to go about recovering.
bmargulies
2010-01-02 21:19:02
I hope my code isn't sloppy :) Most of the faults in my app come from the embeded python interpreter. Certain scripts seem to cause problems.
George Edison
2010-01-02 21:23:52
If you throw away and recreate the interpreter, and if that process does not leak, then you're good to go.
bmargulies
2010-01-02 22:14:13
+1
A:
If you add the /EHa compiler argument then try {} catch(...) will catch all exceptions for you, including SEH exceptions.
You can also use __try {} __except {} which gives you more flexibility on what to do when an exception is caught. putting an __try {} __except {} on your entire main() function is somewhat equivalent to using SetUnhandeledExceptionFilter().
That being said, you should also use the proper terminology. "seg-fault" is a UNIX term. there are no segmentation faults on windows. On windows they are called "Access Violation exceopnts"
shoosh
2010-01-02 22:13:03
One warning: enabling /EHa is a recipe for introducing security vulnerabililities in your application. The problem is that there are exceptions that are thrown by the operating system (like guard page exceptions) which can correctly be filtered if you use the __except filter but if you use /EHa and try {} catch() you won't be able to determine if it's appropriate to let the OS handle the exception. Structured exceptions are extremely difficult to get right without introducing security defects, IMHO Paul Betts answer is right - let the OS handle the error.
Larry Osterman
2010-01-02 23:21:31
I thought I had explained the issue above. Masking exceptions like guard page exceptions or random memory access errors can introduce security holes (for instance if you catch memory access errors, an attacker can use this to defeat platform protections like ASLR - there was at least one recent MSFT security bulletin that was caused by this issue).
Larry Osterman
2010-01-04 06:04:20