Какое исключение привело к сбою моего приложения при наличии стека вызовов с UnhandledExceptionFilter?

Я тестировал свое приложение, и оно вышло из строя. Я не отлаживал его, поэтому сработал отчет об ошибках Windows (я тестировал на виртуальной машине Windows XP, на которой не установлен VS, поэтому я думаю, что именно поэтому отладчик JIT не появился). Я запустил Visual Studio 2010 и удаленно подключился к проблемному процессу. Это стек вызовов, который я получаю из потока, который разбился:

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

Это код, который вызвал это, в:

class _Sentry_base
    {   // stores thread 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();
        }

Итак, что я хочу, так это выяснить, почему произошел этот сбой, если еще не слишком поздно, например, если это было нарушение прав доступа. Я думаю, что это возможно, потому что контекст исключения все еще находится в стеке, но я не знаю, как к нему добраться.

Вероятно, в WinDbg это было бы проще, но я боюсь, что если я остановлю сеанс отладки, процесс может умереть. Это довольно редкая ошибка, и ее нелегко воспроизвести.


person Pedro d'Aquino    schedule 07.04.2011    source источник


Ответы (2)


Если вы уже подключили VS, я бы сначала сохранил файл дампа (Отладка -> Сохранить дамп как). Тогда, возможно, вы могли бы открыть этот файл дампа в WinDbg и попытаться найти контекст исключений в памяти. См., например, http://blogs.msdn.com/b/slavao/archive/2005/01/30/363428.aspx, но все выглядит примерно так (взято из книги Advanced Windows Debugging):

s -d 0 L10000000/4 001003f (поиск сигнатуры контекста - 0001003f - в памяти)

затем, если что-то найдено, измените текущий контекст:

.cxr FOUND_ADDRESS

после этого вы сможете увидеть стек вызовов с k и связанными с ним командами.

person floyd73    schedule 11.04.2011

если вы подключитесь к процессу из WinDbg, вы можете использовать набор команд (.lastevent, .excr, !cppexr), чтобы выяснить, почему приложение разбилось. В Visual Studio вы должны увидеть исключение в окне вывода или попробовать те же команды в непосредственном окне.

person AC.    schedule 07.04.2011