我正在跟踪dmp文件，它看起来像崩溃时调用了破碎对象实例的虚函数。
似乎损坏的对象指针的vft指向错误的地址(0x3822a497)，并且在call edx转换为0x3822a497(LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497)之后，程序立即崩溃，并且指令指针(EIP)甚至无法再前进一步。然后，它不是edx=0x3822a497吗？但是Visual Studio和Windbg都指示edx=0x1e4dcc0。
有人可以解释它怎么发生吗？
编辑:我对LAST_CONTROL_TRANSFER的信任度很高，但仍然存在着谜。请首先查看下面的假设1,2,3，并给我一个可能的情况。
windbg!analyze -v的结果
Failed calling InternetOpenUrl, GLE=12029
FAULTING_IP:
+8cde67
3822a497 006e00 add byte ptr [esi],ch
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 3822a497
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 0138d2cc
Attempt to write to address 0138d2cc
PROCESS_NAME: DDD.exe
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.
FAULTING_MODULE: 76df0000 kernel32
DEBUG_FLR_IMAGE_TIMESTAMP: 518275c9
MODULE_NAME: DDD
ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
EXCEPTION_PARAMETER1: 00000001
EXCEPTION_PARAMETER2: 0138d2cc
WRITE_ADDRESS: 0138d2cc
FOLLOWUP_IP:
DDD+8cde67
00ccde67 ?? ???
FAILED_INSTRUCTION_ADDRESS:
+591b2faf0239d8f4
3822a497 006e00 add byte ptr [esi],ch
MOD_LIST: <ANALYSIS/>
FAULTING_THREAD: 00000650
BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_WRITE_WRONG_SYMBOLS
PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR
DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR
LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497
STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
0018cfe0 00ccde67 1a75cb52 00000000 28e86c00 0x3822a497
0018cfe4 1a75cb52 00000000 28e86c00 00000011 DDD+0x8cde67
0018cfe8 00000000 28e86c00 00000011 29b52260 0x1a75cb52
STACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 1
SYMBOL_NAME: DDD+8cde67
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: DDD.exe
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_DDD.exe!Unknown
WATSON_STAGEONE_URL: http://watson.microsoft.com/...
Followup: MachineOwner
---------
0:000>
windbg .excr的结果
0:000> .ecxr
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210282
3822a497 006e00 add byte ptr [esi],ch ds:002b:0138d2cc=??
windbg r的结果
Last set context:
eax=0018d0c8 ebx=78b3b6a8 ecx=00cddb00 edx=01e4dcc0 esi=0138d2cc edi=0018cfc8
eip=3822a497 esp=0018cfe4 ebp=00000002 iopl=0 nv up ei ng nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210282
3822a497 006e00 add byte ptr [esi],ch ds:002b:0138d2cc=??
LAST_CONTROL_TRANSFER之前的拆卸:从00ccde67到3822a497
current_time = timeGetTime();
00CCDE34 call dword ptr [__imp__timeGetTime@0 (17EE5FCh)]
(*it)->proc();
00CCDE3A mov eax,dword ptr [ebx]
00CCDE3C test eax,eax
00CCDE3E je 00CCDFFE
00CCDE44 test edi,edi
00CCDE46 je 00CCDFFE
00CCDE4C cmp dword ptr [eax+4],edi
00CCDE4F ja 00CCDFFE
00CCDE55 cmp edi,dword ptr [eax+8]
00CCDE58 jae 00CCDFFE
00CCDE5E mov ecx,dword ptr [edi]
00CCDE60 mov eax,dword ptr [ecx]
00CCDE62 mov edx,dword ptr [eax+0Ch]
00CCDE65 call edx
00CCDE67 push 0
编辑
哦，我忘了放堆栈状态。
堆栈(esp = 0x18cfe4)
0x0018CFA4 00000000 00000000 00000000 00000000 ................
0x0018CFB4 00000000 00000000 00000000 00000000 ................
0x0018CFC4 00000000 fffffd34 000002e4 fffffd34 ....4?..?...4?..
0x0018CFD4 000002cc 00000019 00000000 0018d0c8 ?...........??..
0x0018CFE4 >00ccde67 1a75cb52 00000000 28e86c00 g??.R?u......l?(
0x0018CFF4 00000011 29b52260 00000000 78b3c718 ....`"?).....??x
0x0018D004 29b522a0 00000000 78b3b6ac 29b522a0 ?"?)....???x?"?)
0x0018D014 00000000 78b3b6a8 1a75cb52 00000140 ....???xR?u.@...
0x0018D024 01e4f688 1a75cb52 0018d050 0170d884 ???.R?u.P?..??p.
0x0018D034 ffffffff 0018d05c 0098ec41 1a75cb36 ....\?..A??.6?u.
围绕eip拆卸(0x3822A497)
3822A490 54 push esp
3822A491 00 db 00h
3822A492 65 db 65h
3822A493 00 72 00 add byte ptr [edx],dh
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
3822A49A 69 00 74 00 65 00 imul eax,dword ptr [eax],650074h
eip周围的内存转储(0x3822A497)
0x3822A480 55da14f5 80000000 00001e08 00000024 ?.?U........$...
0x3822A490 00650054 00610072 0069006e 00650074 T.e.r.a.n.i.t.e.
0x3822A4A0 004e0020 00630065 006c006b 00630061 .N.e.c.k.l.a.c.
0x3822A4B0 00000065 4d747cba 55da14f2 80000000 e...?|tM?.?U....
显然，这不是有效的说明，而是宽字符文本。
我认为被 call 者很有可能破坏了xwlan所说的
edx信息。(我认为
LAST_CONTROL_TRANSFER是某种可信任的信息。它只是显示eip的最后一个调用堆栈条目)但是我的假设仍然没有道理。有人可以提出一个有意义的方案吗？
假设1:指令跳到
0x3822A497之前并执行了popad我认为这很有意义。 (例如，可以通过某种间接跳转/调用指向文本缓冲区
0x3822A490的指针进行跳转)如果是这样，将执行
popad，这会从堆栈中弹出EDI, ESI, EBP, EBX, EDX, ECX, and EAX。那为什么不能从堆栈中找到这些寄存器的值呢？
例如，如果是这样，我是否应该从
0x00000002 (ebp)附近的堆栈中看到0x01e4dcc0 (edx)和0x0018CFE4 (esp)？假设2:被调用方不是
0x3822A497，指令恰好跳至0x3822A497我认为这是非常罕见的情况。
如果跳转是通过间接调用/ jmp进行的，则不会指向
0x3822A497，它是奇数，如果跳转是通过相对调用/ jmp进行的，则调用指令应位于
0x3822A497附近，但是当我从
0x3822A497附近的每个点反汇编时，我找不到这样的相对调用并且因为它具有##，00，##，00，##模式的宽字符文本，
最可能的跳转指令跳转到下一条指令指针，例如:
3822A494 72 00 > jb 3822A496
3822A496 61 popad
3822A497 00 6E 00 add byte ptr [esi],ch
假设3:Callee是
0x3822A497那为什么edx不是
0x3822A497。 (第一个问题) 最佳答案
您对调用堆栈抱有太多的信心，这里很可能缺少一帧(可能是某种与FPO相关的工件)。我怀疑EDX不是坏的EIP，它拥有有效功能的地址，该功能最终设置了无效的EIP。
如果您是我，我将在崩溃时重建EDX，然后查看它的功能。然后，您可以尝试找出该函数可能会对垃圾回收EIP造成的影响(可能是堆栈溢出)。如果您感到幸运/懒惰，则可以希望EDX保持镇定，看看“uf @edx”能帮到您什么。