Анализ файла аварийного дампа
У меня есть файл аварийного дампа от клиента, который я должен проанализировать. Я новичок в мире анализа аварийных дампов. (Исходный код — C ++).
Вот что я попробовал:
-
Я открыл файл .dmp в MS Visual Studio, которая показала следующую ошибку — Вы не можете отлаживать 64-битный дамп 32-битного процесса. Итак, я подумал о том, чтобы дать
WinDbgпопытка -
Когда я открыл файл в WinDbg после установки пути поиска символов, я начал получать следующее: Отладчик не подключен.
Кто-нибудь может указать мне в правильном направлении? Должен ли я попросить клиента предоставить 32-разрядный дамп с его точки или этот файл дампа может быть отлажен.
Также предоставьте необходимую документацию для начала работы.
Решение
В некоторой степени вы можете отладить 64-битный дамп 32-битного процесса с помощью Windbg,
с помощью wow64exts. Однако, если возможно, я думаю, что лучше иметь 32-битный дамп.
Если клиент может предоставить 32-битный дамп, получите его.
Вот пример wow64exts:
0:008> k
Child-SP RetAddr Call Site
00000000`0291f128 00000000`779d263a wow64cpu!CpupSyscallStub+0x2
00000000`0291f130 00000000`7792c4f6 wow64cpu!WaitForMultipleObjects32+0x1d
00000000`0291f1e0 00000000`7792b8f5 wow64!RunCpuSimulation+0xa
00000000`0291f230 000007fe`e51fd6af wow64!Wow64LdrpInitialize+0x435
00000000`0291f770 000007fe`e519c1ae ntdll!_LdrpInitialize+0xde
00000000`0291f7e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
0:008> .load wow64exts
0:008> !sw
Switched to 32bit mode
0:008:x86> k
ChildEBP RetAddr
02a1f2dc 7783c752 ntdll_779e0000!NtWaitForMultipleObjects+0xc
02a1f460 75b956c0 KERNELBASE!WaitForMultipleObjectsEx+0x10b
02a1f4d4 75b9586a kernel32!WerpReportFaultInternal+0x1c4
02a1f4e8 75b67828 kernel32!WerpReportFault+0x6d
02a1f4f4 778c07c4 kernel32!BasepReportFault+0x19
Другие решения
Самый полезный инструмент для анализа аварийного дампа — это загрузить его в Windbg (Файл -> Открыть аварийный дамп), а затем использовать
!analyze -v
команда. При этом применяется ряд эвристических методов, позволяющих слегка перематывать назад с места фактического сбоя, чтобы определить, где, вероятно, будет причина сбоя, например, где произошла разыменование нулевого указателя. Там хороший учебник Вот. Действительно хороший сайт для закладок — Джон Роббинс блог у которого есть много замечательных статей о Windbg.