What are these ghost drivers named dump_diskdump.sys and other dump_*.sys that didn’t come from any file?


Run Process Explorer with administrative privileges, select Options, Verify Signatures, pick the System process, then open the DLL view. In that view, you'll find some drivers with names like dump_diskdump.sys, dump_dumpfve.sys, and dump_storahci.sys. The Verified Signer column says "An error occurred while reading or writing to a file," these drivers have no description, no company name, and their reported path points to nonexistent files like C:\Windows\System32\Drivers\dump_diskdump.sys. What are these things? Does the computer have a virus?

These are virtual drivers that are used for creating crash dumps.¹

Creating a crash dump is a bit of a catch-22: When the crash occurs, the system is in an unknown state, which means that you can't trust anything, not even the file system or block device drivers. After all, the crash may have been in one of those drivers!

When the system starts up, it preallocates space on the hard drive to record crash dump information, in case that becomes necessary. It also clones the drivers needed to write to the disk. If a crash occurs, the kernel doesn't trust the drivers that were running the show. Instead, it asks these clones to step in and write the crash data. The theory here is that these clone drivers have been kept in a state of suspended animation immediately after they've been initialized, in order to minimize the chance that they have gotten into a corrupted state that would prevent them from doing their job.²

These virtual drivers show up in Process Explorer with no description or other metadata because Process Explorer takes the reported path and extracts the metadata from that path. But these drivers weren't loaded from a file, so there is nothing to show.

Bonus chatter: Most of the driver names are self-explanatory. The one that may not be obvious is dumpfve: "fve" is short for Full Volume Encryption, more commonly known as BitLocker.

¹ Also hibernation files, but crash dumps are the interesting part of the story.

² Of course, if a driver is so buggy that it can't even initialize itself without corrupting itself, then you're screwed. Let's hope that by the time a driver passes WHQL, it can at least initialize itself without corrupting itself.

Comments (12)
  1. Brian_EE says:

    Not to be confused with the virtual drivers (VxD) introduced with Windows 386.

    1. xcomcmdr says:

      Thankfully, it died with the Windows 9X branch, and it never was a part of the Windows NT branch.

  2. These cloned drivers may also been corrupted in memory, if a driver does a bad write, right? Does Windows anything to mitigate that or are such bad writes impossible?

  3. Kemp says:

    Are there cases where the “live” driver could have left things in a bad/unknown state that would cause problems for the clone coming in (which doesn’t know about anything that has happened)? I assume the initialisation process would sort most things out and you’re not relying on hardware that has persistent state as such, but in cases where it happened to be mid-way through updating the directory entry for the location that the dump will be written to for example.

  4. Tim P. says:

    “When the system starts up, it preallocates space on the hard drive to record crash dump information.” Is this simply to avoid having to create files and allocate space and all that other potentially-troublesome bookkeeping? Or is it additionally so that the system can simply remember the physical blocks on disk occupied by that crash dump file and then just write into it without having to also clone the filesystem drivers?

    1. ErikF says:

      My guess is that this prevents the crash handler from being unable to write out the file due to lack of space. Reducing the number of driver layers could definitely be a factor too, though.

    2. Brian says:

      That strategy is pretty common when you absolutely need to be able to handle/log a catastrophic failure. You make sure you build the concrete tornado bunker before you build the house.

  5. Joshua says:

    I have a Windows 10 machine that will bluescreen immediately on taking the anniversary update and roll it back. I ended up with a support case involved with the bluescreen. In this case it was via accessibility support, to the limit of the support case was find out why the bluescreen is not generating a dump.

    From this blog I believe I have the answer. The kernel crashed before the dump_* drivers were cloned (which means before the hardware IO was completely initialized). The bluescreens themselves seem to be due to memory corruption, which is not immediately debuggable.

  6. alegr1 says:

    Immediately before hibernation, the kernel loads the same crashdump driver, but with hiber_ prefix.

  7. alegr1 says:

    >When the system starts up, it preallocates space on the hard drive to record crash dump information,

    This place is actually called pagefile.sys. The crashdump goes to pagefile. On reboot after crash, a new pagefile will be created and the memory dump will be written out of the old pagefile.

Comments are closed.

Skip to main content