Fix STATUS_WAKE_SYSTEM_DEBUGGER (0X80000007)

The debugger woke due to a hardware interrupt. Usually a misconfigured kernel debugger or a driver triggering a breakpoint. Disable or reconfigure it.

Quick Answer

Disable kernel debugging with bcdedit /debug off as admin, then reboot. That's the fix for most people.

Why This Happens

You're looking at STATUS_WAKE_SYSTEM_DEBUGGER, and the key word is 'wake'. Windows has a kernel debugger that sleeps most of the time—it only activates when something specific triggers it. An interrupt, like a hardware breakpoint or an NMI (non-maskable interrupt), wakes it. That's what the error is telling you: the debugger woke and now you see this status instead of a normal boot.

What's actually happening here is one of two things. Either you (or a tool) enabled kernel debugging and left it on, or a driver is hitting a breakpoint that assumes a debugger is attached. The reason this shows up on a normal machine is usually forgotten debug settings from a previous session. I've also seen it after a Windows feature update re-enables debugging—rare, but it happens.

The interrupt part is interesting. It's not a crash. The system didn't fail. It just paused long enough for the debugger to register the wake, then something went wrong and you're stuck at this status. Sometimes it's a one-off, but if it repeats, you need to act.

Fix Steps

Disable kernel debugging — Open Command Prompt as Administrator and run
```
bcdedit /debug off
```
Then reboot. This is the number one fix because the debugger was likely left enabled.
Check for a debugger connection — If you're not using WinDbg or Visual Studio, make sure nothing is attached. Disconnect any USB or serial debug cables. A physical connection can cause a wake trigger.
Remove the debug boot entry — Run
```
bcdedit /deletevalue {current} debug
```
This removes the debug flag entirely, not just toggles it off.
Look at the last boot — If the error appears after a specific driver install, roll back that driver. Use Device Manager to find recently changed devices.

Alternative Fixes

If disabling debug doesn't work, the culprit is a driver or a service that explicitly requests a breakpoint. Here's what I'd try:

Run verifier — Driver Verifier can identify which driver is causing the interrupt. Set it to standard settings, let it crash, and check the dump. It's heavy but it pinpoints the driver. Remember to turn it off after.
Disable NMI — Some systems have an NMI option in BIOS/UEFI. If it's enabled, turn it off. An NMI can wake the debugger even when you don't intend it.
Check your BIOS debug port — If you have a serial debug port configured, disable it. It's easy to forget you left it on.

Prevention

The real fix is to never leave kernel debugging on. If you're a developer who needs it, set it up only when you're actively debugging, then turn it off. I've seen this error on a production server because someone enabled debugging for a driver issue and forgot. Don't be that person.

Also, document your BIOS settings. If you change debug-related options, write them down. It takes two minutes and saves an hour of confusion later.

One more thing: if you're using a VM and this happens, check the hypervisor settings. Some VM tools enable kernel debugging by default. I had this exact issue with a VirtualBox instance—turned off the debug flag and it never came back.