Ah, so you believe that just because it says the dump is 100% complete
this is in fact the case, right? And you probably believe fast mutexes
really ARE fast, fast I/O relates to I/O and again is fast, and the
hypercritical work queue is the appropriate one for your work, too! 
Until the dump header is written to the paging file, the dump is not
complete. EVEN IF you can get the bits (beyond block zero, which is the
dump header) out of the paging file, you don’t have the key data
structures from the dump header to make sense of the rest of it. I CAN
tell you that the dump block signature is the 8 byte string “PAGEDUMP”
(at least on x86. Since the format is different on other platforms,
your mileage may vary). Beyond that, though, I’m not sure as to the
specific meaning of the header.
I suppose another possible cause of this problem is that savedump.exe is
broken in some fashion. This is the program that actually opens the
page file, validates its contents and copies it into the appropriate
location. Of course, if it fails, it reports that information in the
obvious place - the Event Log.
My suspicion is that you don’t get a dump because it writes physical
memory but not the dump header, which makes the whole dump worthless.
As always, I could be wrong, but if that’s the case you’ll need to wait
for someone else to step up to the plate.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2005 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 10:30 AM
To: ntdev redirect
Subject: Re: [ntdev] Forcing pagefile.sys -> memory.dmp
Tony:
On Wed, 9 Feb 2005 00:28:55 -0500, you wrote:
If you are not getting a memory.dmp file, there isn’t one in the page
file.
Tony, I’m sorry, that just doesn’t seem to jibe with my experience.
It also doesn’t jibe with other people’s experience, as well.
Here’s a typical link:
http://groups-beta.google.com/group/comp.os.ms-windows.nt.misc/browse_th
read/thread/b1d1871da83e14f0/6d02628efeb63e7c?q=%22memory.dmp%22&_done=%
2Fgroups%3Fq%3D%22memory.dmp%22%26num%3D100%26hl%3Den%26lr%3D%26sa%3DN%2
6tab%3Dwg%26&_doneTitle=Back+to+Search&&d#6d02628efeb63e7c
This can occur when the dump writing process is interrupted for
any reason - for example, if an error occurs.
But the dump writing process completed. Really. Honest.
I have 512MB of ram on this laptop. I sit there and watch the 100
(decimal)
records being written out.
In fact, this last time I actually sat there with my digital camera and
took
pictures of the dump process. I even managed to get a picture of it
when it
reads “Dumping physical memory to disk: 99”. It completes the
operation at
100. Pictures available upon request.
Alas, this time memory.dmp was produced. But I promise on all that is
holy
to programmers everywhere that often the memory.dmp is not produced even
when “dumping physical memory to disk” has completed sucessfully and we
get
the message “physical memory dump complete”.
Here’s what’s even weirder. After a couple of reboots, memory.dmp seems
to
appear. The following are the details.
(1) baddriver.sys does not exist in c:\windows\system32\drivers.
baddriver.sys is not installed.
(2) Boot into XP Home (on C:) and attempt to install baddriver.sys.
Installation fails because the driver crashes in DriverEntry.
(3) Boot into XP Professional (on D:) and look for memory.dmp.
Sometimes
the latest memory.dmp isn’t there.
(4) Delete c:\windows\system32\drivers\baddriver.sys
(5) Boot into XP Home (on C:) in safe mode. XP Home now comes up
because
baddriver.sys is not in the system. Shut down XP Home normally.
(6) Boot into XP Professional (on D:). Miraculously, the correct
memory.dmp
has been created.
Weird, huh?
Anyway, that’s the way I remember it because it happened that way at
5:30
a.m. today.
Is there a way to convert pagefile.sys to memory.dmp? That is, once the
“dumping physical memory to disk” has completed and one then boots into
*another* Windows partition (thus eliminating the corruption of
pagefile.sys
because one has specified that the page file be on the same partition as
the
OS), can one take the data in pagefile.sys and convert it to memory.dmp?
Clearly, the OS knows how to do it. Is this functionality exposed?
Regards,
Ralph Shnelvar
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ralph Shnelvar
Sent: Wednesday, February 09, 2005 12:10 AM
To: ntdev redirect
Subject: [ntdev] Forcing pagefile.sys -> memory.dmp
I watch as memory is written out due to a crash during a BSOD.
I then boot into another partition so that I can delete the offending
driver
and then reboot into the same partition that caused the crash dump to
be
written to pagefile.sys.
Roughly 30% of the time no memory.dmp is created/overwritten.
Yes, I’m requesting a full dump upon a crash.
Does anyone on this list know how to convert pagefile.sys to
memory.dmp?
In
the alternative, how can I guarantee that a memory.dmp is created?
Or is memory.dmp nothing more than a renamed pagefile.sys?
Ralph Shnelvar
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
