when is crash dump written to disk?

Based on what I’ve read, I believe that when a crash dump occurs it is written out the page file, and then on the next boot the page file is analysed and if there is a crash dump in there it is moved to c:\windows\memory.dmp (or minidump or whatever).

Is this the case?

I just had a crash dump and the system took a long time to boot, seeming to freeze just before it would load my accelerated drivers for xen. If it’s shuffling disk around at that point using the real mode drivers then that would explain why it takes so long. If not, I’ll need to go investigating to see where the performance problem is…

Thanks

James

The crash dump is written out to the disk by a separate driver (a separate
copy of storport.sys (or equivalent) which is tuned for post crash dump
environment, plus a copy of the storport miniport for the device. On
reboot I believe the disk time is the repair of the drive, as far as I know
there is no analysis, and if there is it would be pretty simple mainly
checking the dump header in the file.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, December 07, 2013 8:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] when is crash dump written to disk?

Based on what I’ve read, I believe that when a crash dump occurs it is
written out the page file, and then on the next boot the page file is
analysed and if there is a crash dump in there it is moved to
c:\windows\memory.dmp (or minidump or whatever).

Is this the case?

I just had a crash dump and the system took a long time to boot, seeming to
freeze just before it would load my accelerated drivers for xen. If it’s
shuffling disk around at that point using the real mode drivers then that
would explain why it takes so long. If not, I’ll need to go investigating to
see where the performance problem is…

Thanks

James


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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 is always possible that if you are doing a full memory dump of a large
physical memory, and your disk is quite full and badly-fragmented, that
the copy of an N-GB file (for large values of N) could take a while.
AFAIK, only the ancient FAT drive analysis took forever; NTFS is more
robust and does not require a full drive scan for continued survival.

Note that for any but minidumps, the current dump overwrites the existing
dump file, so if you want to keep the old dump you need to rename it.
joe

The crash dump is written out to the disk by a separate driver (a separate
copy of storport.sys (or equivalent) which is tuned for post crash dump
environment, plus a copy of the storport miniport for the device. On
reboot I believe the disk time is the repair of the drive, as far as I
know
there is no analysis, and if there is it would be pretty simple mainly
checking the dump header in the file.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Saturday, December 07, 2013 8:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] when is crash dump written to disk?

Based on what I’ve read, I believe that when a crash dump occurs it is
written out the page file, and then on the next boot the page file is
analysed and if there is a crash dump in there it is moved to
c:\windows\memory.dmp (or minidump or whatever).

Is this the case?

I just had a crash dump and the system took a long time to boot, seeming
to
freeze just before it would load my accelerated drivers for xen. If it’s
shuffling disk around at that point using the real mode drivers then that
would explain why it takes so long. If not, I’ll need to go investigating
to
see where the performance problem is…

Thanks

James


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

http://blogs.technet.com/b/askperf/archive/2008/01/08/understanding-crash-dump-files.aspx
Returning to the subject of how the dump file itself is generated, If a dump is configured, the system makes a copy of the disk miniport driver used to write to the boot volume in memory and prepends the driver name with “dump_”. The system also checksums all of the components involved with writing a crash dump, (including the copied disk miniport driver), the I/O manager functions that write the dump and the map of where the boot volume’s page file is on the disk. This checksum is saved. When the KeBugCheck function executes it checksums these components again and compares this checksum to the one created at boot. If these checksums do not match, no dump file is written (because of the risk of corrupting the disk). If the checksum matches, the dump information is written directly to the sectors on disk occupied by the page file. The file system driver is completely bypassed - because it may be corrupted or be the cause of the crash. When SMSS.EXE enables paging during the boot process, the system examines the boot volume’s page file to see if there is a crash dump present. If one exists, then this part of the page file is protected. This makes all (or part) of the boot volume’s page file unusable during the early part of the boot process. This may result in notifications that the system is low on virtual memory - a temporary condition. Later in the boot process, WINLOGON.EXE calls the SAVEDUMP.EXE process to extract the dump from the page file and copy it to the final location that is specified in the Dump File field.

On Windows Server 2003, there is some slightly different behavior that is outlined in KB Article 886429. Following the server reboot after the bugcheck, Windows requires a temporary file on the boot volume equal to the size of physical RAM. If there is insufficient disk space to meet this requirement, the dump file is still generated, however the page file size on this volume is reduced. In the first stage of the dump operation, the Session Manager Subsystem (SMSS.EXE) examines the page file head block to determine whether the file is a valid memory dump. If the file is valid, then SMSS.EXE truncates the page file to the size of the dump file and renames the file to Dumpxxx.tmp (the xxx value is calculated from the Lower Word of the tickcount function). SMSS stores the Dumpxxx.tmp file on the boot volume and sets a TempDestination value and a DumpFile value in a volatile registry subkey (HKLM\System\CurrentControlSet\Control\CrashControl\MachineCrash). SAVEDUMP.EXE reads this registry location to determine if a valid memory dump exists and copies the Dumpxxx.tmp file to Memory.dmp.

I think the message content limit was hit, hence could not write that the above content is from the link…http://blogs.technet.com/b/askperf/archive/2008/01/08/understanding-crash-dump-fi
les.aspx

>Based on what I’ve read, I believe that when a crash dump occurs it is

written out the page file, and
then on the next boot the page file is analysed and if there is a crash
dump in there it is moved to ?
c:\windows\memory.dmp (or minidump or whatever).
Is this the case?

Yes. After the crash and reboot your system may be very busy for several
minutes extracting the dump from the pagefile and writing it out to a file.

//Daniel

Yes the copy will make the system busy, but that will be pretty late in the
boot cycle, and is done using the full set of boot drivers. James is
reporting that he is in ‘bootloader’ mode for an extended time, and that is
not a result of dump post processing.

Mark Roddy

On Sun, Dec 8, 2013 at 9:07 AM, wrote:

> Based on what I’ve read, I believe that when a crash dump occurs it is
>> written out the page file, and
>> then on the next boot the page file is analysed and if there is a crash
>> dump in there it is moved to ?
>>
>> c:\windows\memory.dmp (or minidump or whatever).
>> Is this the case?
>>
>
> Yes. After the crash and reboot your system may be very busy for several
> minutes extracting the dump from the pagefile and writing it out to a file.
>
> //Daniel
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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’s unusual that you spend much of the boot time in INT13 phase. I believe the crashdump copy at the next boot is done when the OS is fully up.

On system with BIOS, winload.exe reads ntoskrnl/hal and all boot drivers
using int 13h services, sets up a very complex boot loader block and hands
over to the entry point of ntoskrnl.exe, namely nt!KiInitializeSystem.
After that point, int 13h is no longer used until winresume.exe kicks in.

The agents in NT use int13h are the MBR, bootmgr, winresume and winload.
The first 3 have solid alibi.

To prove winload is innocent, you only need to see if nt!KiInitializeSystem
has been called. It may be done by debugging transistioning in winload but
that’s pretty unpleasant debugging experience. ntos will not boot
completely in such mode.

An easier way is to set an kernel initial BP, if you see the freeze after
the kernel initial BP, that rules out winload because you can’t hit the nt
initial BP before nt!KiInitializeSystem saw the light.

Calvin
p.s.Winload indeed does a lot of crazy and fancy things but I have never
seen it doing anything about crashdump.

On Sat, Dec 7, 2013 at 5:31 PM, James Harper
wrote:

> Based on what I’ve read, I believe that when a crash dump occurs it is
> written out the page file, and then on the next boot the page file is
> analysed and if there is a crash dump in there it is moved to
> c:\windows\memory.dmp (or minidump or whatever).
>
> Is this the case?
>
> I just had a crash dump and the system took a long time to boot, seeming
> to freeze just before it would load my accelerated drivers for xen. If it’s
> shuffling disk around at that point using the real mode drivers then that
> would explain why it takes so long. If not, I’ll need to go investigating
> to see where the performance problem is…
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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 guys, that’s the answer I was looking for. Further investigation revealed that the boot was slow even without the crash. I found a problem in the storage backend and fixed it - int13 under xen is slow at the best of times without any sort of io problem. Now win2008r2 boots are back to seconds instead of minutes, even with crash dumps!

Thanks again!

James

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-547825-
xxxxx@lists.osr.com] On Behalf Of Calvin Guan (news)
Sent: Monday, 9 December 2013 7:11 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] when is crash dump written to disk?

On system with BIOS, winload.exe reads ntoskrnl/hal and all boot drivers
using int 13h services, sets up a very complex boot loader block and hands
over to the entry point of ntoskrnl.exe, namely nt!KiInitializeSystem. After
that point, int 13h is no longer used until winresume.exe kicks in.

The agents in NT use int13h are the MBR, bootmgr, winresume and winload.
The first 3 have solid alibi.

To prove winload is innocent, you only need to see if nt!KiInitializeSystem
has been called. It may be done by debugging transistioning in winload but
that’s pretty unpleasant debugging experience. ntos will not boot completely
in such mode.

An easier way is to set an kernel initial BP, if you see the freeze after the
kernel initial BP, that rules out winload because you can’t hit the nt initial BP
before nt!KiInitializeSystem saw the light.

Calvin
p.s.Winload indeed does a lot of crazy and fancy things but I have never seen
it doing anything about crashdump.

On Sat, Dec 7, 2013 at 5:31 PM, James Harper
wrote:
>
>
> Based on what I’ve read, I believe that when a crash dump occurs it is
> written out the page file, and then on the next boot the page file is analysed
> and if there is a crash dump in there it is moved to c:\windows\memory.dmp
> (or minidump or whatever).
>
> Is this the case?
>
> I just had a crash dump and the system took a long time to boot,
> seeming to freeze just before it would load my accelerated drivers for xen. If
> it’s shuffling disk around at that point using the real mode drivers then that
> would explain why it takes so long. If not, I’ll need to go investigating to see
> where the performance problem is…
>
> Thanks
>
> James
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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