How could it happen? (in debugging minidump file)

Question

I'm tracing dmp file which seems like crashed calling virtual function of broken object instance.

it seems that vft of the broken object pointer pointed wrong address(0x3822a497) and program crashed immediately after call edx to 0x3822a497 (LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497), and instruction pointer (EIP) couldn't even go one step further. then, shouldn't it be edx=0x3822a497? but both Visual Studio and Windbg indicates edx=0x1e4dcc0.

Can somebody explain how could it happen?

EDIT: I trusted LAST_CONTROL_TRANSFER too much, but still mystery exists. please first see updated suppositions 1,2,3 below and give me a possible scenario.

Result of 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>

Result of 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=??

Result of 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=??

Disassembly before LAST_CONTROL_TRANSFER: from 00ccde67 to 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

EDIT

Oh I forgot to put stack state.

stack (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.

Disassembly around 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

Memory dump around 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....

Obviously this is not valid instructions but wide characters text. I think it is very likely that callee broke edx information as xwlan said. ( And I thought LAST_CONTROL_TRANSFER is some kind of trustful information. It was just displaying last callstack entry to eip )

But my suppositions still don't make a sense. Can somebody make a scenario that makes sense?

Suppose 1: instruction jumped before `0x3822A497` and executed `popad`

I think this makes most sense. (e.g. could jumped by some indirection jump/call to pointer to text buffer 0x3822A490)

If so, popad would executed, which pops EDI, ESI, EBP, EBX, EDX, ECX, and EAX from stack. Then why can't I find these register's values from stack? For example, if so, shouldn't I see 0x00000002 (ebp), 0x01e4dcc0 (edx) from stack near 0x0018CFE4 (esp)?

Suppose 2: callee was not `0x3822A497` , instruction jumped exactly to `0x3822A497`

I think it is very rare case. If jump was by indirect call/jmp, nothing would pointed to 0x3822A497 which is odd number, If jump was by relative call/jmp, the call instruction would be near 0x3822A497, but I can't find such a relative calls when I disassembly from every point near 0x3822A497 and because it has ##, 00, ##, 00, ## pattern of wide character text, most possible jump instruction jumps to next instruction pointer, for example:

3822A494 72 00              > jb          3822A496  
3822A496 61                   popad  
3822A497 00 6E 00             add         byte ptr [esi],ch

Suppose 3: Callee was `0x3822A497`

then why edx is not 0x3822A497. (First question)

snoone · Answer 1 · 2013-05-06 15:38:36Z

You're putting too much faith in the call stack, you're likely missing a frame here (probably some sort of FPO related artifact). I suspect that EDX wasn't the bad EIP, it held the address of a valid function that eventually set up the invalid EIP.

If I were you, I would reconstruct EDX at the time of the crash and see what function it is. Then you can try to figure out what that function might have done to trash EIP (probably a stack overflow). If you're feeling lucky/lazy, you could hope that EDX has stayed unmolested and see what, "uf @edx" gets you.

You were right. I knew I should not trust call stack but I've never thought LAST_CONTROL_TRANSFER is just displaying last call stack entry. But still I can't make scenario that makes sense, (added suppositions to original answer) can you point more about this? — curinno, May 7 '13 at 5:14

xwlan · Answer 2 · 2013-05-06 17:45:36Z

up vote 0 down vote

look like stack corruption, "esp=0018cfe4 ebp=00000002", ebp is apparently a bad value. i'd suggest check the code "00CCDE65 call edx", the edx looks like point to a virtual function, this function and its callee corrupt the stack. dds esp in windbg can help to dump current stack memory to check whether there's any suspicious values, e.g. any string?

answered May 6 '13 at 17:45

xwlan
45434

Thanks, as you said It seems that callee corrupted registered but still I can't make scenario that makes sense. I added dumped stack, and updated question. – curinno May 7 '13 at 5:11

since stack is corrupted, eip can not be trusted, it's a trash value when trap into debugger. however, the code between 00CCDE34 and 00CCDE67 is correct. i guess you should know where these asm code map to what source file. 00CCDE65 issue a call to a function ptr, i suggest you investigate from this function. additionaly, dds is a better command to dump stack, because windbg will match symbol for each possible ptr. dds esp-100, this can dump the used stack (lower address). – xwlan May 7 '13 at 6:07

The matching source code is within disassembly: current_time = timeGetTime(); (*it)->proc(); Because it is an iterator for general object and I knew the main reason of crash is because iterator/object is broken, and I probably should narrow down by logging or or full dump in order to track down cause of crash. Actually point of this question was not like 'how to track down cause of crash' but was like 'how come this cpu state (register, eip,..) could happen?' because I just couldn't understood and was curious how last situation happened even it is already corrupted. – curinno May 7 '13 at 7:17

sorry, misunderstood your question. i think your suppose(2) is the only possible case based on the data you post. it's possible that there's a 'jmp dword ptr[xxx]' where xxx contains 0x3822A497. the jmp instruction is included in the region of where corrupted eip ever executed. how about search memory for the pattern 0x3822A497? – xwlan May 8 '13 at 15:00

add comment

asked	1 year ago
viewed	576 times
active	1 year ago

current community

your communities

more stack exchange communities

How could it happen? (in debugging minidump file)

EDIT: I trusted LAST_CONTROL_TRANSFER too much, but still mystery exists. please first see updated suppositions 1,2,3 below and give me a possible scenario.

Result of windbg !analyze -v

Result of windbg .excr

Result of windbg r

Disassembly before LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497

EDIT

stack (esp=0x18cfe4)

Disassembly around eip (0x3822A497)

Memory dump around eip (0x3822A497)

Suppose 1: instruction jumped before `0x3822A497` and executed `popad`

Suppose 2: callee was not `0x3822A497` , instruction jumped exactly to `0x3822A497`

Suppose 3: Callee was `0x3822A497`

2 Answers

Your Answer

Not the answer you're looking for? Browse other questions tagged debugging crash windbg crash-reports or ask your own question.

Visit Chat

Hot Network Questions

current community

your communities

more stack exchange communities

How could it happen? (in debugging minidump file)

EDIT: I trusted LAST_CONTROL_TRANSFER too much, but still mystery exists. please first see updated suppositions 1,2,3 below and give me a possible scenario.

Result of windbg !analyze -v

Result of windbg .excr

Result of windbg r

Disassembly before LAST_CONTROL_TRANSFER: from 00ccde67 to 3822a497

EDIT

stack (esp=0x18cfe4)

Disassembly around eip (0x3822A497)

Memory dump around eip (0x3822A497)

Suppose 1: instruction jumped before 0x3822A497 and executed popad

Suppose 2: callee was not 0x3822A497 , instruction jumped exactly to 0x3822A497

Suppose 3: Callee was 0x3822A497

2 Answers

Your Answer

Sign up or log in

Post as a guest

Not the answer you're looking for? Browse other questions tagged debugging crash windbg crash-reports or ask your own question.

Visit Chat

Related

Hot Network Questions

Suppose 1: instruction jumped before `0x3822A497` and executed `popad`

Suppose 2: callee was not `0x3822A497` , instruction jumped exactly to `0x3822A497`

Suppose 3: Callee was `0x3822A497`