Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

when is crash dump written to disk?

James_HarperJames_Harper Member Posts: 1,615
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

Comments

  • Don_BurnDon_Burn Member - All Emails Posts: 1,649
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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
  • Daniel_TerhellDaniel_Terhell Member Posts: 1,349
    >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
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,305
    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
    >
  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    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
    >
  • James_HarperJames_Harper Member Posts: 1,615
    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
    > <xxxxx@bendigoit.com.au> 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space