4
ProcDump로 만든 크래시 덤프에서 의미있는 정보를 얻는 데 어려움을 겪고 있습니다. 그러나 겉으로보기에는 무작위 충돌과 관련이 있다는 것을 확신합니다.Windbg 크래시 덤프 분석
Windows 7 64 비트에서 실행되는 VB6 응용 프로그램이 있습니다. 가끔씩, 충돌이 발생하여 오류 로그에 ntdll.dll 오류가 있지만 그보다 더 많은 정보를 제공하지 않습니다. 그래서 SysInternals의 ProcDump를 실행하여 자동으로 크래시 덤프를 생성합니다.
사내에서 크래시를 다시 만들 수 없어서 덤프가있는 경우 문제가 무엇인지 알 수있었습니다. 그러나 하루 종일 실행 한 후에도 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
사람이 항목의 의미를 만드는 측면에서 올바른 방향으로 날 지점 수, 나는 그것에 대해 무엇을 할 수 있습니까?
procdump가 실행되는 동안이 응용 프로그램을 디버깅하는 곳은 어디입니까? APPLICATION_FAULT_STATUS_BREAKPOINT_AFTER_CALL은 디버거가 프로세스에 침입했다는 것을 나타내는 것으로 보이는데, 이것은 procdump가 캡쳐 한 덤프입니다. 그래서이 덤프는 실제 문제의 스냅 샷이 아니므로 도움이되지 않습니다.'ProcDump'는 매우 가벼운 도구로 실제 문제가 발생하는 곳에서 실행하고 그 덤프를 분석해야합니다. – jcopenha
그 당시 디버깅 중이 아니 었습니다. ProcDump를 프로덕션 시스템에 설치하여 시작시 스크립팅 (C : \ apps \ procdump.exe -accepteula -e -h -n 10 -t -w application.exe C : \ application.dmp)하도록 스크립팅했습니다. . 그래서 기본적으로 컴파일 된 실행 파일과 함께 ProcDump를 실행하고 덤프를 따라 잡습니다. 그래서 당신이 말하는 것은 이러한 덤프가 기본적으로 ProcDump에 의한 것이므로 걱정할 필요가 없습니다. 가장 확실하게 잡으려고하는 오류는 프로그램 종료로 끝납니다. 그래서 현장에서 발생하면 그게 어쨌든 나는 덤프입니다. –
나는 그들에 대해 걱정할 필요가 없다는 말은 아닙니다. ! analyze -v의 보고서는 이것이 실제 충돌이 아니라 디버거 중단이라고 생각하게 만들었습니다. 다양한 스레드의 호출 스택을 검사하여 어딘가에 다른 예외가 있는지 확인합니다. – jcopenha