|
| Re: RtlpDphReportCorruptedBlock |
 |
Mon, 31 Mar 2008 11:21:46 -070 |
VOID
RtlpDphReportCorruptedBlock (
PVOID Heap,
ULONG Context,
PVOID Block,
<<<<<<<<<<<<<<<<<<<
ULONG Reason
);
Try to do a `!heap -p -a` on the third param to the function.
--
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Lance" <lances@nospam.nospam> wrote in message
news:OWin2P1kIHA.5160@TK2MSFTNGP05.phx.gbl...
>I have a .dmp file with heap corruption, where RtlpDphAddToDelayedFreeQueue
>appears to detect a corrupt block and calls RtlpDphReportCorruptedBlock.
>How can I tell what block it considers corrupted in order to look at it?
>I haven't been able to find any documentation on the parameters to
>RtlpDphReportCorruptedBlock.
> Stack trace and disassembly of the calling code below.
> Thanks,
> -Lance
>
> STACK_TEXT:
> 077ff76c 7c85079b 02281000 077ff81c 077ff7f8 ntdll!DbgBreakPoint
> 077ff77c 7c872081 0000000e 7c872344 02281000 ntdll!RtlpPageHeapStop+0x72
> 077ff7f8 7c872781 02281000 00000009 08998f10
> ntdll!RtlpDphReportCorruptedBlock+0x154
> 077ff85c 7c873345 08a6b208 00000000 02281000
> ntdll!RtlpDphAddToDelayedFreeQueue+0x120
> 077ff880 7c8734c3 02281000 02380000 01001002
> ntdll!RtlpDphNormalHeapFree+0x73
> 077ff8d8 7c8766b9 02280000 01001002 08a6b228
> ntdll!RtlpDebugPageHeapFree+0x146
> 077ff940 7c860386 02280000 01001002 08a6b228 ntdll!RtlDebugFreeHeap+0x1ed
> 077ffa18 7c81d77d 02280000 01001002 08a6b228 ntdll!RtlFreeHeapSlowly+0x37
> 077ffafc 77bbcef6 02280000 01001002 08a6b228 ntdll!RtlFreeHeap+0x11a
> 077ffb44 780c9043 08a6b228 077ffbb4 6705217a msvcrt!free+0xc3
> 077ffb50 6705217a 00000001 00000000 048f8668
>
msvcp60!std::basic_string<char,std::char_traits<char>,std::allocator<
;char>
> >::_Tidy+0x27
> ...
>
> 0:004> ub 0x7c872786 L20
> ntdll!RtlpDphAddToDelayedFreeQueue+0xcd:
> 7c87272e 84db test bl,bl
> 7c872730 751b jne ntdll!RtlpDphAddToDelayedFreeQueue+0xec
> (7c87274d)
> 7c872732 c745c000020000 mov dword ptr [ebp-40h],200h
> 7c872739 8945c8 mov dword ptr [ebp-38h],eax
> 7c87273c 8d4dc0 lea ecx,[ebp-40h]
> 7c87273f 51 push ecx
> 7c872740 83c010 add eax,10h
> 7c872743 50 push eax
> 7c872744 6a09 push 9
> 7c872746 6a00 push 0
> 7c872748 e8f3f7ffff call ntdll!RtlpDphReportCorruptedBlock
> (7c871f40)
>
> 7c87274d 8b0d80c5887c mov ecx,dword ptr
> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)]
> 7c872753 8b01 mov eax,dword ptr [ecx]
> 7c872755 a380c5887c mov dword ptr [ntdll!RtlpDphDelayedFreeQueue
> (7c88c580)],eax
> 7c87275a 897804 mov dword ptr [eax+4],edi
> 7c87275d 8d71f0 lea esi,[ecx-10h]
> 7c872760 8d5e20 lea ebx,[esi+20h]
> 7c872763 6a01 push 1
> 7c872765 8d45c0 lea eax,[ebp-40h]
> 7c872768 50 push eax
> 7c872769 53 push ebx
> 7c87276a e895d8ffff call ntdll!RtlpDphIsNormalFreeHeapBlock
> (7c870004)
> 7c87276f 84c0 test al,al
> 7c872771 750e jne ntdll!RtlpDphAddToDelayedFreeQueue+0x120
> (7c872781)
>
> 7c872773 8d45c0 lea eax,[ebp-40h]
> 7c872776 50 push eax
> 7c872777 53 push ebx
> 7c872778 6a09 push 9
> 7c87277a 6a00 push 0
> 7c87277c e8bff7ffff call ntdll!RtlpDphReportCorruptedBlock
> (7c871f40) <<<<<<<<<<<<<
>
> 7c872781 ff0e dec dword ptr [esi]
> 7c872783 ff4e1c dec dword ptr [esi+1Ch]
>
>
>
|
| Post Reply
|
| Re: RtlpDphReportCorruptedBlock |
 |
Mon, 31 Mar 2008 12:57:28 -070 |
The F0 -> EF seems the pattern of a `InterlockedDecrement((ULONG *)pBlock)`
performed on a freed-block (or, a resuse-after-delete).
The best way to tacle this would be to try to repro under full-page-heap,
so that the culprit is on the stack, but, in absence of that, I would try
to do a `dps 0x00686f38` to see the stack trace responsible for that block,
and take-it per code-review from there.
--
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Lance" <lances@nospam.nospam> wrote in message
news:%23TjoYR2kIHA.5396@TK2MSFTNGP04.phx.gbl...
> Hi Ivan -
>
> !heap -p -a 0x08998f10
> returned nothing. Dumping the block (and metadata), it looks like an
> 'ef' has been written at the 4th byte of the freed area:
>
> 0:004> dc 0x08998f10-0x28 L30
> 08998ee8 008d0044 021703f9 abcdaaa9 82281000 D.............(.
> 08998ef8 000001e1 00000209 089992a8 7c88c580 ...............|
> 08998f08 00686f38 dcbaaaa9 f0f0f0ef f0f0f0f0 8oh.............
> 08998f18 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f28 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f38 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f48 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f58 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f68 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f78 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f88 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
> 08998f98 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>
> Dumping the heap and pageheap metadata:
>
> 0:004> dt _HEAP_ENTRY 0x08998f10-0x28
> +0x000 Size : 0x44
> +0x002 PreviousSize : 0x8d
> +0x000 SubSegmentCode : 0x008d0044
> +0x004 SmallTagIndex : 0xf9 ''
> +0x005 Flags : 0x3 ''
> +0x006 UnusedBytes : 0x17 ''
> +0x007 SegmentIndex : 0x2 ''
>
> 0:004> dt _DPH_BLOCK_INFORMATION 0x08998f10-0x20
> +0x000 StartStamp : 0xabcdaaa9
> +0x004 Heap : 0x82281000
> +0x008 RequestedSize : 0x1e1
> +0x00c ActualSize : 0x209
> +0x010 FreeQueue : _LIST_ENTRY [ 0x89992a8 - 0x7c88c580 ]
> +0x010 FreePushList : _SINGLE_LIST_ENTRY
> +0x010 TraceIndex : 0x92a8
> +0x018 StackTrace : 0x00686f38
> +0x01c EndStamp : 0xdcbaaaa9
>
> Anything else in the metadata that would help in identifying the problem?
>
> Also, is RtlpDphReportCorruptedBlock documented somewhere, including the
> values for the 'reason' parameter?
>
> Thanks,
> -Lance
>
>
> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com>
wrote in message
> news:ubYPVw1kIHA.3400@TK2MSFTNGP03.phx.gbl...
>> VOID
>> RtlpDphReportCorruptedBlock (
>> PVOID Heap,
>> ULONG Context,
>> PVOID Block,
<<<<<<<<<<<<<<<<<<<
>> ULONG Reason
>> );
>>
>> Try to do a `!heap -p -a` on the third param to the function.
>>
>> --
>>
>> --
>> This posting is provided "AS IS" with no warranties, and
confers no
>> rights.
>> Use of any included script samples are subject to the terms specified
at
>> http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "Lance" <lances@nospam.nospam> wrote in message
>> news:OWin2P1kIHA.5160@TK2MSFTNGP05.phx.gbl...
>>>I have a .dmp file with heap corruption, where
>>>RtlpDphAddToDelayedFreeQueue appears to detect a corrupt block and
calls
>>>RtlpDphReportCorruptedBlock. How can I tell what block it considers
>>>corrupted in order to look at it? I haven't been able to find any
>>>documentation on the parameters to RtlpDphReportCorruptedBlock.
>>> Stack trace and disassembly of the calling code below.
>>> Thanks,
>>> -Lance
>>>
>>> STACK_TEXT:
>>> 077ff76c 7c85079b 02281000 077ff81c 077ff7f8 ntdll!DbgBreakPoint
>>> 077ff77c 7c872081 0000000e 7c872344 02281000
ntdll!RtlpPageHeapStop+0x72
>>> 077ff7f8 7c872781 02281000 00000009 08998f10
>>> ntdll!RtlpDphReportCorruptedBlock+0x154
>>> 077ff85c 7c873345 08a6b208 00000000 02281000
>>> ntdll!RtlpDphAddToDelayedFreeQueue+0x120
>>> 077ff880 7c8734c3 02281000 02380000 01001002
>>> ntdll!RtlpDphNormalHeapFree+0x73
>>> 077ff8d8 7c8766b9 02280000 01001002 08a6b228
>>> ntdll!RtlpDebugPageHeapFree+0x146
>>> 077ff940 7c860386 02280000 01001002 08a6b228
>>> ntdll!RtlDebugFreeHeap+0x1ed
>>> 077ffa18 7c81d77d 02280000 01001002 08a6b228
>>> ntdll!RtlFreeHeapSlowly+0x37
>>> 077ffafc 77bbcef6 02280000 01001002 08a6b228
ntdll!RtlFreeHeap+0x11a
>>> 077ffb44 780c9043 08a6b228 077ffbb4 6705217a msvcrt!free+0xc3
>>> 077ffb50 6705217a 00000001 00000000 048f8668
>>>
msvcp60!std::basic_string<char,std::char_traits<char>,std::allocator<
;char>
>>> >::_Tidy+0x27
>>> ...
>>>
>>> 0:004> ub 0x7c872786 L20
>>> ntdll!RtlpDphAddToDelayedFreeQueue+0xcd:
>>> 7c87272e 84db test bl,bl
>>> 7c872730 751b jne
ntdll!RtlpDphAddToDelayedFreeQueue+0xec
>>> (7c87274d)
>>> 7c872732 c745c000020000 mov dword ptr [ebp-40h],200h
>>> 7c872739 8945c8 mov dword ptr [ebp-38h],eax
>>> 7c87273c 8d4dc0 lea ecx,[ebp-40h]
>>> 7c87273f 51 push ecx
>>> 7c872740 83c010 add eax,10h
>>> 7c872743 50 push eax
>>> 7c872744 6a09 push 9
>>> 7c872746 6a00 push 0
>>> 7c872748 e8f3f7ffff call ntdll!RtlpDphReportCorruptedBlock
>>> (7c871f40)
>>>
>>> 7c87274d 8b0d80c5887c mov ecx,dword ptr
>>> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)]
>>> 7c872753 8b01 mov eax,dword ptr [ecx]
>>> 7c872755 a380c5887c mov dword ptr
>>> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)],eax
>>> 7c87275a 897804 mov dword ptr [eax+4],edi
>>> 7c87275d 8d71f0 lea esi,[ecx-10h]
>>> 7c872760 8d5e20 lea ebx,[esi+20h]
>>> 7c872763 6a01 push 1
>>> 7c872765 8d45c0 lea eax,[ebp-40h]
>>> 7c872768 50 push eax
>>> 7c872769 53 push ebx
>>> 7c87276a e895d8ffff call ntdll!RtlpDphIsNormalFreeHeapBlock
>>> (7c870004)
>>> 7c87276f 84c0 test al,al
>>> 7c872771 750e jne
>>> ntdll!RtlpDphAddToDelayedFreeQueue+0x120 (7c872781)
>>>
>>> 7c872773 8d45c0 lea eax,[ebp-40h]
>>> 7c872776 50 push eax
>>> 7c872777 53 push ebx
>>> 7c872778 6a09 push 9
>>> 7c87277a 6a00 push 0
>>> 7c87277c e8bff7ffff call ntdll!RtlpDphReportCorruptedBlock
>>> (7c871f40) <<<<<<<<<<<<<
>>>
>>> 7c872781 ff0e dec dword ptr [esi]
>>> 7c872783 ff4e1c dec dword ptr [esi+1Ch]
>>>
>>>
>>>
>>
>>
>
>
|
| Post Reply
|
| RtlpDphReportCorruptedBlock |
 |
Mon, 31 Mar 2008 13:23:47 -040 |
I have a .dmp file with heap corruption, where RtlpDphAddToDelayedFreeQueue
appears to detect a corrupt block and calls RtlpDphReportCorruptedBlock.
How can I tell what block it considers corrupted in order to look at it? I
haven't been able to find any documentation on the parameters to
RtlpDphReportCorruptedBlock.
Stack trace and disassembly of the calling code below.
Thanks,
-Lance
STACK_TEXT:
077ff76c 7c85079b 02281000 077ff81c 077ff7f8 ntdll!DbgBreakPoint
077ff77c 7c872081 0000000e 7c872344 02281000 ntdll!RtlpPageHeapStop+0x72
077ff7f8 7c872781 02281000 00000009 08998f10
ntdll!RtlpDphReportCorruptedBlock+0x154
077ff85c 7c873345 08a6b208 00000000 02281000
ntdll!RtlpDphAddToDelayedFreeQueue+0x120
077ff880 7c8734c3 02281000 02380000 01001002
ntdll!RtlpDphNormalHeapFree+0x73
077ff8d8 7c8766b9 02280000 01001002 08a6b228
ntdll!RtlpDebugPageHeapFree+0x146
077ff940 7c860386 02280000 01001002 08a6b228 ntdll!RtlDebugFreeHeap+0x1ed
077ffa18 7c81d77d 02280000 01001002 08a6b228 ntdll!RtlFreeHeapSlowly+0x37
077ffafc 77bbcef6 02280000 01001002 08a6b228 ntdll!RtlFreeHeap+0x11a
077ffb44 780c9043 08a6b228 077ffbb4 6705217a msvcrt!free+0xc3
077ffb50 6705217a 00000001 00000000 048f8668
msvcp60!std::basic_string<char,std::char_traits<char>,std::allocator<
;char>
>::_Tidy+0x27
...
0:004> ub 0x7c872786 L20
ntdll!RtlpDphAddToDelayedFreeQueue+0xcd:
7c87272e 84db test bl,bl
7c872730 751b jne ntdll!RtlpDphAddToDelayedFreeQueue+0xec
(7c87274d)
7c872732 c745c000020000 mov dword ptr [ebp-40h],200h
7c872739 8945c8 mov dword ptr [ebp-38h],eax
7c87273c 8d4dc0 lea ecx,[ebp-40h]
7c87273f 51 push ecx
7c872740 83c010 add eax,10h
7c872743 50 push eax
7c872744 6a09 push 9
7c872746 6a00 push 0
7c872748 e8f3f7ffff call ntdll!RtlpDphReportCorruptedBlock
(7c871f40)
7c87274d 8b0d80c5887c mov ecx,dword ptr
[ntdll!RtlpDphDelayedFreeQueue (7c88c580)]
7c872753 8b01 mov eax,dword ptr [ecx]
7c872755 a380c5887c mov dword ptr [ntdll!RtlpDphDelayedFreeQueue
(7c88c580)],eax
7c87275a 897804 mov dword ptr [eax+4],edi
7c87275d 8d71f0 lea esi,[ecx-10h]
7c872760 8d5e20 lea ebx,[esi+20h]
7c872763 6a01 push 1
7c872765 8d45c0 lea eax,[ebp-40h]
7c872768 50 push eax
7c872769 53 push ebx
7c87276a e895d8ffff call ntdll!RtlpDphIsNormalFreeHeapBlock
(7c870004)
7c87276f 84c0 test al,al
7c872771 750e jne ntdll!RtlpDphAddToDelayedFreeQueue+0x120
(7c872781)
7c872773 8d45c0 lea eax,[ebp-40h]
7c872776 50 push eax
7c872777 53 push ebx
7c872778 6a09 push 9
7c87277a 6a00 push 0
7c87277c e8bff7ffff call ntdll!RtlpDphReportCorruptedBlock
(7c871f40) <<<<<<<<<<<<<
7c872781 ff0e dec dword ptr [esi]
7c872783 ff4e1c dec dword ptr [esi+1Ch]
|
| Post Reply
|
| Re: RtlpDphReportCorruptedBlock |
 |
Mon, 31 Mar 2008 15:21:06 -040 |
Hi Ivan -
!heap -p -a 0x08998f10
returned nothing. Dumping the block (and metadata), it looks like an 'ef'
has been written at the 4th byte of the freed area:
0:004> dc 0x08998f10-0x28 L30
08998ee8 008d0044 021703f9 abcdaaa9 82281000 D.............(.
08998ef8 000001e1 00000209 089992a8 7c88c580 ...............|
08998f08 00686f38 dcbaaaa9 f0f0f0ef f0f0f0f0 8oh.............
08998f18 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f28 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f38 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f48 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f58 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f68 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f78 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f88 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
08998f98 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
Dumping the heap and pageheap metadata:
0:004> dt _HEAP_ENTRY 0x08998f10-0x28
+0x000 Size : 0x44
+0x002 PreviousSize : 0x8d
+0x000 SubSegmentCode : 0x008d0044
+0x004 SmallTagIndex : 0xf9 ''
+0x005 Flags : 0x3 ''
+0x006 UnusedBytes : 0x17 ''
+0x007 SegmentIndex : 0x2 ''
0:004> dt _DPH_BLOCK_INFORMATION 0x08998f10-0x20
+0x000 StartStamp : 0xabcdaaa9
+0x004 Heap : 0x82281000
+0x008 RequestedSize : 0x1e1
+0x00c ActualSize : 0x209
+0x010 FreeQueue : _LIST_ENTRY [ 0x89992a8 - 0x7c88c580 ]
+0x010 FreePushList : _SINGLE_LIST_ENTRY
+0x010 TraceIndex : 0x92a8
+0x018 StackTrace : 0x00686f38
+0x01c EndStamp : 0xdcbaaaa9
Anything else in the metadata that would help in identifying the problem?
Also, is RtlpDphReportCorruptedBlock documented somewhere, including the
values for the 'reason' parameter?
Thanks,
-Lance
"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in
message
news:ubYPVw1kIHA.3400@TK2MSFTNGP03.phx.gbl...
> VOID
> RtlpDphReportCorruptedBlock (
> PVOID Heap,
> ULONG Context,
> PVOID Block,
<<<<<<<<<<<<<<<<<<<
> ULONG Reason
> );
>
> Try to do a `!heap -p -a` on the third param to the function.
>
> --
>
> --
> This posting is provided "AS IS" with no warranties, and confers
no
> rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Lance" <lances@nospam.nospam> wrote in message
> news:OWin2P1kIHA.5160@TK2MSFTNGP05.phx.gbl...
>>I have a .dmp file with heap corruption, where
>>RtlpDphAddToDelayedFreeQueue appears to detect a corrupt block and calls
>>RtlpDphReportCorruptedBlock. How can I tell what block it considers
>>corrupted in order to look at it? I haven't been able to find any
>>documentation on the parameters to RtlpDphReportCorruptedBlock.
>> Stack trace and disassembly of the calling code below.
>> Thanks,
>> -Lance
>>
>> STACK_TEXT:
>> 077ff76c 7c85079b 02281000 077ff81c 077ff7f8 ntdll!DbgBreakPoint
>> 077ff77c 7c872081 0000000e 7c872344 02281000
ntdll!RtlpPageHeapStop+0x72
>> 077ff7f8 7c872781 02281000 00000009 08998f10
>> ntdll!RtlpDphReportCorruptedBlock+0x154
>> 077ff85c 7c873345 08a6b208 00000000 02281000
>> ntdll!RtlpDphAddToDelayedFreeQueue+0x120
>> 077ff880 7c8734c3 02281000 02380000 01001002
>> ntdll!RtlpDphNormalHeapFree+0x73
>> 077ff8d8 7c8766b9 02280000 01001002 08a6b228
>> ntdll!RtlpDebugPageHeapFree+0x146
>> 077ff940 7c860386 02280000 01001002 08a6b228
ntdll!RtlDebugFreeHeap+0x1ed
>> 077ffa18 7c81d77d 02280000 01001002 08a6b228
ntdll!RtlFreeHeapSlowly+0x37
>> 077ffafc 77bbcef6 02280000 01001002 08a6b228 ntdll!RtlFreeHeap+0x11a
>> 077ffb44 780c9043 08a6b228 077ffbb4 6705217a msvcrt!free+0xc3
>> 077ffb50 6705217a 00000001 00000000 048f8668
>>
msvcp60!std::basic_string<char,std::char_traits<char>,std::allocator<
;char>
>> >::_Tidy+0x27
>> ...
>>
>> 0:004> ub 0x7c872786 L20
>> ntdll!RtlpDphAddToDelayedFreeQueue+0xcd:
>> 7c87272e 84db test bl,bl
>> 7c872730 751b jne
ntdll!RtlpDphAddToDelayedFreeQueue+0xec
>> (7c87274d)
>> 7c872732 c745c000020000 mov dword ptr [ebp-40h],200h
>> 7c872739 8945c8 mov dword ptr [ebp-38h],eax
>> 7c87273c 8d4dc0 lea ecx,[ebp-40h]
>> 7c87273f 51 push ecx
>> 7c872740 83c010 add eax,10h
>> 7c872743 50 push eax
>> 7c872744 6a09 push 9
>> 7c872746 6a00 push 0
>> 7c872748 e8f3f7ffff call ntdll!RtlpDphReportCorruptedBlock
>> (7c871f40)
>>
>> 7c87274d 8b0d80c5887c mov ecx,dword ptr
>> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)]
>> 7c872753 8b01 mov eax,dword ptr [ecx]
>> 7c872755 a380c5887c mov dword ptr
[ntdll!RtlpDphDelayedFreeQueue
>> (7c88c580)],eax
>> 7c87275a 897804 mov dword ptr [eax+4],edi
>> 7c87275d 8d71f0 lea esi,[ecx-10h]
>> 7c872760 8d5e20 lea ebx,[esi+20h]
>> 7c872763 6a01 push 1
>> 7c872765 8d45c0 lea eax,[ebp-40h]
>> 7c872768 50 push eax
>> 7c872769 53 push ebx
>> 7c87276a e895d8ffff call ntdll!RtlpDphIsNormalFreeHeapBlock
>> (7c870004)
>> 7c87276f 84c0 test al,al
>> 7c872771 750e jne
ntdll!RtlpDphAddToDelayedFreeQueue+0x120
>> (7c872781)
>>
>> 7c872773 8d45c0 lea eax,[ebp-40h]
>> 7c872776 50 push eax
>> 7c872777 53 push ebx
>> 7c872778 6a09 push 9
>> 7c87277a 6a00 push 0
>> 7c87277c e8bff7ffff call ntdll!RtlpDphReportCorruptedBlock
>> (7c871f40) <<<<<<<<<<<<<
>>
>> 7c872781 ff0e dec dword ptr [esi]
>> 7c872783 ff4e1c dec dword ptr [esi+1Ch]
>>
>>
>>
>
>
|
| Post Reply
|
| Re: RtlpDphReportCorruptedBlock |
 |
Mon, 31 Mar 2008 16:41:06 -040 |
Thanks for the InterlockedDecrement thought. I'm looking through the stack
trace. Are the sizes in the HEAP_ENTRY vs DPH_BLOCK_INFORMATION structures
any indication of a problem? The (outer)HEAP_ENTRY size shows 0x44, the
inner DPH_BLOCK_INFORMATION actual size shows 0x209
-Lance
"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in
message
news:uUbWzl2kIHA.1208@TK2MSFTNGP03.phx.gbl...
> The F0 -> EF seems the pattern of a `InterlockedDecrement((ULONG
> *)pBlock)`
> performed on a freed-block (or, a resuse-after-delete).
> The best way to tacle this would be to try to repro under full-page-heap,
> so that the culprit is on the stack, but, in absence of that, I would try
> to do a `dps 0x00686f38` to see the stack trace responsible for that
> block,
> and take-it per code-review from there.
>
> --
>
> --
> This posting is provided "AS IS" with no warranties, and confers
no
> rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Lance" <lances@nospam.nospam> wrote in message
> news:%23TjoYR2kIHA.5396@TK2MSFTNGP04.phx.gbl...
>> Hi Ivan -
>>
>> !heap -p -a 0x08998f10
>> returned nothing. Dumping the block (and metadata), it looks like an
>> 'ef' has been written at the 4th byte of the freed area:
>>
>> 0:004> dc 0x08998f10-0x28 L30
>> 08998ee8 008d0044 021703f9 abcdaaa9 82281000 D.............(.
>> 08998ef8 000001e1 00000209 089992a8 7c88c580 ...............|
>> 08998f08 00686f38 dcbaaaa9 f0f0f0ef f0f0f0f0 8oh.............
>> 08998f18 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f28 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f38 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f48 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f58 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f68 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f78 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f88 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>> 08998f98 f0f0f0f0 f0f0f0f0 f0f0f0f0 f0f0f0f0 ................
>>
>> Dumping the heap and pageheap metadata:
>>
>> 0:004> dt _HEAP_ENTRY 0x08998f10-0x28
>> +0x000 Size : 0x44
>> +0x002 PreviousSize : 0x8d
>> +0x000 SubSegmentCode : 0x008d0044
>> +0x004 SmallTagIndex : 0xf9 ''
>> +0x005 Flags : 0x3 ''
>> +0x006 UnusedBytes : 0x17 ''
>> +0x007 SegmentIndex : 0x2 ''
>>
>> 0:004> dt _DPH_BLOCK_INFORMATION 0x08998f10-0x20
>> +0x000 StartStamp : 0xabcdaaa9
>> +0x004 Heap : 0x82281000
>> +0x008 RequestedSize : 0x1e1
>> +0x00c ActualSize : 0x209
>> +0x010 FreeQueue : _LIST_ENTRY [ 0x89992a8 - 0x7c88c580 ]
>> +0x010 FreePushList : _SINGLE_LIST_ENTRY
>> +0x010 TraceIndex : 0x92a8
>> +0x018 StackTrace : 0x00686f38
>> +0x01c EndStamp : 0xdcbaaaa9
>>
>> Anything else in the metadata that would help in identifying the
problem?
>>
>> Also, is RtlpDphReportCorruptedBlock documented somewhere, including
the
>> values for the 'reason' parameter?
>>
>> Thanks,
>> -Lance
>>
>>
>> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com>
wrote in message
>> news:ubYPVw1kIHA.3400@TK2MSFTNGP03.phx.gbl...
>>> VOID
>>> RtlpDphReportCorruptedBlock (
>>> PVOID Heap,
>>> ULONG Context,
>>> PVOID Block,
<<<<<<<<<<<<<<<<<<<
>>> ULONG Reason
>>> );
>>>
>>> Try to do a `!heap -p -a` on the third param to the function.
>>>
>>> --
>>>
>>> --
>>> This posting is provided "AS IS" with no warranties, and
confers no
>>> rights.
>>> Use of any included script samples are subject to the terms
specified at
>>> http://www.microsoft.com/info/cpyright.htm
>>>
>>>
>>> "Lance" <lances@nospam.nospam> wrote in message
>>> news:OWin2P1kIHA.5160@TK2MSFTNGP05.phx.gbl...
>>>>I have a .dmp file with heap corruption, where
>>>>RtlpDphAddToDelayedFreeQueue appears to detect a corrupt block
and calls
>>>>RtlpDphReportCorruptedBlock. How can I tell what block it
considers
>>>>corrupted in order to look at it? I haven't been able to find
any
>>>>documentation on the parameters to RtlpDphReportCorruptedBlock.
>>>> Stack trace and disassembly of the calling code below.
>>>> Thanks,
>>>> -Lance
>>>>
>>>> STACK_TEXT:
>>>> 077ff76c 7c85079b 02281000 077ff81c 077ff7f8
ntdll!DbgBreakPoint
>>>> 077ff77c 7c872081 0000000e 7c872344 02281000
>>>> ntdll!RtlpPageHeapStop+0x72
>>>> 077ff7f8 7c872781 02281000 00000009 08998f10
>>>> ntdll!RtlpDphReportCorruptedBlock+0x154
>>>> 077ff85c 7c873345 08a6b208 00000000 02281000
>>>> ntdll!RtlpDphAddToDelayedFreeQueue+0x120
>>>> 077ff880 7c8734c3 02281000 02380000 01001002
>>>> ntdll!RtlpDphNormalHeapFree+0x73
>>>> 077ff8d8 7c8766b9 02280000 01001002 08a6b228
>>>> ntdll!RtlpDebugPageHeapFree+0x146
>>>> 077ff940 7c860386 02280000 01001002 08a6b228
>>>> ntdll!RtlDebugFreeHeap+0x1ed
>>>> 077ffa18 7c81d77d 02280000 01001002 08a6b228
>>>> ntdll!RtlFreeHeapSlowly+0x37
>>>> 077ffafc 77bbcef6 02280000 01001002 08a6b228
ntdll!RtlFreeHeap+0x11a
>>>> 077ffb44 780c9043 08a6b228 077ffbb4 6705217a msvcrt!free+0xc3
>>>> 077ffb50 6705217a 00000001 00000000 048f8668
>>>>
msvcp60!std::basic_string<char,std::char_traits<char>,std::allocator<
;char>
>>>> >::_Tidy+0x27
>>>> ...
>>>>
>>>> 0:004> ub 0x7c872786 L20
>>>> ntdll!RtlpDphAddToDelayedFreeQueue+0xcd:
>>>> 7c87272e 84db test bl,bl
>>>> 7c872730 751b jne
>>>> ntdll!RtlpDphAddToDelayedFreeQueue+0xec (7c87274d)
>>>> 7c872732 c745c000020000 mov dword ptr [ebp-40h],200h
>>>> 7c872739 8945c8 mov dword ptr [ebp-38h],eax
>>>> 7c87273c 8d4dc0 lea ecx,[ebp-40h]
>>>> 7c87273f 51 push ecx
>>>> 7c872740 83c010 add eax,10h
>>>> 7c872743 50 push eax
>>>> 7c872744 6a09 push 9
>>>> 7c872746 6a00 push 0
>>>> 7c872748 e8f3f7ffff call
ntdll!RtlpDphReportCorruptedBlock
>>>> (7c871f40)
>>>>
>>>> 7c87274d 8b0d80c5887c mov ecx,dword ptr
>>>> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)]
>>>> 7c872753 8b01 mov eax,dword ptr [ecx]
>>>> 7c872755 a380c5887c mov dword ptr
>>>> [ntdll!RtlpDphDelayedFreeQueue (7c88c580)],eax
>>>> 7c87275a 897804 mov dword ptr [eax+4],edi
>>>> 7c87275d 8d71f0 lea esi,[ecx-10h]
>>>> 7c872760 8d5e20 lea ebx,[esi+20h]
>>>> 7c872763 6a01 push 1
>>>> 7c872765 8d45c0 lea eax,[ebp-40h]
>>>> 7c872768 50 push eax
>>>> 7c872769 53 push ebx
>>>> 7c87276a e895d8ffff call
ntdll!RtlpDphIsNormalFreeHeapBlock
>>>> (7c870004)
>>>> 7c87276f 84c0 test al,al
>>>> 7c872771 750e jne
ntdll!RtlpDphAddToDelayedFreeQueue+0x120
>>>> (7c872781)
>>>>
>>>> 7c872773 8d45c0 lea eax,[ebp-40h]
>>>> 7c872776 50 push eax
>>>> 7c872777 53 push ebx
>>>> 7c872778 6a09 push 9
>>>> 7c87277a 6a00 push 0
>>>> 7c87277c e8bff7ffff call
ntdll!RtlpDphReportCorruptedBlock
>>>> (7c871f40)
<<<<<<<<<<<<<
>>>>
>>>> 7c872781 ff0e dec dword ptr [esi]
>>>> 7c872783 ff4e1c dec dword ptr [esi+1Ch]
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
| Post Reply
|
|
|