Just a quick note: if you break into your kernel debugger after booting Windows and type ‘lm’, you will probably see some version of this at the bottom of the command output:
Unloaded modules: fffff880`01846000 fffff880`01854000 crashdmp.sys fffff880`01854000 fffff880`0185e000 dump_storport.sys fffff880`0185e000 fffff880`0187b000 dump_LSI_SAS.sys fffff880`0187b000 fffff880`0188e000 dump_dumpfve.sys
The unloaded modules list is used for debugging purposes and shows modules/drivers that were recently loaded and then unloaded (Volatility has a good post about the unloaded module list here). But why do we see the crash dump stack drivers here? Shouldn’t they be loaded in memory in case a crash occurs? Well, they are, just scroll up a bit:
fffff880`04400000 fffff880`0440e000 crashdmp (deferred) fffff880`0440e000 fffff880`04418000 dump_diskdump (deferred) fffff880`04418000 fffff880`04435000 dump_LSI_SAS (deferred) fffff880`04435000 fffff880`04448000 dump_dumpfve (deferred)
So why do they appear in both the unloaded list and the current loaded list? Since the crash dump stack always loads during phase 1 kernel initialization and then subsequently when a page file is created and hyber/crash file space is actually available, the stack is actually always loaded at least twice and it’s the second load that persists (when the boot device’s page file is created). If you have the page file and hibernation features disabled, you should not see the crash dump stack in the loaded module list, but you would see it in the unloaded modules list (I have not tested this!).
Also note that “dump_storport.sys” was unloaded after the first stack load and “dump_diskdump” was loaded in its place on the second load. These drivers are the same (note their image ranges show identical size) driver, diskdump.sys. This renaming is part of the load process (for more details, explore the various sections on this website).