RESOURCE_OWNER_POINTER_INVALID 0x00000132 and lock ownership crashes

Fix it now

These four stops are lock accounting failures: an invalid resource owner pointer, a resource released by a thread that never owned it, a thread terminated with AutoBoost lock entries still held, or a thread that exited with an asynchronous procedure call pending. On a virtualisation host the culprit is nearly always a file system filter driver.

fltmc filters
verifier /querysettings

1. Confirm the host is keeping dumps. In System Properties, Advanced, Startup and Recovery, set debugging information to Automatic or Kernel memory dump.
2. Open the newest dump in the Windows debugger and run !analyze -v. Note the module it names; that name is the whole point of the exercise.
3. Match every third-party filter in the fltmc filters output to a product you know is installed. Antivirus, backup, encryption and data loss prevention agents all appear here.
4. Check the named driver against its vendor’s supported platform list for the exact Windows Server build you are running, and update it.
5. Where two products provide overlapping filters, remove one with the vendor’s own uninstaller, reboot, and confirm with fltmc filters that the filter has actually gone.

For 0x00000020 read parameter 2, the thread’s APC disable count. Microsoft states that a negative value means a driver disabled APCs without re-enabling them and a positive value means the reverse, which is the fastest route to the offending code path.

If the host is stable after updating or removing the driver the dump named, you are done. If it is not, the next section explains what the kernel was checking and which of the four codes you have.

Why it happens

Windows uses executive resources to arbitrate shared access to kernel structures. A resource records which thread owns it, whether that ownership is shared or exclusive, and who is waiting. Alongside them the kernel runs AutoBoost, which tracks lock ownership so that a thread holding a lock can be given a temporary priority lift when something more important is waiting on it. Both mechanisms depend on ownership records that describe reality.

Each of these four stops is the moment a record stopped describing reality. 0x00000132 says an invalid resource owner pointer was supplied, and its parameters hand you the resource, its owner table, the current thread and the pointer that was wrong. 0x000000E3 is blunter: a thread tried to release a resource it did not own. 0x00000153 says a thread was terminated before it had freed all its AutoBoost lock entries, which the documentation attributes to a thread relying on another thread to release its lock, or to inconsistent flags passed to the lock package. 0x00000020 says an asynchronous procedure call was still pending when a thread exited.

The kernel cannot carry on from any of them. Ownership records are what guarantee two pieces of code are not modifying the same structure at once, so continuing on records known to be wrong is worse than stopping. That is why there is no repair to apply on the machine: the fix is always to identify the driver that broke the pairing.

They cluster on virtualisation hosts for a structural reason. A host runs very few applications but a great many filter drivers, all intercepting file and storage operations at high volume against cluster shared volumes and multi-terabyte virtual disk files. That is a workload most vendors test less thoroughly than a file server, and it is where the bugs surface.

Full reference

Reading the four codes apart

Parameter 2 of 0x00000020 is the one to read first on any of these. The count is decremented when a driver calls KeEnterCriticalRegion, FsRtlEnterFileSystem or acquires a mutex, and incremented when it calls the matching KeLeaveCriticalRegion, KeReleaseMutex or FsRtlExitFileSystem. Because those calls should always pair, the count should be zero at thread exit. A non-zero value tells you which half of the pair a driver skipped.

Working out which filters are loaded

Driver Verifier deliberately bugchecks the machine on the first violation it finds. Enable it for a small, named set of third-party drivers only, out of hours, and be certain you can reach Safe Mode to run verifier /reset before you start.

Removing an agent properly

1. Take the host out of service and drain its virtual machines first. A stop during removal is not unusual.
2. Use the vendor’s dedicated removal utility rather than Programs and Features. A normal uninstall commonly leaves the minifilter registered.
3. Reboot, then run fltmc filters and confirm the filter is absent rather than merely idle.
4. Only then install whatever is replacing it, and confirm the replacement’s filter appears where you expect.

When the filter list is clean and it still stops

• Check the storage path. A multipath, RAID or host bus adapter driver mismatched against its firmware produces exactly this class of fault under load, and the dump names the module.
• Apply the latest cumulative update to the host before opening a case. Lock accounting defects are routinely fixed in servicing without a public note.
• Compare nodes. If one node in a cluster stops and the others do not, diff their driver versions before you diff anything else.
• Keep every dump. A single dump gives you one module name; three dumps that all name the same module give you a support case the vendor cannot deflect.

Every code this article covers

Confirm the fix worked

1. Run the host through a complete backup cycle and a full business day without a stop.
2. Run fltmc filters and confirm the filter set is what you intended, with no leftovers from a removed product.
3. Confirm the agent you updated reports its new version in its own management console.
4. Confirm no new dump has appeared in the Windows folder or its Minidump subfolder since the change.
5. Run verifier /querysettings and confirm nothing is left under verification.

Questions people ask about this