PatchDay Alert
Analysis · 6 min read · 1,205 words By The Commentary Desk · Commentary

Hotpatch was supposed to be the smoother path

KB5087424 broke 32-bit printing on Windows Server 2022, and the no-reboot delivery model that was supposed to reduce friction has no fix path that doesn't surrender the security content.

Hotpatch was supposed to be the smoother path

The 32-bit build of Notepad at C:\Windows\SysWOW64\notepad.exe will not print on a Windows Server 2022 host that took the May hotpatch. It throws 0xc0000142 and exits. The 64-bit Notepad next to it prints normally. That is the entire reproduction, and it has been reproducible for two weeks on hosts that installed KB5087424, the May 12, 2026 hotpatch cumulative update.

Hotpatching was sold as the smoother path. No reboots, same security baseline, less operational friction. On the first big print-stack regression to hit the channel, the smoother path has no smooth way out. There is no Known Issue Rollback, no ADMX toggle, no registry workaround, no out-of-band fix. The only confirmed remediation in the field is uninstalling the hotpatch, which is also the security content you took the hotpatch to get.

What broke

splwow64.exe is the WoW64 shim that 32-bit applications use to reach the 64-bit Print Spooler. After KB5087424 installs, that process fails during initialization with status code 0xc0000142, which is STATUS_DLL_INIT_FAILED. Any 32-bit application that tries to print hits the error and prints nothing. Native 64-bit printing is unaffected.

The exact DLL or initialization step at fault has not been publicly identified. A 0xc0000142 out of splwow64 is consistent with a DLL failing a version handshake or hitting an ordering conflict during process init, and hotpatches mutate in-memory code rather than replacing files on disk, which makes a spooler-adjacent DLL the plausible suspect. That is a hypothesis from the symptom, not a Microsoft postmortem.

Who actually owns this

The blast radius is bounded by the delivery channel. Hotpatches land only on Windows Server 2022 Datacenter: Azure Edition hosts enrolled in Windows Autopatch hotpatching. Servers receiving the conventional May cumulative, KB5087545, did not see KB5087424. So the affected population is not “every Server 2022 box,” it’s the slice that’s moved to no-reboot patching.

Inside that slice, the highest-risk hosts are Remote Desktop Services servers running 32-bit line-of-business clients. ERP front-ends, clinical and lab systems, banking software, manufacturing and label-printing stations. The applications that have been 32-bit for a decade because nobody is paying to recompile them. Those are the same hosts where “no reboots” was the entire reason to enroll in hotpatching in the first place.

Field reports surfaced primarily through BornCity’s IT blog, with English-language comments documenting reproduction across multiple physical servers and VMs in distinct customer environments. A separate Dynamics 365 community thread reports the on-premises Document Routing Agent breaking after the May updates. The causal KB hasn’t been confirmed there, but the timing aligns. I don’t know whether the Document Routing Agent failure is the same bug or a separate component; that’s worth testing if you run it.

What Microsoft has said

Almost nothing. Two weeks after release, the Windows Server 2022 release health page does not list the regression. The KB5087424 support article itself does not document a known issue for 32-bit printing. No KIR, no workaround, no out-of-band patch. The next scheduled cumulative for Server 2022 is June 10, 2026.

There is also an open question about scope. The hotpatch and its full-CU companion are designed to land on the same security baseline through the quarter. If the regression sits in the in-memory hotpatch diff, the full CU KB5087545 may be clean. If the regression sits in the security fix content itself, KB5087545 carries the same bug. Nobody outside Microsoft has independently confirmed which. Test 32-bit print paths before assuming the non-hotpatch CU is safe.

Why this keeps happening to the print stack

The print stack regresses every time Microsoft hardens it. This is the pattern, not the exception.

PrintNightmare in June 2021 forced an out-of-band Spooler fix and a follow-up that layered Point and Print admin-credential requirements via KB5005033 in August 2021. The hardening immediately broke unattended driver deployment. By October 2021, KB5006670 replaced Win32spl.dll with a version that broke network printing entirely and returned 0x00000709 errors, fixed two weeks later out of cycle. October 2022’s KB5018410 broke printer extensions for Type 4 drivers and wasn’t fully resolved until November 2023. January 2025’s Patch Tuesday made dual-mode USB printers emit raw IPP protocol headers instead of documents, patched with a KIR in February and not permanently closed until KB5053657 shipped in March 2025.

Microsoft is deliberately unwinding the legacy print architecture. The End of Servicing Plan for Third-Party Printer Drivers, published in September 2023 and covered by Neowin, blocks third-party drivers from Windows Update by default starting January 15, 2026, elevates the IPP inbox class driver to the preferred path by July 2026, and confines legacy drivers to security-only fixes from July 2027. Microsoft’s MORSE team told Bleeping Computer in December 2023 that Spooler bugs account for 9% of all Windows MSRC cases and that Windows Protected Print Mode would mitigate over half of known print-class vulnerabilities.

That is the context this regression sits inside. The print stack is being rewritten in flight on a fleet that still has 32-bit line-of-business clients on it. Bugs in the seams are not a surprise. The surprise is that hotpatch, a delivery model whose whole pitch is that it removes friction, has nothing better to offer than “uninstall the security update.”

What you should actually expect

If you run Server 2022 Datacenter: Azure Edition with Autopatch hotpatching enabled, audit your hosts for 32-bit print dependencies before assuming this regression doesn’t touch you. RDS hosts with legacy line-of-business clients are the first place to look. If 32-bit printing is in scope and the host took KB5087424, the only confirmed fix is removing the hotpatch and accepting the security gap until either Microsoft ships a KIR or the June 10 cumulative supersedes the regression. Don’t assume KB5087545 is clean. Test it. We track this kind of thing day by day in PatchDay Alert, the digest. When the June 10 cumulative ships, we’ll flag whether the splwow64 regression follows it.

The deeper expectation worth resetting: hotpatching reduces reboot friction. It does not reduce the chance of a regression, and when one lands, the rollback path is the same uninstall it has always been, just without the option to ride out the issue until next month because you already deployed it without a reboot window.

Hotpatching was supposed to be the smoother path. On its first big print-stack break, it’s the same path, with one fewer exit.

Sources

Share

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekday digest.

Subscribe