Under xen I can take a dump of a VM. From that dump, I can synthesize a Windows crash dump (by finding the KeInitializeCrashDumpHeader data that I prepare on boot then writing out the pages as required).
If I take the xen dump on a crashed system it seems to produce something useful, but if the system isn’t crashed the resulting windows memory.dmp says things like:
Debugger could not find ntdll in module list, module list might be corrupt, error 0x80070057.
And then when I do !stacks:
Unable to get value of PsActiveProcessHead.Flink
Am I chasing something impossible by trying to get a crash dump out of a running system or is there something I could do to make it work, or at least work better?
Thanks
James
x86 or x64 vm? What does the debugger command prompt look like?
On 9/19/2012 7:46 PM, James Harper wrote:
Under xen I can take a dump of a VM. From that dump, I can synthesize a Windows crash dump (by finding the KeInitializeCrashDumpHeader data that I prepare on boot then writing out the pages as required).
If I take the xen dump on a crashed system it seems to produce something useful, but if the system isn’t crashed the resulting windows memory.dmp says things like:
Debugger could not find ntdll in module list, module list might be corrupt, error 0x80070057.
And then when I do !stacks:
Unable to get value of PsActiveProcessHead.Flink
Am I chasing something impossible by trying to get a crash dump out of a running system or is there something I could do to make it work, or at least work better?
Thanks
James
We tried to get this working a while back (during the XP->Vista era)
at Stratus, and we ended up convincing ourselves that there was
‘stuff’’ done during the dump process that is not replicated by simply
applying the dump header to a memory snapshot. Unfortunately I can’t
remember the details of what was missing. Later conversations with
MSFT indicated that they still thought it was possible, but those
conversations were always distorted by the inside the bubble vs out in
the fields perspective.
Mark Roddy
On Wed, Sep 19, 2012 at 7:46 PM, James Harper
wrote:
> Under xen I can take a dump of a VM. From that dump, I can synthesize a Windows crash dump (by finding the KeInitializeCrashDumpHeader data that I prepare on boot then writing out the pages as required).
>
> If I take the xen dump on a crashed system it seems to produce something useful, but if the system isn’t crashed the resulting windows memory.dmp says things like:
>
> Debugger could not find ntdll in module list, module list might be corrupt, error 0x80070057.
>
> And then when I do !stacks:
>
> Unable to get value of PsActiveProcessHead.Flink
>
> Am I chasing something impossible by trying to get a crash dump out of a running system or is there something I could do to make it work, or at least work better?
>
> 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
It should be possible to freeze a VM and write a dump, windbg can with the .dump command. I suppose one could argue that interrupting with windbg only occurs at certain logical boundaries, and perhaps this will not work on just any instruction boundary. Just to verify, I interrupted a target and ran .dump /f xxx.dmp and 3 minutes later had a 8 GB dump file that opens in windbg and offhand to find all the symbols, !prrocess 0 7 worked. The target was Win8. When I resumed the target from the debugger, the system seems to still work fine.
It might be educational to carefully observe the traffic generated by windbg when running .dump.
Jan
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, September 19, 2012 7:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] crash dump from a running system
We tried to get this working a while back (during the XP->Vista era) at Stratus, and we ended up convincing ourselves that there was ‘stuff’’ done during the dump process that is not replicated by simply applying the dump header to a memory snapshot. Unfortunately I can’t remember the details of what was missing. Later conversations with MSFT indicated that they still thought it was possible, but those conversations were always distorted by the inside the bubble vs out in the fields perspective.
Mark Roddy
On Wed, Sep 19, 2012 at 7:46 PM, James Harper wrote:
> Under xen I can take a dump of a VM. From that dump, I can synthesize a Windows crash dump (by finding the KeInitializeCrashDumpHeader data that I prepare on boot then writing out the pages as required).
>
> If I take the xen dump on a crashed system it seems to produce something useful, but if the system isn’t crashed the resulting windows memory.dmp says things like:
>
> Debugger could not find ntdll in module list, module list might be corrupt, error 0x80070057.
>
> And then when I do !stacks:
>
> Unable to get value of PsActiveProcessHead.Flink
>
> Am I chasing something impossible by trying to get a crash dump out of a running system or is there something I could do to make it work, or at least work better?
>
> 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
—
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
“Jan Bottorff” wrote in message news:xxxxx@ntdev…
It should be possible to freeze a VM and write a dump, windbg can with the
.dump command.
Freezing a target machine via WinDBG is a fairly controlled process that
includes coordination amongst all of the target’s processors. This includes
the target’s processors doing some stuff to tidy for the debugger before
going into their loop (e.g. saving trap frames to show the user as the state
of the processors, saving the pre-break in IRQLs so !irql works, etc.).
You might be able to fix a lot of this with a target side assist or some
post-processing on the dump. There are people that make commercial products
that do this kind of thing. For example:
http://www.moonsols.com/windows-memory-toolkit/
Though I would imagine it’s a non-trivial undertaking as none of this stuff
is documented.
To the original issue:
On Wed, Sep 19, 2012 at 7:46 PM, James Harper
wrote:
> Debugger could not find ntdll in module list, module list might be
> corrupt, error 0x80070057.
>
> And then when I do !stacks:
>
> Unable to get value of PsActiveProcessHead.Flink
The debugger gets the module list and process list from the dump header, so
something is out of whack. You can use .dumpdebug to see the dump header as
WinDBG sees it and then try to work out what’s wrong from there. I think
you’ll have larger issues overall that need solved, but it might at least
give you some insight as to why this particular dump is bad.
-scott
>
“Jan Bottorff” wrote in message news:xxxxx@ntdev…
>It should be possible to freeze a VM and write a dump, windbg can with
>the .dump command.
Freezing a target machine via WinDBG is a fairly controlled process that
includes coordination amongst all of the target’s processors. This includes the
target’s processors doing some stuff to tidy for the debugger before going
into their loop (e.g. saving trap frames to show the user as the state of the
processors, saving the pre-break in IRQLs so !irql works, etc.).
You might be able to fix a lot of this with a target side assist or some post-
processing on the dump. There are people that make commercial products
that do this kind of thing. For example:
http://www.moonsols.com/windows-memory-toolkit/
Though I would imagine it’s a non-trivial undertaking as none of this stuff is
documented.
Thanks for that. Makes the decision on where to spend my time a bit simpler 
I’ll still with synthesizing a dump from an already crashed system (eg because the crash dump write failed) for the moment.
To the original issue:
On Wed, Sep 19, 2012 at 7:46 PM, James Harper
wrote:
> > Debugger could not find ntdll in module list, module list might be
> > corrupt, error 0x80070057.
> >
> > And then when I do !stacks:
> >
> > Unable to get value of PsActiveProcessHead.Flink
>
> The debugger gets the module list and process list from the dump header, so
> something is out of whack. You can use .dumpdebug to see the dump
> header as WinDBG sees it and then try to work out what’s wrong from there.
> I think you’ll have larger issues overall that need solved, but it might at least
> give you some insight as to why this particular dump is bad.
>
This one was a bit embarrassing. I don’t use IE normally, but had used it last week and had set a proxy server when I was off site, which obviously didn’t work on a different network and I’d forgotten that IE proxy = system proxy. There were no messages I could see about symbol download failures, but once I cleared the proxy settings it all suddenly worked again.
Thanks
James