大神们,请教分析64位dump文件方法
C/C++本地代码调试
大神们,请教分析64位dump文件方法
HiJack
2014-03-18, 15:39 下午
各位高手，我的程序在64位机器崩溃，获取到dump文件。然后到我的32位机器下用32位的windbg分析，我的操作步骤如下：
1 先用 .effmach amd64指令切换到64位模式
0:008:x86> .effmach amd64
2 然后在加载符号
3 然后运行!analyze -v 命令分析，但
STACK_TEXT里没有我的模块信息。
FAULTING_IP:
FOLLOWUP_IP: 都是我的模块。我用~*kvn打印所有堆栈信息，也看不到我的函数调用栈，只能看到系统的。难道我操作错了吗？还望大神指点。
例如我用命令k
打印出来的却是这样：没有我的程序的信息，都是系统的
0:001> k
Child-SP RetAddr Call Site
00000000`00e6e9b8 00000000`74be2bcd wow64cpu!CpupSyscallStub+0x9
00000000`00e6e9c0 00000000`74c5d07e wow64cpu!Thunk0ArgReloadState+0x1a
00000000`00e6ea80 00000000`74c5c549 wow64!RunCpuSimulation+0xa
00000000`00e6ead0 00000000`76febde7 wow64!Wow64LdrpInitialize+0x429
00000000`00e6f020 00000000`76fa2aae ntdll! ?? ::FNODOBFM::`string'+0x2b064
00000000`00e6f090 00000000`00000000 ntdll!LdrInitializeThunk+0xe
附上分析结果
FAULTING_IP:
HttpService_cURL_Single_U!TEP::HttpService::ErrorInfo::getErrorInfoA+186
00000000`70935de6 8b4a04 mov ecx,dword ptr [rdx+4]
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000070935de6 (HttpService_cURL_Single_U!TEP::HttpService::ErrorInfo::getErrorInfoA+0x0000000000000186)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000004
Attempt to read from address 0000000000000004
PROCESS_NAME: mCloudmgr.exe
OVERLAPPED_MODULE: Address regions for 'FWPUCLNT' and 'wship6' overlap
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 0000000000000004
READ_ADDRESS: 0000000000000004
FOLLOWUP_IP:
HttpService_cURL_Single_U!TEP::HttpService::ErrorInfo::getErrorInfoA+186
00000000`70935de6 8b4a04 mov ecx,dword ptr [rdx+4]
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
LAST_CONTROL_TRANSFER: from 0000000074c5cb12 to 0000000074c5c9f1
FAULTING_THREAD: ffffffffffffffff
BUGCHECK_STR: APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_READ
PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_DEREFERENCE
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
STACK_TEXT:
00000000`0308df30 00000000`74c5cb12 : 00000000`0308df80 00000000`0001003f 0000401d`a64f919e 40000000`00000001 : wow64!Wow64NotifyDebugger+0x1d
00000000`0308df60 00000000`74c5cc48 : 00000000`03dce62c 00000000`7ef2e000 00000000`7ef30000 00000000`0308c000 : wow64!HandleRaiseException+0xee
00000000`0308e2c0 00000000`74c76a11 : 00000000`00000000 00000000`77bb4c3d 00000000`0308e600 00000000`03dce5d0 : wow64!Wow64NtRaiseException+0x88
00000000`0308e620 00000000`74c5cf87 : 00000000`00000000 00000000`03dcda40 00000000`7ef2e000 00000000`7ef30000 : wow64!whNtRaiseException+0x15
00000000`0308e650 00000000`74be276d : 00000000`750d72af 00000000`00000023 00000000`03dce5dc 00000000`03dce210 : wow64!Wow64SystemServiceEx+0xd7
00000000`0308ef10 00000000`74c5d07e : 00000000`00000000 00000000`74be1920 00000000`00000000 00000000`00000000 : wow64cpu!TurboDispatchJumpAddressEnd+0x24
00000000`0308efd0 00000000`74c5c549 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : wow64!RunCpuSimulation+0xa
00000000`0308f020 00000000`76febde7 : 00000000`00000000 00000000`7efdf000 00000000`7ef2e000 00000000`00000000 : wow64!Wow64LdrpInitialize+0x429
00000000`0308f570 00000000`76fa2aae : 00000000`0308f630 00000000`00000000 00000000`7efdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x2b064
00000000`0308f5e0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: httpservice_curl_single_u!TEP::HttpService::ErrorInfo::getErrorInfoA+186
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: HttpService_cURL_Single_U
IMAGE_NAME: HttpService_cURL_Single_U.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 531ee7e4
STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~8s; .ecxr ; kb
FAILURE_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE_c0000005_HttpService_cURL_Single_U.dll!TEP::HttpService::ErrorInfo::getErrorInfoA
BUCKET_ID: X64_APPLICATION_FAULT_NULL_CLASS_PTR_DEREFERENCE_INVALID_POINTER_READ_httpservice_curl_single_u!TEP::HttpService::ErrorInfo::getErrorInfoA+186
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/mCloudmgr_exe/1_0_0_17/5323acae/HttpService_cURL_Single_U_dll/1_0_1_8/531ee7e4/c0000005/00005de6.htm?Retriage=1
Followup: MachineOwner
Re: 大神们,请教分析64位dump文件方法
格蠹老雷
2014-03-18, 20:15 下午
你的应用是32位，以WoW方式运行在64位系统上，使用32位WinDBG打开时，
0:008:x86>提示符表示已经在32位上下文，为何还要
.effmach amd64 ？
直接k就行了
明显是空指针啊，访问空对象偏移4的字段
Re: 大神们,请教分析64位dump文件方法
HiJack
2014-03-19, 11:24 上午
谢谢张老师指点，仔细看了一下
.effmach指令，是我用错了。还有
这个空指针的错误，我也明白,因为edx是0了。
但由于我初学Windbg有许多细节不是很明白,
比如有时WinDbg提示
ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]
这个代表什么意思？ 虽说可以根据DEFAULT_BUCKET_ID能看出大概，但我还是想知道，我觉得，Windbg给出的信息应该都是有用的。谢谢张老师
Re: 大神们,请教分析64位dump文件方法
格蠹老雷
2014-03-19, 20:51 下午
这句话对英语是外语的人来说是有难度的 :-)
这句话是用来说明!analyze结果里的另一个重要字段Followup的，
Followup字段的意思就是
这个问题“接下来应该找谁”。
要知道对于一个严重的BUG来说，谁都不愿意看到自己
的名字
出现在Followup后，要加班的！哈哈
因为Followup结论是根据规则自动产生的，于是就可能不准确，就可能有人抵赖，因此就有必要解释一下
上面所引用的这句翻译成白话就是：这个问题“接下来应该找谁”这个结论是基于
Is_ChosenCrashFollowupThread这个属性，从线程【
PSEUDO_THREAD
】的0号栈帧得出的
Re: 大神们,请教分析64位dump文件方法
HiJack
2014-03-19, 23:53 下午
谢谢张老师，但
Is_ChosenCrashFollowupThread和PSEUDO_THREAD(伪线程)这些信息，我怎在Windbg的帮助信息搜索不到？而且
PSEUDO_THREAD有时候会是0xffffffff,这怎么理解呢？嘿嘿 ，真是麻烦您了