What was the exception that crashed my app, given a call stack with UnhandledExceptionFilter?

I was testing my app, and it crashed. I wasn't debugging it, so Windows Error Reporting kicked in (I was testing on a Windows XP virtual machine which doesn't have VS installed, so I think that's why the JIT debugger didn't show up). I fired up Visual Studio 2010 and remotely attached to the offending process. This is the call stack I get from the thread that crashed:

ntdll.dll!_KiFastSystemCallRet@0()  
ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0xc bytes   
kernel32.dll!_WaitForMultipleObjectsEx@20()  - 0x48 bytes   
kernel32.dll!_WaitForMultipleObjects@16()  + 0x18 bytes 
faultrep.dll!StartDWException()  + 0x5df bytes  
faultrep.dll!ReportFault()  + 0x533 bytes   
kernel32.dll!_UnhandledExceptionFilter@4()  + 0x55c bytes   
kernel32.dll!_BaseThreadStart@8()  + 0x2f45e bytes  
kernel32.dll!__except_handler3()  + 0x61 bytes  
ntdll.dll!ExecuteHandler2@20()  + 0x26 bytes    
ntdll.dll!ExecuteHandler@20()  + 0x24 bytes 
ntdll.dll!_KiUserExceptionDispatcher@8()  + 0xe bytes   
myDLL.dll!std::basic_ostream<char,std::char_traits<char> >::_Sentry_base::_Sentry_base(std::basic_ostream<char,std::char_traits<char> > & _Ostr)  Line 93 + 0x2a bytes  C++
myDLL.dll!std::basic_ostream<char,std::char_traits<char> >::sentry::sentry(std::basic_ostream<char,std::char_traits<char> > & _Ostr)  Line 114 + 0x4e bytes C++
myDLL.dll!std::basic_ostream<char,std::char_traits<char> >::write(const char * _Str, __int64 _Count)  Line 553 + 0xc bytes  C++
//... more stuff from my app

This is the code that caused it, in :

class _Sentry_base
    {   // stores thr开发者_运维技巧ead lock and reference to output stream
public:
    __CLR_OR_THIS_CALL _Sentry_base(_Myt& _Ostr)
        : _Myostr(_Ostr)
        {   // lock the stream buffer, if there
        if (_Myostr.rdbuf() != 0)
            // ***VC++ says this next line was the return address***
            _Myostr.rdbuf()->_Lock();
        }

So what I want is find out why this crash happened, if it isn't too late already -- for instance, if it was an access violation. I think it is possible because the exception context is still on the stack, but I don't know how to get to it.

This would probably be easier in WinDbg, but I'm afraid that if I stop the debugging session, the process may die. This is a pretty rare bug and isn't easily reproducible.

---

If you already attached VS I would first save a dump file (Debug -> Save Dump As). Then maybe you could open this dump file in WinDbg and try to look for the exceptions context in memory. See for example http://blogs.msdn.com/b/slavao/archive/2005/01/30/363428.aspx but it goes more or less like this (taken from Advanced Windows Debugging book):

s -d 0 L10000000/4 001003f (search for the context signature - 0001003f - in memory )

then if something found change the current context:

.cxr FOUND_ADDRESS

you should then be able to see the callstack with the k and related commands.

---

if you attach to the process from WinDbg you could use bunch of commands (.lastevent, .excr, !cppexr) to figure out why the app crashed. In Visual Studio you should see the exception in output window or try the same commands in immediate window.