APC_INDEX_MISMATCH 0x00000001 and WIN32K_CRITICAL_FAILURE 0x00000164 crashes

Fix it now

0x00000001 is a thread returning from kernel mode with its APC disable count unbalanced: something disabled asynchronous procedure calls and never re-enabled them. 0x00000164 is win32k failing one of its own consistency checks. Both usually point at third-party code hooking the windowing or print path.

verifier /querysettings
rundll32 printui.dll PrintUIEntry /s /t2

1. Work out whether the crash is tied to an action. Printing, opening one particular application, screen sharing and remote-control sessions are the four that matter, because they all cross win32k.
2. Install every outstanding Windows update and reboot before you remove anything. Several crashes in this family have been fixed on the Windows side, and patching is quicker than diagnosing.
3. List the software that hooks the interface: security suites with a browser or window shield, screen recorders, remote-control agents, dock and window-manager utilities, vendor printer software. Uninstall the most likely one with the vendor’s own removal tool, reboot, and repeat the action that crashed the machine.
4. If printing is the trigger, remove the print driver and its package from the Drivers page you opened above, then reinstall the printer with an in-box or current vendor driver.
5. Open the System log in Event Viewer and read the BugCheck entry. It records the stop code and its four parameters, which is what the next section teaches you to read.

Driver Verifier crashes the machine deliberately when it catches a violation. Run it out of hours, set verifier /bootmode resetonbootfail first so a failed boot disables it, and know how to reach Safe Mode to run verifier /reset.

If the crashes stop after patching or after removing one product, you are done. If not, the next section explains what the four parameters in the dump are telling you.

Why it happens

Asynchronous procedure calls are how the kernel interrupts a thread to run work in that thread’s context. Code that must not be interrupted that way enters a critical or guarded region, which increments a per-thread counter, and leaves it again, which decrements it. The pairing is strict. When a thread is about to return to user mode the kernel checks the counter is back where it started, and if it is not, it stops the machine.

Microsoft publishes exactly what to read. Parameter 3 of 0x00000001 is the thread’s CombinedApcDisable field, which is two 16-bit halves packed together: SpecialApcDisable in the high half and KernelApcDisable in the low half. A negative value in either half means a driver disabled that class of APC and never re-enabled it. A positive value means it enabled them too many times. Parameter 4 is the call type: 0 for a system call, 1 for a worker routine. That last one matters, because a worker routine tells you the imbalance happened on a system thread rather than on a thread your user was driving.

0x00000164 comes from a different mechanism reaching the same place. Rather than the dispatcher noticing an imbalance, win32k itself detects that its internal state is wrong and stops. Parameter 1 names the subtype, and the published list is specific enough to be useful: a region out of surface bounds, a missing critical APISET extension, a GDI sprite shape deleted without deleting the sprite, a failure to open the pointer device, a failed SAS key registration. Graphics, printing and input each have their own entry, so the parameter tells you which subsystem to look at before you touch anything.

The other three codes in this family are frequently listed together and are frequently described as interchangeable. They are not. 0x0000013C is INVALID_IO_BOOST_STATE, a thread that exited with a non-zero I/O boost state when it should have been zero. 0x00000160 is WIN32K_ATOMIC_CHECK_FAILURE, a win32k function violating an atomic check, with parameter 1 counting the functions on the stack inside that atomic operation. 0x00000197 is WIN32K_SECURITY_FAILURE, and its only published subtype is an object handle entry that did not point back to its object.

Full reference

Reading the parameters rather than guessing at the code

The BugCheck entry in the System log carries all four parameters. For 0x00000001 they are published as follows, and the third is the one that identifies the fault.

For 0x00000164 the first parameter is a failure type rather than an address, and Microsoft publishes the list. Match yours against it before you assume the crash is a graphics problem.

The three codes that get filed under this one

None of these three is a synonym for the other two, and none of them is a general-purpose ‘graphics crashed’ code. If your dump carries one of them, read its own parameters rather than treating it as another face of 0x00000001.

Driver Verifier without losing the machine

Driver Verifier does not find faults by watching. It applies stricter rules to the drivers you name and crashes the machine on purpose the moment one breaks a rule. That is the point, and it is why it belongs in a maintenance window.

Never turn Driver Verifier on for all drivers on a production machine. Name the third-party drivers you actually suspect. Verifying everything at once slows the machine badly and gives you a crash you cannot attribute.

Where the evidence lives

• The System log in Event Viewer records a BugCheck entry with the stop code and all four parameters. This is enough to identify the subtype without a debugger.
• Windows Error Reporting entries alongside it frequently name a module, which is usually the fastest route to a suspect.
• The memory dump under the Windows folder holds the stack. !analyze in a debugger reads it, and Microsoft points at !apc for inspecting the APCs on the thread.
• Print Server Properties, opened with rundll32 printui.dll PrintUIEntry /s /t2, lists every print driver installed and lets you remove a driver package rather than just the printer.

When the obvious suspects are all clear

• Check whether the machine has two products doing the same job. A second window or browser shield is the most common overlooked cause on managed desktops.
• Check the parameter 4 value on 0x00000001. A worker routine puts the fault on a system thread, which shifts suspicion away from anything the user was doing at the time.
• Check the graphics driver against the vendor’s list for the exact Windows build. A driver that was fine before a feature update is a plausible suspect after one.
• Test the memory. Handle and state corruption codes such as 0x00000197 come from bad memory as readily as from bad drivers.
• If the machine is a virtual desktop, check the hypervisor’s own graphics and input drivers. They hook the same path as anything else.

Every code this article covers

Confirm the fix worked

1. Repeat the exact action that used to crash the machine, several times, over a working day.
2. Check the System log and confirm no new BugCheck entries since the change.
3. Confirm Windows Update reports the machine as up to date, so the platform is genuinely ruled out.
4. Run verifier /querysettings and confirm no drivers are left under verification.
5. If you removed a print driver, print to that device again and open its properties dialog.

Questions people ask about this