STATUS_WX86_BREAKPOINT 0x4000001F — WOW64 Breakpoint Fix

You're debugging a 32-bit process on 64-bit Windows. Everything's fine, then your debugger breaks with STATUS_WX86_BREAKPOINT (0x4000001F). It happens right after a thread context switch, usually the moment you step into a call that enters the WOW64 layer — GetThreadContext, Wow64GetThreadContext, or anything touching the x86 emulation path. Visual Studio users see it as a first-chance exception. WinDbg users see it land in wow64cpu!CpupSyscallStub or wow64win!whNtCallbackReturn. It's not your code. It's not something you broke.

What this exception actually is

0x4000001F is a Microsoft-defined status code the WOW64 subsystem uses as a signaling mechanism. Under the hood, the x86 emulation layer needs to stop the 32-bit thread, swap it back to 64-bit mode, do something (like service a syscall), then swap back. The clean way to do that is to plant an int 3-style breakpoint. When the kernel traps it, WOW64 knows the thread is parked exactly where it expects, and it can do its x64 work safely.

So the breakpoint fires. Normally the kernel swallows it silently because it's the one that set it. The problem is when a user-mode debugger is attached — it sees the exception first and reports it, because it doesn't know the kernel planted it for itself. That's the entire story. There's no memory corruption, no bad pointer, no hung driver.

If you're seeing 0x4000001F at a random point with no debugger attached, that's a different problem — usually a broken third-party hook DLL (antivirus, EDR, some overlay tools) that's intercepting the WOW64 path and not chaining the exception properly.

The real fix

The fix is almost always "tell your debugger to ignore it." Don't try to patch anything, don't reinstall Windows, don't chase driver updates. The exception is by design.

Confirm you're debugging a 32-bit process on 64-bit Windows. In Task Manager, check for the "(32 bit)" suffix next to the process. In WinDbg, run !wow64exts.info. If you're on pure 64-bit or pure 32-bit Windows, this exception shouldn't appear, and its presence means something else is hooking the process.
In Visual Studio: Debug → Windows → Exception Settings. Search for 0x4000001F or STATUS_WX86_BREAKPOINT. Uncheck the box. If it's not listed, click the plus, add the code as a Win32 exception, and leave it unchecked. The "Just My Code" setting under Tools → Options → Debugging also helps — it filters out non-user-code exceptions.
In WinDbg: set the exception filter to ignore it. From the command line:
```
sxe -c "gh" 4000001f
```
The -c "gh" tells WinDbg to handle-and-continue automatically. If you want to log it once and then silence it, use sx- 4000001f after the first hit. Reload the extension with .reload if the filter doesn't stick.
In your code (if you own the debugger loop): if you're writing a custom debugger or using WaitForDebugEvent, check for EXCEPTION_BREAKPOINT with the code 0x4000001F and pass it through with DBG_CONTINUE. Don't call SuspendThread first — that's what causes WOW64 to deadlock on the next context swap.
```
if (de.dwDebugEventCode == EXCEPTION_DEBUG_EVENT &&
    de.u.Exception.ExceptionRecord.ExceptionCode == 0x4000001FUL) {
    ContinueDebugEvent(de.dwProcessId, de.dwThreadId, DBG_CONTINUE);
    return;
}
```
Check your anti-malware and EDR. CrowdStrike Falcon, SentinelOne, and several older Symantec Endpoint builds hook ntdll and can turn this benign breakpoint into a real crash. If 0x4000001F shows up in production with no debugger, temporarily disable the AV, reproduce, and check wow64log.txt in the process directory (enable via HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<exe>, add string Wow64LogEnable = 1).
Update your debugging symbols. Stale symbols for wntdll.pdb make the stack look wrong and send people down rabbit holes. Set the symbol path to srv*C:\Symbols*https://msdl.microsoft.com/download/symbols and run .reload /f.

If it still fails

If the exception keeps happening after you've told the debugger to ignore it, something else is firing it. Walk this list:

You're stepping into WOW64 code. Don't. Press F10 over any call into kernel32!Wow64* or ntdll!Nt* — step over it. Stepping into the emulation layer is asking for weird states.
A 32-bit DLL is doing something sketchy. Old DRM wrappers (SecuROM, StarForce), some game anti-cheat modules, and ancient Visual C++ 6 runtime shims love to hook the WOW64 transition. Process Explorer → View → Lower Pane → DLLs will show you what's loaded. Cross-reference with Microsoft's WOW64 docs.
You're inside a Windows Insider build or a patched kernel. Some builds have shipped WOW64 regressions where the exception filter is set wrong. Check the build number (winver) and search the Feedback Hub.
Turn on WOW64 logging temporarily. Add the registry value above, reproduce, read wow64log.txt. It'll show you exactly which syscall triggered the trap and which module was on the stack.
Check for pending Windows updates. Not the vague "update Windows" advice — specifically, look at the WOW64-related hotfixes in the last six months. KB numbers around WOW64 context handling have shipped as recently as the 23H2 servicing train.

One more thing: if you're running a 32-bit process under a job object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE and it's crashing on 0x4000001F, that's a separate known issue — the job object kills the thread mid-WOW64-transition. Remove the limit, test, and if it clears, you know where to look.

Nine times out of ten, ignoring the exception in the debugger is the whole fix. The other one time, an EDR product is the culprit. Start there before you do anything drastic.