Как мне диагностировать этот сбой? - PullRequest
Новая
       22

Как мне диагностировать этот сбой?

0 голосов
/ 14 февраля 2012

Файл карты выглядит следующим образом: 

0002:000442e4 00000118H .idata$2                DATA   
0002:000443fc 00000014H .idata$3                DATA   
0002:00044410 00000b7cH .idata$4                DATA   
0002:00044f8c 0000512eH .idata$6                DATA   
0002:0004a0ba 00000000H .edata                  DATA

Информация о сбое выглядит следующим образом: 

Application Error : The instruction at "0x00458ae1" referenced memory at "0x00000074". The memory could not be "read".

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

Я не совсем уверен, хотя, потому что я прочитал некоторые статьи, подобные этой: Underстатья Hood , кажется, указывает, что это область имен импортируемых методов

Данные, которые библиотека импорта предоставляет для импортированного API, хранятся в нескольких разделах, имена которых начинаются с .idata (например, .idata $ 4, .idata $ 5 и .idata $ 6).Раздел .idata $ 5 содержит один DWORD, который при загрузке исполняемого файла содержит адрес импортированной функции.Раздел .idata $ 6 (если имеется) содержит имя импортируемой функции.При загрузке исполняемого файла в память загрузчик Win32 использует эту строку для эффективного вызова GetProcAddress для импортированной функции.

Без обратного следования стека я как бы застрял.Я смотрю на эту аварию неправильно?

1 Ответ

2 голосов
/ 15 февраля 2012

Забудьте файлы MAP, лучше используйте файлы PDB. Для этого включите опцию компоновщика / DEBUG - да, даже для сборок Release. / DEBUG - опция компоновщика, _DEBUG - опция компилятора. Только _DEBUG контролирует код и любую условную компиляцию, которую исходники / заголовки выставили против этого.

В отладочных сборках отключены оптимизации, включен макрос _DEBUG. В сборках релизов включены оптимизации, макрос _DEBUG отключен. / DEBUG просто поместит отладочную информацию в EXE / DLL и не повлияет на что-либо еще.

Возвращаясь к проблеме, когда происходит сбой. НЕ закрывайте приложение, когда WER (Windows Error Reporting) сообщает о сбое. Вместо этого держите его там, перейдите в диспетчер задач, перейдите на вкладку Процесс , выберите этот сбой / сбой и нажмите « Создать файл дампа ». Файл дампа (полный дамп) будет создан в некоторой локальной папке (путь будет показан менеджером задач). Теперь вы можете закрыть сбойное приложение (окно WER).

Теперь скопируйте этот файл .DMP в какое-то безопасное место, предпочтительно в папку, в которой находится исходная папка выпуска. Откройте его в Visual Studio или WinDbg. На VS, просто нажмите F11 / F10, и вам будет показан стек вызовов. Если запущено несколько потоков (в вашем аварийном приложении), запустите представление «Потоки» и увидите единственный приостановленный поток, дважды щелкните его, и вы найдете место сбоя.

Вы должны иметь правильные PDB вместе со всеми двоичными файлами и абсолютно один и тот же код, чтобы видеть код, иначе стек вызовов не будет хорошим.

Чтобы получить больше информации о PDB и прочем, вы можете прочитать эту статью .

...