I recently updated my Windows Vista install to service pack 2, and since the update I am no longer getting MEMORY.DMP files written to my Windows directory after a crash. I still get the blue screen, and it says that it’s writing a memory dump file, but when the system comes back up the file isn’t there. I’ve checked the dump files settings under “Startup and Recovery” and everything looks fine. I also tried deleting the old MEMORY.DMP file in case it was in the way and couldn’t be overwritten. I checked my disk space, and there is plenty available. Does anyone have any ideas what might be going on here?
I recently updated my Windows Vista install to service pack 2, and since the
update I am no longer getting MEMORY.DMP files written to my Windows
directory after a crash. I still get the blue screen, and it says that it’s
writing a memory dump file, but when the system comes back up the file isn’t
there. I’ve checked the dump files settings under “Startup and Recovery”
and everything looks fine. I also tried deleting the old MEMORY.DMP file in
case it was in the way and couldn’t be overwritten. I checked my disk
space, and there is plenty available. Does anyone have any ideas what might
be going on here?
In my searching I found an article that mentioned this. It said your paging file should be at least 1 MB greater than the size of your physical memory. I have 3.0GB memory, and my my page file is set to 3361 MB, so I think I should be OK on that note.
Do you need the full Memory dump file? If so, just rename the MEMORY.dmp file after each crash and you’ll have a series of them.
If not, set the system to make minidumps - and it’ll do that automatically for you:
Go to Start and type in “sysdm.cpl” (without the quotes) and press Enter
Click on the Advanced tab
Click on the Startup and Recovery Settings button
Ensure that “Automatically restart” is unchecked
Under the Write Debugging Information header select “Small memory dump (64 kB)” in the dropdown box
Ensure that the Small Dump Directory is listed as “%systemroot%\Minidump” (without the quotes)
Click OK twice to exit the dialogs, then reboot for the changes to take effect.
There are many reasons for a crash dump not being created.
Collecting of the crash dump actually starts when you boot the system, and continues when the crash occurs, then even more occurs when you reboot after the crash. See page 1130 of Windows Internals, 5th Edition for a description.
The article that you read specifies the size of the RAM plus 1mB (I recall a different number, but can’t locate it right now). This is for a complete memory dump as the crash writes the contents of memory to the disk when the crash occurs. This setting is also adequate for kernel and minidumps.
But, when KeBugCheckEx executes - it checksums the components involved in writing the dump. If this doesn’t agree with the checksum that it got earier, then it doesn’t write the dump.
Other factors, such as a crash early in the boot process, can add to the complexity of this topic.
Also note that it can take up to 10 minutes or so for the memory.dmp to
be created after the reboot following the bluescreen, as it has to copy
it out of pagefile.sys. So, if you check right away following the
reboot, it won’t yet exist.
Also note that it can take up to 10 minutes or so for the memory.dmp to be
created after the reboot following the bluescreen, as it has to copy it out
of pagefile.sys. So, if you check right away following the reboot, it won’t
yet exist.
If the pagefile is on the same volume as the destination for the dump file, then AFAIK, the pagefile is simply renamed to the name of the dump file. I can’t see this event taking very long.
If it’s not, then there’s a truncation event that takes place (to remove the empty space in the pagefile that isn’t used for the dump), then the dump file is stored in a temporary location, then it’s copied to it’s permanent location. I’d suspect that this could take some time - but would also suspect that it will occur before the system gets into Windows.
I have not looked on Vista and later systems, but it definitely was not
the case on Server 2003 or earlier. There was no copy done, the page
file was renamed memory.dmp with proper truncation and a new page file
was created.
From: xxxxx@jimdonelson.com [mailto:xxxxx@jimdonelson.com] On Behalf Of Jim
Donelson
Posted At: Saturday, June 19, 2010 9:50 AM
Posted To: windbg
Conversation: MEMORY.DMP Not Generated on Vista SP2
Subject: Re: MEMORY.DMP Not Generated on Vista SP2
Also note that it can take up to 10 minutes or so for the memory.dmp to
be created after the reboot following the bluescreen, as it has to copy
it out of pagefile.sys. So, if you check right away following the
reboot, it won’t yet exist.
Is this true? I have not heard this before.
__________ Information from ESET Smart Security, version of virus
signature database 5209 (20100619) __________
I assume other information is included with the page file in the dmp file.
I too had never seen any indication of this on Vista or Win7, but then I
never went back and looked for a missing dump file. Just wondering if I
should make a point to do so…
It was my understanding that there was not further processing - what you got
(or did get) is what you got.
On Sat, Jun 19, 2010 at 9:57 AM, Don Burn wrote:
> I have not looked on Vista and later systems, but it definitely was not > the case on Server 2003 or earlier. There was no copy done, the page > file was renamed memory.dmp with proper truncation and a new page file > was created. > > > Don Burn (MVP, Windows DKD) > Windows Filesystem and Driver Consulting > Website: http://www.windrvr.com > Blog: http://msmvps.com/blogs/WinDrvr > > > > From: xxxxx@jimdonelson.com [mailto:xxxxx@jimdonelson.com] On Behalf Of Jim > Donelson > Posted At: Saturday, June 19, 2010 9:50 AM > Posted To: windbg > Conversation: MEMORY.DMP Not Generated on Vista SP2 > Subject: Re: MEMORY.DMP Not Generated on Vista SP2 > > > Also note that it can take up to 10 minutes or so for the memory.dmp to > be created after the reboot following the bluescreen, as it has to copy > it out of pagefile.sys. So, if you check right away following the > reboot, it won’t yet exist. > > > Is this true? I have not heard this before. > > Information from ESET Smart Security, version of virus > signature database 5209 (20100619) > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > — > 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 >
* On Sat, Jun 19, 2010 at 09:57:43AM -0400 Don Burn wrote:
I have not looked on Vista and later systems, but it definitely was not
the case on Server 2003 or earlier. There was no copy done, the page
file was renamed memory.dmp with proper truncation and a new page file
was created.
I once had a setup (WinXP) where the pagefile resided on a different
drive than the location for the memory.dmp was set to. In this case,
Windows in fact copies the memory.dmp file from the pagefile.sys, which
could take much time. (How should Windows fulfill the requirement
without copying in this case?)
Of course, I “fixed” this setup shortly after I found out about this
problem.
I’ve seen something similar on 7. After restart, the os will present a prompt asking to ckeck for a solution online or to cancel. If you execute any of the buttons, then the dmp file is deleted. After restart, copy the dmp and then dismiss the dialog as suited.
----- Original Message ----
From: “xxxxx@gmail.com” To: Kernel Debugging Interest List Sent: Fri, June 18, 2010 10:28:45 PM Subject: [windbg] MEMORY.DMP Not Generated on Vista SP2
Hi All,
I recently updated my Windows Vista install to service pack 2, and since the update I am no longer getting MEMORY.DMP files written to my Windows directory after a crash. I still get the blue screen, and it says that it’s writing a memory dump file, but when the system comes back up the file isn’t there. I’ve checked the dump files settings under “Startup and Recovery” and everything looks fine. I also tried deleting the old MEMORY.DMP file in case it was in the way and couldn’t be overwritten. I checked my disk space, and there is plenty available. Does anyone have any ideas what might be going on here?
" If you want a crash dump on Windows 7 and you have less than 25 GB of
free space on disk 1, you need another registry setting. Set the
following registry value to 1:
-----Original Message-----
From: Calin Iaru [mailto:xxxxx@yahoo.com]
Posted At: Saturday, June 19, 2010 4:41 PM
Posted To: windbg
Conversation: MEMORY.DMP Not Generated on Vista SP2
Subject: Re: MEMORY.DMP Not Generated on Vista SP2
I’ve seen something similar on 7. After restart, the os will present a
prompt
asking to ckeck for a solution online or to cancel. If you execute any
of the
buttons, then the dmp file is deleted. After restart, copy the dmp and
then
dismiss the dialog as suited.
----- Original Message ----
From: “xxxxx@gmail.com” > To: Kernel Debugging Interest List > Sent: Fri, June 18, 2010 10:28:45 PM > Subject: [windbg] MEMORY.DMP Not Generated on Vista SP2 > > Hi All, > > I recently updated my Windows Vista install to service pack 2, and since the > update I am no longer getting MEMORY.DMP files written to my Windows directory > after a crash. I still get the blue screen, and it says that it’s writing a > memory dump file, but when the system comes back up the file isn’t there. > I’ve checked the dump files settings under “Startup and Recovery” and > everything looks fine. I also tried deleting the old MEMORY.DMP file in case > it was in the way and couldn’t be overwritten. I checked my disk space, and > there is plenty available. Does anyone have any ideas what might be going on > here? > > Thanks, > Jeff > > > — > 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 > > > > > > > Information from ESET Smart Security, version of virus signature > database 5210 (20100619) > > The message was checked by ESET Smart Security. > > http://www.eset.com >
> I have not looked on Vista and later systems, but it definitely was
not
the case on Server 2003 or earlier. There was no copy done, the page
file was renamed memory.dmp with proper truncation and a new page file
was created.
I deal with this quite often on Win2003 and previously WinNT, so I know
it’s true. It’s described fairly well in Windows Internals, but
basically boils down to:
The bluescreen dumps memory into PAGEFILE.SYS.
When the system boots, it starts a process called SAVEDUMP.EXE.
That process COPIES (not renames) the information out of
PAGEFILE.SYS into MEMORY.DMP.
Depending on your devices, this takes different amounts of time, but
on IDE systems with 2 GB of RAM, it doesn’t finish until about 5-10
minutes after the reboot.
Thanks for the replies. I know that it’s not a crash early in the boot process - I first used osrbang to cause the crash, and I also tried using the CrashOnCtrlScroll method. Neither of them work. The page file and the memory dump destination are both on my boot drive, which is something that hasn’t changed since before I installed this service pack.
I read up on the info on crash dump generation in the Windows Internals book and it was very helpful. The fact that I’m seeing the dump progress reach 100% on the blue screen leads me to believe that the checksums on the disk miniport and other components match with the ones generated during boot. Can anyone confirm that?