extract dump file from pagefile from non-booting machine

James_Harper · June 26, 2011, 8:55am

In doing some regression testing my driver crashed on install, and now
the system won’t boot (0x7B). I know why it won’t boot and I could
probably get it booting but it would be nice if I could take the dump
data out of the pagefile (which I can easily get to) on that machine and
construct a memory.dmp file from it. Is this possible? And is there an
existing tool to do it?

Thanks

James

NTDEV-26 · June 26, 2011, 9:51am

Pagefile will not have non-paged memory and moreover it is not certain that
pagefile will have updated data.

Converting it into a memory dump format would of any use?

Though, I remember sometime back I read sandman’s project, Matt Suiche’s had
developed some utilities on
hibernation to memory dump and vice versa conversion, however no conversion
from pagefile

-Deepak

On Sun, Jun 26, 2011 at 6:25 PM, James Harper > wrote:

> In doing some regression testing my driver crashed on install, and now
> the system won’t boot (0x7B). I know why it won’t boot and I could
> probably get it booting but it would be nice if I could take the dump
> data out of the pagefile (which I can easily get to) on that machine and
> construct a memory.dmp file from it. Is this possible? And is there an
> existing tool to do it?
>
> Thanks
>
> James
>
> —
> NTDEV 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
>

James_Harper · June 26, 2011, 10:11am

>

Pagefile will not have non-paged memory and moreover it is not certain
that
pagefile will have updated data.

Converting it into a memory dump format would of any use?

Though, I remember sometime back I read sandman’s project, Matt
Suiche’s had
developed some utilities on
hibernation to memory dump and vice versa conversion, however no
conversion
from pagefile

What I meant was, my machine crashed and wrote out the dump. As I
understand it, this gets done into the pagefile and then on the next
boot the data is moved from the pagefile into the memory.dmp file.
Unfortunately, although I can get to the filesystem the machine is now
unbootable so I don’t have a memory.dmp file, just a pagefile.

James

pradeep_bisht · June 26, 2011, 1:40pm

Many a time I had similar situtations and I just opened the pagefile.sys in windbg and was able to run !analyze -v and debug the BSOD. I remember reading it here that some process/utility at next reboot extracts .dmp from pagefile.sys but for me opening pagefile.sys has worked - may be I was just lucky.

Don_Burn_1 · June 26, 2011, 1:47pm

Actually, the dump file is written into the page file on the crash, and
on reboot it is renamed, and a new page file is created.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@yahoo.com” wrote in message
news:xxxxx@ntdev:

> Many a time I had similar situtations and I just opened the pagefile.sys in windbg and was able to run !analyze -v and debug the BSOD. I remember reading it here that some process/utility at next reboot extracts .dmp from pagefile.sys but for me opening pagefile.sys has worked - may be I was just lucky.

raj_r · June 26, 2011, 4:17pm

if you have copied the pagefile.sys from the non booting machine

you can simply use windbg on it directly with -z

like below

C:\Documents and Settings\Admin\Desktop>dir m*.*
Volume in drive C has no label.
Volume Serial Number is 9836-92E3

Directory of C:\Documents and Settings\Admin\Desktop

27/06/2011 00:50 417,939,456 MEMORY.DMP <- the truncated
pagefile.sys by smss.exe and renamed by savedump.exe
27/06/2011 03:58 629,145,600 MYTIMEPA.DMP <- copied and renamed
pagefile.sys with ntfsfordos from a virtual machine
2 File(s) 1,047,085,056 bytes
0 Dir(s) 4,829,061,120 bytes free

C:\Documents and Settings\Admin\Desktop>f:\windbg\612windbg\kd -z
MYTIMEPA.DMP -
c “!analyze -v;q”

Loading Dump File [C:\Documents and Settings\Admin\Desktop\MYTIMEPA.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: SRV*F:\symbols*
http://msdl.microsoft.com/download/symbols

Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
Debug session time: Mon Jun 27 00:16:45.949 2011 (UTC + 5:30)
System Uptime: 0 days 0:02:53.609
Loading Kernel Symbols
…
…
Loading User Symbols

Loading unloaded module list
…
*** ERROR: Module load completed but symbols could not be loaded for
BANG.SYS
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck DEADDEAD, {0, 0, 0, 0}

Probably caused by : BANG.SYS ( BANG+5b2 )

Followup: MachineOwner

kd> kd: Reading initial command ‘!analyze -v;q’
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

MANUALLY_INITIATED_CRASH1 (deaddead)
The user manually initiated this crash dump.
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xDEADDEAD

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from f7b585b2 to 805337e1

STACK_TEXT:
f7904c74 f7b585b2 deaddead 805a399d 82ded030 nt!KeBugCheck+0x14
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7904d4c 805a3c73 80000534 00000001 00000000 BANG+0x5b2
f7904d74 804e426b 80000534 00000000 82fc6640 nt!IopLoadUnloadDriver+0x45
f7904dac 8057aeff f414bcf4 00000000 00000000 nt!ExpWorkerThread+0x100
f7904ddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
BANG+5b2
f7b585b2 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: BANG+5b2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: BANG

IMAGE_NAME: BANG.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 4a044cfc

FAILURE_BUCKET_ID: 0xDEADDEAD_BANG+5b2

BUCKET_ID: 0xDEADDEAD_BANG+5b2

Followup: MachineOwner

or you can use dumpcheck.exe diretly on the pagefile.sys

C:\Documents and Settings\Admin\Desktop>f:\windbg\612windbg\dumpchk.exe
MYTIMEPA
.DMP > blah.txt
Loading dump file MYTIMEPA.DMP

C:\Documents and Settings\Admin\Desktop>

Use !analyze -v to get detailed debugging information.

BugCheck DEADDEAD, {0, 0, 0, 0}

Probably caused by : BANG.SYS ( BANG+5b2 )

Followup: MachineOwner

----- 32 bit Kernel Full Dump Analysis

DUMP_HEADER32:
MajorVersion 0000000f
MinorVersion 00000a28
KdSecondaryVersion 00000000
DirectoryTableBase 00039000
PfnDataBase 8103d000
PsLoadedModuleList 8055b1c0
PsActiveProcessHead 80561358
MachineImageType 0000014c
NumberProcessors 00000001
BugCheckCode deaddead
BugCheckParameter1 00000000
BugCheckParameter2 00000000
BugCheckParameter3 00000000
BugCheckParameter4 00000000
PaeEnabled 00000000
KdDebuggerDataBlock 8054cde0
SecondaryDataState 00000000
ProductType 00000001
SuiteMask 00000110

Physical Memory Description:
Number of runs: 3 (limited to 3)
FileOffset Start Address Length
00001000 0000000000001000 0009e000
0009f000 0000000000100000 00eff000
00f9e000 0000000001000000 17ef0000
Last Page: 0000000018e8d000 0000000018eef000

KiProcessorBlock at 8055a0c0
1 KiProcessorBlock entries:
ffdff120

or if you want to be extreme you can do all of it by hand like i did some
long time back

http://computer.forensikblog.de/en/2006/03/dmp_file_structure.html

rgrds

raj

On Sun, Jun 26, 2011 at 7:40 PM, James Harper > wrote:

> >
> > Pagefile will not have non-paged memory and moreover it is not certain
> that
> > pagefile will have updated data.
> >
> > Converting it into a memory dump format would of any use?
> >
> > Though, I remember sometime back I read sandman’s project, Matt
> Suiche’s had
> > developed some utilities on
> > hibernation to memory dump and vice versa conversion, however no
> conversion
> > from pagefile
> >
>
> What I meant was, my machine crashed and wrote out the dump. As I
> understand it, this gets done into the pagefile and then on the next
> boot the data is moved from the pagefile into the memory.dmp file.
> Unfortunately, although I can get to the filesystem the machine is now
> unbootable so I don’t have a memory.dmp file, just a pagefile.
>
> James
>
> —
> NTDEV 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
>

–
thanks and regards

raj_r

Jake_Oshins · June 26, 2011, 5:09pm

Pagefiles don’t exist until the boot device starts working. (There may be a stale one in the filesystem, but that won’t tell you anything interesting.) Dump files can’t exist until the boot device registers as the crash handler.

Bugcheck 0x7B means that the boot device never started.

There is no way to look at this after-the-fact with any file as the target.

Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

“raj_r” wrote in message news:xxxxx@ntdev…
if you have copied the pagefile.sys from the non booting machine

you can simply use windbg on it directly with -z

like below

C:\Documents and Settings\Admin\Desktop>dir m*.
Volume in drive C has no label.
Volume Serial Number is 9836-92E3

Directory of C:\Documents and Settings\Admin\Desktop

27/06/2011 00:50 417,939,456 MEMORY.DMP <- the truncated pagefile.sys by smss.exe and renamed by savedump.exe
27/06/2011 03:58 629,145,600 MYTIMEPA.DMP <- copied and renamed pagefile.sys with ntfsfordos from a virtual machine
2 File(s) 1,047,085,056 bytes
0 Dir(s) 4,829,061,120 bytes free

C:\Documents and Settings\Admin\Desktop>f:\windbg\612windbg\kd -z MYTIMEPA.DMP -
c “!analyze -v;q”

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Documents and Settings\Admin\Desktop\MYTIMEPA.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: SRVF:\symbolshttp://msdl.microsoft.com/download/symbols

Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
Debug session time: Mon Jun 27 00:16:45.949 2011 (UTC + 5:30)
System Uptime: 0 days 0:02:53.609
Loading Kernel Symbols
…
…
Loading User Symbols

Loading unloaded module list
…
ERROR: Module load completed but symbols could not be loaded for BANG.SYS
***************************************************************************
*
Bugcheck Analysis

Use !analyze -v to get detailed debugging information.

BugCheck DEADDEAD, {0, 0, 0, 0}

Probably caused by : BANG.SYS ( BANG+5b2 )

Followup: MachineOwner
---------

kd> kd: Reading initial command ‘!analyze -v;q’

Bugcheck Analysis
*
*******************************************************************************

MANUALLY_INITIATED_CRASH1 (deaddead)
The user manually initiated this crash dump.
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xDEADDEAD

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from f7b585b2 to 805337e1

STACK_TEXT:
f7904c74 f7b585b2 deaddead 805a399d 82ded030 nt!KeBugCheck+0x14
WARNING: Stack unwind information not available. Following frames may be wrong.
f7904d4c 805a3c73 80000534 00000001 00000000 BANG+0x5b2
f7904d74 804e426b 80000534 00000000 82fc6640 nt!IopLoadUnloadDriver+0x45
f7904dac 8057aeff f414bcf4 00000000 00000000 nt!ExpWorkerThread+0x100
f7904ddc 804f88ea 804e4196 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
BANG+5b2
f7b585b2 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: BANG+5b2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: BANG

IMAGE_NAME: BANG.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 4a044cfc

FAILURE_BUCKET_ID: 0xDEADDEAD_BANG+5b2

BUCKET_ID: 0xDEADDEAD_BANG+5b2

Followup: MachineOwner
---------

or you can use dumpcheck.exe diretly on the pagefile.sys

C:\Documents and Settings\Admin\Desktop>f:\windbg\612windbg\dumpchk.exe MYTIMEPA
.DMP > blah.txt
Loading dump file MYTIMEPA.DMP

C:\Documents and Settings\Admin\Desktop>

Use !analyze -v to get detailed debugging information.

BugCheck DEADDEAD, {0, 0, 0, 0}

Probably caused by : BANG.SYS ( BANG+5b2 )

Followup: MachineOwner
---------

----- 32 bit Kernel Full Dump Analysis

DUMP_HEADER32:
MajorVersion 0000000f
MinorVersion 00000a28
KdSecondaryVersion 00000000
DirectoryTableBase 00039000
PfnDataBase 8103d000
PsLoadedModuleList 8055b1c0
PsActiveProcessHead 80561358
MachineImageType 0000014c
NumberProcessors 00000001
BugCheckCode deaddead
BugCheckParameter1 00000000
BugCheckParameter2 00000000
BugCheckParameter3 00000000
BugCheckParameter4 00000000
PaeEnabled 00000000
KdDebuggerDataBlock 8054cde0
SecondaryDataState 00000000
ProductType 00000001
SuiteMask 00000110

Physical Memory Description:
Number of runs: 3 (limited to 3)
FileOffset Start Address Length
00001000 0000000000001000 0009e000
0009f000 0000000000100000 00eff000
00f9e000 0000000001000000 17ef0000
Last Page: 0000000018e8d000 0000000018eef000

KiProcessorBlock at 8055a0c0
1 KiProcessorBlock entries:
ffdff120

or if you want to be extreme you can do all of it by hand like i did some long time back

http://computer.forensikblog.de/en/2006/03/dmp_file_structure.html

rgrds

raj

On Sun, Jun 26, 2011 at 7:40 PM, James Harper wrote:

>
> Pagefile will not have non-paged memory and moreover it is not certain
that
> pagefile will have updated data.
>
> Converting it into a memory dump format would of any use?
>
> Though, I remember sometime back I read sandman’s project, Matt
Suiche’s had
> developed some utilities on
> hibernation to memory dump and vice versa conversion, however no
conversion
> from pagefile
>

What I meant was, my machine crashed and wrote out the dump. As I
understand it, this gets done into the pagefile and then on the next
boot the data is moved from the pagefile into the memory.dmp file.
Unfortunately, although I can get to the filesystem the machine is now
unbootable so I don’t have a memory.dmp file, just a pagefile.

James

—
NTDEV 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

–
thanks and regards

raj_r

James_Harper · June 26, 2011, 9:17pm

>

Pagefiles don’t exist until the boot device starts working. (There
may be a
stale one in the filesystem, but that won’t tell you anything
interesting.)
Dump files can’t exist until the boot device registers as the crash
handler.

Bugcheck 0x7B means that the boot device never started.

There is no way to look at this after-the-fact with any file as the
target.

The sequence of events was this:

boot windows
started installing driver
windows crashed (0xD1) and wrote dump file
system rebooted
crash during boot (0x7B)

It’s the dump file generated at #3 that I want, so renaming the pagefile
should work (or should have worked - I’ve since mounted the registry
hive in another machine and cleaned out the driver cruft to get it
booting again).

The 0x7B happened because my driver disables the emulated PCI IDE
devices and uses my PV block device driver instead, but the crash must
have occurred right at the point where my bus driver was installed my
the scsiport driver wasn’t properly installed.

Thanks

James