Stop Fast Startup or hibernation from restoring a broken boot or display state

Fast Startup can make a shutdown followed by power-on behave differently from Restart. Windows closes applications and signs out users, but it saves the kernel session and loaded kernel-mode drivers in Hiberfil.sys. The next power-on restores that saved state instead of constructing an entirely new kernel state. Normal hibernation saves an even broader system state to the same file.

If a display, storage, chipset, network, or other kernel driver enters a bad power state, Fast Startup or hibernation can restore the problem on the next start. Restart deliberately performs a full boot and can therefore appear to “fix” the computer temporarily. Disabling Fast Startup is a valid diagnostic test and workaround; it is not proof that Windows itself, the graphics card, or the system disk is defective.

Searchable Windows error codes and exact messages

There is no error code that uniquely means Fast Startup restored a bad state. Use the codes only when Windows or the event log actually displays them.

Do not convert a generic black screen into 0x9F or 0xA0. Record a stop code only if Windows, a dump, Reliability Monitor, or Event Viewer actually reports it.

Use this procedure when Windows 10 or Windows 11 can reach a usable desktop, Restart reliably works better than Shut down followed by power-on, or ordinary hibernation repeatedly restores the same black screen, frozen display, device failure, or stop code. The best evidence is that a forced hybrid shutdown reproduces the fault while a forced full shutdown does not.

Do not use this as the primary repair when the same failure occurs after Restart and full shutdown, the system disk disappears from firmware, the computer performs two firmware POST cycles before Windows Boot Manager, a monitor or cable fails before Windows begins loading, memory diagnostics report errors, or a crash dump consistently identifies a specific driver that has its own repair. A post-sign-in black screen caused by explorer.exe, a shell replacement, or a user profile is also a separate condition.

The exact Windows build, the precise reason the saved state became bad, and the responsible driver may remain unknown for the initial repair. Whether Fast Startup is available, whether the failure is limited to hybrid startup or also affects ordinary hibernation, and whether Restart/full shutdown consistently avoid it may not remain unknown.

• A Windows session that can reach the desktop normally or through Safe Mode
• Administrator access
• All work saved before any shutdown or hibernation test
• Enough free space for the hibernation file if hibernation will be re-enabled
• A record of the original HiberbootEnabled state before changing it, plus a CrashControl export and DumpFilters record before any dump-filter edit
• At least two controlled test cycles for each startup path
• Access to Event Viewer or Reliability Monitor if Windows recorded a stop or forced reset

Save and close every application. A hibernation-file rebuild deletes the existing saved hibernation state. Do not begin by deleting Hiberfil.sys manually, editing several power values, updating multiple drivers, or changing firmware settings. First compare the hybrid, full-shutdown, and Restart paths so the repair has a measurable basis.

1. Open an elevated Command Prompt. The commands in this writeup are shown for cmd.exe.

2. Record which sleep states Windows currently supports:

   powercfg /a
   

3. Interpret the output:

   • If Fast Startup is available, continue with the hybrid test.
   • If Fast Startup is unavailable, record the reason Windows displays. Do not diagnose a Fast Startup failure, although ordinary hibernation can still be tested if it is available.
   • If hibernation is unavailable by policy or firmware design, do not force it on merely to run this test.

4. Record the configured Fast Startup value:

   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled
   

   0x1 means enabled and 0x0 means disabled. A missing value can leave behavior controlled by the Windows default or policy, so pair it with powercfg /a and the Power Options interface.

5. Test the hybrid path. Save all work, run the following command, wait for power-off, and then power the computer on:

   shutdown /s /hybrid /t 0
   

6. Record the exact result: successful desktop, black screen, blinking cursor, device absent, stop code, automatic recovery, or forced-reset requirement.

7. After recovering to Windows, test a full shutdown that explicitly omits the hybrid option:

   shutdown /s /t 0
   

   Power the computer on and record the result.

8. Test Restart, which uses a full boot path:

   shutdown /r /t 0
   

9. Repeat the three-path comparison once. One good boot and one bad boot are weak evidence if the original problem is intermittent.

10. Open Reliability Monitor:

    perfmon /rel
    

    Record any Windows failure at the time of the bad startup, including the stop code and named module.

11. Open Event Viewer:

    eventvwr.msc
    

    In Windows Logs > System, inspect the same time period for Event IDs 41, 45, 6008, and 1001. Record the event source, complete message, friendly-view data, and any bug-check parameters.

12. Interpret the comparison:

    • Hybrid fails; full shutdown and Restart work: Fast Startup is strongly implicated.
    • Hybrid and ordinary hibernation fail; full shutdown and Restart work: The saved kernel/resume state or a power-transition driver is implicated.
    • All three paths fail: Stop. This writeup does not isolate the cause.
    • Only Restart fails: This is not the expected pattern for BP-039.

Branch A — Disable Fast Startup but retain ordinary hibernation

Use this branch when the hybrid path fails but full shutdown and Restart work.

1. Create a backup folder and record the original Fast Startup value before changing it. Redirecting standard error records the difference between a missing value and a query failure:

   md C:\BootRepairBackup 2>nul
   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled > C:\BootRepairBackup\HiberbootEnabled-before.txt 2>&1
   powercfg /a > C:\BootRepairBackup\Power-states-before.txt 2>&1
   

2. Open HiberbootEnabled-before.txt. Record whether the value was missing, 0x0, or 0x1. Stop if the query failed for an access, hive, or registry-corruption reason rather than because the value was absent.

3. Disable only Fast Startup:

   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f
   

4. Confirm the new value:

   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled
   

5. Perform a full shutdown:

   shutdown /s /t 0
   

6. Power the computer on and repeat the full shutdown/power-on cycle two more times.

7. If all three starts succeed, leave Fast Startup disabled while the exact graphics, chipset, storage, network, or other power-transition driver is investigated. Fast Startup being disabled is an acceptable workaround, but it may increase startup time.

8. If the failure still occurs with Fast Startup disabled, do not continue attributing it to Fast Startup. Move to the branch indicated by the actual stop code, named driver, display symptom, or storage evidence.

Branch B — Rebuild Hiberfil.sys

Use this branch when ordinary hibernation also fails, 0xA0 parameters implicate the hibernation file, or disabling Fast Startup alone does not clear a demonstrably stale saved state. This resets both normal hibernation and the file used by Fast Startup.

1. Confirm that all work is saved and no session needs to be resumed later.

2. Create the backup folder and record both the original hibernation availability and the original Fast Startup value before either is changed:

   md C:\BootRepairBackup 2>nul
   powercfg /a > C:\BootRepairBackup\Power-states-before-Hiberfil-rebuild.txt 2>&1
   reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled > C:\BootRepairBackup\HiberbootEnabled-before-Hiberfil-rebuild.txt 2>&1
   

3. Open both files. Record whether Hibernate was available and whether HiberbootEnabled was missing, 0x0, or 0x1. Stop if either command failed for an access, hive, or policy error that prevents a reliable rollback.

4. Disable hibernation. Windows deletes Hiberfil.sys as part of this operation:

   powercfg /hibernate off
   

5. Restart to obtain a new kernel state:

   shutdown /r /t 0
   

6. After Windows starts, re-enable hibernation and request a full hibernation file:

   powercfg /hibernate on
   powercfg /hibernate /type full
   

7. Keep Fast Startup disabled during the first validation cycles:

   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f
   

8. Confirm the available states again:

   powercfg /a
   

9. Test ordinary hibernation once from the Windows power menu. Resume and verify the desktop, display, network, and storage devices.

10. Perform two full shutdown/power-on cycles.

11. Re-enable Fast Startup only if it is wanted and the hibernation test is stable:

    reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 1 /f
    

12. Test with the explicit hybrid command:

    shutdown /s /hybrid /t 0
    

13. If the fault immediately returns, disable Fast Startup again. The hibernation-file rebuild worked as a reset, but the hybrid driver path remains incompatible or unstable.

Branch C — Event ID 45 contains C004002D and C0000034

Use this narrow branch only when Event ID 45 actually contains both documented statuses. Do not edit DumpFilters for an unrelated black screen.

1. Create the backup folder, export the original CrashControl key, and record its existing DumpFilters multi-string before changing anything:

   md C:\BootRepairBackup 2>nul
   reg export "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" C:\BootRepairBackup\CrashControl-before-DumpFilters-repair.reg /y
   reg query "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v DumpFilters > C:\BootRepairBackup\DumpFilters-before.txt 2>&1
   

2. For every entry other than dumpfve.sys, identify the file owner and installed product before considering a registry edit. Replace <filter>.sys with one recorded filename:

   dir C:\Windows\System32\drivers\<filter>.sys
   powershell -NoProfile -Command "$p='C:\Windows\System32\drivers\<filter>.sys'; (Get-Item $p).VersionInfo | Format-List CompanyName,ProductName,FileDescription,FileVersion,OriginalFilename"
   powershell -NoProfile -Command "Get-AuthenticodeSignature 'C:\Windows\System32\drivers\<filter>.sys' | Format-List Status,StatusMessage,SignerCertificate,Path"
   

3. Correlate the company/product information with Settings > Apps > Installed apps, Device Manager, or the product's management console. If ownership cannot be established, stop. Do not delete an unidentified boot- or dump-path driver.

4. Use the owning vendor's supported update, repair, or uninstall process first. Restart and retest hibernation and explicit hybrid shutdown. If Event ID 45 no longer contains both C004002D and C0000034, stop; no DumpFilters edit is needed.

5. Only if the exact Event ID/status pair remains after the owning product has been updated, repaired, or removed, open Registry Editor:

   regedit
   

6. Navigate to:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
   

7. Open DumpFilters and compare every line with DumpFilters-before.txt. Stop if the value has changed since the backup.

8. For this exact, still-present event/status combination, apply Microsoft's narrow repair: remove the obsolete additional entries and leave dumpfve.sys as the only value.

9. If an additional filter still belongs to a required, installed product, stop and escalate to that product's vendor. Do not remove the filter merely to make the event disappear.

10. Close Registry Editor and restart.

11. Test hibernation and hybrid shutdown separately. Confirm that Event ID 45 does not recur.

Branch D — A crash dump consistently names one driver

1. Preserve the dump in C:\Windows\Minidump or the configured kernel-dump location before changing the driver.

2. Confirm that the same third-party module appears in more than one relevant 0x9F, 0xA0, or adjacent power-transition analysis, or that its device stack is shown blocking the power IRP.

3. Use the device or software vendor’s supported rollback, update, or uninstall process. Change one driver or owning product at a time.

4. Leave Fast Startup disabled until the replacement driver passes full shutdown, hybrid shutdown, Restart, and ordinary hibernation tests.

5. If no driver can be coherently identified, do not guess from the first filename near the stack. Retain the reversible Fast Startup workaround and collect better dump evidence.

• Hybrid fails while full shutdown and Restart work: Fast Startup is implicated with high practical confidence.
• Disabling Fast Startup stops the failure: Retain the workaround and investigate the power-transition driver if the feature is needed.
• Rebuilding Hiberfil.sys fixes hibernation and hybrid startup: The saved file or state was stale or damaged.
• Ordinary hibernation still produces 0xA0: Use its parameters. A too-small hibernation file, checksum mismatch, storage failure, or resume timeout requires a narrower repair.
• 0x9F names or leads to one driver stack: Repair the owning driver or product rather than repeatedly rebuilding the hibernation file.
• Event ID 45 stops after the exact DumpFilters repair: The documented dump-filter load failure was resolved.
• All startup paths fail the same way: Leave this procedure and diagnose the displayed boot, driver, file-system, storage, memory, or hardware condition.
• The computer only records Event ID 41 or 6008: Those events prove an unclean reset, not what caused the freeze.

• Do not delete Hiberfil.sys manually.
• Do not call every black screen a Fast Startup problem.
• Do not assign 0x9F or 0xA0 unless Windows or a dump actually reports it.
• Do not change Fast Startup, multiple drivers, firmware power settings, and display cables in the same test cycle.
• Do not remove unknown DumpFilters values without the exact Event ID 45 evidence and an ownership check.
• Do not use repeated forced power-offs as the normal test method.
• Do not re-enable Fast Startup before ordinary full boots and hibernation are stable.
• Do not treat Event ID 41 as proof of a bad power supply or a Windows power-management bug; it records the unclean restart.

Restore only the original HiberbootEnabled value recorded in HiberbootEnabled-before.txt or HiberbootEnabled-before-Hiberfil-rebuild.txt. Do not import an entire Power key, because that could overwrite unrelated power-policy changes made after the backup.

• If the original value was 0x1, restore it with:

  reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 1 /f
  

• If the original value was 0x0, restore it with:

  reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f
  

• If the original query recorded that the value did not exist, return it to the missing state with:

  reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /f
  

Restore hibernation separately from the original powercfg /a record:

• If Hibernate was available before the repair, restore it with:

  powercfg /hibernate on
  

• If the original system used a full hibernation file, also run:

  powercfg /hibernate /type full
  

• If the original record explicitly said hibernation had not been enabled, return to that state with:

  powercfg /hibernate off
  

Do not override a Group Policy or firmware restriction merely to reproduce the earlier text from powercfg /a.

If the Event ID 45 branch changed DumpFilters, restore the exact original multi-string lines recorded in DumpFilters-before.txt through Registry Editor. As a whole-key emergency rollback, import the CrashControl export only if no other CrashControl setting has changed since it was created:

reg import C:\BootRepairBackup\CrashControl-before-DumpFilters-repair.reg

Restart after restoring the intended values. If the original configuration itself recreates the failure, disable Fast Startup again and retain the before/after records rather than repeatedly toggling the setting.

• powercfg /a shows the intended hibernation and Fast Startup capabilities.
• HiberbootEnabled has the intended value.
• Restart succeeds twice.
• Full shutdown followed by power-on succeeds three times.
• Ordinary hibernation and resume succeed twice if hibernation remains enabled.
• Hybrid shutdown and power-on succeed three times if Fast Startup is re-enabled.
• The display, storage, network, and other affected device are usable after resume.
• No new relevant 0x9F, 0xA0, or Event ID 45 occurs.
• Reliability Monitor contains no new Windows failure for the tested transitions.

Confidence is high when the fault can be reproduced with shutdown /s /hybrid /t 0, cannot be reproduced with shutdown /s /t 0 or Restart, and stops when HiberbootEnabled is set to 0. Confidence is moderate when disabling Fast Startup appears to help but the original failure was intermittent. Stop if full and hybrid starts fail identically, the disk disappears, memory or storage diagnostics fail, the computer double-POSTs before Windows Boot Manager, a dump consistently identifies another condition, or the fault persists after Fast Startup is disabled and Hiberfil.sys is rebuilt.