壊れたオブジェクト インスタンスの仮想関数を呼び出してクラッシュしたように見える dmp ファイルをトレースしています。
壊れたオブジェクト ポインタの vft が間違ったアドレス( ) を指していたようで、to ( ) の0x3822a497直後にプログラムがクラッシュし、命令ポインタ ( ) は 1 つも先に進むことができませんでした。では、そうではないでしょうか？しかし、Visual Studio と Windbg の両方が を示しています。call edx0x3822a497LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497EIPedx=0x3822a497edx=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....
明らかに、これは有効な命令ではなく、ワイド文字テキストです。edxxwlanが言ったように、呼び出し先が情報を壊した可能性が非常に高いと思います。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: 呼び出し先は0x3822A497
では、なぜ edx ではないのでしょうか0x3822A497。（最初の質問）