-
(9) the failing PC has a newer motherboard BIOS, downloaded from HP’s website, and that newer BIOS is the latest version, successfully installed in the failing PC several months back
If I’m understanding your above statement correctly, the BIOS on the successfully updated PC is an older version than the failing PC?
That would mean the PC with the “older” BIOS doesn’t show an IDE controller while the PC with the “newer” BIOS does; even though there’s no IDE device installed in it that would require such a driver!
I know it’s not normal procedure to do this but, I’ve seen a lot of online posts over the years where an “updated” BIOS caused users various problems (including not being able to update their OS) and the fix was to download/install an older BIOS version for their motherboard (i.e. “downgrade” the BIOS.)
Since the older version worked just fine for upgrading the other PC, I’d suggest you download/install it on the failing PC and see if that lets you upgrade it… or at the very least gets rid of the phantom IDE device.
1 user thanked author for this post.
-
There is also a “Logicool HID-compliant Cordless Mouse” driver that is showing up in DriverEasy. I’ve searched everywhere in my home lab, but failed to find the matching USB “dongle” for that mouse. Logitech still sells that cordless mouse, so I can buy a new one for about $20.
The “current” driver version for the Logicool mouse is shown as 10.0.18362.1 which means it’s using the Windows provided driver and isn’t whatever driver is causing your problem!
1 user thanked author for this post.
-
Because I’ll never need that 1 x PCI expansion slot, I installed a slot exhaust fan in that expansion slot which helps to cool the 2727SGL.
Is the exhaust fan actually plugged into the PCI slot and getting powered via the PCI bus or is it simply mounted to the rear of the case using a “slot cover plate” and powered by a connector from the PSU?
If it’s using the PCI bus, that might be the source of your phantom IDE driver.
1 user thanked author for this post.
-
The issue may not be as simple as drivers being used on your 1909 PC that are not on the 22H2 PC but the actual versions of the drivers (even those that are “shared” between the 2 PC’s.)
BTW, you can discount any 10.0.#.# driver versions as those are all “Windows drivers” and would get successfully updated to 22H2 versions.
Also bear in mind, there are some significant OS “core” differences between 1903/1909 and 2004/22H2… which is why it’s not possible to upgrade 1903/1909 to 22H2 using a simple “enablement package” like the upgrades from 2004 > 20H2 > 21H1 > 21H2 > 22H2!)
So, just because a particular device using a 3rd party driver has been working fine on Win10 1909, does not mean it’ll also work on Win10 22H2 (i.e the Conexant audio driver that caused 1903/1909 to 2004 – 22H2 update failures for some users is a perfect example!)
I’d “suggest” you check each of the 3rd party drivers to see if a newer version is available and, if so, update them.
As for the IDE drivers, if you disable them, they “should” be ignored during the update process.
1 user thanked author for this post.
-
Did you “compare” the lists from both PC’s to see if there were any differences? Especially in the versions of the drivers.
The easiest way to do that is to “sort” the results from both PC’s and then open both text files side-by-side so any lines with different info will standout.
1 user thanked author for this post.
-
My bad, I didn’t include the Select part of the command!
It should’ve been:
Get-WmiObject Win32_PnPSignedDriver | Select DeviceName,DriverVersion
BTW, I didn’t include the “Description” option because, at least on my system, it’s exactly the same as DeviceName!
1 user thanked author for this post.
-
Since you have two “basically identical” PC’s, finding the problem driver(s) just became a lot easier.
Use the following powershell command to generate a list of the drivers/versions on each PC.
Get-WmiObject Win32_PnPSignedDriver | DeviceName,DriverVersion
Note: the powershell window must be wide enough or it won’t display the whole version# (I’d suggest at least 136 characters.)
Then simply compare the drivers/versions between the two PC’s to determine which one’s are “different” on the 1909 PC you can’t update and then update them to the same version as the 22H2 PC and try to update 1909 to 22H2 again.
FYI, if the 1909 PC is using a driver the 22H2 PC isn’t using, and it’s not required for some particular function on the 1909 PC, delete it!
One gottcha with this powershell command… it only displays “signed” drivers so, if your system is using any “unsigned” drivers, they won’t be shown!
1 user thanked author for this post.
-
Hadn’t remembered this one since it’s been so long ago when I updated from 1909 to 21H1 but…
If you system is using a Conexant audio driver (version 7.231.3.0 or older), it won’t update beyond 1909 unless you either update the driver to a newer version or uninstall it using device manager (choosing the option to “remove drivers“) and then immediately run the update without rebooting first.
If you system isn’t using a Conexant driver, you could try running Microsoft’s SetupDiag program to see if it “might” provide more info about exactly which driver is causing your problem.
Some online users have indicated they weren’t able to jump “directly” from 1909 to 22H2 but were able to go from 1909 to 2004 to 22H2 so another option would be to go to the UUPdump site and download the aria2 script files to create an ISO of the Feature update to Windows 10, version 2004 (19041.1415) and see if that’ll upgrade your 1909 to 2004?
If that works, then try to update to 22H2 again.
BTW, Microsoft force updated existing Win10 1903/1909 users to Win10 2004 way back in Jun – Nov 2020! Since that hasn’t happened to your Win10 1909 system, it’s unlikely their new forced updated to 22H2 starting in Jun 2023 will affect it.
Of course we are talking about Microsoft so, anything’s possible (although if you can’t get it to update because of an “incompatible” driver, they won’t be able to either… unless they uninstall, disable or update the problem driver.)
1 user thanked author for this post.
-
Based on some Googling of your driver error code I discovered that Virtualization Technology (VTx) can sometimes cause this problem because, if it’s enabled in the BIOS, it forces Windows to install a driver that “may” be incompatible with the new update. And because the VTx driver isn’t for an external device, disconnecting all your peripherals doesn’t get rid of the error!
The setting “should” be in your 6300 MT BIOS under Security > System Security > Virtualization Technology (VTx)
1 user thanked author for this post.
-
IMHO, your topic title is extremely misleading!
There’s absolutely nothing in the article you link to that indicates Win11 users won’t be able to still download, install and use WinRAR, 7-zip or other 3rd party archive extractors if they choose to. So exactly “how” does Microsoft’s adding native support for more archive formats justify a claim they’ve killed WinRAR and 7-zip.
In fact, if their “native support” for extracting .7z, .gz, .rar, etc. archives is like what they use for .zip archives (which it most likely will be), I’d be willing to bet a lot of users will still want to use WinRAR or 7-zip because those programs offer way more options than simply “extracting” the contents of the archive.
Personally, I’ve been using 7-zip instead of Windows “native support” for dealing with compressed files for a very long time because I wanted more control than Windows “native support” provided.
-
-
According to Microsoft’s Windows 10 upgrade resolution procedures page, 0xC1900101 – 0x20017 is a SafeOS boot failure typically caused by drivers, non-Microsoft disk encryption software or hardware failure.
Recommendations:
• Disconnect all peripheral devices connected to the system, except for the mouse, keyboard and display, and try the update again.
• Update or uninstall the problem driver(s).
It also includes a link for Windows Vista, Windows 7, Windows Server 2008 R2, Windows 8.1, and Windows 10 setup log file locations that contains a long list of various log file locations you can check that “might” help isolate the specific driver causing the problem.
You could also visit the HP Customer Support – Software and Driver Downloads site and click the “Let HP detect your product” option to see if it finds any newer drivers for that system.
1 user thanked author for this post.
-
I rarely agree with Windows on such things and hide all offered driver updates. Then I use the computer manufacturer’s update utility to check for drivers.
Same here with my old Asus Maximus VIII Gene with the Z170 chipset and my current Asus Maximus XI Gene motherboard with the Z390 chipset.
Like you, I downloaded/installed all the newest drivers from Asus when I first installed the motherboard but, after a Windows update of the “audio driver” killed my audio (I had to download/install the “older” version from Asus to get it working again), I disabled driver updates in Group Policy and use WUmgr to hide any driver updates being offered by Windows.
I haven’t had any “driver problems” since I did that and occasionally, about once a year, I’ll check the Asus and actual device manufacturer’s sites to see if any newer drivers might be available; which I then download/install.
I also keep copies of the installers for the “currently working” drivers in case a new one doesn’t work and I have to revert back to the old one!
-
Yeah, that’s what I figure.
Strange thing is, I compared the computer section of the “current” CNN supported devices page with the Wayback Archives snapshot from Jan 01 2023 at 03:27:38 and they’re both exactly the same!
And while it doesn’t specifically mention Firefox ESR, Seamonkey did always give me the desktop version until their April 19th “site refresh“.
I’m guessing whoever programed the code for the refresh started using commands from some module that’s not part of the older ESR browser.
-
I once had a motherboard that allowed this to be disabled in the BIOS.
Both my old Asus Maximus VIII Gene and current Maximus XI Gene motherboards have a BIOS settings that allows you to “individually” enable/disable hot swap for the SATA ports.
If hot swap is disabled, Windows reports that particular drive as fixed.
If hot swap is enabled, Windows reports that particular drive as removable.
So, as @steeviebops said, calling this a “Windows bug‘ is complete rubbish; Windows reports exactly what the BIOS tells it to report!
BTW, the reason my Drive F is reported as removable is because I’m using this $80 ICY DOCK ExpressCage MB324SP-B to house the SATA drives that “use” to be internal on my PC.
Two reasons:
1. I can “hot swap” in my backup drive and get full internal SATA speeds during my weekly backups (~5 mins for 60GB vs 30+ mins using an external drive + USB port.)
2. If/when a drive fails, I can easily swap it out without having to take my PC apart to get to it!
2 users thanked author for this post.
Author
