Сбой программы Visual C ++, но файл дампа не создан. Зачем?

У меня очень странная ситуация. Я использую серверную программу IOCP, запрограммированную Visual Studio 2010 на C ++.

Он использует «minidump», поэтому, когда есть логическая ошибка, такая как неправильное использование указателя, программа аварийно завершает работу с файлом дампа, поэтому я могу узнать, где находится точка сбоя в кодах.

Иногда (очень редко) происходит сбой программы и отсутствуют файлы дампа.

Какая ситуация делаетSetUnhandledExceptionFilter() не работает? Кто-нибудь знает эту проблему? Я не могу понять.

 DumbCoder20 мая 2012 г., 11:35

Ответы на вопрос(1)

конечно, вы не знаете, потому что у вас нет минидампа для просмотра. Вы должны сделать абсолютный минимум, когда срабатывает обратный вызов SetUnhandledExceptionFilter. Процесс находится в опасном состоянии. Оно сломалось. Замки можно держать, куча замков особенно хлопотна. Вы не можете ожидать, что MiniDumpWriteDump () будет успешным.

То, что вам нужно, это небольшой процесс защиты, который ожидает именованного события. Запустите его как можно раньше в вашей функции main () и передайте ему свой идентификатор процесса. Процесс защиты ожидает и этого события, и вашего дескриптора процесса. В вашем исключении обратного вызова, просто сигнализировать о событии и немедленно спать в течение длительного времени. Это пробуждает защитный процесс, вызывает MiniDumpWriteDump () и все остальное, что необходимо, чтобы сообщить о сбое. И убивает вашу основную программу.

 23 окт. 2013 г., 20:41
Спасибо за ответ. Все еще не совсем уверен здесь: если процесс настолько поврежден, чтоCreateFile дает сбой (поправьте меня, но может ли он потерпеть неудачу, если память ядра не повреждена?), то вы также можете утверждать, чтоSetEvent будут. То же самое касаетсяHeapAlloc в основном, если это не сработает для OOM. Я бы предположил, что MDWD работает на «предварительно выделенном» статические данные - это также объясняет, почему они не являются поточно-ориентированными. На менее техническом примечании, у вас был мини-дамп, сгенерированный вне контекста, который, вероятно, не имел бы внутрипроцессное решение?
 23 окт. 2013 г., 20:18
Я не понимаю, какMiniDumpWriteDump больше шансов на успех при запуске из другого процесса. Если замки удерживаются, то эти замки удерживаются. Не имеет значения, какой процесс пытается получить доступ к заблокированному ресурсу. Плюс, так какMiniDumpWriteDump не потокобезопасен, вы обречены в любом случае. Если вы не можете синхронизировать все потоки (чего вы не можете, так как ваша программа находится в неопределенном состоянии), гарантии успеха нет. То, что вы говорите, звучит правдоподобно, но не дает обоснования того, почему у процесса защиты будет больше шансов на успех.
 23 окт. 2013 г., 20:54
Не уверен, что яhave чтобы убедить вас в чем-то, звучит как большая работа. Пожалуйста, нажмите кнопку Задать вопрос.
 23 окт. 2013 г., 21:11
Конечно, вы неhave убедить меня. Но так как я поставил под сомнение точность предложенного вами ответа, было бы глупо, если бы вы не смогли. Я искренне заинтересован.
 23 окт. 2013 г., 20:28
Безопасность потоков не имеет значения, у вас есть только один поток, вызывающий MiniDumpWriteDump (). Если процесс настолько поврежден, что базовые вызовы, такие как CreateFile () и HeapAlloc (), которые необходимы MDWD для выполнения своей работы, могут потерпеть неудачу, несомненно, вызывает беспокойство. Это своего рода фильтр, если вы сделаете это в процессе, то вы никогда не увидите действительно плохих сбоев, которые невозможно отладить. Хорошая вещь, возможно.

Ваш ответ на вопрос