Category Archives: Device drivers

Still Behind USB4 Curve

Drat! I’ve just upgraded my two Canary test PCs to build 25324. The announcement says “We are adding a USB4 hubs and devices Settings page…” But it had been on a gradual rollout, and I think that is still happening. Why do I say that? Because one of my test machines shows TB4 and USB4 in the Thunderbolt Control Center, but there’s no USB4 page in Settings on that machine. Sigh. Alas I think that means I’m still behind USB4 curve.

That’s what you see in the lead-in graphic above. It shows no USB4 hubs in DevMgr (left), the 25324 build (middle) and the TB4/USB4 items in the Thunderbolt Control Center (right).

If I’m Still Still Behind USB4 Curve, What Now?

It could be one of two things. I don’t have the right drivers loaded (I don’t think that’s the case, but it’s possible) or I don’t have any native USB4-equipped devices. Perhaps MS hasn’t rolled this update all the way out just yet, and my PCs are still on the trailing edge. Given my history with glomming onto new features, it’s darned likely to be the latter.

In the meantime, all I can do is wait for it to show up. I’m also going to reach out to my Lenovo contacts and see if they have any history with this capability on their end. I’ve got two pretty new machines (the P16 Mobile Workstation and the U360 Ultra SFF PC) that have leading-edge TB4/USB4 capabilities. Maybe I’ll have to load the 25324 image on one or both of them and see what comes up.

In the meantime, I’m just sitting on the dock of the bay, watching the tide roll away… Wish me luck!

Concluding Note: If It’s Not There, It’s Not There…

OK, so I’m learning that USB4 support will show up inside Device Manager using the “Devices by connection” view. (See this informative MS Learn article for more info Introduction to the USB4 connection manager in Windows.) If your PC is properly outfitted you’ll see a series of entries that look like this:

⌄ USB4(TM) Host Router (Microsoft)
    › USB(TM) Root Device Router (Microsoft)
          USB4(TM) Device Router (Microsoft)

Alas, none of my PCs apparently have the right kinds of USB-C (or Type A) ports, because I can’t see this on any of them. Gives me a good excuse to ask for another Lenovo eval, I guess!

Facebooklinkedin
Facebooklinkedin

Intel ARC Drivers Arrive Via WU

There’s a new set of Intel ARC drivers for built-in GPUs (and of course, discrete ARC devices as well). How do I know this? I just updated one of my Canary Channel test machines. During that process, I saw the Intel ARC drivers arrive via WU (Windows Update). Until this morning, I had been obtaining them exclusively from the Intel Driver & Support Assistant.

You can see the information about this latest driver from its Intel download page above. Notice the version number: 31.0.101.4146.

How Do I Know Intel ARC Drivers Arrive Via WU?

Check out the driver version in my Update History from the X12 Hybrid Tablet, captured minutes ago. Compare the version number for the “Intel Corporation – Extension” item and you’ll see it’s identical to the version number from the Intel download page.

ARC Drivers Arrive Via WU.history

The name isn’t terribly helpful, but the version number tells me what I need to know.<\p>

What else I can tell you about this alternate method is that it’s MUCH faster than installing the driver (plus supporting software) from the Intel download page. It took only 20-30 seconds to complete. The full-blown Intel package takes minutes.

Does this mean I will occasionally need to visit the Intel page to update the Intel Graphics Command Center software? Nope. The IGCC that works with Intel GPUs is a Windows Store app. And it updates itself, either through routine checks, or when you try to run that app the next time after installing a new driver.

Hey!  I might actually like this. It’s faster and less work that using the Intel Driver & Support Assistant. Good stuff, and good job: MS & Intel!

Facebooklinkedin
Facebooklinkedin

RAPR V0.11.92 Remains a Real Gem

I’m working on revisions to older stories I’ve written for ComputerWorld. Just yesterday, I revised my CIO story for them about purging duplicate and obsolete drivers from the Windows driver store. For that purpose, there simply is no better tool, nor one easier to use than Driver Store Explorer (aka RAPR or RAPR.exe). Indeed among my many Windows cleanup tools, RAPR v0.11.92 remains a real gem.

Why RAPR V0.11.92 Remains a Real Gem

Here’s the deal: when you update a Windows driver, it gets stashed in a special storage area with all the other drivers. What most people don’t know — including admins — is that when you update a driver, its predecessor remains present. And in fact, it never leaves unless you remove it yourself. In a nutshell: that’s one of the things that RAPR does with ease and grace.

When I wrote the afore-linked CIO story back in 2015, RAPR could help you find and remove duplicate and obsolete drivers. (Note: that item is now carried under the ComputerWorld masthead for IDG’s ineffable reasons.) But you had to do it more or less “by hand.” This took some time and effort to accomplish. No more: now RAPR includes a “Select Old Driver(s)” button. It automatically flags items that might potentially be removed from a target PC’s driver store. Click the Delete Driver(s) button next (see lead-in graphic) and RAPR will remove any selected driver that’s not in actual use.

Why (and When) to Use RAPR

The why comes from reducing the size of the driver store. This applies to any and all windows images for which driver updates get applied. If you put a new one in, RAPR lets you take the old one out. For deployment images — which may run on hundreds to thousands of PCs (or more) — this is especially important.

I’ve gotten in the habit of using this tool monthly. I seldom recover less than 100-200 MB of space. And when GPU drivers come into play (most of them occupy 1.0 -1.2 GB of disk space) those numbers really jump. My biggest-ever savings on an older PC that hadn’t been touched for a couple of years was on the order of 4-5 GB. That’s something fairly substantial.

You owe it to yourself to visit Github and download the latest version of RAPR. Use it to look at your standalone PCs, and the Windows images in your deployment library. I predict space savings all the way around.

Facebooklinkedin
Facebooklinkedin

Port Selection Determines Konyead NVMe Workability

OK, then. I think I’ve figured out what’s going on with my previously reported Konyead mystery. The error reported in that recitation is “The request failed due to a fatal device hardware error.” This happens if I plug into a USB-C port that supports neither USB4 nor Thunderbolt 3 or higher. Thus, it looks like port selection determines Konyead NVMe workability. Interesting!

If Port Selection Determines Konyead NVMe Workability…

I can work around my seeming inability to move the Konyead device from one PC to another by carefully choosing which USB-C port I plug into. I’ve also got an Acasis USB4 NVMe enclosure. It switches back and forth between USB4 and USB3.1 mode without difficulty. The Konyead unit cannot do this, apparently. If it’s presented with a lower-level USB port, it simply refuses to work.

What does this tell me? I think I see the evidence in Device Manager. If you look at the composed screencap at the head of this story, it shows two vital bits of data:
1. It shows that the Thunderbolt Control Center sees the device as Intel USB4.0 (rear layer, top left)
2. It also shows the names of the drivers this connection is using (e.g. WpdFs.dll, WpdUpFltr.sys, and WUDFRd.sys).

When I connect to a down-level USB-C port with the Konyead device, it won’t initialize in Disk Management. It also shows a different set of drivers in Device Manager (Disk.sys, EhStorClass.sys, and partmgr.sys). Those are the same drivers that show up when the Acasis is plugged into the same down-level port. The only difference is, the Acasis device also works with those drivers, too. The Konyead device, however, does not.

The mystery is now somewhat illuminated. I think I’m dealing with the consequences of my experimental idea to “buy the cheapest USB4/TB4 NVMe enclosure” to see what happens. Now I know: it works on the higher-end USB-C ports, but not the lower-end ones. An unforeseen, but at least now visible and understandable, consequence of that perhaps rash approach.

I have to laugh. But indeed, that’s the way things sometimes go, here in Windows-World.

Facebooklinkedin
Facebooklinkedin

Enduring Konyead NVMe USB4 Drive Mystery

Wow! I’m really stumped. I’ve got a Konyead M.2 NVMe drive enclosure that works on only one computer right now. For a long time, I was unable to eject the drive safely. But after backing off the write caching setting for quick removal, and resetting the drive letter from F: to X:, I can now do that. But even so, if I then unplug the drive and plug it into another PC it’s unrecognizable. This enduring Konyead NVMe USB4 drive mystery is driving me nuts!

Showing Enduring Konyead NVMe USB4 Drive Mystery…

When I plug the Konyead into any compatible USB port on another PC (USB3.1 via Type A connector, or USB4 via USB-C connector) it won’t come up. If I go into Disk Management, it immediately throws an error message that says the drive must be initialized. Options offered are MBR and GPT. Choose either one, and the right-hand error box pops up citing a “fatal device hardware error.” Yet, the drive works fine on my Lenovo X1 Extreme (8th gen Intel CPU). What gives?

I’ve tried fixing it with MiniTool Partition Wizard, too. It shows me the device, but also shows it at zero length. Thus, it’s unable to access the raw disk data to find the partitions (and related tables ) that I know are on the drive.

I’ve checked the Crucial SSD’s firmware and driver: both pass the tests from Crucial Storage Executive (the maker’s diagnostic/mgmt tool for this drive). This mystery remains opaque to me. I’m galled that the device works in one PC, but not in others: what’s the point of a removable drive in those circumstances?

Next Steps…

I’ve not been able to find anything about this kind of problem via online searching. I’ll reach out to Crucial’s tech support operation and see if they’ve ever heard of anything like this before. Konyead is impenetrable: konyead.net shows the NVMe enclosure, but all text is in Chinese, and the page for my device won’t come up. They do have a contact page, though, so I suppose I should give it a whirl.

Stay tuned. I won’t quit bulldogging this, but I’m afraid I’m up against what might be an intractable language and culture barrier. We’ll see.

Facebooklinkedin
Facebooklinkedin

Newer USB Justifies Added Costs

I had a revelation via contrasting benchmarks yesterday. A friend returned a mid-range USB 3.1 NVMe drive enclosure after an extended loan. Thus, I popped it into my production desktop (an i7 Skylake Gen 4 PC) to see how fast it ran. Good enough. Then, just for grins I popped it into the 2021 vintage Lenovo P16 Gen 1 Mobile Workstation (an i9 Gen 12 PC). Much faster! Enough so, in fact, that it’s clear that newer USB justifies added costs of acquisition. Let me explain…

Why Say: Newer USB Justifies Added Costs?

Take a look at the lead-in graphic. It shows the difference between older USB technology in the Skylake desktop vs. newer USB technology in the Gen 12 mobile workstation. Both are using USB 3.1 ports (though the older PC goes via USB-A, the newer goes thru USB-C) to the same hardware running the same benchmark. Why is the new so much faster than the old?

Short answer: UASP, aka the USB Attached SCSI Protocol. The newer PC supports it, while the older one does not. You can see there’s a driver difference in Device Manager when it comes to accessing the NVMe drive enclosure and its installed SSD: the older machine runs a driver named USBSTOR.sys, while the newer one runs UASPStor.sys. Plain as day.

The Deal With UASP

The Wikipedia article on UASP is a good place to find some explanation. To wit: “UAS [USB Attached SCSI] generally provide faster transfers when compared to the older USB Mass Storage Bulk-only (BOT) protocol drivers.” In a nutshell, that’s UASPStor.sys versus USBSTOR.sys.

As I learned about this technology in the period from 2016 to 2019, the word at TenForums.com ran something like “Speeds of 500 MBps mean USB bulk transfer; 1 Gbps or better means UAS transfer.” And that, dear readers, is the difference you see between the right-hand side in the lead-in graphic (USBSTOR.sys on the Skylake) and the left-hand side (UASPStor.sys on the Gen 12).

In practical terms, this translates into much, much faster IO on the newer PC vis-a-vis the older one. I think it’s incredibly worthwhile, given that backups complete 2-3 times faster on the P16 than the Skylake. Likewise for big, bulk file transfers (such as Windows ISOs, which I mess with frequently).

Retrofit and Replacement

Does this mean one has to toss older PCs and replace them with newer models? Maybe, but not necessarily. For between US$50 and 100, you can purchase UASP capable PCIe adapter USB cards. As long as you’ve got an open PCIe x4 port available on your motherboard (desktops only, so sorry) this could be a good solution. I’m a fan of this US$95 StarTech unit for that purpose.

Older laptops can be dicey and depend on support for USB ExpressCards. I mucked around with these on some 2012-vintage Lenovo ThinkPads in the 2014-2016 timeframe (an X1 and a T420). They work, but they’re cumbersome and expensive (see this Amazon Review for a great discussion).

For best results, it may be time to shell out for a new desktop or laptop PC. That way, the fastest USB (and even Thunderbolt) technologies are likely to come built-in and ready to go. Could be worthwhile!

 

 

Facebooklinkedin
Facebooklinkedin

Figuring Out Intel Arc Iris Xe Drivers

For a long, long time Intel has made newer drivers available for its various integrated graphics circuitry. I’m talking older stuff like its UHD graphics, as well as newer Arc and Iris Xe graphics. Until last year, laptop operators were warned off these drivers because they could overwrite OEM extensions and customizations. I’ve been installing and figuring out Intel Arc Iris Xe drivers lately because that warn-off has been modified.

Here’s an “exception” of sorts that now appears in the Intel Driver & Support Assistant‘s cover language for the Intel Arc & Iris Xe Windows Drivers:

If you have a 6th Generation Intel® processor or higher, your computer manufacturer’s customizations will remain intact after upgrading to this graphics driver. To identify your Intel® Processor generation, see How to Find the Generation of Intel® Core™ Processors.

For the record, my test PC is a Lenovo ThinkPad X12 Hybrid Tablet. It runs an 11th Gen Intel CPU (i7-1180G7), with onboard Irix Xe graphics.

What Figuring Out Intel Arc Iris Xe Drivers Buys

Much of the Arc and Iris capability in the Intel ARC Control app is oriented to games, especially its “Studio” functions, designed to let an ARC device broadcast, capture, share highlights, or set up and use a virtual camera, all within the game-play context. Because I’m not a gamer (and have no actual ARC GPUs only on-CPU graphics subsystems) this doesn’t really signify much for me. I did, however, learn that ARC was looking out of the camera on the back of my X12 Hybrid at my desktop cubbyholes. I promptly turned that off.

What I’m concerned about is usability, stability, and everyday performance. By this I mean that the new driver doesn’t impact usability or stability. I also mean that it has no negative impact on performance, either.

The Verdict So Far

In working with my test system locally and remotely, I’ve noticed nothing different or unusual about the graphics driver. Usability, stability and performance all seem the same.

Reliability Monitor tells a different story, though. Over the past 6 days, it shows 3 APPCRASH events all aimed at “ArcControlAssist.exe.” Each seems to fall around when I open or update the ARC Control Assist app.

Thankfully, the everyday behavior of the system remains rock solid. I’m guessing there may be some teething pains involved here. I’ll say that the new drivers are worth testing, but don’t seem entirely ready for production at this time. At this point, I’m more inclined to blame flaky software (the Intel ARC Control Center app itself) rather than a flaky driver (no other behavior to indicate problems). I’ll keep an eye on this stuff, and let you know how it plays out. Stay tuned!

 

Facebooklinkedin
Facebooklinkedin

16 Month Pause Between Audio Updates

Whoa! I finally hit paydirt yesterday. I’ve been checking for updated drivers for my Realtek® Audio (UAD) device for some time now. As I’ve just calculated, there’s been a 16 month pause between audio updates on my production PC. Undoubtedly that’s because it’s an i7 Skylake (Intel Gen 6) CPU that made its debut in 2016. Could this be another sign that it’s time to retire this PC? Probably!

Why a 16 Month Pause Between Audio Updates?

Please look at the intro graphic. Because I just updated the ASRock Realktek audio driver yesterday, you can see two versions of the corresponding setup information (INF) file, hdxasrok.inf. Note the dates: the newer one reads 12/27/2022 while the older reads 8/3/2021. Do the math, and that’s 16 months plus over 3 weeks. Wow!

I’d been visiting the ASRock Support website and my favorite alternate driver source — namely station-drivers.com— for a long, long time before I finally struck gold. Before I dug into this ZIP file and realized it covered my audio chipset, the vast majority of recent updates were for Nahimic audio chips, not the plain-vanilla Realtek chips in my now-aging motherboard.

Frankly, I don’t know why it took so long to find a newer version. My best guess is that older motherboards (and chipsets) don’t get the same love and attention that newer ones do. I have to guess that’s because driver updates require time and effort to create, and older stuff is less likely to be in demand than newer stuff. The just the way of Windows-World: older hardware eventually gets no love at all. Mine is pushing that envelope, clearly.

Thanks Again, RAPR!

The Driver Store Explorer (aka RAPR.exe) once again comes in handy for inspecting driver status on my Windows 10 production PC. It’s the source of the screencap at the head of this story. It does a stellar job of showing Windows drivers, including their number and status on targeted PCs. This search proved an excellent stimulus for me to update RAPR itself, too. Thus, I’m now running v0.11.92 (uploaded to GitHub on 1/6/2023). Previously, I’d been running v0.10.58 (internal file date: 4/10/2020).

Thus, the need to upgrade one thing (the Realtek driver) also reminded me to upgrade another (RAPR). Now, I’ll need to distribute this around my entire PC fleet. Good stuff!

 

Facebooklinkedin
Facebooklinkedin

Obvious Fix Addresses 0xC1900101 Install Error

I run two Dev Channel test PCs. Yesterday, the Lenovo ThinkPad X12 Hybrid failed to upgrade to Build 25284. And it threw a familiar error code — one I’d just written about on ElevenForum just two days ago. Fortunately, the obvious fix addresses 0xC1900101 install error, as I will explain. But gosh! What a coincidence to have dispensed advice about this error only to experience it myself shortly afterward.

What Obvious Fix Addresses 0xC1900101 Install Error?

First let me share the text from my ElevenForum post (from which a screencap appears above):

Check out this MS Learn article: it asserts that an incompatible driver is present when this error code presents: https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/windows-10-upgrade-resolution-procedures

So what I did next was to review all of the device drivers on the problem PC, and to upgrade those that weren’t current. To that end, I used a 3rd-party tool from IObit called Driver Booster (available in both free and for-a-fee versions). It found over 20 drivers in need of updating, and I updated all of them.

Long story short: two reboots later (one from the drivers the program found, another from a Lenovo Vantage update) I retried the 25254 install. And this time it completed successfully, sans the driver-related error. As I poke around online, I also see this is a fairly common install error where the obvious repair strategy is most often effective.

Shoot! It’s nice when things work the way they’re supposed to. Luckily, that does happen here in Windows-World from time to time.

Facebooklinkedin
Facebooklinkedin

Intel Drops iGPU OEM Warning

Once upon a time, the Intel Driver & Support Assistant (IDSA) used to warn laptop owners about its built-in GPU driver updates. There’s even an Intel Support Note on this topic. It reads in part “Installing this graphics driver from Intel may overwrite customizations from your … OEM.” Recently, Intel drops iGPU OEM warning. Why? Because it’s been reworked NOT to overwrite customizations. No more need, no more warning, I guess.

When Intel Drops iGPU OEM Warning, Then What?

If you look at the latest finding inside the IDSA in the graphic up top, you’ll see the warnings are gone. Nothing loath, I tried it out on my Lenovo ThinkPad X380 Yoga Dev Channel test laptop. It spun away for a bit before throwing up a “Begin installation” pane from the installer.

Intel Drops iGPU OEM Warning.begin

Next, it displayed the phases it would walk through, starting with a huge honkin license agreement to which installers must accede before the process gets underway. Click “I agree” to continue, as I just did.

Intel Drops iGPU OEM Warning.agree

Setup says it will install a driver and a graphics command center, after which one clicks start. Install shows progress bars for said driver and command center, with an option to “Show details” (lists changes as they’re made including registry entries, installing files, and so forth). Driver install takes several minutes to complete.

A reboot is required for changes to take effect. Once I had done so, I didn’t find the Intel Graphics Command Center (IGCC) installed. Thus, I visited the Microsoft Store to download and install same. It had me uninstall the apparently now-unnecessary Intel Graphics Control Panel.

Post Reboot, Things Get Interesting…

Once the PC restarted, the unit booted normally (the shut-down phase, when it was presumably writing new driver stuff did take a bit longer than usual). After the reboot the graphics look and work enough like the preceding iteration that I can’t see or tell anything different.

But when I tried to open the IGCC, it hung in “loading mode” (a line of balls moving from left to right at the bottom of the window). It never went anywhere. Turns out running two user sessions, each trying to start up IGCC isn’t a good idea. As soon as I killed one, the other started working. From there I was able to explore and play with the IGCC without further difficulty. Looks like I’ll have fun digging in and learning more. Stay tuned: I’ll report back.

Facebooklinkedin
Facebooklinkedin