Ситуация такая: прога написана на C++ в MS VS. Иногда вылетает окно о GPF, запись в системном журнале есть. В проге делается SetUnhandledExceptionFilter, где в обработчике должен бы создаваться минидамп:
ksd>Ситуация такая: прога написана на C++ в MS VS. Иногда вылетает окно о GPF, запись в системном журнале есть. В проге делается SetUnhandledExceptionFilter, где в обработчике должен бы создаваться минидамп: ksd><...> ksd>однако что то никак дампов не создается, т.е. не попадает в SEHandler: что это может быть? где бы подробнее почитать?
ksd>смотрел исходники CrashRpt, там тоже используется SetUnhandledExceptionFilter помимо прочего.
Из личного опыта: некоторые DLL, даже предустановленные в системе, сами вызывают SetUnhandledExceptionFilter(...) при своей загрузке. А вызов установленного ранее обработчика (который пишет дампы) в них просто не предусмотрен.
Плюс, если посмотреть SetUnhandledExceptionFilter по исходникам Win2k, то мы увидим обычный try-except вызов в kernel32-враппере нити (BaseThreadStart -> UnhandledExceptionFilter). Из этого следует, что нативные нити им не покрываются. Ну и из предположений:
инициализация глобальных переменных, DllMain'ы статически слинкованных библиотек и весь код до вызова SetUnhandledExceptionFilter(...)
не проверял, но есть сомнения: ловит ли UnhandledExceptionFilter, например, инициализаторы TLS (вызывается ли этот код внутри kernel32!BaseThreadStart)
Re: почему может не ловить краши UnhandledExceptionFilter?
Здравствуйте, ksd, Вы писали:
ksd>однако что то никак дампов не создается, т.е. не попадает в SEHandler: что это может быть? где бы подробнее почитать?
SetUnhandledExceptionFilter ловит не все.
Полезно еще, к примеру, поставить обработчик _set_invalid_parameter_handler и другие.
Вот список (возможно, не полный):
signal
_set_invalid_parameter_handler
_set_purecall_handler
set_unexpected
set_terminate
Причем set_unexpected и set_terminate нужно делать отдельно для каждого своего потока.
----
Ну а еще может не работать потому, что кто-то другой сделал SetUnhandledExceptionFilter/AddVectoredExceptionHandler.
Или "замаскировал" ошибку внутри __try/__except.
Re: почему может не ловить краши UnhandledExceptionFilter?
UnhandledExceptionFilter не вызывается в случае проблем со стеком, а так же в случае проблем с хипом если установлен HeapSetInformation(...HeapEnableTerminationOnCorruption...). Причем я видел как ентот HeapEnableTerminationOnCorruption самовольно устанавливала какая-то версия msxml.
Вообще этот фильтр — штука ненадежная, и еще — если им и пользоваться — то максимально "тонкий" код в нем писать, а сдампливание вынести например в другой процесс.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ksd, Вы писали:
ksd>однако что то никак дампов не создается, т.е. не попадает в SEHandler: что это может быть? где бы подробнее почитать?
Здравствуйте, ksd, Вы писали:
ksd>однако что то никак дампов не создается, т.е. не попадает в SEHandler: что это может быть? где бы подробнее почитать?
MiniDumpWriteDump should be called from a separate process if at all possible, rather than from within the target process being dumped. This is especially true when the target process is already not stable. For example, if it just crashed. A loader deadlock is one of many potential side effects of calling MiniDumpWriteDump from within the target process.
Re: почему может не ловить краши UnhandledExceptionFilter?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, ksd, Вы писали:
_NN>Если хотите дамп, лучшим будет сконфигурировать Windows Error Reporting для этого процесса. _NN>Windows сам соберёт дамп как надо.
Ну так а что ты хотел собстенно
а) нет защиты от рекурсии. При любой фигне твоя функция впадет в рекурсию и умрет на SO
б) если MiniDumpWriteDump ничего не сделал ты возвращаешь EXCEPTION_CONTINUE_SEARCH, поиск идет дальше и логично уходит в систему
в) какая-то дллина установила свой обработчик.
потом ты поставил свой.
а потом она выгрузилась и восстановила системный
а потом крэш