Fix 0x2B2 Debugger Cannot Provide Handle

Yeah, that error is annoying because it kills your session right when you're about to find the bug. Let's get you back to debugging.

The Quick Fix

Open WinDbg or Visual Studio as Administrator. That's it. Nine times out of ten, this error disappears the moment you elevate.

If you're launching from a command line, make sure that shell is elevated too, because the debugger inherits the token. Right-click the terminal and pick Run as administrator, then start your debugger from there.

Still failing? Then grant your user account the SeDebugPrivilege explicitly. Run this in an elevated PowerShell:

secedit /export /cfg C:\secpol.cfg
(gc C:\secpol.cfg) -replace 'SeDebugPrivilege = ', 'SeDebugPrivilege = *S-1-5-32-544,' | Set-Content C:\secpol.cfg
secedit /configure /db C:\Windows\security\local.sdb /cfg C:\secpol.cfg /areas USER_RIGHTS
rm C:\secpol.cfg

Then log off and back on. That gives your admin group the debug privilege permanently.

Why This Works

What's actually happening here is the debugger is trying to call OpenProcess with PROCESS_ALL_ACCESS (or at least PROCESS_QUERY_INFORMATION and PROCESS_VM_READ). To do that on a process running under a different user or at a higher integrity level, your process needs SeDebugPrivilege enabled in its access token.

By default, members of the Administrators group have this privilege assigned, but it's not enabled unless the process is elevated. When you run as admin, the token gets the privilege enabled, and the handle opens cleanly.

The registry/policy change above forces the privilege to be present for all processes started by admins, even non-elevated ones. That's why it fixes cases where simply right-clicking as admin doesn't work—like when you're scripting a debug session or working inside an IDE that spawns child processes without elevation.

Less Common Variations

1. Anti-Cheat or DRM Interference

If you're debugging a game or any app with anti-cheat (EAC, BattlEye, Denuvo), those deliberately block OpenProcess from non-system debuggers. You'll see 0x2B2 even as admin. The real fix is to disable the anti-cheat for your session or use a kernel debugger, not to fight the handle call.

2. Protected Processes (PPL)

Windows marks certain system processes as protected (e.g., csrss.exe, lsass.exe). Even with SeDebugPrivilege, you can't open a handle unless your debugger is also signed by a Microsoft and has the anti-malware protection level. This is by design. You won't fix this with flags—you need to debug those with a kernel debugger or dump files.

3. 32-bit Debugger on 64-bit Target

Rarely, a 32-bit WinDbg trying to attach to a 64-bit process fails with this code because of Wow64 handle translation issues. Use the 64-bit version of WinDbg (or the x64 version of Visual Studio) to match the target architecture.

4. WOW64 and Handle Inheritance

If you're launching the target process from within your debugger and you get this error, the child process might be inheriting a restricted token. For example, if you launch a 32-bit process from a 64-bit context under CreateProcess with CREATE_SUSPENDED, the debugger waits for a handle that never opens. Instead, use DebugActiveProcess after the process starts—or check the bInheritHandles flag in your host code.

Prevention

Don't rely on manual elevation every time. Set up your environment so the debugger always runs elevated:

Pin WinDbg to your taskbar, right-click, go to Properties → Advanced → Run as administrator, and check the box.
For Visual Studio, create a shortcut and set the compatibility flag to run as admin, or use a script that starts devenv.exe with a scheduled task that runs elevated.
If you're a developer who debugs daily, apply the SeDebugPrivilege change from above once and forget it—your normal user token will have the privilege.
Keep your debugger version current. Old WinDbg builds had known handle leaks that would cause 0x2B2 after many attach/detach cycles. Update to the WinDbg from the Microsoft Store or the latest SDK.

One last thing: if you're using a remote debugger (like dbgsrv), the privilege must be on the machine where the target process runs, not on your local machine. That trips up a lot of people. The error text doesn't tell you that, but the handle is requested on the remote side.

That's the whole picture. Start with elevation, verify your target isn't protected, and you'll be back to breakpoints in no time.