Значение шестнадцатеричного числа в диалоговом окне сбоя Windows

Время от времени (гм...) мой код дает сбой в какой-то системе; довольно часто мои пользователи присылают скриншоты диалогов сбоя Windows. Например, я недавно получил это:

Unhandled win32 exception @ 0x3a009598 in launcher2g.exe:
0xC00000005: Access violation writing location 0x00000000.

Мне ясно (из-за кода 0xc0000005, а также написанного сообщения об ошибке), что я следую нулевому указателю где-то в моем процессе launcher2g.exe. Что мне непонятно, так это значение числа «0x3a009598». Является ли это смещением кода в адресном пространстве процесса, где хранится инструкция ассемблера, вызвавшая проблему?

Предполагая, что 0x3a000000 — это позиция, в которой модуль launcher2g.exe был загружен в процесс, я использовал отладчик Visual Studio для проверки ассемблерного кода по адресу 0x3a009598, но, к сожалению, это было просто множество инструкций «int 3» (это была отладка). build, так что есть много отступов int 3).

Мне всегда было интересно, как максимально использовать эти числа @ 0x12345678 - было бы здорово, если бы кто-нибудь здесь мог пролить на это свет или поделиться некоторыми указателями для дальнейших объяснений.

ОБНОВЛЕНИЕ: Если кто-то найдет этот вопрос в будущем, вот очень интересное чтение, которое я нашел, которое объясняет, как понимать сообщения об ошибках, как я цитировал выше: Поиск информации о сбоях с помощью файла MAP.


person Frerich Raabe    schedule 07.07.2009    source источник


Ответы (1)


0x3a009598 будет адресом инструкции x86, вызвавшей сбой.

EXE обычно загружается по своему предпочтительному адресу загрузки — обычно 0x04000000 iirc. Так что это, вероятно, чертовски далеко от 0x3a009598. Вероятно, по этому адресу находится какая-то загружаемая процессом DLL.

Аварийные дампы обычно являются наиболее полезным способом отладки такого рода вещей, если вы можете заставить своих пользователей генерировать и отправлять их. Вы можете загрузить их с Visual Studio 2005 и выше и получить автоматическое разрешение символов системных DLL.

Затем файлы .map, созданные в процессе сборки, должны помочь вам определить нарушающую функцию — при условии, что вам удастся выяснить, внутри какого модуля exe/dll произошел сбой, и каков был его фактический адрес загрузки.

Пользователи XP могут использовать DrWatsn32 для создания и отправки аварийных дампов. В Vista и более поздних версиях служба отчетов об ошибках Windows записывает аварийные дампы в c:\users\\AppData\Local\Temp*.mdmp.

person Chris Becke    schedule 07.07.2009
comment
Да, по этому адресу находится DLL, и я знаю, какая (так случилось, что это DLL, которую я разработал, с которой связывается мое приложение). Один комментарий по поводу аварийных дампов в Vista: нужно ли их как-то включать? У меня было несколько сбоев, но файлы mdmp в %TEMP% не были видны. Спасибо за указатель на файлы .map, я посмотрю на это! - person Frerich Raabe; 08.07.2009
comment
Я думаю, что файлы mdmp могут появиться только в том случае, если пользователь выберет отправку отчета об ошибке в службу отчетов об ошибках Windows. По-видимому, есть какой-то способ, с помощью которого вы можете, если вы подпишете файлы приложений в цифровой форме с помощью надлежащего сертификата, фактически получите аварийные дампы от Microsoft, которые пользователи отправят через Сообщить об этой ошибке в MS, и посмотрите, есть ли какие-либо диалоговые окна с исправлениями, которые показывает ОС. Я не могу посоветовать, насколько прост и экономичен этот вариант. - person Chris Becke; 09.07.2009