Installing KB5021233 keeps causing BSOD 0xc000021a

So at last I found a solution to my problem with not being able to copy the hidparse.sys file. In a post on Reddit I happened upon a guy who seemed to know his stuff. Basically, since I have more than one drive in my computer, my boot drive could be any other letter than C since that didn't work before. My default starting point at the Command Prompt was X:\windows\system32 which is, as I read it, created by the Boot Manager in memory and it doesn't have a clue which drive is which. So, you have to find the letter of the system drive by using diskpart at the Command Prompt.

diskpart

list volume

exit

My system drive happened to be E so: xcopy E:\windows\system32\drivers\hidparse.sys E:\windows\system32\hidparse.sys

Do you want to overwrite the file? YES!

1 file copied

Rebooted the computer and it worked. Checked the files in Explorer and they were now the same.

Also..the double backslashes in the solution on many sites are a typo.

Link to original solution here: https://www.reddit.com/r/WindowsHelp/comments/zpa2k2/w11_bsod_with_stopcode_0xc000021a_microsofts/

December 2022

You might receive an error (0xc000021a) with a blue screen

Status Originating update History

Mitigated OS Build 19045.2364

KB5021233

2022-12-13 Last updated: 2022-12-17, 15:18 PT

Opened: 2022-12-17, 15:18 PT

After installing KB5021233, some Windows devices might start up to an error (0xc000021a) with a blue screen. Technical note: After installing KB5021233, there might be a mismatch between the file versions of hidparse.sys in c:/windows/system32 and c:/windows/system32/drivers (assuming Windows is installed to your C: drive), which might cause signature validation to fail when cleanup occurs.

Workaround: To mitigate this issue on devices already experiencing it, you will need to use Windows Recovery Environment (WinRE) with the following steps:

You will need to enter Windows Recovery Environment. If your device has not automatically started up into WinRE, please see Entry points into WinRE.

Select the Troubleshoot button.

Select the "Start recovery, troubleshooting, and diagnostic tools" button.

Select the "Advanced Options" button.

Select the "Command Prompt" button and wait for your device to restart, if needed.

Your device should restart to a Command Prompt window. You might need to sign into your device with your password before getting to the Command Prompt window.

Run the following command (Important: If Windows is not installed to C:\windows you will need to modify the command to your environment): xcopy C:\windows\system32\drivers\hidparse.sys C:\windows\system32\hidparse.sys

Once the previous command completes, type: exit

Select the "Continue" button.

Windows should now start up as expected.

Important: It is not recommended to follow any other workaround than those recommended above. We do not recommend deleting the hidparse.sys from your Windows\System32 folder.

Affected platforms:

Client: Windows 10, version 22H2; Windows 10, version 21H2; Windows 10, version 21H1; Windows 10, version 20H2

Server: None

Source:

https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22h2#2986msgdesc

This workaround isn't viable. I am unable to overwrite C:\Windows\System32\hidparse.sys or otherwise delete it (after creating a backup, of course) from Safe Mode. In the "Safe Mode + Command Prompt" mode, the "xcopy" command incurs an "Access is denied" error. Booting into Safe Mode with the Desktop UI, my user only has "Read" and "Read + Execute" permissions for C:\Windows\System32\hidparse.sys.

From the advanced startup options, I was able to workaround this issue by choosing the "Disable Driver Signature Enforcement" option. After restarting in this mode, I was able to rename C:\Windows\System32\hidparse.sys to hidparse.sys.old and replace it with a copy of C:\Windows\System32\drivers\hidparse.sys. For some reason, I couldn't delete the file, nor could I overwrite it, but renaming it worked...

I didn't have hidparse.sys in my system32 folder, just in the system32\drivers folder. I xcopied it to system32 folder. See what happens. I can't take these BSOD issues any longer, it's costing my business money with these crashes.

Update: by "SFC didn't work." I meant that SFC gave me an error that the action couldn't be completed (also it finished too fast). I also did SFC again after DISM revert pending actions and got the same result. Also, turning off secure boot and using flags in bcdedit testsigning and nointegritychecks didn't change the outcome. Sigverif didn't find any improperly signed drivers. Booting into safe mode didn't work, but it did trigger an "update uninstall due to boot problem" notification after I got into the system via disabling driver signatures as before. What finally let me boot consistently was: after booting by disabling driver signatures, I was lucky enough to get SFC to properly scan the live system and repair/replace the corrupted files (from the windows image that dism previously removed the unfinished update from). Also, I manually reset windows update and associated components and file repositories to get rid of the pending update. Why does SFC not work in WinRE? Automated repair SrtTrail.txt gave me: "A recently serviced boot binary is corrupt." Finally, I paused all updating for as long as possible, until I get a response from microsoft regarding what caused this massive and catastrophic issue. Fortunately, I didn't have to reinstall by some miracle, but it was close. We'll see how things work in the coming days. The thread on reddit just keeps growing. I have a feeling that there is some dll in the update that is only used or updated on a small handful of systems that wasn't properly signed by MS in the pre-Holiday rush, whose integrity check perhaps triggers even before bcd flags get used.