Windbg documents the existence of a -zp command which may be used to add
a pagefile to the debug context. The documentation states enigmatically
that “only specially-modified page files can be used.” But nowhere do I
find more specific instructions on how to modify a pagefile for use with
windbg. Would someone please elaborate on how, specifically, pagefiles
may be used with windbg?
Regards,
George.
iirc the major change is you need the header to be PAGE.DMP instead of
PAGEDUMP or PAGEDU64 which is default for 32 / 64 bit
refer IDebugClient4::AddDumpInformationFileWide method
Type [in]
Specifies the type of the file in FileName or FileHandle. Currently,
only files containing paging file information are supported, and Type
must be set to DEBUG_DUMP_FILE_PAGE_FILE_DUMP.
you can try reading
http://computer.forensikblog.de/en/2006/03/dmp-file-structure.html
http://computer.forensikblog.de/en/2008/02/64bit-crash-dumps.html
as i havent played with page file and windbg recently to recollect much
On 11/8/12, George M. Garner Jr. wrote:
> Windbg documents the existence of a -zp command which may be used to add
> a pagefile to the debug context. The documentation states enigmatically
> that “only specially-modified page files can be used.” But nowhere do I
> find more specific instructions on how to modify a pagefile for use with
> windbg. Would someone please elaborate on how, specifically, pagefiles
> may be used with windbg?
>
> Regards,
>
> George.
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
oops like i said i am rusty
the pagefiles that have PAGEDUMP or PAGEDU64 were probably pagefiles
that were carved out from crashed systems before rebooting they all
had a valid dump header of one page iirc
the normal pagefile (not sure but i just booted an iso in a vm and
scooped out a pagefile and rebooted normally and loaded the scooped
out pagefile.sys in a hexeditor and i find it doesnt have any header
at all the first 1000 bytes are empty
ill see what is the pagefile status is when i do a blue screen and post back
On 11/8/12, raj_r wrote:
> iirc the major change is you need the header to be PAGE.DMP instead of
> PAGEDUMP or PAGEDU64 which is default for 32 / 64 bit
>
>
> refer IDebugClient4::AddDumpInformationFileWide method
>
> Type [in]
> Specifies the type of the file in FileName or FileHandle. Currently,
> only files containing paging file information are supported, and Type
> must be set to DEBUG_DUMP_FILE_PAGE_FILE_DUMP.
>
> you can try reading
> http://computer.forensikblog.de/en/2006/03/dmp-file-structure.html
> http://computer.forensikblog.de/en/2008/02/64bit-crash-dumps.html
> as i havent played with page file and windbg recently to recollect much
>
>
>
> On 11/8/12, George M. Garner Jr. wrote:
>> Windbg documents the existence of a -zp command which may be used to add
>> a pagefile to the debug context. The documentation states enigmatically
>> that “only specially-modified page files can be used.” But nowhere do I
>> find more specific instructions on how to modify a pagefile for use with
>> windbg. Would someone please elaborate on how, specifically, pagefiles
>> may be used with windbg?
>>
>> Regards,
>>
>> George.
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
ok used osrbang let it write a dump
booted using an iso and copied the pagefile.sys to some place
rebooted normally and let savedump.exe write the memory.dump
and examined the pagefile.sys in xpsp3vm the PAGEDUMP signature exists
and if you supply that pagefile.sys via -zp you get corrupt error as
it seems to be checking for
PAGE.DMP hexing the header bytes
there seems to be no apparent error but not sure how it is going to work
a session of
-z memory.dmp
versus
-z memeory.dmp -zp mod_pagefile.sys
doesnt show any noticeable difference in the few minutes i poked around
here is the error where the PAGE.DMP is comapred to PAGEDUMP
00A1FB48 0104F268 USER32.MessageBoxW
00A1FB4C 002A03B0 hOwner = 002A03B0 ('WinDbg:6.12.0002.633
X86 ',class=‘WinDbgFrameClass’)
00A1FB50 01071F80 Text = “Unable to use ‘pagefile.sys’,
Win32 error 0n1392…The file or directory is corrupted and
unreadable.”
00A1FB54 01076280 Title = "WinDbg:6.12.0002.633 X86 "
00A1FB58 00002040 Style = MB_OK|MB_ICONASTERISK|MB_TASKMODAL
Memory map, item 35
Address=00920000
Size=00010000 (65536.)
Owner= 00920000 (itself)
Section=
Type=Map 00041002
Access=R
Initial access=R
Mapped as=\Device\HarddiskVolume4\windbg\pagefile.sys
Handles, item 44
Handle=000000B4
Type=File (sys)
Refs= 2.
Access=00120089 SYNCHRONIZE|READ_CONTROL|READ_DATA|READ_EA|READ_ATTRIBUTES
Info=Size 209715200. (0C800000) bytes
Name=f:\windbg\pagefile.sys
00920000 50 41 47 45 44 55 4D 50 0F 00 00 00 28 0A 00 00 PAGEDUMP…(…
00920010 00 90 03 00 00 00 00 81 C0 B1 55 80 58 13 56 80 .?..???U?XV?
022730A6 |. F3:A7 REPE CMPS
DWORD PTR ES:[EDI], DWORD PTR DS:[ESI]
ECX=00000002 (decimal 2.)
DS:[ESI]=[00920000]=45474150
ES:[EDI]=[020497B0]=45474150
dbgeng.AddTargetInfoFile+0A6
ECX=00000001 (decimal 1.)
DS:[ESI]=[00920004]=504D5544 DUMP
ES:[EDI]=[020497B4]=504D442E .DMP
dbgeng.AddTargetInfoFile+0A6
80070570
!error 80070570
Error code: (HRESULT) 0x80070570 (2147943792) - The file or directory
is corrupted and unreadable.
On 11/8/12, raj_r wrote:
> oops like i said i am rusty
> the pagefiles that have PAGEDUMP or PAGEDU64 were probably pagefiles
> that were carved out from crashed systems before rebooting they all
> had a valid dump header of one page iirc
>
> the normal pagefile (not sure but i just booted an iso in a vm and
> scooped out a pagefile and rebooted normally and loaded the scooped
> out pagefile.sys in a hexeditor and i find it doesnt have any header
> at all the first 1000 bytes are empty
>
> ill see what is the pagefile status is when i do a blue screen and post
> back
>
> On 11/8/12, raj_r wrote:
>> iirc the major change is you need the header to be PAGE.DMP instead of
>> PAGEDUMP or PAGEDU64 which is default for 32 / 64 bit
>>
>>
>> refer IDebugClient4::AddDumpInformationFileWide method
>>
>> Type [in]
>> Specifies the type of the file in FileName or FileHandle. Currently,
>> only files containing paging file information are supported, and Type
>> must be set to DEBUG_DUMP_FILE_PAGE_FILE_DUMP.
>>
>> you can try reading
>> http://computer.forensikblog.de/en/2006/03/dmp-file-structure.html
>> http://computer.forensikblog.de/en/2008/02/64bit-crash-dumps.html
>> as i havent played with page file and windbg recently to recollect much
>>
>>
>>
>> On 11/8/12, George M. Garner Jr.
>> wrote:
>>> Windbg documents the existence of a -zp command which may be used to add
>>> a pagefile to the debug context. The documentation states enigmatically
>>> that “only specially-modified page files can be used.” But nowhere do I
>>> find more specific instructions on how to modify a pagefile for use with
>>> windbg. Would someone please elaborate on how, specifically, pagefiles
>>> may be used with windbg?
>>>
>>> Regards,
>>>
>>> George.
>>>
>>> —
>>> WINDBG is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>
raj_r.
Thanks for taking the time to respond. When the system generates a
crashdump, the dump information is written to the first system pagefile.
When the system reboots this pagefile is renamed to " memory.dmp" and
a new pagefile is created. Maybe someone from MS can clarify whether
there are any changes made to the dump file information in the process.
However, my understanding is that it is simply renamed. In this light
I don’t see much difference between adding a "
DEBUG_DUMP_FILE_PAGE_FILE_DUMP" and adding a regular crash dump. What I
was looking to do is to add a pagefile that contains paged virtual
address contents to support resolution of soft PTE’s. I gather that
this is not something that Windbg currently supports, though the
following line in the documentation suggests (erroneously, it would
seem), that it might: “This is useful if you are debugging a dump file
and want to use the .pagein (Page In Memory) command.”
Regards,
George.
This feature has been in the debugger for quite a while, though I have never
seen any public documentation on how you a) preserve or b) format
complementary paging files (though long ago there was a company that claimed
to have a product).
The fact that you can now write your crashdump file to someplace other than
pagefile.sys (see DedicatedDumpFile) probably solves the problem of
preserving the contents, but I’m pretty sure the necessary format is still
undocumented. A neat feature in theory though.
-scott
OSR
“George M. Garner Jr.” wrote in message news:xxxxx@windbg…
raj_r.
Thanks for taking the time to respond. When the system generates a
crashdump, the dump information is written to the first system pagefile.
When the system reboots this pagefile is renamed to " memory.dmp" and
a new pagefile is created. Maybe someone from MS can clarify whether
there are any changes made to the dump file information in the process.
However, my understanding is that it is simply renamed. In this light
I don’t see much difference between adding a "
DEBUG_DUMP_FILE_PAGE_FILE_DUMP" and adding a regular crash dump. What I
was looking to do is to add a pagefile that contains paged virtual
address contents to support resolution of soft PTE’s. I gather that
this is not something that Windbg currently supports, though the
following line in the documentation suggests (erroneously, it would
seem), that it might: “This is useful if you are debugging a dump file
and want to use the .pagein (Page In Memory) command.”
Regards,
George.
Scott,
Thanks for taking the time to respond. I don’t think that preserving a
pagefile is all that great a technical problem. Using the pagefile once
preserved is another matter. I gather from your last post that
DEBUG_DUMP_FILE_PAGE_FILE_DUMP does indeed refer to a page file,
possibly with some special formatting, and not a crash dump file that is
waiting to be renamed to “memory.dmp.” If MS is going to expose this
functionality at all they should at least document the feature enough to
actually make use of it.
Regards,
gmg.
“George M. Garner Jr.” wrote in message news:xxxxx@windbg…
I gather from your last post that DEBUG_DUMP_FILE_PAGE_FILE_DUMP does
indeed refer to a page file, possibly with some special formatting, and not
a crash dump file that is waiting to be renamed to “memory.dmp.”
Correct, that’s the idea (as I understand it, at least…I’ve never bothered
to go any further and actually try to make it work).
-scott
OSR
“George M. Garner Jr.” wrote in message news:xxxxx@windbg…
Scott,
Thanks for taking the time to respond. I don’t think that preserving a
pagefile is all that great a technical problem. Using the pagefile once
preserved is another matter. I gather from your last post that
DEBUG_DUMP_FILE_PAGE_FILE_DUMP does indeed refer to a page file,
possibly with some special formatting, and not a crash dump file that is
waiting to be renamed to “memory.dmp.” If MS is going to expose this
functionality at all they should at least document the feature enough to
actually make use of it.
Regards,
gmg.
Hmmm! Let’s see:
dbgeng!?xxxxx@KernelFullSumDumpTargetInfo@@UAEJK_KPAXK@Z.
On 11/8/12, George M. Garner Jr. wrote:
> this is not something that Windbg currently supports, though the
> following line in the documentation suggests (erroneously, it would
> seem), that it might: “This is useful if you are debugging a dump file
> and want to use the .pagein (Page In Memory) command.”
no the .pagein wont work on dumpfile
first there is a bitmask that simply would return back syntax error
0x66 & 0x1A instead of 0x8000ffff & 0x1a
(so this is a feature that is probably taking wings and might fly in
some future versions )
you can keep on bypassing and windbg will keep on failing all the way
upto Read/Write~Virtual() and back
32-bit Kernel triage dump: f:\mini.dmp
Microsoft (R) Windows Debugger Version 6.2.9200.16384 X86
Copyright (c) Microsoft Corporation. All rights reserved.
command line: ‘“C:\Program Files\Windows
Kits\8.0\Debuggers\x86\windbg.exe” -z f:\mini.dmp -zp f:\pagefile.sys’
Debugger Process 0xAEC
kd> .pagein
Pagein requires an address to be specified
kd> .pagein fcc08000
Pagein operations are only supported for user mode addresses due to
limitations in the memory manager
kd> .pagein 7fdf0000
This operation only works on live kernel debug sessions
PageIn for address 7fdf0000, process 00000000 failed
kd> .pagein /f 7fdf0000
This operation only works on live kernel debug sessions
PageIn for address 7fdf0000, process 00000000 failed
kd> .pagein /p @$proc /f 7fdf0000
This operation only works on live kernel debug sessions
PageIn for address 7fdf0000, process f78b45e2 failed
kd> .pagein /p @$proc /f 7fdf0000
Could not determine status or debugger worker thread
PageIn for address 7fdf0000, process f78b45e2 failed
kd> .pagein /p @$proc /f 7fdf0000
This operation only works on live kernel debug sessions
PageIn for address 7fdf0000, process f78b45e2 failed
kd> .pagein /p @$proc /f 7fdf0000
DbsSplayTreeRangeMap::Add: Conflicting region 804d7580 - 80549aff
Unable to map ntoskrnl.exe region at 804d7580, NTSTATUS 0xC0000018
You need to continue execution (press ‘g’ ) for the pagein to
be brought in. When the debugger breaks in again, the page will be
present.
raj_r,
Read Scott Noone’s post above in this thread. The functionality is in
Windbg (or more properly dbgeng.dll) to translate soft (pagefile) PTE’s.
You have to add one or more specially formatted pagefiles BEFORE
opening the crashdump file; and the pagefiles need to be specially
formatted with an undocumented header that begins with the string
“PAGE.DMP” as the first 8 bytes. What you are seeing is Windbg silently
fail when you attempt to add the pagefile without the required header.
What is missing from the documentation is how to format the pagefile so
that Windbg will recognize it, There must be (or at least at one time
have been) a tool which does this. Microsoft needs to explain what tool
this is, or at least document the header in general terms.
Regards,
gmg.
On 11/9/12, George M. Garner Jr. wrote:
> raj_r,
>
> Read Scott Noone’s post above in this thread. The functionality is in
> Windbg (or more properly dbgeng.dll) to translate soft (pagefile) PTE’s.
> You have to add one or more specially formatted pagefiles BEFORE
> opening the crashdump file; and the pagefiles need to be specially
> formatted with an undocumented header that begins with the string
> “PAGE.DMP” as the first 8 bytes. What you are seeing is Windbg silently
> fail when you attempt to add the pagefile without the required header.
> What is missing from the documentation is how to format the pagefile so
> that Windbg will recognize it, There must be (or at least at one time
> have been) a tool which does this. Microsoft needs to explain what tool
> this is, or at least document the header in general terms.
>
> Regards,
>
> gmg.
oops i must have missed that mail let me check the forum
On 11/8/2012 11:26 AM, Scott Noone wrote:
“George M. Garner Jr.” wrote in message news:xxxxx@windbg…
> I gather from your last post that DEBUG_DUMP_FILE_PAGE_FILE_DUMP does
> indeed refer to a page file, possibly with some special formatting,
> and not a crash dump file that is waiting to be renamed to “memory.dmp.”Correct, that’s the idea (as I understand it, at least…I’ve never
bothered to go any further and actually try to make it work).-scott
OSR
Windbg will load any file that starts with “PAGE.DMP” as a dump
information file. However, you have to load both the dump information
file and dump file from the command line or the information file never
get’s loaded: windbg.exe -zp d:\pagefile.sys -z memory.dmp. The
.pagein command is broke, however, for the purposes of crashdump
analysis. Only the kernel debug pagein is implemented. There doesn’t
appear to be any control path that leads to the debug engines
ReadPageFile function. Even if it did, the method by which the PTE’s
pagefile offset is translated into a file offset reflects a level of
indirection that is not used by the current page fault handler. Maybe
it was used back in the Windows 3.1 days. Even assuming one were to get
past this hurdle the PageFileOffset function contains a bug (even in
64-bit builds) that truncates the file offset to a 32-bit unsigned
integer. The long and the short of it being that I think that it would
be easier to start over than to try and use the debug engine implementation.
MS should revise the windbg documentation to remove reference to the -zp
option and the dead code should be removed from the debug engine,
particularly in the version that ships with the OS.
Regards,
george.