How to extract a crash dump from a swap file?

Dmitriy_Budko · June 19, 2007, 1:48am

I have a Windows system and it BSODs and writes memory dump into the swap
file on boot. Safe mode doesn’t help (or impossible to enter). Without
successfully booting it is not possible to get the dump file. Is a way to
mount the hard drive / file system that contains the swap file with the dump
and extract the dump manually?

Dmitriy Budko
VMware

anton_bassov · June 19, 2007, 4:01am

Dmitry,

I am afraid that doing it on the same machine is rather problematic. Apparently, what you have to do here is to examine the disk (it is understandable that you have to insert it into a bootable machine) - as long as you are able to understand NTFS, you can locate the data that you are interested in without a slightest problem. After all, this is what the forensic analysis of disks is all about, so that the whole thing is definitely feasible…

Anton Bassov

Mark_Roddy · June 19, 2007, 7:05am

At the risk of asking the obvious, why not attach a debugger and do a live
analysis?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-290662-
xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Tuesday, June 19, 2007 1:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to extract a crash dump from a swap file?

I have a Windows system and it BSODs and writes memory dump into the
swap
file on boot. Safe mode doesn’t help (or impossible to enter). Without
successfully booting it is not possible to get the dump file. Is a way
to
mount the hard drive / file system that contains the swap file with the
dump
and extract the dump manually?

Dmitriy Budko
VMware

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Maxim_S_Shatskih · June 19, 2007, 10:32am

Try to mount it from under FreeBSD/Linux and copy %SystemRoot%\MEMORY.DMP
to some other location outside this volume.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Dmitriy Budko” wrote in message news:xxxxx@ntdev…
I have a Windows system and it BSODs and writes memory dump into the swap
file on boot. Safe mode doesn’t help (or impossible to enter). Without
successfully booting it is not possible to get the dump file. Is a way to
mount the hard drive / file system that contains the swap file with the dump
and extract the dump manually?

Dmitriy Budko
VMware

Skywing · June 19, 2007, 10:39am

You might also be able to use a WinPE/BartPE boot CD to gain NTFS read
access + network access and copy the file to a net share somewhere else.

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> Try to mount it from under FreeBSD/Linux and copy
> %SystemRoot%\MEMORY.DMP
> to some other location outside this volume.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Dmitriy Budko” wrote in message news:xxxxx@ntdev…
> I have a Windows system and it BSODs and writes memory dump into the swap
> file on boot. Safe mode doesn’t help (or impossible to enter). Without
> successfully booting it is not possible to get the dump file. Is a way to
> mount the hard drive / file system that contains the swap file with the
> dump
> and extract the dump manually?
>
>
> Dmitriy Budko
> VMware
>
>

Tim_Roberts · June 19, 2007, 12:56pm

Maxim S. Shatskih wrote:

Try to mount it from under FreeBSD/Linux and copy %SystemRoot%\MEMORY.DMP
to some other location outside this volume.

Perhaps I am mistaken, but I thought that the live memory dump was
buried in the swap file, and was not actually copied to MEMORY.DMP until
part way through a successful boot. If you really can’t through a boot,
then there’s a chance MEMORY.DMP doesn’t actually exist yet.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Maxim_S_Shatskih · June 19, 2007, 1:17pm

> Maxim S. Shatskih wrote:

> Try to mount it from under FreeBSD/Linux and copy %SystemRoot%
\MEMORY.DMP
> to some other location outside this volume.
>

Perhaps I am mistaken, but I thought that the live memory dump was
buried in the swap file, and was not actually copied to MEMORY.DMP until
part way through a successful boot. If you really can’t through a boot,
then there’s a chance MEMORY.DMP doesn’t actually exist yet.

Yes, Tim, surely you’re correct. PAGEFILE.SYS should be used instead of
MEMORY.DMP

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

OSR_Community_User · June 19, 2007, 3:58pm

What the KeBugCheckEx does is it uses an alternate storage stack with the
dump_ prefix. After a check to make sure the drivers are ok (you never know
when you BSOD), the data is written RAW at the sector address of the paging
file, bypassing the file system (or the whole storage stack, for that
matter). Note that in Windows Vista the storage stack is not bypassed
anymore AFAIK.

When paging is activated, the system looks into the paging file of the boot
volume to see if there is a dump (***hint*** this means there is a pattern
in the dump). If yes, this part will be marked as unusable, until the system
checks the page file again later in the boot process and extracts it.

Amusingly enough, this is the system used for hibernation, except it reads
from/writes to hiberfil.sys instead.

=> you don’t need to understand the file system, you can do a raw edit of
the disk and look for the header of a memory dump (if you have only one the
disk). Unfortunately I don’t have one at hand to tell you what the header
is, but this should worx0r.

=> Live CD is a good alternative.

=> Depending on the configuration of your dumps, the dump may fail if your
pagefile is not big enough. You need as much as your whole memory + 1 MB for
full dumps.

=> w00t arrows!

–

Edouard A.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-290722-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: mardi 19 juin 2007 18:56
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to extract a crash dump from a swap file?

Maxim S. Shatskih wrote:
> Try to mount it from under FreeBSD/Linux and copy
%SystemRoot%\MEMORY.DMP
> to some other location outside this volume.
>

Perhaps I am mistaken, but I thought that the live memory dump was
buried in the swap file, and was not actually copied to MEMORY.DMP
until
part way through a successful boot. If you really can’t through a
boot,
then there’s a chance MEMORY.DMP doesn’t actually exist yet.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Dmitriy_Budko · June 19, 2007, 7:51pm

> > Maxim S. Shatskih wrote:

> > Try to mount it from under FreeBSD/Linux and copy %SystemRoot%
>\MEMORY.DMP
> > to some other location outside this volume.
> >
>
> Perhaps I am mistaken, but I thought that the live memory dump was
> buried in the swap file, and was not actually copied to MEMORY.DMP until
> part way through a successful boot. If you really can’t through a boot,
> then there’s a chance MEMORY.DMP doesn’t actually exist yet.

Yes, Tim, surely you’re correct. PAGEFILE.SYS should be used instead of
MEMORY.DMP

–
Maxim Shatskih, Windows DDK MVP

Getting PAGEFILE.SYS is easy. I want to know the difficult part: how to
extract MEMORY.DMP from PAGEFILE.SYS? How difficult is to figure it out: 1
hour, 1 day, 1 week?

Is the standard .dmp header with the ‘PAGE’ & ‘DUMP’ signature already in the
.SYS paging file?

Dmitriy Budko
VMware

anton_bassov · June 19, 2007, 9:45pm

Dmitry,

Getting PAGEFILE.SYS is easy. I want to know the difficult part: how to
extract MEMORY.DMP from PAGEFILE.SYS?

Actually, judging from how your original post was formulated, I thought that you are unable to locate a paging file on the disk…

Concerning extracting MEMORY.DMP from PAGEFILE.SYS, I think the keyword is “%systemroot% Savedump.exe” - this program is used for extracting a crash dump from the page file and copying it to the final destination. Disassemble it with IDA, analyze its code and try to understand what it does.

How difficult is to figure it out: 1 hour, 1 day, 1 week?

I would give you an answer in terms of size, rather than time - the size of its code it just 0x2400 bytes, i.e. just a bit more than 2 pages. Apparently, the lion’s share of work is done by imported libraries, rather than by its own code, which seems to simplify your task quite a lot…

Anton Bassov

anton_bassov · June 20, 2007, 12:31am

Dmitry,

Taking into consideration out earlier discussions, I somehow presume your plans are going much further than simply retrieving a crash dump of a machine that you cannot boot - apparently, you just want to figure out how it all works. Therefore, following my previous post, I can tell you that there is one more keyword, namely, NtQuerySystemInformation(), infoclass 34 - it tells you whether crash dump exists in the pagefile, although it does not attempt to retrieve it. When you boot the system, Winlogon first calls NtQuerySystemInformation() in order to figure out whether a crash dump exists in the pagefile, and if it does, it launches Savedump.exe that actually retrieves and relocates it. To summarize, get ready to do some disassembly…

Anton Bassov

OSR_Community_User · June 20, 2007, 1:17am

Dmitriy Budko wrote:

Getting PAGEFILE.SYS is easy. I want to know the difficult part: how to
extract MEMORY.DMP from PAGEFILE.SYS?

The following procedure might probably work:

Extract the page file (easy as you say).
Copy the page file over a different but similar Windows installation (probably same OS version is enough) that is currently shutted down.
Boot that second Windows. Probably you will get your dump file.

I assume the save dump procedure doesn’t check the dump file content (why it should?). It probably only looks for the signature and size. If so, this should work.

anton_bassov · June 20, 2007, 2:16am

> - Copy the page file over a different but similar Windows installation (probably

same OS version is enough)

The same OS version is DEFINITELY not enough here, because:

The size of the paging file may be different for different machines - it depends on the amount of
physical memory on the target machine ( paging file of the size approx 1.5 of that of physical RAM is considered normal), as well as on configuration
The structure of the paging file may be different for different machines - Windows allows paging file to be split into several files (IIRC, 16 is the maximum), so that it depends on how the target machine is configured

Therefore, in order for your approach to work, machines must have not only the same OS version, but the same size and structure of the paging file as well (which implies they must have the same amount of RAM and identical configuration)

Anton Bassov

Maxim_S_Shatskih · June 20, 2007, 6:32am

>Getting PAGEFILE.SYS is easy. I want to know the difficult part: how to

extract MEMORY.DMP from PAGEFILE.SYS?

I do not think this is complex.

Reason: this works very quickly on usual Windows boot, surely this does not
involve the data copy from the page file. Maybe truncating the pagefile is
enough.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

raj_r · June 20, 2007, 12:03pm

i too was interseted in knowing what swap files contain and how it
works for quiet some time now

so this thread provided me an oppurtutnity to look at it really

it looks like its pretty easy to recover the memory dump (atleast a
complete memory dump i havent checked out a minidump yet)

ill post what i did below and may be if there are questions i will be
happy to answer
and or take the flames if it is the case

my vm is vpc 2004
image on vpc == w2k sp4
formatted with fat (may be ntfs would be different)

opened vpc 2004 w2k sp4
vpc is running at 48 mb allocated ram

changed the virtual memory in
mycomputers-> properties-> advanced -> startup and recovery
to 96 mb start / 96 mb max

disabled the automatically reboot option
in startup and recovery

changed the minidump to complete memory dump

downloaded the osronline bang in host and drag dropped it to w2k
downloaded winhex trial version ( i wanted the dos winhex replica
but they are not offering a trial for it) and drag dropped it
to vpc
downloaded a bootfloppy image (virtual floppy drive image)
drag dropped windbg 6.7.5 and installed it

in vpc -> capture floppy disk image

ran bang and crashed the w2k it wrote the dmp in bsod

action reset

boot via floppy now

c:

attrib -s -h -r pagefile.sys

copy pagefile.sys “*desktop*”

remove boot floppy image

ctrl+alt+del (right alt +del)

now windows will boot and then it will do its duty
and save a memory.dmp in c:\winnt

copied it to “*desktop*”

drag dropped windbg 6.7.5 and installed it in vpc

opened crash dump the one windows saved after booting
c:\winnt\memory.dmp(sorry no symbols yet)

?: kd> !analyze -v
GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147
Unable to get program counter
GetContextState failed, 0xD0000147
Unable to get current machine context, NTSTATUS 0xC0000147
GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.
MODULE_NAME: nt

FAULTING_MODULE: 80400000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 384d9b17

BUGCHECK_STR: MANUALLY_INITIATED_CRASH

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

STACK_TEXT:
GetContextState failed, 0xD0000147
Unable to get current machine context, NTSTATUS 0xC0000147

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

looks like the pagefile.sys contains everything in start

see the fcompare it simply didnt find any differnces till file size mattered

On 6/20/07, Maxim S. Shatskih wrote:
> >Getting PAGEFILE.SYS is easy. I want to know the difficult part: how to
> >extract MEMORY.DMP from PAGEFILE.SYS?
>
> I do not think this is complex.
>
> Reason: this works very quickly on usual Windows boot, surely this does not
> involve the data copy from the page file. Maybe truncating the pagefile is
> enough.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

raj_r · June 20, 2007, 12:07pm

On 6/20/07, raj_r wrote:
> i too was interseted in knowing what swap files contain and how it
> works for quiet some time now
>
> so this thread provided me an oppurtutnity to look at it really
>
> it looks like its pretty easy to recover the memory dump (atleast a
> complete memory dump i havent checked out a minidump yet)
>
> ill post what i did below and may be if there are questions i will be
> happy to answer
> and or take the flames if it is the case

it looks like only half got posted so reposting again

opened vpc 2004 w2k sp4
vpc is running at 48 mb allocated ram

changed the virtual memory in
mycomputers-> properties-> advanced -> startup and recovery
to 96 mb start / 96 mb max

disabled the automatically reboot option
in startup and recovery

changed the minidump to complete memory dump

downloaded the osronline bang in host and drag dropped it to w2k
downloaded winhex trial version ( i wanted the dos winhex replica
but they are not offering a trial for it) and drag dropped it
to vpc
downloaded a bootfloppy image (virtual floppy drive image)
drag dropped windbg 6.7.5 and installed it

in vpc -> capture floppy disk image

ran bang and crashed the w2k it wrote the dmp in bsod

action reset

boot via floppy now

c:

attrib -s -h -r pagefile.sys

copy pagefile.sys “desktop”

remove boot floppy image

ctrl+alt+del (right alt +del)

now windows will boot and then it will do its duty
and save a memory.dmp in c:\winnt

copied it to “desktop”

drag dropped windbg 6.7.5 and installed it in vpc

opened crash dump the one windows saved after booting
c:\winnt\memory.dmp(sorry no symbols yet)

?: kd> !analyze -v
GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147
Unable to get program counter
GetContextState failed, 0xD0000147
Unable to get current machine context, NTSTATUS 0xC0000147
GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147

Bugcheck Analysis

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

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

**Kernel symbols are WRONG. Please fix symbols to do analysis.
MODULE_NAME: nt

FAULTING_MODULE: 80400000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 384d9b17

BUGCHECK_STR: MANUALLY_INITIATED_CRASH

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

STACK_TEXT:
GetContextState failed, 0xD0000147
Unable to get current machine context, NTSTATUS 0xC0000147

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

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

do a file compare

desktop:/>dir
Volume in drive C has no label.
Volume Serial Number is 3A2B-16E8

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

01/07/2007 06:11p .
01/07/2007 06:11p …
06/20/2007 07:59p 50,331,648 PAGEFILE.SYS
06/20/2007 08:03p 8,192 BANG_v1
06/20/2007 08:51p winhex
06/20/2007 08:49p 33,083,392 MEMORY.DMP
04/28/2007 09:33p 16,591,704 dbg_x86_6.7.05.0.exe
06/20/2007 08:59p dbg_x86_6.7.05.0
06/20/2007 09:18p 2,487 checkswap.txt
5 File(s) 100,017,423 bytes
4 Dir(s) 16,221,536,256 bytes free

desktop:/>fc /b memory.dmp pagefile.sys
Comparing files MEMORY.DMP and PAGEFILE.SYS
FC: PAGEFILE.SYS longer than MEMORY.DMP

desktop:/>

desktop:/>windbg -z c:\docume~1\admini~1\desktop\pagefile.sys

desktop:/>

opened the pagefile.sys as crash dump

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

Loading Dump File [c:\docume~1\admini~1\desktop\pagefile.sys]
Kernel Complete Dump File: Full address space is available

Symbol search path is: Invalid ***

result of analyze -v

MODULE_NAME: nt

FAULTING_MODULE: 80400000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 384d9b17

BUGCHECK_STR: MANUALLY_INITIATED_CRASH

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

STACK_TEXT:
GetContextState failed, 0xD0000147
Unable to get current machine context, NTSTATUS 0xC0000147

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

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

GetContextState failed, 0xD0000147
GetContextState failed, 0xD0000147

OSR_Community_User · June 20, 2007, 3:06pm

anton bassov wrote:

> - Copy the page file over a different but similar Windows installation
> (probably same OS version is enough)

The same OS version is DEFINITELY not enough here, because:

The size of the paging file may be different for different machines …

The structure of the paging file may be different for different machines …

Of course that I don’t know for sure if same OS version would be enough, but I suspect so and it would make sense. Actually, it is *possible* that this might even work across different OS versions.

Windows doesn’t rely on the *previous* state of the paging files (except for extracting the dump file). You can delete or resize all the page files when it is shutted down, and Windows will recreate the page files as needed on reboot. This is needed, among other reasons, because the amount of RAM could perfectly be different since the previous boot.

When Windows extracts the dump file it is *probably* as flexible as possible. The configuration might be different since the previous boot that caused a BSOD. It wouldn’t be so uncommon to remove hardware, or even RAM if the user suspect that was the reason of the crash. It would also be quite normal to start in safe mode, or in some alternate configuration. So I would expect that Windows doesn’t care too much about the exact content of the dump and page file. I would expect it looks for a signature and some kind of header and not much more.

The page file size do might be important for temporary paging purposes. Windows can’t overwrite the dump file until it was copied/extracted. So if the page file is too small, you might have problems. Then in the worst case, I would expect that you only need to make sure that the page file is big enough, which would be trivial to do.

Seems that later OS versions just truncate the page file and rename it to a temporary. This would match Maxim’s idea that the dump is written at the very beginning of the page file. Actually, it is possible that you could use the page file directly. Furthermore, “savedump.exe” seems to accept some parameters, it is possible then that you can just run savedump to copy/extract the dump from your saved copy of the page file.

anton_bassov · June 20, 2007, 5:43pm

> Windows doesn’t rely on the *previous* state of the paging files (except for

extracting the dump file).

Try to think about it in context of a problem that we discuss. Unless we speak of minidump, the size of the fill memory dump may be HUGE. What if currently existing page file on the target disk is not large enough to hold it??? Therefore, you will have to allocate some extra disk space (it is understandable that you have to do everything on the machine that is currently booted - as far as this machine is concerned, both source and destination disks are nothing more than additional disks, so that the OS has not been loaded from the destination disk). In other words, the OS that resides on destination disk has no clue about anything - the state and *actual* size of the pagefile has changed while the OS was off.

So I would expect that Windows doesn’t care too much about the exact content
of the dump and page file.

Probably, not, but still it may check if registry settings correspond to the actual state of the machine, just in order to ensure consistenct of operations. I am afraid that you are more than likely to screw up the existing installation with such approach. In practical terms, the maximum I would risk here is just copying *contents* of the pagefile if there is sufifcient space - anything else may be quite dodgy (although it may be quite interesting exercise in hacking if you do it on the test machine that you don’t really care about - you gave me quite an interesting idea to experiment with)

Anton Bassov

raj_r · June 21, 2007, 1:59pm

subsequent to yesterdays dumping and loading it as dump in windbg i thought ill
try to utilize savedump.exe and try ripping off a memory.dmp from it

i was using xp savedump.exe on a pagefile.sys copied from w2k crash

didnt work still it was nice to know how it works
an assembly level tracing commeted is in below link
http://blufferisme.googlepages.com/experimentswithpagefile.sysandsavedump.e

google pages is weird cut off the exe to e no .html or htm or .asp
at the end

On 6/20/07, raj_r wrote:
> On 6/20/07, raj_r wrote:
> > i too was interseted in knowing what swap files contain and how it
> > works for quiet some time now
> >
> > so this thread provided me an oppurtutnity to look at it really
> >
> > it looks like its pretty easy to recover the memory dump (atleast a
> > complete memory dump i havent checked out a minidump yet)
> >
> > ill post what i did below and may be if there are questions i will be
> > happy to answer
> > and or take the flames if it is the case
>
>
> it looks like only half got posted so reposting again
>
> opened vpc 2004 w2k sp4
> vpc is running at 48 mb allocated ram
>
> changed the virtual memory in
> mycomputers-> properties-> advanced -> startup and recovery
> to 96 mb start / 96 mb max
>
> disabled the automatically reboot option
> in startup and recovery
>
> changed the minidump to complete memory dump
>
> downloaded the osronline bang in host and drag dropped it to w2k
> downloaded winhex trial version ( i wanted the dos winhex replica
> but they are not offering a trial for it) and drag dropped it
> to vpc
> downloaded a bootfloppy image (virtual floppy drive image)
> drag dropped windbg 6.7.5 and installed it
>
> in vpc -> capture floppy disk image
>
> ran bang and crashed the w2k it wrote the dmp in bsod
>
> action reset
>
> boot via floppy now
>
> c:
>
> attrib -s -h -r pagefile.sys
>
> copy pagefile.sys “desktop”
>
> remove boot floppy image
>
> ctrl+alt+del (right alt +del)
>
> now windows will boot and then it will do its duty
> and save a memory.dmp in c:\winnt
>
> copied it to “desktop”
>
> drag dropped windbg 6.7.5 and installed it in vpc
>
> opened crash dump the one windows saved after booting
> c:\winnt\memory.dmp(sorry no symbols yet)
>
>
> ?: kd> !analyze -v
> GetContextState failed, 0xD0000147
> GetContextState failed, 0xD0000147
> Unable to get program counter
> GetContextState failed, 0xD0000147
> Unable to get current machine context, NTSTATUS 0xC0000147
> GetContextState failed, 0xD0000147
> GetContextState failed, 0xD0000147
> ***
> *
> * Bugcheck Analysis
> *
>
>
> MANUALLY_INITIATED_CRASH1 (deaddead)
> The user manually initiated this crash dump.
> Arguments:
> Arg1: 00000000
> Arg2: 00000000
> Arg3: 00000000
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
> **Kernel symbols are WRONG. Please fix symbols to do analysis.
> MODULE_NAME: nt
>
> FAULTING_MODULE: 80400000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 384d9b17
>
> BUGCHECK_STR: MANUALLY_INITIATED_CRASH
>
> DEFAULT_BUCKET_ID: WRONG_SYMBOLS
>
> STACK_TEXT:
> GetContextState failed, 0xD0000147
> Unable to get current machine context, NTSTATUS 0xC0000147
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: ntoskrnl.exe
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
>
> do a file compare
>
> desktop:/>dir
> Volume in drive C has no label.
> Volume Serial Number is 3A2B-16E8
>
> Directory of C:\Documents and Settings\Administrator\Desktop
>
> 01/07/2007 06:11p .
> 01/07/2007 06:11p …
> 06/20/2007 07:59p 50,331,648 PAGEFILE.SYS
> 06/20/2007 08:03p 8,192 BANG_v1
> 06/20/2007 08:51p winhex
> 06/20/2007 08:49p 33,083,392 MEMORY.DMP
> 04/28/2007 09:33p 16,591,704 dbg_x86_6.7.05.0.exe
> 06/20/2007 08:59p dbg_x86_6.7.05.0
> 06/20/2007 09:18p 2,487 checkswap.txt
> 5 File(s) 100,017,423 bytes
> 4 Dir(s) 16,221,536,256 bytes free
>
> desktop:/>fc /b memory.dmp pagefile.sys
> Comparing files MEMORY.DMP and PAGEFILE.SYS
> FC: PAGEFILE.SYS longer than MEMORY.DMP
>
>
>
> desktop:/>
>
> desktop:/>windbg -z c:\docume~1\admini~1\desktop\pagefile.sys
>
> desktop:/>
>
> opened the pagefile.sys as crash dump
>
>
> Microsoft (R) Windows Debugger Version 6.7.0005.0
> Copyright (c) Microsoft Corporation. All rights reserved.
>
>
> Loading Dump File [c:\docume~1\admini~1\desktop\pagefile.sys]
> Kernel Complete Dump File: Full address space is available
>
> Symbol search path is: Invalid ***
>
> result of analyze -v
>
> MODULE_NAME: nt
>
> FAULTING_MODULE: 80400000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 384d9b17
>
> BUGCHECK_STR: MANUALLY_INITIATED_CRASH
>
> DEFAULT_BUCKET_ID: WRONG_SYMBOLS
>
> STACK_TEXT:
> GetContextState failed, 0xD0000147
> Unable to get current machine context, NTSTATUS 0xC0000147
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: ntoskrnl.exe
>
> BUCKET_ID: WRONG_SYMBOLS
>
> Followup: MachineOwner
> ---------
>
> GetContextState failed, 0xD0000147
> GetContextState failed, 0xD0000147
>