I have a DLL which calls SetUnhandledExceptionFilter() (SUEF) in order to produce a minidump when an unhandled exception occurs. I am investigating a problem whereby an application which uses this DLL crashes but no minidump is produced and the standard Windows dialog box is shown.
After a lot of investigation, I found out that the VC++ 2005 RTL is calling SUEF() after we are, thereby overriding us. This is being done from multiple places in the RTL file unhndld.cpp, for which no source code appears to be available. The function names are __CxxSetUnhandledExceptionFilter(), which is called automatically at startup, and __CxxRestoreUnhandledExceptionFilter(), which seems to be registered with atexit() or _onexit() to be called at application shutdown.
On the surface it might appear to be pretty reasonable and harmless to install these things at startup and on exit, since in-between a program can do whatever it likes, but in fact it can be a big problem because this is not just being done for EXEs, but for DLLs as well (at least those statically linked with the RTL), and the UEF is process-specific, not module-specific.
In the case I'm investigating, our DLL was calling SUEF(), and then dynamically loading another DLL built with beta 2 that is statically linked with the RTL. The newly-loaded DLL's copy of the RTL then installs itself as the UEF. I was able to work around this by moving our call to SUEF() to be just after the LoadLibrary() call to the newly-loaded DLL, which works but is pretty subtle to say the least.
It means that if you call any 3rd-party code which happens to load a DLL statically linked with the RTL, then you will lose your UEF. So if you really want to be sure you are the UEF, you have to keep on calling SUEF() on a regular basis.
Is there an elegant solution to this All I want to do is to find a way to reliably get a minidump anytime an unhanded Win32 exception occurs in an application linked with our DLL. That seems to be surprisingly difficult.
VC++ 2005 beta 2 RTL overriding my UnhandledExceptionFilter
Hot Topic
- help with MFC application
- using a vb6 dll in vc++?
- Unexplained stack\heap overflow
- Running a very simple Win32 app on a comp without VC++ 2005 Express
- How to get a dynamicly created control's dc
- How to find the C++ source lines given a crash address?
- Help with using DLLs
- HTMLHelp confusion
- Multithreading
- Question Regarding Automation
Visual C++
- problem with SDK header files
- Problem overloading and using ostream operator << for my own classes
- floating point vector optimization
- How to make a window moving handle (click and drag the handle to move the window)
- Windows Forms
- VC 6.0 Debug-Additional DLLs: equivalent in VC 2005?
- Checkbox problem
- How could i pass a structure as CmdLine parameter while using CreateProcess?
- App Icon for C++ project
- GDI+ : Drawing objects over TabControl
VC++ 2005 beta 2 RTL overriding my UnhandledExceptionFilter
BernhardR
UEF or other CRT handlers are kept on either per-process or per-thread bases. In case of UEF, it is process specific. Earlier in VS2005 we have considered moving all CRT handlers to per-module or per-thread bases, however decided to postpone for this release due to several reasons - low interest, impact of this breaking change, etc.
Anyway, to answer you question about elegant solution. As of right now, it is applications job to specify what to do on unhandled exception occured in the process. DLL should not be defining UEF and let application to handle UE. We may re-open this discussion in the next release, so feel free to open bug on lab.msdn.microsoft.com as a suggestion. Your report will go directly to our database of requests and will be considered among with others during the next feature planning phase.
Thanks,
Nikola
VC++