Usermode and possible paged-out or corrupt data.

[Kjell Gunnar]

Environment: usermode dumps, very big MFC 70 app , XP SP2, Windbg
6.11.1.404.

Yes, I have read the previous thread, and understood from Ivan
Brugiolo that memory corruption is likely cause.

I have also a number of dumps where windbg shows this output.

Here is a sample of output at the end of lm:

Unloaded modules:
00720000 00e1002e Unknown_Module_00720000
00530073 00bc00db ocx
00062e05 006a2e69 x
00000fe1 4266610d _han.ocx
132c0000 132e7000 draft.ocx
Missing image name, possible paged-out or corrupt data.

But where in the dump or memory does windbg read when listing unloaded
modules ?
I want to try to set some traps to catch eventually wild writing
pointers

After little googleing I found RtlGetUnloadEventTrace:
http://msdn.microsoft.com/en-us/library/bb432428%28VS.85%29.aspx

ntdll!RtlGetUnloadEventTrace:
7c950e33 b8c0d8977c mov eax,offset ntdll!RtlpUnloadEventTrace

And examin the data from the array RtlpUnloadEventTrace shows sensible
Names and data:

Also is there chances to figure out what windbg think is corrupt ?

Thank you
Kjell Gunnar
========== See output here : ===========
My output from RtlpUnloadEventTrace is not that garbage as lm shows :

r? $t0 = @@masm(ntdll!RtlpUnloadEventTrace)
.echo Addr Base Size Time Module
.for(r $t2=0; @$t2 < 0n16; r $t2 = @$t2 + 1)
{
as /x $Addr @$t0
as /x $Base poi(@$t0)
as /x $Size poi(@$t0 + 4)
as /x $time poi( @$t0 + 4 * 3 )
as /mu ${/v:$Mod} @$t0 + (5*4)
.block
{
.echo ${$Addr}: ${$Base} ${$Size} ${$time} ${$Mod}

}
ad ${/v:$Addr}
ad ${/v:$Base}
ad ${/v:$Size}
ad ${/v:$time}
ad ${/v:$Mod}

r? $t0 = @$t0+ 0x0054

}

Addr Base Size Time Module
0x7c97d8c0: 0x132c0000 0x27000 0x4331500f draft.ocx
0x7c97d914: 0x13290000 0x1b000 0x4266512c disp_han.ocx
0x7c97d968: 0x13220000 0x63000 0x4a1837b2 ddg_a.ocx
0x7c97d9bc: 0x130c0000 0x36000 0x46666ab3 ctsShipWide.ocx
0x7c97da10: 0x13080000 0x2a000 0x48526a3c cb.ocx
0x7c97da64: 0x13050000 0x1f000 0x436b4e94 cargo_temp.ocx
0x7c97dab8: 0x13010000 0x29000 0x45dd5354 azimctr.ocx
0x7c97db0c: 0x12fd0000 0x22000 0x4845566a autro_pt.ocx
0x7c97db60: 0x12fa0000 0x1c000 0x483ff911 autro_oz.ocx
0x7c97dbb4: 0x12f60000 0x22000 0x48c51c67 autro_lp.ocx
0x7c97dc08: 0x12f20000 0x25000 0x41e27400 asc_upca.ocx
0x7c97dc5c: 0x12a10000 0x1a000 0x3d80544f anadata.ocx
0x7c97dcb0: 0x12420000 0x34000 0x46f29331 meas_dh.ocx
0x7c97dd04: 0x145d0000 0x5c000 0x4a8e9bc5 MMMCON~1.OCX
0x7c97dd58: 0x12a40000 0x38000 0x483e9793 sbmotor1.ocx
0x7c97ddac: 0x73420000 0x154000 0x41109750 MSVBVM60.DLL

[kim.k...@googlemail.com]

On Oct 20, 10:18 pm, Kjell Gunnar <ktens...@hotmail.com> wrote:
>
> Also is there chances to figure out what windbg think is corrupt ?
>

Have you tried the !analyze -v command? Take a look at
http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/
.

With best regards,
Kim Kulling

[Kjell Gunnar]

Hi,
Yes the !analyze prints out :
OVERLAPPED_MODULE: Address regions for '<One of my dll>' and
'Unknown_Module_00720000' overlap

Yes I regulary reads on www.dumpanalysis.org

Regards
Kjell Gunnar
On Oct 22, 3:15 pm, "kim.kull...@googlemail.com"

<kim.kull...@googlemail.com> wrote:
> On Oct 20, 10:18 pm, Kjell Gunnar <ktens...@hotmail.com> wrote:
>
>
>
> > Also is there chances to figure out what windbg think is corrupt ?
>

> Have you tried the !analyze -v command? Take a look athttp://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-t...