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.

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.

“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?

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.