Several Windows 10 versions affected by blue screen issue

Topic

New Reply

Saw this over at GHacks.net and I can confirm that I got affected by it recently.

https://www.ghacks.net/2022/12/18/several-windows-10-versions-affected-by-blue-screen-issue/

Mike

“Several Windows 10 versions are affected by a new issue that may cause blue screen errors on affected devices. Microsoft confirmed the issue on Saturday for the following Windows 10 versions: Windows 10 version 22H2, 21H2, 21H1 and 20H2.”

3 users thanked author for this post.

unbob, rontpxz81, NaNoNyMouse

Reply | Quote

Replies

You have already got a thread with this info.
https://www.askwoody.com/forums/topic/win-10-pro-22h2-os-fails-to-boot-after-updates/

cheers, Paul

Reply | Quote

https://www.askwoody.com/forums/topic/final-patches-for-2022/page/3/#post-2509545

Reply | Quote

Note that they aren’t all suddenly having this issue.  What happen was that the secure boot patch triggered a blue screen when it was offered up to 21H2, 21H1 and 20H2 back in August and then it’s now triggering bsod’s on some machines – not all – now that it’s offered up to 22H2.

The post is a bit misleading.

Bottom line, and I keep saying this, block it on home and consumer machines.  I see no reason to install it.  Microsoft doesn’t know your risks.

Susan Bradley Patch Lady

Reply | Quote

yup, KB5012170 is being offered to BOTH Win10 22H2 (build 19045) AND Win11 22H2 (build 22621) versions since last Tue. Dec. 13

block/hide the KB5012170 update asap

Reply | Quote

I have installed both KB5012170 (in Aug.) and KB5021233 (Dec.) and haven’t encountered any BSODs.

I suspect those affected haven’t updates their PCs BIOS/Firmware for long.

I do think the Microsoft with its harvested Telemetry should know exactly, and publish, the cause of the BSODs so users can check their PCs for compatibility before installation.

2 users thanked author for this post.

wavy, oldfry

Reply | Quote

And yes, it would be nice if they could expose a bit of the telemetry and say what’s going on.  There’s more to this.

Susan Bradley Patch Lady

Reply | Quote

Just FYI…

The article @Mike refers to in his initial post, as well as numerous others now on the web, and the proposed Microsoft workaround are for KB5021233 (2022-12 Cumulative Update for Windows 10) not the Security update for Secure Boot DBX (KB5012170).

Check the “known issues” section at December 13, 2022—KB5021233 (OS Builds 19042.2364, 19043.2364, 19044.2364, and 19045.2364)

Also, the syntax of the proposed Microsoft workaround is wrong!

It says to use…

xcopy C:\windows\system32\drivers\hidparse.sys C:\windows\\system32\hidparse.sys

…which will not work for two different reasons.

1st, there’s an “unacceptable” double slash \\ between C:\windows and system32

2nd, the “proper” syntax to copy a “file” from one folder to another is xcopy [path to the source file] [path to the destination folder]

The “correct” command to copy hidparse.sys from the Systems32\Drivers folder to the System32 folder using xcopy would be…

xcopy C:\windows\system32\drivers\hidparse.sys C:\windows\system32

2 users thanked author for this post.

satrow, WCHS

Reply | Quote

I’ve seen both throw off issues.  Now mind you, I’ve only see bsod’s on the 22H2 and no other platform.

Something sounds weird like some other root cause/gamer overclocking/something is triggering this.

There’s more to this going on as it’s not every machine doing this.  Either a piece of software introduced this mismatch or some OEM build or something.

Susan Bradley Patch Lady

Reply | Quote

I have W10 Pro 22H2 installed as of 11/9/22 and KB5012170 installed (without issue) as of 8/23/22. I have not yet attempted to install any of the Dec. updates but have tried to understand the antecedent condition for the hidparse.sys bsods with KB5021233. On my system hidparse.sys ver. 10.0 19041.2251 size 45.0kb appears in C:\windows\system32 in C:\windows\system32\drivers and in C:\windows\system32\driverstore. They are all the same versions of hidparse.sys and were last updated when the upgrade to W10 22H2 occurred. Some people report they do not have hidpars.sys in their C:\winidows\system32 folder and since MS uses xcopy command to move this file to the system folder, does that suggests that if the file is not there prior to installing KB5021233 the system will develop the stop error on reboot? It is not clear to me how to determine if system is at risk for bsod from one that is not at risk based upon info from MS. Please someone, tell me what I am missing?

1 user thanked author for this post.

WCHS

Reply | Quote

Kudos to alejr post below:  https://www.askwoody.com/forums/topic/several-windows-10-versions-affected-by-blue-screen-issue/?view=all#post-2510432  Have you tried out his batch file?

Susan Bradley Patch Lady

Reply | Quote

No, I cannot access the file, however, if I am understanding his post he seems to imply that there should not be a copy of hidparse.sys in the C:\windows\system32 folder. The information from MS seems to imply that the problem arises when hidparse.sys is missing, not when it is present. That is why MS appears to want you to copy the file to C:\windows\system32 to address the bsod stop error. MS gives no clue if the file does not exists prior to installing the update or whether the installation corrupted the file. IMHO MS could do a little better on the communications front.

Reply | Quote

Register on the site and then you can access the file to check your system.  The way I read it is if there are two different versions.

 

“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). This might cause signature validation to fail when cleanup occurs.”

Susan Bradley Patch Lady

Reply | Quote

Microsoft’s explanation of the problem indicates it’s caused by a version mismatch between duplicate hidparse.sys files in those two different locations.

That “seems” to indicate the update changes the one in the C:\Windows\System32\drivers directory (where device drivers are “normally” expected to be located) but not the one in the C:\Windows\System32 directory — which causes the resultant version mismatch and BSOD.

So, if your system only has one copy of hidparse.sys in the C:\Windows\System32\drivers directory (where device drivers are “suppose” to be) then you likely won’t encounter any problems installing the update.

On the other hand, if there’s a duplicate in the C:\Windows\System32 directory, even if it’s the exact same version as the one in the C:\Windows\System32\drivers directory, you “might” encounter the BSOD problem after installing the update.

My batch file doesn’t compare the version info between duplicate hidparse.sys files, it simply checks to see if your system actually has a duplicate hidparse.sys file in the C:\Windows\System directory and, if so, lets you know there may be a “POSSIBLE CONFLICT”.

BTW, the one located in C:\windows\system32\driverstore is a backup copy in case Windows detects the primary is corrupt and needs to be replaced. And, if it does replace it, it’ll only replace the one located in the C:\Windows\System32\drivers directory!

1 user thanked author for this post.

jburk07

Reply | Quote

Susan Bradley wrote:

It is not clear to me how to determine a system that is at risk for bsod from one that is not at risk based upon info from MS.

I have the same question. I am Win10/Pro, 21H2 (still). I want to update to December’s CU KB5021233, but I am wondering if I am headed for a BSOD.

I have two laptops, both of which installed November’s CU KB5019959, Build 19044.2251 on Dec 4.

Laptop 1 downloaded the CU at 3:19 PM and restarted at 3:43 PM. Between the download and the restart, at 3:32 PM, hidparse.sys appeared in two places C:\Windows\System32 and C:\Windows\System32\drivers.

On the other hand, Laptop 2 downloaded the CU at 6:14 PM and restarted at 6:36 PM. Between that download and that restart, at 6:33 PM, hidparse.sys appeared in only one place C:\Windows\System32\drivers.

The hidparse.sys file is 45KB for version 10.0.19041.2251

So, both laptops have hidparse.sys in C:\Windows\System32\drivers but only laptop 1 has a duplicate in C:\Windows\System32\.

Should hidparse.sys be in both locations? Or should it be in only 1 location? And if only 1 location — which one?

Reply | Quote

If you only have one located in c:/windows/system32/drivers  that’s (as far as I can tell) the normal one.  If you have two are they the same file file version/date?

Susan Bradley Patch Lady

1 user thanked author for this post.

jburk07

Reply | Quote

More strangeness about this situation…

According the Microsoft’s known issues note about the KB5021233 BSOD problem (emphasis is mine):

After installing this update, 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). This might cause signature validation to fail when cleanup occurs.

So, I checked both of my PC’s and the 6 I maintain for my Uncle (combination of Win10 Pro 22H2 and Win10 Home 22H2) and hidparse.sys was only in the C:\Windows\System32\drivers folder.

This would explain why only some PC’s are experiencing the BSOD problem, but wait, there’s even more strangeness!

I googled hidparse.sys problems and, believe it or not, found a post from Oct 9 2017 on the Tom’s Hardware forum (Help! BSOD every day) where the mini dumps the individual posted looking for help show hidparse.sys was being loading twice on his system; once from C:\Windows\System32\drivers, and a second time from C:\Windows\System32.

So it appears, the issue of duplicates of hidparse.sys in two different locations in Win10 has been around for quite a while!

However, since it seems not every copy of Win10 has duplicate hidparse.sys files, the question becomes what causes the duplication on some systems.

IMHO, the most likely culprit is probably some “3rd party S/W” for a particular HID device that, during installation, looks for an existing hidparse.sys driver in the wrong place (C:\Windows\System32 instead of C:\Windows\System32\drivers) and, when it doesn’t find it, installs its own copy into C:\Windows\System32 (with the appropriate registry hooks to load it from that location.)

Anyway, I’ve attached a simply batch file (see the attached zip) you can extract and run to check whether your particular Win10 installation has a duplicate hidparse.sys in C:\Windows\System32 that might cause BSOD problems if you install KB5021233.

NOTE

Please see my post #2511713 further down this thread for the new version of this batch file.

10 users thanked author for this post.

jburk07, BigBadSteve, James77242, GeeBeeDee, andrewbore, JohnV, rebop2020, Bob99, DrBonzo, PKCano

Reply | Quote

My Win 10 installation has a hidparse.sys in both System32 and System32\drivers. They both have exactly the same created and modified dates.

Reply | Quote

I downloaded the batch file to check for the existence of the files but Microsoft Defender Smart Screen won’t allow it to run.

Reply | Quote

Click on More Info, the click Run Anyway.

Reply | Quote

On the system I’m on right now, it’s in drivers, and system32, and in several other directories whose name begins with amd64.  The first 2 are dated (modified) Dec 8 and are the same size.  The others are mixed dates.

Reply | Quote

emanhaus wrote:

I downloaded the batch file to check for the existence of the files but Microsoft Defender Smart Screen won’t allow it to run.

First, you should use the new version of this file from my Dec 26 post #2511713.

Second, here’s how to unblock it.

• “Right-click” the downloaded file and select Properties.
• On the “General tab“, check the Unblock option at the bottom.
• Click OK to apply it.

You’ll now be able to extract and run the batch file it contains.

1 user thanked author for this post.

jburk07

Reply | Quote

Thanks.  Ran it successfully and found only one instance of the hidpars.sys file.  Ran Windows Update with no ill affects.

1 user thanked author for this post.

jburk07

Reply | Quote

Susan Bradley wrote:

And yes, it would be nice if they could expose a bit of the telemetry and say what’s going on.  There’s more to this.

I would have gone further and put a block on updates on these PCs just like it is done with offering new feature releases.

Reply | Quote

alejr wrote:

So, if your system only has one copy of hidparse.sys in the C:\Windows\System32\drivers directory (where device drivers are “suppose” to be) then you likely won’t encounter any problems installing the update.

On the other hand, if there’s a duplicate in the C:\Windows\System32 directory, even if it’s the exact same version as the one in the C:\Windows\System32\drivers directory, you “might” encounter the BSOD problem after installing the update.

KB5021233 installed on Dec 15. No BSOD.
hidparse.sys has been changed/accessed on Nov. 9 (KB5019959 patch Tuesday update).
Nothing has been installed by me on Nov. 4. It seems like Microsoft ran KIR ?

Reply | Quote

No.  It’s not impacting all computer.  Like I said and alejr indicates, there’s something third party triggering this.

Susan Bradley Patch Lady

Reply | Quote

What is the ‘RollupFix’ on the file on Nov. 4 ?

Reply | Quote

Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Windows\System32\DriverStore\FileRepository\input.inf_x86_3996137c65da3bb6\
Windows 10: C:\Windows\System32\drivers\
Windows 10: C:\Windows\System32\DriverStore\FileRepository\input.inf_amd64_ebb0b272a2e119ce\
Windows 10: C:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.16299.1029_none_303f96331b9eb088\

Windows 10: C:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.16299.15_none_4bb552745b124b42\

All the places it can be.  The date doesn’t jive with a KIR timing though.

Susan Bradley Patch Lady

Reply | Quote

I think that’s just a backup/redundancies not that windows is relying on it.

10.0.19041.868 is the version in one folder, 10.0.19041.2251 is the version in another on my system.

Susan Bradley Patch Lady

Reply | Quote

Susan, it seems we are at an impasse if you have hidparse.sys in the system 32 directory and also in the system32\drivers directory even if they are the same version of the file. The reason I say this is that MS clearly advises against deletion of the file in system 32 directory prior to installing KB5021233. If you must install the update with hidparse.sys in both locations, even if identical, to see if you end up with bsod stop error, there is no apparent  apriori method to determine outcome. You must install and then go into recovery mode if it turns out you are in the unlucky column. I continue to suspect that KB5021233 is causing the issue because the solution is to manually copy the hidparse.sys file from system32\drivers to system32 directory. how or why the file mismatch occurs is what we are missing it seems.

Reply | Quote

The way I’m reading it, it only gets triggered if there is a mismatch.

It comes down to – if you have a backup, you can recover from ANYTHING.  If you are concerned about this BSOD you should also be concerned about ransomware, loss of power supply, hard drive crash, etc etc.

You shouldn’t be any more or less concerned about this update than anything else that can happen to your computer.

Susan Bradley Patch Lady

Reply | Quote

alejr wrote:

Anyway, I’ve attached a simply batch file (see the attached zip) you can extract and run to check whether your particular Win10 installation has a duplicate hidparse.sys in C:\Windows\System32 that might cause BSOD problems if you install KB5021233.

Or, you can just run free portable ‘Everything’ app.

Reply | Quote

I just updated both of my Win10 Pro 22H2 PC’s with KB5021233 and had no problems with hidparse.sys (only one in C:\Windows\System32\drivers before the update, only one after the update.)

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
However, I did encounter some extreme weirdness on my Dell laptop!

After it successfully rebooted and got to the desktop, the lower right corner displayed “Windows 10 Enterprise“?!?!

So I ran WinVer and it also displayed “Windows 10 Enterprise“?!?!

Then I checked Settings > System > About > Windows specifications and it showed “Windows 10 Pro” (which is my actual OS.)

This lasted for about 5 mins, and then the desktop label disappeared and Winver reverted to “Windows 10 Pro” like it should.

What

Did KB5021233 “temporarily” upgrade me to Win10 Enterprise for some reason and then downgrade me back to Pro?

1 user thanked author for this post.

jburk07

Reply | Quote

At any point in time have you had a Microsoft 365 license? Some of them include a Windows enterprise license as well.

Susan Bradley Patch Lady

Reply | Quote

Susan Bradley wrote:

At any point in time have you had a Microsoft 365 license? Some of them include a Windows enterprise license as well.

Nope, not even a trial version!

Reply | Quote

That’s exactly what I had on my Lenovo laptop. It said Enterprise in the bottom right hand corner of the home screen. The next time I booted it, I got the BSOD.

Mike

i5-3210M, Win10 Pro

Reply | Quote

Interesting.

Maybe another piece of the puzzle as to why some PC’s are effected and some aren’t?

Anyway, I didn’t experience a BSOD on mine… but then I didn’t reboot it until “after” it reverted back to indicating I was on Win10 Pro.

Reply | Quote

Susan Bradley wrote:

If you only have one located in c:/windows/system32/drivers that’s (as far as I can tell) the normal one. If you have two are they the same file file version/date?

Susan, Laptop 1 has two, i.e., hidparse.sys, in both locations and the file version/date/time/size is the same according to the respective file-description bubble that pops up.

Reply | Quote

KB5021233 issues –
From the horses mouth (Last updated: 2022-12-21) link:

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

Windows devices might start up to an error (0xc000021a) with a blue screen….

Workaround

1. You will need to enter Windows Recovery Environment.

2. Select the Troubleshoot button.

3. Select the “Start recovery, troubleshooting, and diagnostic tools” button.

4. Select the “Advanced Options” button.

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

6. 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.

7. Run the following command: xcopy C:\windows\system32\drivers\hidparse.sys C:\windows\system32\hidparse.sys (note, you must change this path if Windows is not installed on the C drive)

8. Once the previous command completes, type: exit

9. Select the “Continue” button.

10. 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.

Keeping IT Lean, Clean and Mean!

1 user thanked author for this post.

jburk07

Reply | Quote

Microfix wrote:

From the horses mouth (Last updated: 2022-12-21)

And a followup to your earlier post:

I notice the Microsoft has changed the double slash before “system32” in the destination path to a single slash. But, “hidparse.sys” still repeats in the destination path? Is that OK?

1 user thanked author for this post.

Tregonsee

Reply | Quote

WCHS wrote:

And a followup to your earlier post:

nope, I never posted anything prior to #2510767 on this thread 🙂

Keeping IT Lean, Clean and Mean!

1 user thanked author for this post.

WCHS

Reply | Quote

Microfix wrote:

WCHS wrote:

And a followup to your earlier post:

nope, I never posted anything prior to #2510767 on this thread 🙂

Sorry, wrong person. I confused you (@Microfix) with @Alejr.

So, it should read:

And a followup to @Alejr’s post

I notice the Microsoft has changed the double slash before “system32” in the destination path to a single slash. But, “hidparse.sys” still repeats in the destination path? Is that OK?

Reply | Quote

WCHS wrote:

I notice the Microsoft has changed the double slash before “system32” in the destination path to a single slash. But, “hidparse.sys” still repeats in the destination path? Is that OK?

As I pointed out above, xcopy does not work if you use it that way (it doesn’t allow you to specify a “filename” for a copied file, only it’s destination!)

The syntax for the standard copy command does allow that sort of syntax so, whomever created the workaround, likely just confused that “minor” difference in how the two commands work.

BTW, the different between copy and xcopy is xcopy copies all a file’s info (i.e. dates, owner, permissions, etc.) while copy doesn’t; which is most likely why they want you to use xcopy.

2 users thanked author for this post.

Bob99, WCHS

Reply | Quote

alejr wrote:

As I pointed out above, xcopy does not work if you use it that way (it doesn’t allow you to specify a “filename” for a copied file, only it’s destination!)

The Xcopy command as published by Microsoft works without error for me (at an Admin command prompt):

I agree that specifying the destination filename seems unnecessary (and could cause an extra F or D question).

But there’s nothing wrong about using a destination filename with Xcopy:

Destination — Specifies the destination of the files you want to copy. This parameter can include a drive letter and colon, a directory name, a file name, or a combination of these.

xcopy syntax [Microsoft Learn]

Windows 11 Pro version 22H2 build 22621.1778 + Microsoft 365 + Edge

2 users thanked author for this post.

Specialist17, Alex5723

Reply | Quote

Microsoft is negligent with the xcopy command – first having a typo with a \\ and then a command error requiring user interaction (file or folder prompt). The average user can’t deal with this mitigation especially with these mistakes. It’s just incompetence.

Reply | Quote

@alejr –

BTW, the different between copy and xcopy is xcopy copies all a file’s info (i.e. dates, owner, permissions, etc.) while copy doesn’t; which is most likely why they want you to use xcopy.

Thanks! Not having had to use a command prompt for a few decades, I’d forgotten the difference between the two, and was indeed wondering why MS chose to use the xcopy command instead of just copy.  👍👍

Reply | Quote

If anyone has installed KB5021233 on W10 Pro 22H2 and experienced the BSOD post install, it would be interesting to know what version of hidparse.sys was copied to the system32 folder after you successfully recovered a bootable system with the mitigation. I believe a fully updated W10 system would have hidparse.sys ver. 10.0 19041.2251 in system32/drivers prior to installing KB5021233. I wonder if the December update changes the driver version without updating the file in system32 folder?

Reply | Quote

My (double) hidparse.sys files have 6.2.19041.2251 / 10.0.19041.2251 since patch November.

KB5021233 has been installed on Dec. 15 on Windows 10 Pro 22H2.

No BSOD.

Reply | Quote

Frank wrote:

I wonder if the December update changes the driver version without updating the file in system32 folder?

I mounted the backup I made before installing KB5021233 and the before/after hidparse.sys file versions were exactly the same (10.0.19041.2251) with the same creation date 11/13/22. So, at least on my system, it didn’t get updated/changed by KB5021233!

I then mounted my backup made prior to installing KB5019959 and it contained an “older” version of hidparse.sys (10.0.19041.868) so it “appears” last month’s KB5019959 is what changed it – which makes sensor since that KB also updated my Windows version # to 19045.2251.

So now the question now is, if it was changed during last month’s update, why is this month’s update suddenly causing BSOD problems on some systems??

The more info we come up with, the stranger the cause of this problem becomes.

BTW, my particular system doesn’t have a duplicate hidparse.sys in the C:\Windows\System32 folder and, from what I found looking thru my backups, never has!

Reply | Quote

Bases upon your info, it would appear that for a W10 system that experiences a BSOD post install of KB5021233 and recovers a bootable system with the prescribed xcopy mitigation copies hidparse.sys ver. 10.0 19041.2251 from the system32/drivers folder to the system32 folder. That would imply that W10 OS needs hidparse.sys in the system32 folder and yet some systems do not have a copy there. It would be helpful if MS gave up a little info on what the normal base condition between the folders is supposed to be inasmuch as their mitigation in fact copies the hidparse.sys file to system32. I have not installed KB5021233 yet and will defer until the situation becomes more clear.

Reply | Quote

IMHO, the most likely culprit is probably some “3rd party S/W” for a particular HID device that, during installation, looks for an existing hidparse.sys driver in the wrong place (C:\Windows\System32 instead of C:\Windows\System32\drivers) and, when it doesn’t find it, installs its own copy into C:\Windows\System32 (with the appropriate registry hooks to load it from that location.)

The above quote from @alejr is what I consider a very plausible explanation of why this issue has been cropping up only for some folks but not others.

The best way to see if you might be affected is to “look before you leap”… check now whether you have the file in only one or both locations and, if you do, see if they both match. I would think that they should match if you’re currently having no problems and have the file in both locations.

Reply | Quote

[Bob99]

Why not completely avoid the need to go into the Recovery Environment (WinRE) by looking in the two directories mentioned in the workaround to see if they both have the file in question and, if they do, make sure that both files are identical down to the exact file version?

If the file is only in the \Windows\system32\drivers directory, you’re probably fine and will probably have no issues.

If the file is in both places and the file copies aren’t identical after having run the install routine for KB5021233 but BEFORE rebooting the computer per the request from Windows Update, run the xcopy command using the syntax provided by Microsoft and THEN reboot the computer.

Hmm, methinks there’s a good script to be written for this using PowerShell!! The script could:

1. Run the batch file from @Bigal67 (@alejr), looking for the presence of the file in question.
2. If found, inform the user of just where it was found and, if in both the \Windows\system32 and the \Windows\system32\drivers folders, inform the user of this, telling them NOT to reboot the computer after installing the “offending” update using Windows Update or the stand-alone installer acquired from the MS Catalog and…
3. If run after the user has run the installer for the “offending” KB using Windows Update, run the xcopy command using the syntax provided by Microsoft. Upon successful completion of the xcopy command, prompt the user to reboot the computer.

Are the 3 above items too much for a good PowerShell script? Any takers, @RetiredGeek , @Paul-T , or @Rick-Corbett ?

• This reply was modified 5 months, 1 week ago by Bob99. Reason: clarified several items

Reply | Quote

Bob99 wrote:

telling them NOT to reboot the computer after installing the “offending” update

I see that you have revised the post that I originally saw in my email. It’s a bit more clear now. It appears that the proposed script is supposed to work this way:

1. If the user has not updated yet and plans on doing the update, the script determines whether or not there is going to be a problem. If there is going to be a problem, it tells the user, in advance of doing the update, not to restart, when WU asks for a restart. If the script finds no problem, it tells the user, in advance of doing the update, that it’s OK to restart when WU tells it to do so.
2. The user then does the update and does not restart if told not to do it. Instead, they run the script again and this time the script figures out it needs to do the xcopy (it only provided a warning the first time). After that, the user restarts the device.

Methinks that the update changes the hidparse.sys file in \System32\drivers between the time the “Restart” begins and the time the “Restart” finishes (i.e., during the reboot). So, doing the xcopy before the “Restart” (if that is what you are proposing) is not going to fix the problem because the “Restart” is going to change the \System32\drivers file but not the \System32 file and so you have a mismatch now – too late for the script to do anything about it.

Reply | Quote

WCHS wrote:

Methinks that the update changes the hidparse.sys file in \System32\drivers between the time the “Restart” begins and the time the “Restart” finishes (i.e., during the reboot).

As I pointed out above in my post #2511113, searching my backups “clearly” shows the Dec CU (KB5021233) does not change the hidparse.sys file, it was changed by the Nov CU (KB5019959).

So the proposed script would work as described as long as it’s copying the hidparse.sys version 10.0.19041.2251 that was installed by the Nov update.

It’s also entirely possible, if your system has duplicate hidparse.sys files in both locations but they’re both the new 10.0.19041.2251 version, your system won’t experience the BSOD problem.

Of course the only way to really tell if that’s true, is if someone who actually had duplicates of the new version in both locations and installed KB5021233 didn’t experience a BSOD.

1 user thanked author for this post.

WCHS

Reply | Quote

Just installed KB5012170,KB5021233 and .NET on 10 years old Windows 10 Pro 22H2 with i3-3xxx CPU, 8GB RAM and 512GB HDD.
No problems during (slow) installation, no BSOD.

Reply | Quote

WCHS wrote:

Methinks that the update changes the hidparse.sys file in \System32\drivers between the time the “Restart” begins and the time the “Restart” finishes

For me the files were changed with the Nov KB5019959 update.
KB5021233 didn’t touched these files.

1 user thanked author for this post.

WCHS

Reply | Quote

@alex5723, you used the plural files in your post.

Does that mean you had duplicate hidparse.sys files in both locations before installing KB5021233?

If so, that would seem to prove my above conjecture that KB5021233 is safe to install (as long as hidparse.sys in both locations are the new versions) and the script proposed by @Bob99 could be a workable solution.

1 user thanked author for this post.

Alex5723

Reply | Quote

I tend to agree with the thesis that the same file in both locations prior to installing KB5021233 is a safe to install base condition. My W10 Pro 22H2 system has hidparse.sys ver. 10.0.19041.2251 in both system32 and system32/drivers folders. The properties info shows both files were created on 11/9/22 at the same time and have the same file size on disk. The creation date of the files was when the November updates and migration from W10 21H2 to 22H2 occurred. I believe that these are the latest versions of hidparse.sys and the system would probably install KB5021233 without restart issues unless the update does something weird like corrupting the file in system32 during the installation itself.

Reply | Quote

alejr wrote:

@alex5723, you used the plural files in your post.

Does that mean you had duplicate hidparse.sys files in both locations before installing KB5021233?

Yes.

Reply | Quote

I’m a little late to the party, but decided to sacrifice one of my Win 10 Pro 21H2 production desktops (AMD) earlier than planned. Note that this machine is fully patched – Windows, firmware (UEFI/BIOS) and 3P drivers.

BEFORE Dec Cumulative Update KB5021233:

1. hidparse.sys present in both directories
2. Version 10.0 19041.2251 and same file size for both
3. Creation and Modified date on both the same (Nov 14)

Nov 14 is the date that I applied November Cumulative KB5019959 which clearly updated the files in both locations.

AFTER successful Dec Cumulative Update KB5021233:

1. hidparse.sys still present in both directories
2. Version 10.0 19041.2251 and same file size for both (no change)
3. Creation and Modified date on both unchanged (Nov 14)

HOWEVER, KB5021233 DID “touch” both files because the Access timestamp has been changed to when the update occurred (Dec 24, 7:27PM). When KB5021233 peeks into hidparse.sys, what’s it looking for and what does it do if it finds it? Your guess is as good as mine. Microsoft, you need to do better.

Conclusion? Well, always remember that anecdotal evidence doesn’t prove anything (but can be helpful for some). Personally, if I had only one computer, lacked technical acumen, or had no tech support should things go south, I’d probably not throw caution to the wind just yet and wait for Sue’s guidance. Blue screens can definitely ruin your holiday plans.

3 users thanked author for this post.

CyberguyJ, JohnV, Deo

Reply | Quote

Carl wrote:

because the Access timestamp has been changed

I think the posts heretofore have been about what happens when duplicate hidparse.sys files are present on 22H2 systems when KB5021233 is installed. I have been wondering what happens in a similar situation (i.e., duplicate files when KB5021233 is installed) on a 21H2 system. So, thank you for that info.

About access date, though: I’ve found that my access date on those duplicate hidparse.sys files has changed, too, but not because I’ve installed KB5021233 (I haven’t done that yet.) The access date of the file in the \System32 folder\drivers folder is almost right now at the *time of this post: 12/25/2022 12:33 AM EST and that is precisely when I last powered on. The access date of the file in the \System32 folder is the day before on (12/24/2022) at 2:13 AM EST and I have only a little idea what I was doing at that time; it may have been when I last powered off.

Here the access date, in this case, does not coincide with the latest Windows CU. It is coinciding with a power-on date for one file and possibly with a power-off date for the other file. So, the access date of these two files is ever-changing.

*the time stamp on AskWoody posts is CST (an hour earlier than EST).

Reply | Quote

Ah … Good catch. That makes perfect sense. The access time probably changed during the reboot process of the update and is likely tied to Windows file integrity checks during the boot process rather than the update itself.

I’m curious to know if running DISM and SFC prior to applying the patch would fix problems that folks might have beforehand. Also, wasn’t it the purpose of cumulative updates to eliminate patch level, version discrepancies. How did this even happen?

Fortunately, the problem isn’t widespread. I personally have not fielded any calls so far from people experiencing the issue, but my sample size isn’t as large as it used to be either.

Reply | Quote

Another thing that would change the “access” time stamp is if you have an HID device connected to your PC that actually uses hidparse.sys.

If so, then every time you boot, the time stamp will get changed because Windows needs to “load” that file so the device will work properly.

Reply | Quote

Hello all here, is this issue fixed now? It’s a little hard to understand all the technical lingo. It just says “mitigated” for my version of W10 https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-21h2 and I would rather not have to do the recipe under there if I do not have to. Has there been a known issue rollback on this update or does the problem still persist?

Reply | Quote

To the best of my knowledge, MS saying issue has been mitigated means that you have to go into the recovery environment and manually copy the hidparse.sys file from the system32/drivers folder to the system32 folder using the xcopy command. MS has been pretty  limited in providing any useful info on what actions KB5021233 either does or does not do to trigger the bsod issue on reboot. Some added info might be helpful in gauging the individual system risk of installing the update. If you read the posts on this thread, everyone has been trying to sort through to antecedent conditions to gauge the risk.

Reply | Quote

Just another data point to add… I’m running a Dell XPS desktop with Win10 21H2.

I only had hidparse.sys in the system32\drivers folder, so only one copy with the 2251 Nov version.

The update ran without any issues. I checked and still only have one copy of hidparse.sys still in the \drivers folder and still version 2251.

To me, this backs up that if you have one copy of the file in drivers you, should be fine as there there’s no mismatch with only one file.

2 users thanked author for this post.

PDX5802, Deo

Reply | Quote

Ok, if you have duplicate hidparse.sys files, it “appears” installing the KB5021233 update is safe as long as both files are the newer 2251 version installed by the November update.

So I’ve updated my original hidparse check batch file (see attached zip) to not only check for duplicate hidparse.sys files but, if it finds them, to display the version info for each file as follows:

Since, as pointed out several times, Microsoft has failed to disclose any specifics of exactly what’s causing the BSOD; other that indicating if you “duplicate” the hidparse.sys in the System32\drivers folder over to the System32 folder it solves that problem; I hereby take no responsibility if you use my file and, because it shows your duplicates are the same version, then decide to install the update and it causes problems.

9 users thanked author for this post.

jburk07, TechTango, redMagna, Tregonsee, Berserker79, PDX5802, NaNoNyMouse, CyberguyJ, pbollens

Reply | Quote

Lots of discussion about IF you have duplicate hidparse.sys files.

Running 22H2 updated thru November, I have only one (1) hidparse.sys file in c:\windows\system32\drivers.

Have we safely ruled out any problem with this configuration?  Or does MS want me to have (matching) duplicate files in two (2) locations?

Windows 10 Pro x64 v22H2 and Windows 7 Pro SP1 x64 (RIP)

Reply | Quote

I’m a tad confused (not surprisingly)…

I have two hidparse.sys, both identical as to version, time, size and in system32 and system32\drivers as expected.

However, I have not been offered KB5021233 nor is it in my uninstall list or hidden with WUShowHide. What does that mean? Win 10 Pro 22H2 build 19045.

Reply | Quote

There are *seven* copies of hidparse.sys on my system running Windows 10 Pro 22H2 (see screenshot). I also attached the screenshot file since the image in this message seems a wee bit small.

None of them are in the /system32 folder at least.

Reply | Quote

All those others are either backup copies or older versions that get used by Windows if DISM or SFC detects a problem and needs to replace the ones currently “in use” or if the user selects the “Restore previous versions” option.

The only ones actually being used when Windows is running that can cause the BSOD problem are in ones in the “C:\Windows\System32” and “C:\Windows\System32\drivers” folders.

3 users thanked author for this post.

jburk07, Kobac, WCHS

Reply | Quote

We have 15 workstations. Some have the file in both locations and some only in c:\windows\system32\drivers. We have decided to skip both the November and December updates and wait until January.  There is currently no confirmed way to mitigate this bug BEFORE installing the quality update. Microsoft is incompetent. And there is also the issue with the taskbar and desktop freeze bug that’s still not fixed.

Reply | Quote

To complicate things, before installing KB5021233 today I did have two different versions of hidparse.sys. However, the update installed and restarted without throwing a BSOD.

Lenovo ThinkPad P1, Win 10 Pro 22H2, Windows version 19045.2251 prior to the update and 19045.2364 afterwards. In …/system32/drivers the hidparse.sys version was 10.0.19041.2251 dated 10 Nov 22. In the parent …/system32 it was 10.0.19041.1 (yep, .1) of 7 Dec 2019.

The update process chugged along nominally. Restarted when prompted and it went through updating, cleaning up, and then launching the desktop/login as per usual. No drama at all. Even did a shutdown, wait 30 sec, startup, and still no BSOD.

My only explanation is that I was too ready: full Acronis backup today, fresh recovery USB stick, and a page of notes on what to do in the Recovery Environment. (shakes head)

Oh, and both versions of hidparse.sys are intact post-update; .2251 in …/drivers and .1 in …/System32.

Computers are weird.

It’s possible that the errant version in …/system32 was installed by something two or three years or so ago which was then subsequently uninstalled. Perhaps the uninstall script cleaned up a registry entry pointing to the …/system32 file, so that the update installer “didn’t know” that the extra file existed?

1 user thanked author for this post.

Carl

Reply | Quote

Very interesting. Precisely one of the scenarios I wanted to test. Mismatch and 22H2. Apparently, the conditional triggering a BSOD is a wee bit more complex than anticipated based on what MS disclosed thus far. I now wonder if reversing file locations would change the outcome.

reboot
if (a and b) BSOD;
where “a” is the mismatch and “b” is unknown

Of course, the “b” could turn out to be something simple such as having a hid device connected during the patch reboot process.

In a couple of forums on different sites, there are people who experienced the BSOD and claimed to have put the OS back into a bootable state by:

1) Booting into safe mode, then
2) SFC /scannow as Admin

If credible, you probably would have experienced less nail biting while patching. (Regardless of the precautions you took, I still award you kudos for being a brave lad.)

Like you, I’d like to know how the mismatch happened on the ThinkPad in the 1st place and also why this wasn’t corrected by KB5019959. Weird? Yeah, I agree.

1 user thanked author for this post.

WCHS

Reply | Quote

Not so brave. I checked the ThinkPad’s manual to ensure that it would boot into the Recovery Environment after two consecutive failed boot attempts, and was ready to run through the xcopy routine as outlined ‘way upthread. Worse case, start a restore via Acronis then have lunch while it chugs away.

Of course, now I’m worried that since it *didn’t* BSOD as expected there must be something wrong. Never satisfied, I guess.

Reply | Quote

The Safe Mode Scannow method fixed the hidparse.sys mismatch on 21H2 for me!

Thanks to all posters on this thread.

Reply | Quote

unbob wrote:

The Safe Mode Scannow method fixed the hidparse.sys mismatch on 21H2 for me!

I am Win10/Pro 21H2.
Did you do the Safe Mode Scannow BEFORE you installed KB5021233 update?
Or did you do it AFTER you installed the update?

If you did it AFTER, you got the BSOD, right?
And then how did you get into Safe Mode after the BSOD? I’d like to know the steps that you took to get into Safe Mode and the steps afterwards to execute the sfc /scannow. And was the sfc a PowerShell command? or a Command Prompt?

Reply | Quote

I did the Safe Mode Scannow AFTER I installed KB5021233 update.

That did resolve the mismatch between the two copies of hidparse.sys but unfortunately is has not resolved the BSOD.

My BSOD troubles began on 12/15 – long before KB5021233 was installed on the 27th – so maybe my BSODs have nothing to do with KB5021233.

Three windows updates were installed on 12/14 (see below).

Also, My BSODs now occur daily since 12/15 – but they only occur in the wee hours of the morning while I’m sleeping. They never occur during the daytime when I’m using my laptop. Why? I don’t know!

So every morning when I open my laptop lid the Windows login screen is displayed due to the system re-booting (due to the “Bluescreen” event (code 133) during the night.

Just to be clear, the system re-boot during night is apparently normal (AFAIK) – the BSOD occurs many hours later.

I have no clue how to resolve this and just hoping it will resolve itself over time via future updates from either MS or Dell. Meantime, as long as the BSODs occur during the night when I’m not using my laptop, I suppose I can live with it indefinitely.

Reply | Quote

As expected, since I did not have hideparse.sys in the system32/ folder, I had no problems downloading and installing the December updates.

Before I did that, though, I created image backups of my Windows drive (SSD) and of my data drive (HDD) using Macrium Reflect, in case anything did go sideways.

Reply | Quote

Some interesting trivia…

Note the two different sizes and specifically that some of the folder names have \n at the end. …\n could just be an intentional subdirectory named n (for the N version of Windows?) or… It could be a mistake where a newline character has been interpreted into a folder name. Note that the files are two different sizes. It maybe nothing, just throwing this out there…

23:07:03.61 C:\TEMP>dir c:\Windows\hidparse.sys /s
Volume in drive C is C - NoelC6
Volume Serial Number is CC97-0CA7

Directory of c:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2311.1.11\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec\n

11/04/2022 11:01 PM 20,739 hidparse.sys
1 File(s) 20,739 bytes

Directory of c:\Windows\System32\drivers

11/09/2022 12:23 PM 46,080 hidparse.sys
1 File(s) 46,080 bytes

Directory of c:\Windows\System32\DriverStore\FileRepository\input.inf_amd64_292ece99a27cec96

11/09/2022 12:23 PM 46,080 hidparse.sys
1 File(s) 46,080 bytes

Directory of c:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec

11/09/2022 12:23 PM 46,080 hidparse.sys
1 File(s) 46,080 bytes

Directory of c:\Windows\WinSxS\amd64_dual_input.inf_31bf3856ad364e35_10.0.19041.2251_none_9d8e6d8b9f1f91ec\n

11/04/2022 11:01 PM 20,739 hidparse.sys
1 File(s) 20,739 bytes

Total Files Listed:
5 File(s) 179,718 bytes
0 Dir(s) 1,434,984,943,616 bytes free

-Noel

Reply | Quote

Please see my above post #2511970 for an explanation of why all those other copies of hidparse.sys exist!

Just FYI, The WinSxS (Windows Side by Side) folder is where Windows stores backup copies of the files it replaced during a Windows and/or Update installation and \n is an actual subdirectory in that location.

Reply | Quote

OK, as I mentioned, I have .2251 in BOTH locations. Today I was offered the 1233 update. Is this the safe configuration to run this? And maybe even more important, is there anything in 1233 that I need and compels me to run this?

Or, am I in the vulnerable spot having both and both identical hidparse files?

Thanks.

I’ll read the above a bit more, but am still not seeing the when to and when not to.

Reply | Quote

OK, just reread this entire topic again and it seems there is low probability of an issue for me with identical 2251’s in both directories.

So, do I want to do 1233? What is the benefit? What does it contain that’s worth the risk? Or just hide it until January?

What does Susan now recommend?

Reply | Quote

Read this post for clarification:
https://www.askwoody.com/forums/topic/confused-with-susan-bradleys-12-27-2022-update-re-hidparse-sys-file/#post-2512313

Carpe Diem {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1778 x64 i5-9400 RAM16GB HDD Firefox114.0b8 MicrosoftDefender

1 user thanked author for this post.

WCHS

Reply | Quote

rebop2020 wrote:

So, do I want to do 1233? What is the benefit? What does it contain that’s worth the risk? Or just hide it until January?

Here’s the link to beeping computer’s Dec 13 article listing all the fixes included in KB5021233.

• Microsoft December 2022 Patch Tuesday fixes 2 zero-days, 49 flaws

With the “growing number” of AskWoody users with duplicate 2251 hidparse.sys files that have successfully installed it with no BSOD, it’s pretty much up to you whether it’s worth the risk to get those fixes.

Reply | Quote

@alejr

Please see my post 2511977

Are we OK if we only have one (1) hidparse.sys file where it was originally intended in the  c:\windows\system32\drivers folder?

 

Windows 10 Pro x64 v22H2 and Windows 7 Pro SP1 x64 (RIP)

Reply | Quote

[Bob99]

Tex265 wrote:

Are we OK if we only have one (1) hidparse.sys file where it was originally intended in the c:\windows\system32\drivers folder?

I’m not @alejr, but I can answer your question. The answer is YES, you can feel free to install the December patch (KB5021233) if you have hidparse.sys in only the \Windows\system32\drivers folder.

I have two machines that meet the criteria in your question, and they both had no hiccups installing KB5021233 at all.

Also, if you read enough of other folks’ posts who’ve installed the December patch for Win 10, nobody who’s only had hidparse.sys in the \drivers folder has had a BSOD problem after installing the December update.

There is ONE person who claims to have had a BSOD after installing the December update, but that person also admits the BSOD existed before installing the December update, so the update didn’t fix their BSOD as they had hoped.

The only problem I experienced this month was self-inflicted… I tried installing KB5012170 on one of my machines, and that wound up causing some issues that I documented in another thread.

• This reply was modified 5 months ago by Bob99.

1 user thanked author for this post.

DrBonzo

Reply | Quote

At this point I’m very confused. On one PC we have the file in multiple directories. For the 2 directories at the heart of the discussion, the files have the same size and date. So my question – should that be safe?

Reply | Quote

WSpbug56 wrote:

At this point I’m very confused. On one PC we have the file in multiple directories. For the 2 directories at the heart of the discussion, the files have the same size and date. So my question – should that be safe?

Your answer is contained in the following post from @alejr here on AskWoody. Please read it carefully, keeping in mind the two directories at the core of the current discussion:

https://www.askwoody.com/forums/topic/confused-with-susan-bradleys-12-27-2022-update-re-hidparse-sys-file/#post-2512313

The copies of the hidparse.sys file that are in locations other than \Windows\System32\drivers and \Windows\System32 are older copies that have been stored in the event they’re needed for a system restore or OS version rollback operation.

1 user thanked author for this post.

DrBonzo

Reply | Quote

Thanks. So it really is pretty simple on the PC I’m checking – properties in WE show both to be 2251, both dated Dec 8, 2022 (when I ran November updates).  So I need to check these 2 on several other PC’s.

I get that if they are mismatched, then I have a serious risk and I’m trying to understand whether I can fix it before doing the December updates. I have 5 more PC’s to deal with and one is at another location I can’t get to, so I’ll have to deal with that. So, if they are a mismatch, what do I do pre updates?

1 user thanked author for this post.

DrBonzo

Reply | Quote

WSpbug56 wrote:

So if they are a mismatch, what do I do pre updates?

THAT is the $64,000 question. I haven’t seen any concrete solutions on if it’s possible to do anything about a version mismatch (i.e. a fix) before installing KB5021233.

For now, with a version mismatch before installing the update, I believe the consensus is split between waiting until January’s updates are released to see if they contain the fix and taking the plunge with a copy of MS’s instructions printed out and in hand which will render you ready to implement their fix, albeit in an unusual way.

1 user thanked author for this post.

DrBonzo

Reply | Quote

Thanks. Appreciate it. Will read.

Reply | Quote

Getting closer to when I have to update here, do you all here think MS will fix the update itself before Jan 10th or in the Jan update itself? I dont really know what to do here now…

Reply | Quote

If you only have one copy of the “file” go for it. Otherwise, it gets more complicated. I don’t think MS will “fix” this issue before the next update cycle.

Reply | Quote

Hi! I have one version of the file in System32/drivers  – 10.0.19041.2251

There is also one in System32/driverstore/filerepository/ – also – 10.0.19041.2251 so the details are identical – is this a copy made by windows perhaps?

I cannot find one in the System32 folder itself.

Reply | Quote

System32/driverstore/filerepository/ is some type of backup for windows so that’s not an issue. Not having one in system32, but only in drivers is good and, IMHO, you should be good to go. I just applied the update to 2 PCs, which have the file in the same folders, with no issues.

Reply | Quote

Understood, many thanks for you answer!

Reply | Quote

Have been updating a gang of machines (50 or so). Most don’t have 2 files, but out of the ones that do, if the file versions matched, even one with file version 10.0.19041.868 in both folders, all has gone well.

Never Say Never

2 users thanked author for this post.

redMagna, Bob99

Reply | Quote

Good to know, especially for those concerned that they may not have version .2251 anywhere on their drive!

Reply | Quote

Perhaps, as @cyberSAR ‘s experience above has shown, the only critical thing is to have BOTH versions MATCH in both file locations if you have it in both locations, and not worry about it being the latest version of .2251.

Just sayin’.

Reply | Quote

Just updated W10 Pro x64 system with hidparse.sys ver. .2251 in system32 and system32/drivers folders. KB5021233 completed install without issues and is another data point for those wondering whether they wany to install the update. Please note that I had a full system image and recovery drive available before I attempted the December update but I was pretty certain that I would not experience a problem.

1 user thanked author for this post.

geekdom

Reply | Quote

Ok, despite the fact all the circumstantial evidence currently “seems” to point to the fact that…

1- if you only have a copy of hidparse.sys in C:\Windows\System32\drivers, KB5021233 will work.

2- if you have copies of hidparse.sys in C:\Windows\System32\drivers and C:\Windows\System32 and they’re both the same version, KB5021233 will work.

…it’s actually pretty simply why everyone is still very confused about this issue.

Microsoft hasn’t revealed exactly why some systems are experiencing a BSOD after installing KB5021233 if, and only if, hidparse.sys is located in both the C:\Windows\System32 and C:\Windows\System32\drivers folders due to a version mismatch.

That means anything and everything you see posted, either here on AskWoody or elsewhere on the web about this issue, is pure speculation based on the experiences of those who’ve actually installed the update.

At this point, just like every other monthly update, it’s up to each individual to evaluate what they’ve read, what other’s have experienced, and decide for themselves whether they want to follow any guidance others, including myself, may provide!

BTW, just to be very clear and try to eliminate any extra confusion…

The only hidprase.sys located on you PC that matters are the ones located in the C:\Windows\System32\drivers and/or C:\Windows\System32 folders!

Any and all other copies of hidparse.sys that may be location elsewhere on your system DO NOT play a part in whether the update may or may not cause a BSOD problem so “please” stop asking questions asking about them

5 users thanked author for this post.

Tregonsee, NaNoNyMouse, Foothills Dave, Jaquin757, geekdom

Reply | Quote

Make a backup. Period.

Carpe Diem {with backup and coffee}
offline▸ Win10Pro 2004.19041.572 x64 i3-3220 RAM8GB HDD Firefox83.0b3 WindowsDefender
offline▸ Acer TravelMate P215-52 RAM8GB Win11Pro 22H2.22621.1265 x64 i5-10210U SSD Firefox106.0 MicrosoftDefender
online▸ Win11Pro 22H2.22621.1778 x64 i5-9400 RAM16GB HDD Firefox114.0b8 MicrosoftDefender

Reply | Quote

Hello again all, have there been any further developments on the bsod problem? I can only pause updates until the 16th. I have not seen anything new from MS.

Reply | Quote

You have identical copies of hidparse so all should be fine.

Make sure you have an image backup and then let ’em rip.

cheers, Paul

Reply | Quote

Hi, I only had the one in System32/drivers? The other one was some kind of Windows backup directory I think. (?)

Reply | Quote

If you don’t have the file in the C:\Windows\System32\ folder (the only one is in the C:\System32\drivers) or they are identical in both folders (same date/version), you are OK.

Reply | Quote

I really hope so, just wish Microsoft said something so that I could be 100% sure I would not end up in that mess.

Reply | Quote

Nothing in life is 100% guaranteed, except death and taxes.

cheers, Paul

Reply | Quote

Hi PK

I assume an update last night included KB5021233.
I had left the computer to return for an early hours webinar (8hr time diff) to find the computer seemed to have gone into reboot, so assume it had done an installation as 16 Jan was probably at the end of delay options..

This morning I cannot open the Start menu with neither mouse nor short key.

Is that part of this same update problem??
Don’t think I can run @alejr ‘s batch file even.

Thank you for any insight you can provide

UPDATE: It wasn’t  KB5021233 last night but KB5022282.

 Should I uninstall it to see if functionality is restored?

 

 

ASUS GL702VS 24GB RAM Intel Core i7 64 bit Win 10 Home 21H2 OS Build 19044.2486 Windows Feature Experience Pack 120.2212.4190.0. Not Win 11 eligible.

Reply | Quote

KB5022282 uninstalled resolved the issue. Don’t know whether an upgrade to 22H2 would make a difference.

Will add this to previous KB5022282 thread elsewhere

Noticed that Update History does not include uninstall history.

ASUS GL702VS 24GB RAM Intel Core i7 64 bit Win 10 Home 21H2 OS Build 19044.2486 Windows Feature Experience Pack 120.2212.4190.0. Not Win 11 eligible.

Reply | Quote

I just successfully installed KB5021233 on my Windows 10 Pro/21H22 system. I had the latest version of hisparse.sys (ver. 2251) in only C:\Windows\System32\drivers and not C:\Windows\System32. However, during installation, I saw something odd. Several items were installed before KB5021233 and this was the last item to be installed. However, during the installation of KB5021233, Windows Update showed “Restart required” and gave the “Restart now” button before the installation was complete (see attachment …A which is at 72%). Next, after this reached 100%, a second installation commenced still showing (I have another screenshot but the post won’t allow me to attach it) still showing “Restart required”. After this went to 100% did the “Pending restart” message show.

What would of happened if I clicked on the “Restart now” button before the installation was complete. With the risk of being wrong, could this have something to do with the issue around KB5021233?

1 user thanked author for this post.

NaNoNyMouse

Reply | Quote

To add to the data point…

I’ve just successfully installed KB5021233 on my Windows 10 Pro/22H2 system.

I had the latest version of hisparse.sys (ver. 2251) in only C:\Windows\System32\drivers and not C:\Windows\System32.

Reply | Quote

sahalen wrote:

What would of happened if I clicked on the “Restart now” button before the installation was complete. With the risk of being wrong, could this have something to do with the issue around KB5021233?

Probably doesn’t have anything to do with this specific issue, but it IS something I’ve occasionally seen happen in the past with updates to my own machines, and I’ve always wondered about it. Obviously the only way to find out what would happen would be to actually click “Restart now” before the installation was complete, but equally obviously most people would refrain from doing that, as long as they’d noticed what was going on. Perhaps the unfinished installation would just pick up where it left off on restarting, but I personally wouldn’t bank on it…

Reply | Quote

Personally, I prefer to wait till all show 100%, but I’ve hit RESTART (on screen, not the START menu) at times with no issue.

Reply | Quote

How is this strange?  Most times I do WU, it offers to have you reboot before the ‘installation’ hits 100%.  As I understand it, all it really does is shift some of the install work from being done with Windows up to Windows being down and running the remaining parts of the updates.

Now why does MS do this?  I can only guess is that it lets you walk away a bit sooner.

Now the real issue is all about that driver.  And you having a recent version and in only one place is good.  Some of us have it in both places and identical and recent, which seems fine as well.  So anyone, please feel free to correct me, but I’d say that for sahalen, no problem here.

Reply | Quote

sahalen wrote:

What would of happened if I clicked on the “Restart now” button before the installation was complete. With the risk of being wrong, could this have something to do with the issue around KB5021233?

No it does not.
CU has 2 components. The first to install is a Servicing Stack followed by the CU.
Microsoft sometime displays: restart now after the Servicing Stack update which you should ignore.

I use WUmgr and never receive ‘restart now’ untill all updates have finished installation.

Dump Windows Update and use WUmgr.

Reply | Quote

I have often seen this also, whenever the updates include a KB for .NET. The .NET update generates the Restart Now prompt upon its completion, independent of whatever else is going on.

Once, when being less vigilant than usual, I clicked on this and performed the Restart, which interrupted the Windows CU in progress. After the reboot, the Windows CU restarted from scratch (I may have interrupted the CU during download, I don’t remember as it was quite some time ago). The Windows CU eventually completed normally that time. So, if one is lucky, the only consequence of the early Restart is several minutes of wasted time and some anxiety, but I don’t recommend it.

I would recommend that if you stay with Windows Update to be sure all updates have installed before performing the requested Restart.

Regards, Phil

1 user thanked author for this post.

geekdom

Reply | Quote

After reading through all this, I’m still unclear (and not a technician). I’m running Windows 10 Pro 22H2 on an ASUS mini desktop. In my \System32 folder I have Hidparse.sys version 868 from May 4, 2021. 45.0 Kb. In my \System32\Drivers folder I have version 2251, from 12/7/22 (date I installed the November updates).

I have not yet installed the December updates. So, should I be preemptive before installing the December updates and go into Windows Recovery Environment and Xcopy Hidparse.sys from \System32\Drivers to the \System32 folder? Would it work? Is there a risk to doing the Xcopy thing? Any downsides?

Or would I be better off waiting until later in January and not install any updates until we get the all clear from Ask Woody? Thanks.

Reply | Quote

You only need the Recovery Environment if you already updated and got a Blue Screen Of Death. Otherwise, just Xcopy away.

Windows 11 Pro version 22H2 build 22621.1778 + Microsoft 365 + Edge

Reply | Quote

Thanks ma’am!

Reply | Quote

How come this topic now has a “resolved” tag on it? Issue still persists as far as I know?

Reply | Quote

Solution is known so it’s resolved.

cheers, Paul

Reply | Quote

Hi, so I may be facing this problem soon as well. Is the solution to copy the files before installing this update?

I have one in system32/drivers.

Reply | Quote

If you only have one, you won’t see the problem.

Windows 11 Pro version 22H2 build 22621.1778 + Microsoft 365 + Edge

Reply | Quote

So the solution should this happen is the xcopy in the recovery environment after the bsod happens? Will it be wise to copy the file beforehand using this method? Sorry for nagging, the solution is just not clear to me atm…

Reply | Quote

Susan Bradley wrote:

If hidparse.sys is not in both locations, or if it is in both locations with the same size (and perhaps date stamp), you won’t have issues with the December updates for Windows 10.

Windows 11 Pro version 22H2 build 22621.1778 + Microsoft 365 + Edge

Reply | Quote

Sam, see my question at https://www.askwoody.com/forums/topic/several-windows-10-versions-affected-by-blue-screen-issue/#post-2515048
and the reply at https://www.askwoody.com/forums/topic/several-windows-10-versions-affected-by-blue-screen-issue/#post-2515052 above. Looks like if you have only the one Hidparse.sys in folder C:\windows\system32\drivers then you are probably OK.

Reply | Quote

Thank you both!

Reply | Quote