Windows boot troubleshooting: WinRE, BCD repair and crash dumps

Take a VirtualBox snapshot of SRV01 named “Before boot lab”. Then work as SAATLAB\adm.rahul in PowerShell as administrator on SRV01.

1Read the firmware type and boot entry

On SRV01:

$env:firmware_type
bcdedit /enum '{current}'

You’ll see something like this:

UEFI

Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows Server
locale                  en-US
recoverysequence        {6b3a2f41-91c4-11ef-9a2e-080027a1b2c3}
displaymessageoverride  Recovery
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {6b3a2f40-91c4-11ef-9a2e-080027a1b2c3}
nx                      OptOut

UEFI with winload.efi means the boot files live on the EFI System Partition. If your VM shows Legacy and winload.exe, it uses BIOS boot; the steps still work, only the partition differs. Save a copy of the BCD before you change anything:

New-Item C:\Lab -ItemType Directory -Force | Out-Null
bcdedit /export C:\Lab\bcd-backup

You should see this:

The operation completed successfully.

✅ Checkpoint: You know the firmware type and the boot loader path, and C:\Lab\bcd-backup exists.

2Set up kernel crash dumps

Check the current settings and the page file:

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl |
    Select-Object CrashDumpEnabled, DumpFile, MinidumpDir, AutoReboot
(Get-CimInstance Win32_ComputerSystem).AutomaticManagedPagefile

You’ll see something like this:

CrashDumpEnabled DumpFile                MinidumpDir           AutoReboot
---------------- --------                -----------           ----------
               7 %SystemRoot%\MEMORY.DMP %SystemRoot%\Minidump          1

True

7 is “automatic memory dump”, a kernel dump with a page file Windows sizes for you. Set it to a plain kernel dump (2) so you know exactly what you’ll get:

Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl -Name CrashDumpEnabled -Value 2

✅ Checkpoint: CrashDumpEnabled is 2, the dump goes to MEMORY.DMP, and the page file is system managed.

3Cause a test crash with NotMyFault

Download Microsoft’s NotMyFault tool and use its built-in test driver to crash SRV01:

Invoke-WebRequest https://download.sysinternals.com/files/NotMyFault.zip -OutFile C:\Lab\NotMyFault.zip
Expand-Archive C:\Lab\NotMyFault.zip -DestinationPath C:\Lab\NotMyFault -Force
C:\Lab\NotMyFault\notmyfaultc64.exe crash 0x01

SRV01 shows a blue screen, writes the dump and restarts. Crash type 0x01 is a “high IRQL fault” inside NotMyFault’s own test driver, myfault.sys. [Add your screenshot here]

After the restart, read the bug check event:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1001; ProviderName = 'Microsoft-Windows-WER-SystemErrorReporting' } -MaxEvents 1 |
    Format-List TimeCreated, Message
Get-Item C:\Windows\MEMORY.DMP | Select-Object Name, @{ n = 'MB'; e = { [math]::Round($_.Length / 1MB) } }

You’ll see something like this:

TimeCreated : 20/10/2026 10:42:10
Message     : The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000d1 (0xffffd70c4e3a1010,
              0x0000000000000002, 0x0000000000000000, 0xfffff8064a2112d0). A dump was saved in:
              C:\Windows\MEMORY.DMP. Report Id: 3f6c2a10-9a1b-4c8e-b7d2-5e0f1a2b3c4d.

Name       MB
----       --
MEMORY.DMP 612

✅ Checkpoint: Event 1001 shows bug check 0xD1 and C:\Windows\MEMORY.DMP exists.

4Read the dump with WinDbg

Copy MEMORY.DMP to a Windows machine, install WinDbg and open the dump:

winget install Microsoft.WinDbg
# In WinDbg: File > Open dump file > MEMORY.DMP, then type:
.symfix
.reload
!analyze -v

You’ll see something like this (cut down):

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.

PROCESS_NAME:  notmyfaultc64.exe
SYMBOL_NAME:  myfault+12d0
MODULE_NAME: myfault
IMAGE_NAME:  myfault.sys

The two lines that matter at work are IMAGE_NAME (the driver) and the bug check name. Then you check that driver’s version, vendor updates and recent changes. Symbols come from Microsoft’s public symbol server, so the first load takes a minute.

✅ Checkpoint: !analyze -v names DRIVER_IRQL_NOT_LESS_OR_EQUAL and myfault.sys.

5Turn on boot logging

On SRV01, enable boot logging, restart and read the log:

bcdedit /set '{current}' bootlog yes
Restart-Computer
# after the restart:
Get-Content C:\Windows\ntbtlog.txt -Encoding Unicode | Select-Object -First 4
bcdedit /deletevalue '{current}' bootlog

You’ll see something like this:

Microsoft (R) Windows (R) Version 10.0 (Build 26100.NNNN)
10 20 2026 10:55:03.500
BOOTLOG_LOADED \SystemRoot\system32\ntoskrnl.exe
BOOTLOG_LOADED \SystemRoot\system32\hal.dll

ntbtlog.txt lists every driver loaded (or not loaded) during boot. When a server stops at the same point every time, the last driver in the list is a strong lead. Turn logging off when you’re done.

✅ Checkpoint: ntbtlog.txt lists loaded drivers, and boot logging is off again.