View Full Version : How to analyze the full dump memory file of a process

August 11th, 2013, 20:36
I have used process explorer to dump a process memory.Also, I am using winhex to analyze the full dump file of a process. But when I use ReadProcessMemory function to read some value, the offset of a particular value differ from the offset of the dump file. I want to know why the offsets of a particular value are different. For example, the offset of MZ in dump file is 0x000CCBDB while I have to pass 0x00400000 offset in ReadProcessMemory function in order to read the same MZ value. Could anyone please explain why is this happening.

August 12th, 2013, 01:29
dump format is semi / UN Documented
to read dump file you would need to use dbgeng functions

it knows how to read the streams inside dump file look up documentation for IdebugAdvanced2 gAdvanced2->Request ();


if (( status = g_Advanced2->Request(







) ) != S_OK ) {

the dbgeng also knows where to map certain MZ (you will find Several MZ in the dump file corresponding to the dlls (modules ) that were loaded when the full dump was taken.

when you are using ReadProcessmemory you are required to provide the virtual address

so the main module if it was mapped at 0x400000 you would be requred to provide it
and the next time if aslr (address space layout randomization) was effective the module might have been mapped at 0x10000000
and for a live readprocessmemory session you have to provide 0x1000000 not 0x400000

August 12th, 2013, 11:20
Thanks a lot blabberer. Your explanation is just great..
I have one doubt regarding the full memory dump i.e whether the memory dump offsets are the virtual address offsets?

August 12th, 2013, 12:56

whether the memory dump offsets are the virtual address offsets?

a dump file doesn't have any concepts of virtual relative or absolute anything

it is a collection of streams

the header will have a pointer to the description of each type of stream

a module stream might contain (use dbgeng / dbghelp functions to access) list of modules
a xyz data stream might contain pointers to the location of xyz data
a thread stream might contains pointers to location / definition / context / ...... of the threads

you can fopen("foo.dump","rb" to open the dump and fseek() , ftell() fread() around yourself if you know how to traverse the streams

see some links on the file format header


August 12th, 2013, 18:51
Thanks Blabberer for such a nice explanation. One thing I want to point out that my dump file with .dmp extension is showing entirely different signature i.e the file signature starts with MDMP . I have taken full dump from procdump.

August 12th, 2013, 19:25
do not quote unnecessarily quote only selected parts if it is required absolutely
use reply to thread instead of reply with quote

yes it can have HDMP too iirc

like i said it is undocumented
PAGEDUMP PAGEDU64 etc are Signatures of page.sys that was forensically retrieved out of crashed but un rebooted machine
MDMP can be visual studio dump
iirc HDMP is from windbg .dump /ma command

it is undocumented so it can have anything who knows it can have BILL ATE MY DUMP too in some exotic os

F:\windbg>strings *.dll | grep -i dmp
F:\windbg\dbgeng.dll: .dmp
F:\windbg\dbgeng.dll: PAGE.DMP
F:\windbg\dbgeng.dll: VDMProcessException
F:\windbg\dbgeng.dll: .dmp
F:\windbg\dbgeng.dll: .mdmp
F:\windbg\dbgeng.dll: .hdmp
F:\windbg\dbgeng.dll: .kdmp
F:\windbg\dbgeng.dll: SDMPt
F:\windbg\dbgeng.dll: SDMPt
F:\windbg\dbgeng.dll: 9MDMPu
F:\windbg\dbgeng.dll: MDMP
F:\windbg\dbgeng.dll: hMDMP
F:\windbg\dbghelp.dll: MDMP
F:\windbg\dbghelp.dll: hMDMP
F:\windbg\dbghelp.dll: 8MDMPu
F:\windbg\sos.dll: Unable to enumerate any modules in the DMP file!
F:\windbg\sos.dll: <CustomActions1> !cce System.Configuration.ConfigurationException 1; j ($t1 = 1) '.dump /ma /u c:\dumps\mydump.dmp' ; '' </CustomActions1>


August 12th, 2013, 19:31

August 12th, 2013, 20:23
you can hope to see all these HEADER Signatures


User-defined comments
Address Disassembly Comment
00417E38 CMP DWORD PTR DS:[EDX], 45474150 PAGEDUMP
00418838 CMP DWORD PTR DS:[EDX], 45474150 PAGEDU64
0041A198 CMP DWORD PTR DS:[EDX], 45474150 PAGEDUMP
0041B148 CMP DWORD PTR DS:[EDX], 45474150 PAGEDU64
0041C138 CMP DWORD PTR DS:[EDX], 45474150 PAGEDUMP
0041CD58 CMP DWORD PTR DS:[EDX], 45474150 pageDU64
0041FF15 CMP DWORD PTR DS:[EDX], 52455355 USERDU64
00423284 CMP DWORD PTR DS:[ECX], 504D444D mdmp
00428F06 CMP EAX, DWORD PTR DS:[EDX+EE8] cedx,ceds,cedc

August 13th, 2013, 10:31
Yeah blabberer. Actually I got confused with executable file format. Because PE file format have a consistent MZ value, so I thought that even in memory dump there will be consistent format. But after reading post number 6, I got to know that file signature of dump file totally depends on which file the dump has been taken, e.g page.sys file, and from which environment dump has been collected i.e visual studio.
Thanks blabberer