Как получить значимую трассировку стека с помощью MiniDumpWriteDump
Я пытаюсь программно генерировать трассировку стека. Когда у моих пользователей происходит сбой, в частности случайный, трудно обсудить их с процессом получения дампа, чтобы я мог решить проблему. В прошлом, как только они посылали мне трассировку, я перекрестно ссылался на содержащиеся в ней адреса в файл Intermediate/foo.map, чтобы выяснить, с какой функцией возникла проблема (это лучший способ?)
Я собрал библиотеку из различных примеров, найденных в сети, чтобы вывести мини-дамп, чтобы облегчить мою работу. Я поставил сбой, но трассировка стека, которую я получаю из файла мини-дамп, сильно отличается от трассировки живого стека, которую я получаю от присоединения windbg. Примеры обоих ниже:
minidump.dmp:
KERNELBASE.dll!76a6c42d()
[Frames below may be incorrect and/or missing, no symbols loaded for KERNELBASE.dll]
KERNELBASE.dll!76a6c42d()
kernel32.dll!75bd14bd()
game.exe!00759035()
game.exe!00575ba3()
WINDBG.EXE:
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
game.exe не мой, и у меня нет источника / символов. Main.dll внедряется в game.exe и предоставляет интерфейсную функцию для загрузки дополнительных DLL из игры. Отладочный код и поэтапный сбой находятся в Minidump.dll. После того, как Main.dll загружает Minidump, он вызывает AfterLoad(), который устанавливает фильтр исключений, а затем вызывает сбой. Соответствующий код мини-дамп ниже:
Когда я открыл MiniDump.dmp, я указал его на все мои файлы символов (за исключением game.exe, которого у меня нет), и эта часть, кажется, работает. Я указываю на двоичный файл game.exe, поскольку он у меня есть. Трассировка стека, которую я получаю, просто бесполезна. Моя конечная цель - чтобы пользователь мог просто загрузить DLL, вызвать сбой и отправить мне файл дампа по электронной почте. Затем я прикреплю файлы символов и двоичные файлы и смогу диагностировать проблему по ним. Я делаю что-то не так или просто невозможно получить то, что я хочу.
typedef BOOL (WINAPI *MINIDUMPWRITEDUMP)(
HANDLE hProcess,
DWORD ProcessId,
HANDLE hFile,
MINIDUMP_TYPE DumpType,
CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
LONG WINAPI WriteDumpFilter(struct _EXCEPTION_POINTERS *pExceptionPointers)
{
HANDLE hFile = NULL;
HMODULE hDll = NULL;
MINIDUMPWRITEDUMP pMiniDumpWriteDump = NULL;
_MINIDUMP_EXCEPTION_INFORMATION ExceptionInformation = {0};
//load MiniDumpWriteDump
hDll = LoadLibrary(TEXT("DbgHelp.dll"));
pMiniDumpWriteDump = (MINIDUMPWRITEDUMP)GetProcAddress(hDll, "MiniDumpWriteDump");
//create output file
hFile = CreateFile( _T( "C:\\temp\\MiniDump.dmp"),
GENERIC_READ|GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
//bail if we don't have a file
if ((hFile != NULL) && (hFile != INVALID_HANDLE_VALUE))
{
//get exception information
ExceptionInformation.ThreadId = GetCurrentThreadId();
ExceptionInformation.ExceptionPointers = pExceptionPointers;
ExceptionInformation.ClientPointers = TRUE;
//write the debug dump
pMiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, MiniDumpWithFullMemory, &ExceptionInformation,
NULL, NULL );
//close the debug output file
CloseHandle(hFile);
}
return EXCEPTION_EXECUTE_HANDLER;
}
VOID crashme() {int* foo = 0; *foo = 0;}
VOID AfterLoad(VOID)
{
SetUnhandledExceptionFilter(WriteDumpFilter);
crashme();
}
Я попытался обрезать некоторые детали во всех деталях, чтобы упростить проблему, но я могу быть более точным, если это необходимо. Я нашел хорошую рецензию на CodeProject и попытался найти дополнительную справочную информацию для чтения, чтобы помочь мне понять проблему, но то, что я смог найти, не помогло мне понять, что они были просто пошаговыми инструкциями работает (что уже есть). Кто-нибудь имеет представление о том, что я делаю неправильно, или, может быть, указывает мне на соответствующее чтение?
После предложения Сергея я выполнил.ecxr в windbg и получил лучший результат, но он все равно не соответствует трассе, которую я получаю, когда подключаю windbg прямо к процессу и запускаю сбой. Вот след минидампа;
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0018e774 00759035 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
0018e7b4 00575ba3 00000000 00000000 00000001 game+0x359035
0018fc50 0057788a 009855ef 0018fdcb 00000001 game+0x175ba3
0018fc78 77b7e013 012d9230 002d91d0 002d9200 game+0x17788a
0018fc90 77ba9567 00290000 00000000 002d91d0 ntdll!RtlFreeHeap+0x7e
0018fd6c 0076ece2 0018ff78 007e1b7e ffffffff ntdll!LdrRemoveLoadAsDataTable+0x4e0
002bbc38 5c306174 61666544 00746c75 5d4c3055 game+0x36ece2
002bbc3c 61666544 00746c75 5d4c3055 8c000000 0x5c306174
002bbc40 00746c75 5d4c3055 8c000000 00000101 0x61666544
002bbc44 5d4c3055 8c000000 00000101 01000000 game+0x346c75
002bbc48 8c000000 00000101 01000000 00000000 0x5d4c3055
002bbc4c 00000000 01000000 00000000 0000006e 0x8c000000
и след от присоединения отладчика к процессу
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
У меня нет исходного кода для game.exe (у меня есть для библиотек DLL, в которых ошибка), но я декомпилировал game.exe и вот что находится в игре +0x359035.
.text:00759001 ; =============== S U B R O U T I N E =======================================
.text:00759001
.text:00759001 ; Attributes: library function bp-based frame
.text:00759001
.text:00759001 ; __stdcall _CxxThrowException(x, x)
.text:00759001 __CxxThrowException@8 proc near ; CODE XREF: .text:0040100Fp
.text:00759001 ; sub_401640+98p ...
.text:00759001
.text:00759001 dwExceptionCode = dword ptr -20h
.text:00759001 dwExceptionFlags= dword ptr -1Ch
.text:00759001 nNumberOfArguments= dword ptr -10h
.text:00759001 Arguments = dword ptr -0Ch
.text:00759001 var_8 = dword ptr -8
.text:00759001 var_4 = dword ptr -4
.text:00759001 arg_0 = dword ptr 8
.text:00759001 arg_4 = dword ptr 0Ch
.text:00759001
.text:00759001 push ebp
.text:00759002 mov ebp, esp
.text:00759004 sub esp, 20h
.text:00759007 mov eax, [ebp+arg_0]
.text:0075900A push esi
.text:0075900B push edi
.text:0075900C push 8
.text:0075900E pop ecx
.text:0075900F mov esi, offset unk_853A3C
.text:00759014 lea edi, [ebp+dwExceptionCode]
.text:00759017 rep movsd
.text:00759019 mov [ebp+var_8], eax
.text:0075901C mov eax, [ebp+arg_4]
.text:0075901F mov [ebp+var_4], eax
.text:00759022 lea eax, [ebp+Arguments]
.text:00759025 push eax ; lpArguments
.text:00759026 push [ebp+nNumberOfArguments] ; nNumberOfArguments
.text:00759029 push [ebp+dwExceptionFlags] ; dwExceptionFlags
.text:0075902C push [ebp+dwExceptionCode] ; dwExceptionCode
.text:0075902F call ds:RaiseException
.text:00759035 pop edi
.text:00759036 pop esi
.text:00759037 leave
.text:00759038 retn 8
.text:00759038 __CxxThrowException@8 endp
Моя ошибка, которую я вызываю, находится в Minidump.dll, но этот код в верхней части стека находится в game.exe. Там может быть много происходящего внутри game.exe, о котором я не знаю, может быть это может быть угон ошибки, которую я каким-то образом вызываю? IE, я вызываю ошибку в DLL, но что-то, настроенное в game.exe, фиксирует поток программы до вызова фильтра исключений, который записывает мини-дамп?
Если это так, когда я присоединяю отладчик к процессу, запускаю ошибку и получаю правильный вывод, который указывает на ошибку в моей DLL, то это означает, что game.exe не захватывает поток программы до того, как отладчик сможет это сделать. след. Как я мог заставить свой код минидампа вести себя так же... Это проникновение на территорию, с которой я не очень знаком. Есть идеи?
Я погнался дальше, и функция, вызывающая эту функцию, содержит следующую строку:
.text:00575A8D mov esi, offset aCrashDumpTooLa ; "Crash dump too large to send.\n"
Итак, я думаю, что game.exe захватывает исключение для создания собственного дампа до того, как мой код попытается получить его. И тогда моя трассировка дампов - это просто след процесса дампов game.exe...
Ответ
Я понял это. Я не уверен, как ответить на свой собственный пост, так что вот в чем дело.
.text:0057494A push offset aDbghelp_dll ; "DbgHelp.dll"
.text:0057494F call ds:LoadLibraryA
.text:00574955 test eax, eax
.text:00574957 jz short loc_5749C8
.text:00574959 push offset aMinidumpwrited ; "MiniDumpWriteDump"
.text:0057495E push eax ; hModule
.text:0057495F call ds:GetProcAddress
.text:00574965 mov edi, eax
.text:00574967 test edi, edi
.text:00574969 jz short loc_5749C8
.text:0057496B mov edx, lpFileName
.text:00574971 push 0 ; hTemplateFile
.text:00574973 push 80h ; dwFlagsAndAttributes
.text:00574978 push 2 ; dwCreationDisposition
.text:0057497A push 0 ; lpSecurityAttributes
.text:0057497C push 0 ; dwShareMode
.text:0057497E push 40000000h ; dwDesiredAccess
.text:00574983 push edx ; lpFileName
.text:00574984 call ds:CreateFileA
.text:0057498A mov esi, eax
.text:0057498C cmp esi, 0FFFFFFFFh
.text:0057498F jz short loc_5749C8
.text:00574991 call ds:GetCurrentThreadId
.text:00574997 push 0
.text:00574999 push 0
.text:0057499B mov [ebp+var_1C], eax
.text:0057499E lea eax, [ebp+var_1C]
.text:005749A1 push eax
.text:005749A2 push 0
.text:005749A4 push esi
.text:005749A5 mov [ebp+var_18], ebx
.text:005749A8 mov [ebp+var_14], 1
.text:005749AF call ds:__imp_GetCurrentProcessId
.text:005749B5 push eax
.text:005749B6 call ds:GetCurrentProcess
.text:005749BC push eax
.text:005749BD call edi
.text:005749BF push esi ; hObject
.text:005749C0 call ds:CloseHandle
.text:005749C6 jmp short loc_574A02
Это из game.exe. Оказывается, game.exe делает свой собственный мини-дамп. Мой минидамп срабатывал после их, так что в трассировке стека я увидел след процесса их дампа. Я нашел файл dmp в каталоге установки игры и, как только я загрузил в него свои символы, он показал правильный вывод, который я получил.
2 ответа
Я понял. В основном game.exe имел свой собственный код MiniDumpWriteDump, который запускался перед моим кодом. Таким образом, трассировка стека, которую я получал, была не следом ошибки, а следом от game.exe, выполняющего собственный MiniDump. Я разместил больше деталей в оригинальном посте.
Спасибо!
У тебя все хорошо. Когда вы открываете созданный вами мини-дамп, после загрузки символов выполните
.ecxr
сначала установить контекст в то, что вы сохранили в ExceptionInformation параметр для MiniDumpWriteDump(), Тогда у вас будет законный след стека.
Мы используем аналогичный механизм генерации дампов в том месте, где я работаю.
Есть некоторые будущие ошибки, хотя. Вы хотите проверить, запущен ли механизм захвата дампа на таких вещах, как abort() вызов.
Для этого проверьте _set_invalid_parameter_handler() а также signal(SIGABRT, ...),