Fix ERROR_POSSIBLE_DEADLOCK 0x0000046B on Windows

ERROR_POSSIBLE_DEADLOCK means a driver or app locked resources in the wrong order. Most times it's a third-party driver or antivirus filter. Fix the driver, not the symptom.

Quick answer: 0x0000046B is STATUS_POSSIBLE_DEADLOCK. It shows up when two threads each hold a lock the other needs. Usually it's a third-party driver (antivirus filter, VPN, storage). Update or remove that driver and the crash stops.

Windows doesn't crash on every deadlock — the kernel has a deadlock detector (Deadlock Detection and Recovery, DDR) that watches lock acquisition order. When it sees a cycle forming, it raises this code before the box locks hard. You'll normally see it as a BSOD with ERROR_POSSIBLE_DEADLOCK, or as an entry in Event Viewer under System with source BugCheck and the bugcheck parameter 0x46B.

I had a client last month — a small accounting firm with 12 workstations — where two machines kept rebooting mid-day. Event Viewer showed the same stop code every time: 0x46B. Turned out to be an old version of a file-sync agent that hooked the filesystem filter stack. Two threads inside ntfs.sys and the filter driver kept grabbing resources in opposite order. Newer version of the sync client, crash gone. That's the pattern with this code. It's rarely Windows itself.

First, get the bugcheck parameters

Before you do anything else, pull the crash dump and the bugcheck args. The four parameters on 0x46B tell you which resource types are involved. Open Event Viewer, filter the System log for source BugCheck, and look at the entry with Event ID 1001.

Or from an admin PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} | Where-Object { $_.Message -match '0x0000046b' } | Select-Object TimeCreated, Message -First 10

Write down those four hex values. Param 1 is usually the resource type. Param 2-4 point at the lock/thread. If you've got WinDbg installed, load the dump and run !analyze -v. That'll give you the faulting driver name right at the top.

Fix it in order — don't skip steps

Update every third-party driver that touches storage, network, or the file system. That means antivirus (all of them, including the ones bundled with OEM machines), VPN clients, backup software, cloud sync agents, and disk encryption tools. This alone fixes maybe 70% of 0x46B cases I've seen.
Uninstall recently added filter drivers. Anything installed in the last 30 days that hooks the filesystem or network stack is a suspect. Check with fltmc filters from an admin prompt. If you see a filter you don't recognize, that's your guy.

fltmc filters
fltmc instances

Run Driver Verifier on suspect drivers only. Don't enable it on all drivers — that's how you get a boot loop. Pick two or three at a time and let it run for 24 hours.

verifier /standard /driver yourdriver.sys
verifier /querysettings

When it flags one, you'll get a 0x46B dump with the specific driver named in !analyze -v. Then update or remove it.

Check for Windows updates. Microsoft has shipped fixes for lock-order issues in ntfs.sys and tcpip.sys across 2022-2024. If the machine is behind on quality updates, patch it. Windows 10 21H2 and Windows 11 22H2 both had deadlock-related fixes in their servicing stacks.
Test in safe mode with networking. If it doesn't crash there, it's a third-party driver. Confirm and narrow by disabling startup items and non-Microsoft services one batch at a time via msconfig.

If that doesn't fix it

Run SFC and DISM. Corrupted system files can cause bad lock handling. It's a long shot for this code but it's cheap.

sfc /scannow
dism /online /cleanup-image /restorehealth

Look at the app, not just drivers. User-mode apps that use WaitForMultipleObjects with mutexes can trigger kernel detection when they hold a lock across an IPC call. If the crash correlates with a specific app (Dropbox, OneDrive, a backup tool), update that app first.
Check disk health. A dying SSD can cause timeouts that look like deadlocks. Run CrystalDiskInfo or check SMART with:

wmic diskdrive get model,status
Get-PhysicalDisk | Select-Object FriendlyName, HealthStatus, OperationalStatus

Roll back the last driver update. Device Manager → right-click the device → Properties → Driver tab → Roll Back Driver. Do this for the display adapter and any storage controller that was touched recently.

Prevention

Don't stack filter drivers. Two antivirus products, a VPN, and a backup agent all hooking the same I/O path is a recipe for lock-order inversions. Pick one AV, one backup tool, and one VPN. Also keep Driver Verifier off in production unless you're actively debugging — it changes timing and can create deadlocks that don't exist under normal load.

And if you manage more than a handful of machines, enable kernel dump collection on every box. Without a dump, 0x46B is just a code. With a dump, !analyze -v hands you the driver name in ninety seconds.