Анализ аварийных дампов Windbg
Мне трудно получить какую-либо значимую информацию из аварийного дампа, который я создал с помощью ProcDump, но я почти уверен, что он имеет отношение к, казалось бы, случайному аварийному отказу, который у меня был.
У меня есть приложение VB6, работающее на Windows 7 64-bit. Время от времени происходит сбой, оставляя запись в журнале ошибок, которая вызывает ошибку ntdll.dll, но не дает больше информации, чем эта. Итак, я запустил процесс с запущенным ProcDump от SysInternals для автоматического создания аварийных дампов для меня.
Я не смог воссоздать аварию на месте, поэтому я был почти уверен, что, если у меня вообще будет свалка, она скажет мне, в чем проблема. Однако после работы в течение большей части дня я вижу, что ProcDump уже написал несколько дампов, хотя программа все еще работает нормально. Кажется, он указывает на проблемы с ntdll.dll, но я не знаю, с чего начать применять исправление для этого.
Бег !analyze -v на одной из свалок дает мне следующее:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
FAULTING_IP:
+0
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 000007c8
PROCESS_NAME: application.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: application.exe
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT_AFTER_CALL
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT_AFTER_CALL
LAST_CONTROL_TRANSFER: from 7754431f to 7752014d
STACK_TEXT:
0382fdf4 7754431f 00000005 035e62c8 00000001 ntdll!ZwWaitForMultipleObjects+0x15
0382ff88 74cd339a 00000000 0382ffd4 77539ed2 ntdll!TppWaiterpThread+0x33d
0382ff94 77539ed2 035e6298 74e2a30c 00000000 kernel32!BaseThreadInitThunk+0xe
0382ffd4 77539ea5 775441f3 035e6298 00000000 ntdll!__RtlUserThreadStart+0x70
0382ffec 00000000 775441f3 035e6298 00000000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: ~0s; .ecxr ; kb
FOLLOWUP_IP:
ntdll!ZwWaitForMultipleObjects+15
7752014d 83c404 add esp,4
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: ntdll!ZwWaitForMultipleObjects+15
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ntdll
IMAGE_NAME: ntdll.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7ba58
FAILURE_BUCKET_ID: STATUS_BREAKPOINT_AFTER_CALL_80000003_ntdll.dll!ZwWaitForMultipleObjects
BUCKET_ID: APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL_ntdll!ZwWaitForMultipleObjects+15
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/BlackJack_exe/1_5_0_0/50227d4e/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
Followup: MachineOwner
Может кто-нибудь указать мне правильное направление, с точки зрения понимания этой записи, и что я могу с этим поделать?
1 ответ
Просто чтобы убедиться, я выполнил несколько тестов со своей стороны, подключаясь к исправным процессам и создавая дампы только что запущенного процесса. Во всех случаях вывод команды ! Analyse -v был очень похож на ваш, за исключением того факта, что мой вывод более подробный, я думаю, что это зависит от версии отладчика.
Например, вот вывод, который я получил после присоединения к только что запущенному Paint:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1
FAULTING_IP:
ntdll!DbgBreakPoint+0
00000000`76d90530 cc int 3
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000076d90530 (ntdll!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000000
FAULTING_THREAD: 0000000000000cbc
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: mspaint.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
EXCEPTION_PARAMETER1: 0000000000000000
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT
LAST_CONTROL_TRANSFER: from 0000000076e37ef8 to 0000000076d90530
STACK_TEXT:
FOLLOWUP_IP:
ntdll!DbgBreakPoint+0
00000000`76d90530 cc int 3
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: ntdll!DbgBreakPoint+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: ntdll
IMAGE_NAME: ntdll.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4ec4aa8e
STACK_COMMAND: ~8s ; kb
FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint
BUCKET_ID: X64_APPLICATION_FAULT_STATUS_BREAKPOINT_ntdll!DbgBreakPoint+0
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/mspaint_exe/6_1_7600_16385/4a5bca29/ntdll_dll/6_1_7601_17725/4ec4aa8e/80000003/00050530.htm?Retriage=1
Followup: MachineOwner
---------
Я также взглянул на объяснение флагов ProcDump здесь: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx. Это похоже на использование командной строки, как
C:\apps\procdump.exe -accepteula -e -h -n 10 -t -w application.exe
вы заставляете procdump останавливаться на каждом признаке зависания или исключения без установки определенных параметров, таких как номер использования памяти или процент использования процессора.
Я бы предложил использовать DebugDiag, который предоставляет хороший интерфейс, где вы можете настроить правила, описывающие, когда должен быть создан дамп. Вот объяснение от меня, как собрать дамп, если у вас есть проблема с чрезмерным использованием памяти или высокая загрузка ЦП:
http://kate-butenko.blogspot.com/2012/06/how-to-gather-dump-with-debugdiag.html
и вот еще одно прекрасное объяснение на основе скриншота, как получить дамп в DebugDiag для конкретного исключения:
Из множества более легких инструментов вы также можете проверить инструмент AdPlus (находится в папке C:\Program Files\Debugging Tools for Windows (x64)). Я предпочитаю DebugDiag, так как он позволяет отлавливать определенные типы исключений.