*Update* Microsoft has released several out-of-band updates to address the BSoD issues detailed in this article. The KB’s are KB5001565, KB5001566, KB5001567, & KB5001568. Packages for these updates are available in PDQ Deploy’s package library. These new updates should also be available via automatic updates. The methods for dealing with faulty updates covered in this article are still relevant and may be useful for managing updates in the future.
As if Microsoft didn’t already have its hands full with its recent Exchange vulnerabilities, users are reporting that the latest Windows 10 security updates are crashing systems while attempting to print to certain network printers. You know what they say: when it rains, it pours, and our network printers stop working… or something like that.
March’s Patch Tuesday has come and gone, and with it, a flurry of new cumulative updates. Two updates in particular, though, seem to be the culprits behind the newest IT pain point. KB5000808 and KB5000802 are gaining a nasty reputation for not playing nice with certain network printers. While Kyocera printers seem to be the most widely reported, other printer brands that seem to be experiencing problems with these updates are Dymo, OKI Data, Zebra, and Ricoh.
Users are reporting that after applying these updates, they are no longer able to print to affected printers. Attempting to print to any affected device results in a BSoD (blue screen of death) with the following details:
Stop code: APC_INDEX_MISMATCH
What failed: win32kfull.sys
Several methods of resolving these issues have come out online, though users are reporting varying degrees of success. The most common and successful solution seems to be uninstalling the updates. Unfortunately, since these are security updates, that means you may be opening up your systems to vulnerabilities by removing these updates. But, if you like living on the edge and aren’t afraid to roll those dice, this method should get your users off your back while you wait for Microsoft to patch the patch.
Here are a few different ways to remove the affected KBs.
If you only have a couple of affected machines and you don’t mind going for a walk, uninstalling this update through Control Panel is a pretty simple and straightforward process.
Type Control Panel into the Windows 10 search box and hit Enter
Click Uninstall a program
Click View installed updates
Select the appropriate update (KB5000802 or KB5000808) and click Uninstall
After running the uninstall, the system will ask for a reboot. Congrats, you can now blow through as much expensive toner as you want!
Similar results can be accomplished with the following commands in an elevated command prompt:
wusa /uninstall /KB:5000808
wusa / uninstall /KB:5000802
The problem with this command is that it will require user input. Some users have said they were able to use the /quiet parameter, though most reports say that the /quiet parameter doesn’t work. I’ve tried it, and it was unsuccessful for me.
Suppose you’ve already applied these updates to hundreds of machines and are now being bombarded with phone calls from angry people saying you broke their computers. In that case, it’s time to use the power of PDQ Deploy & Inventory to get people back up and printing.
Launch PDQ Deploy and click New Package
Enter a package name like Uninstall KB5000808
Click New Step > PowerShell
Add the following PowerShell command
Get-WindowsPackage -Online | where PackageName -like *18362.1440.1.7 | Remove-WindowsPackage -Online -NoRestart
With our package created, we’re ready to deploy it to the affected workstations. We can use dynamic collections in PDQ Inventory to target only the computers with the KB installed.
While in Deploy, click on the Uninstall KB5000808 package and click Deploy Once
Click Choose Targets > PDQ Inventory > Collection
Click Windows Update > Workstations > Windows 10 > Windows 10 Version 1909 > Cumulative Update 64-bit > Win 10 Version 1909 Cumulative Update 64-bit (Latest)
Click Deploy Now
To deploy this to computers with KB5000802, use the following script instead and deploy it to the Win 10 Version 2004 Cumulative Update 64-bit (Latest) collection in PDQ Inventory.
Get-WindowsPackage -Online | where PackageName -like *19041.867.1.8 | Remove-WindowsPackage -Online -NoRestart
Some users have reported that switching to a Microsoft PCL6 or other type of driver has resolved the issues for them. The downside to this is you may lose some functionality with the printer.
An employee from Microsoft has also offered the following resolution on Reddit.
“If you run into APC_INDEX_MISMATCH BSOD, you can try these steps as a mitigation until Microsoft addresses it in the future -
Section 1 - Enable Direct Printing. This should allow 32bit apps to print on 64bit OS without crashing.
Identify the name of your printer. E.g., "Kyocera TASKalfa 820 KX"
In an elevated command prompt, run rundll32 printui.dll,PrintUIEntry /Xg /n "Kyocera TASKalfa 820 KX". If Direct appears on the line of attribute:, that means direct printing has been turned on and you had the right settings - stop here and proceed to section 2. Note - replace the Kyocera TASKalfa 820 KX text with your printer's name
If Direct setting is not on, in an elevated command prompt, run rundll32 printui.dll,PrintUIEntry /Xs /n "Kyocera TASKalfa 820 KX" attributes +direct Note - replace the Kyocera TASKalfa 820 KX text with your printer's name
Often times, apps like Acrobat and OpenOffice runs as 32bit apps and this should be enough to workaround around the problem until Microsoft addresses the issue. But this will not solve the problem for 64bit applications printing on 64bit OS, nor 32bit applications printing on 32bit OS. Section 2 - Enable PrintIsolationAware appcompat fix to your printer. This should allow 64bit applications printing on 64bit OS and 32bit applications printing on 32bit OS without crashing.
Follow the directions from Microsoft to acquire the Application Compatibility Tookit.
Follow these instructions to use the Compatibility Administrator tool to apply the “PrinterIsolationAware” fix to the affected application”
It’s times like these that people should reflect on their patch management policy and determine if changes should be made. With critical vulnerabilities, implementing patches should be the highest priority. However, if security updates are low risk, then waiting a few days or even a week before patching may better serve your organization. Within a week, known issues will usually be reported and often fixed. Microsoft has been criticized in the past for not thoroughly testing their updates, don’t let them make you their test subjects.