Вопрос

У меня есть процесс, который отлично обрабатывает исключения.Он вызывает:

_set_se_translator(exception_trans_func); 
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit

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

За исключением одного сайта клиента.Когда они завершают процесс, возникает исключение, которое по какой-то причине не маршрутизируется через эти вызовы, и они получают ошибку:

Инструкция по адресу «0x101ba9df» обращается к памяти по адресу «0x00000004».Память не могла быть «прочитана».Нажмите «ОК», чтобы прекратить действие...».

Ссылка на память x000000004 выглядит так, будто это, вероятно, нулевой указатель.И глядя на этот адрес появляется быть деструктором глобального объекта STL (вероятно, в вызове initterm CRT, где очищаются глобальные значения).

Однако сейчас я как бы застрял, так как не могу получить диагностический дамп и стек вызовов и точно увидеть, что происходит.Так....

Почему исключение не перенаправляется через вышеуказанные обработчики, а вместо этого отображается пользователю?

Есть ли способ скрыть этот диалог (поскольку в этот момент никакого вреда не будет)?

И есть ли способ отследить рутовую ошибку?

Спасибо за любые идеи.

Это было полезно?

Решение

Какую операционную систему они используют?

Я предполагаю, что вы устанавливаете режим ошибки, используя что-то вроде

::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);

чтобы убедиться, что Windows не выполняет собственную обработку ошибок?

Другие советы

Похоже, что CRT поместил блок try/catch SEH (не могу написать его правильно, срабатывает Markdown) вокруг некоторого фрагмента кода и перехватывает исключение для отображения сообщения, так что вы никогда не вызовете необработанный Путь к коду исключения.Возможно, вам придется немного взломать CRT, чтобы понять, что происходит.

Возможно, код STL выполняется во время уничтожения глобальных переменных во время завершения работы программы и, возможно (в зависимости от используемой вами версии STL) некоторые глобальные переменные, которые ему необходимы, уже уничтожены.

Я видел это с STL VS2008.Существуют некоторые объекты блокировки STL, которые создаются на уровне статических файлов во время запуска.

Используете ли вы STL в своих функциях обработчика ошибок?Возможно, один из них срабатывает поздно при завершении работы программы и вызывает проблему.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top