Category Archives: Device drivers

Windows 11 Disks & Volumes Info

Here’s something I didn’t know. Through System → Storage → Disks & volumes, Windows 11 makes all kinds of storage device info available. Indeed, such Windows 11 Disks & Volumes info (see lead-in graphic) even includes “Drive Health” for suitably-equipped devices. Let’s explore a little bit more about what that means. But first, take another look at the graphic above.

Digging Into Windows 11 Disks & Volumes Info

What can you see in this graphic? The first section shows disk info for the internal SSD, a 1 TB Kioxia NVMe. It also shows bus, target and logical unit number (LUN 0) data. There’s a Status field that shows the drive is online. Next, a Health section shows remaining life, available spare, and temperature. Finally, Partition Style shows up as GUID Partition Table (GPT). Previously, garnering this info required accessing Disk Management and Device Properties. Fabu!

In fact, if you click on Advanced Disk Properties, the same Properties page you can access through those other utilities comes up. But to me, that’s not what’s most interesting. Turns out, older USB attached devices (USB 3.x, in my local case) do not show the Drive Health section. That only works for USB4 devices (including Thunderbolt 4 items, as USB4 is a strict subset of TB4).

Now I Get It, Yet Again

Once again, I’m seeing a tangible improvement in transparency and usability when plugging in newer and more capable (but also more costly) USB4 peripherals. Even on laptops like the 2022 vintage Lenovo ThinkPad P1Gen6 Mobile Workstation (which still relies on the Thunderbolt Controller not a USB4 Host Router) these benefits convey.

As I said before in an earlier blog post “NOW I get it.” The value of the new interface is starting to come ever clearer. When I talk to the Panasonic engineers in a few minutes, I hope I will learn more. Stay tuned!

{Note Added 4 Hours Later] None of the engineers or developers I talked to was conversant with the switchover from Thunderbolt to USB4 Host Router at the hardware level. They’re floating a discreet inquiry to the Japanese engineering team to find out more. When I get more info, I’ll share it here (or in a new post, as things unfurl). Again: stay tuned!



HWiNFO Bestows USB4 Insight

I just learned something very interesting. Most of it comes courtesy of the GitHub HWiNFO project.  Use it to garner system information and diagnostics in Windows. The lead-in graphic  shows a  Thunder-bolt 4 NVMe enclosure plugged into a Panasonic Toughbook FZ-55. There (upper right) it appears as a Crucial NVMe SSD with PCIe x4 controller. For reasons I am about to reveal, I believe HWiNFO bestows USB4 insight into the USB-C connection in use.

What HWiNFO Bestows USB4 Insight Means

That insight comes from the full text of the Drive Controller info. It reads “NVMe (PCIe x4 8.0 GT/s @x4 8.0 GT/s). That means the PC sees the external drive, plugged in through a USB-C port on the FZ-55 as a PCIe x4 device capable of up to 8 giga-transfers per second (that latter part is what 8.0 GT/s means).

Basically, rating throughput in GT/s gives drive makers a way to account for encoding overhead in the PCIe protocol. Note: 8 GT/s translates into 7.877 Gbps with overhead backed out. Indeed, what this really means is the connection clocks half the maximum speed per PCIe x4 lane (16 GT/s). To me that indicates this connection tops out at a nominal 10 Gbps ( aka USB 3.2 Gen 2×1).

Where USB4 Comes Into Play

This is where I finally get to see a feature in Windows 11 I’ve read about but hasn’t manifested on PCs in my possession. The Toughbook FZ-553 delivered just before Christmas displays a USB option labeled “USB4 Hubs and Devices” (see below).

HWiNFO Bestows USB4 Insight.settings.sys.usb

If I hadn’t seen the PCIe x4 stuff in HWiNFO, I’d never have looked for this!

Indeed, it was seeing the mention of a visible NVMe controller and its PCIe x4 details in HWiNFO that led me to start wondering about USB4 and related Thunderbolt support. On other (older) PCs, I’ve only been able to access info about USB4 and Thunderbolt devices through the Intel Thunderbolt Control Center app. That’s been present by default on those other PCs with high-speed USB-C ports. On the FZ-55, Thunderbolt Control Center is absent. It doesn’t even come up in the Store (though it shows up clearly as a search string).

OK, NOW I get it: the Intel USB4 Host Router does on newer PCs what the Intel Thunderbolt Control Center does on older ones. It makes USB4 storage devices visible and accessible. Good to know!

Thankfully, HWiNFO shows more about the device, including the NVMe maker, controller, and drive model (a 1TB PCIe x4 Crucial NVMe drive). Likewise good to know; more insight, too!


Speccy ToughBook BSOD Analysis

Here’s an interesting situation: after installing Piriform’s Speccy hardware inspection tool on the new loaner Panasonic Toughbook FZ55-3, it crashes every time I run the program. Indeed, you can see the corresponding BSOD screen in the lead-in graphic. The stop code is SECURE_PCI_CONFIG_SPACE_ACCESS_VIOLATION. The culprit: the cpuz149_x64.sys driver. After some online research, my Speccy ToughBook BSOD analysis tells me that this driver is attempting PCI data access that Windows 11 disallows.

To be more specific I found an Open Systems Resources (OSR) community discussion that lays out exactly what’s going on. The datails are nicely covered in an MS Learn item. It’s named Accessing PCI Device Configuration Space, dated 3/13/2023. Essentially it  constrains developers to use the BUS_INTERFACE_STANDARD bus interface, and specific read-config and write-config IO request packets to interact with said bus. Based on its BSOD error, the cpuz149_x64.sys driver apparently fails on one or more of those counts. That made me wonder: is there a workaround?

Speccy ToughBook BSOD Analysis Says: Don’t Use That Driver!

For grins, I found the offending item in my user account’s …\AppData\Local\Temp folder hierarchy. I renamed it with a sy1 extension. Then I tried Speccy again: it still crashed. Drat! The program is “smart” enough to see the file is missing and supplies a new one. Now that folder shows the old renamed .sy1 file and a .sys replacement (with today’s data and a recent timestamp).

Speccy ToughBook BSOD Analysis.file-returns

When I rename to deny access to the current instance, Speccy supplies a new one.

That can’t work. Inevitably, the program promptly throws another BSOD. According to the Speccy forum, this happens with Memory Integrity enabled (as it is on the TB, and I want to keep it that way). This is what causes the BSOD. What to do?

If You Can’t Fight, Switch!

Fortunately, there are plenty of other freeware hardware profile and monitoring tools available. I happen to like HWiNFO64 myself. So I’ve removed Speccy and am using it instead. It is well behaved in its PCI bus access behavior and causes no BSODs.

Frankly, I’m surprised Piriform knows about this issue and hasn’t switched to a different driver (apparently, it comes from Franck Delattre over at CPU-Z, judging from its name). But boy howdy, is that ever the way things go sometimes, here on the wild frontier in Windows-World. Yee-haw!


Working SDIO Driver Updates

OK, then. I ‘ve been living and working with Snappy Driver Installer Origin (aka SDIO) for 4 or 5 months now. It’s an Open Source project from a person named Glenn Delahoy. Snappy has a comprehensive database of drivers (I’ve run only into 4 related elements — all part of a single device, really, for which it didn’t have drivers present). In working SDIO driver updates I’ve learned how to use the program in a way that should stay inside organizational policies for acceptable use (AUPs). Let me explain

Best Ways for Working SDIO Driver Updates

Snappy describes itself as a “portable tool.” What that means is you don’t need to keep it around. In fact, because it will get you the most current software and driver database indexes (and such content as you may need), it’s best to grab a fresh ZIP file each time you want to use it.

When you run the exe file (full name for 64-bit version: SDIO_x64_R759.exe), you must accept its license terms. Then you’ll see the screen that shows up in the lead-in graphic above. Note that it provides buttons labeled as follows:

  • Download All Driver Packs
  • Download Network Drivers Only
  • Download Indexes Only

Working Through The Buttons

These require some explanation. The first button (All …) speaks to SDIO’s architecture as a BitTorrent distributed environment. All Driver Packs come in at around 60GB, and by downloading them, you open the door for the host PC to act as a Torrent server for other users who wish to access the Snappy Driver databases. Because this violates every AUP I know of, don’t do this at work.

The second button (Network…) downloads driver packs for networking stuff so that PCs that lack drivers for wired or wireless Ethernet, Bluetooth, and so forth, can be “fixed” to access their local and other networks. You probably won’t need this, but it might come in handy sometime. Keep it in your hat…

The third button (Indexes…) involves an 18 MB download with the info that Snappy needs to  (a) identify all the drivers it recognizes on PCs on which its run and (b) find a match in its driver packs or report a driver it lacks. As I said before, I’ve seen missing drivers come up only one machine of the dozens I’ve used it on since last August (2023). That’s ultimately why it’s my go-to button in SDIO.

How I Use Snappy Could Tell You Something…

I use Snappy on my PC fleet once a month. I visit the maker’s page, where you will always find a link to the current version and database. I remove older versions from my Snappy folder, unZIP its ZIP file, and run the 64-bit version. After accepting the license terms, and selecting the “Indexes” button it tells me if I need any driver updates on the target PC where it’s run. Mostly I get a screen that looks like this:

Working SDIO Driver Updates.drv-up2date

With four months of regular use, I mostly see “Drivers are up to date” on Windows PCs.

It doesn’t bother me to get mostly “up to date” reports from Snappy. Indeed, that’s what I hope it will tell me. If the tool finds any drivers in need of update they will show up as a list in the upper-right quadrant. Simply by clicking Install(x) — where x is the number of out-of-date drivers Snappy finds — you can get it to catch that PC up with where Snappy thinks it should be.

So far, my results from using Snappy have been uniformly positive. I’ve not encountered any driver related issues since I started using it regularly a while back. That’s the basis for my coverage and (still-tentative) recommendation. Try it out — you may learn to like it, as have I.


Counting MS 2006 Drivers

Yesterday’s post about generic, MS-supplied device drivers got me thinking. These drivers bear an issue date of 6/21/2006, which coincides with Windows Vista’s RTM date. To be more specific, I wondered how many such items might appear in the Windows DriverStore. With counting MS 2006 drivers in mind, I asked Copilot for a PowerShell script to count them for me. Just for grins I compared that count to the total items as well.

Scripting Out Counting MS 2006 Drivers

You can see the results of my query to Copilot in the lead-in graphic. That query was “Write me a PowerShell script to display number of Windows drivers dated 6/21/2006 and total driver count.” As it turned out, on my Lenovo X380 ThinkPad running Windows 11, those numbers were 517 (2006 count) and 701 (total count). On my i7Skylake homebuilt system running Windows 10, those numbers were 511 and 672, respectively.

I’ll show the PowerShell commands below, but first I want to observe I had NO IDEA that MS supplies roughly 5 of every 7 drivers that Windows uses (over 70%). From looking at the items in the DriverStore more closely thanks to PowerShell, I see that this is because many of them are class, bus and service drivers. You can thus understand them as part of the driver stack between the OS and the function driver (at the bottom of the stack, it actually interacts with devices).

Here’s how MS shows this architecture in its MS Learn article “What is a driver?

Counting MS 2006 Drivers.diagram
The driver at the bottom of the stack that communicates with a device is a function driver; according to the MS Learn item, filter drivers do “auxiliary processing” which may involve monitoring, verifying, translating, or otherwise manipulating in- and out-bound stack communications. By convention app to device communication moves down the stack, while device to app communication goes the other way.

PowerShell Details

Here’s the PowerShell that Copilot handed to me in response to my query, including comments (start with a # character):

#Get all the drivers from the online Windows image
$drivers = Get-WindowsDriver -Online -All
# Filter the drivers by the date of June 21, 2006
$drivers_2006 = $drivers | Where-Object {$_.Date -eq "6/21/2006"}
# Count the number of drivers with that date
$drivers_2006_count = $drivers_2006.Count
# Display the number of drivers and their names
Write-Output "There are $drivers_2006_count drivers dated 6/21/2006 in the online Windows image."
Write-Output "The names of the drivers are:"
$drivers_2006 | ForEach-Object {Write-Output $_.OriginalFileName}
# Display the total number of drivers
$alld = $drivers | Where-Object {$_.Inbox -eq "True"}
Write-Output "There are $alld.count total Windows drivers in the online Windows image."

Some of the lines shown above break across two lines in the browser, but are actually single PowerShell commands. If you run them, you must put them on a single line. I just ran the commands in sequence, one at a time as you can see in the lead-in graphic. I cheated, though: I simply output $alld.count in the last line shown. The PowerShell shown above wraps this in some explanatory text.


2006 Microsoft Device Driver Date

Here’s an interesting bit of administrivia. Look at any number of generic drivers inside Microsoft Device Manager. Invariably you’ll see some interesting and apparently ancient items. They’ll show Device Provider: Microsoft and a Driver Date of 6/21/2006. On a Windows 11 test machine just now, for example, I saw that very date under six-plus headings. That included Batteries, Bluetooth, ACPI, Remote Display Adapter, Device Firmware,  and USB . What’s special about this 2006 Microsoft Device Driver date anyway? Good question!

Understanding the 2006 Microsoft Device Driver Date

As it turns out, 6/21/20016 was the day Windows Vista released to manufacturing  (aka RTM date). Since then, when MS supplies a driver for a non-Microsoft device it uses this date. This pushes the driver far back in time. As Device Manager chooses a driver to install it picks the best match for its device ID AND the one with the highest version number and the most recent date.

Why do this? If the OEM (or some other 3rd party with driver signing authority) produces a driver, it will bear a newer date (and possibly a higher version number). Thus, the other driver gets selected and installed. This ensures Windows always installs the best possible driver for any device. And, most of the time, it works!

The MS Driver Date Rationale

As MS updates generic drivers, it increments the driver version number. But it leaves the date at 6/21/2006. That way if a third-party driver comes along, it will almost always trump the MS generic driver version.

Why use the Vista date? Raymond Chen’s MS blog on this topic (2/8/2017) explains things in a bit more detail. A PC Magazine story from the same year supplies another crucial quote from an MS developer:

since only drivers as far back as Vista are compatible with new versions of Windows, every driver should have a date newer than Vista RTM, preserving the driver you installed as the best ranked driver.

So now we know why certain MS-supplied drivers go back to the start of the “modern Windows era.” Good stuff!



Snappy Driver Installer Worth Considering

I know. I know. Lots of Windows experts and pundits, including at AskWoody, TenForums and ElevenForum, don’t recommend or support driver update tools. That said, I find Snappy Driver Installer worth considering anyway (at least, the Origin fork). Let me recite some recent experience. Then I’ll enumerate the reasons why I’m so grateful for Snappy Driver Installer…

Why Say: Snappy Driver Installer Worth Considering

First let me explain why I’m grateful for this tool and its labor-intensive project. Almost alone among such tools, Snappy Driver installer (SDI) is open source (GNU GPL v3.0 license). Most decent driver update tools cost upwards of US$30 per year, some more than that.

Just this morning, Norton (still running it on my production PC, but I plan to bid it adieu with my next desktop build) told me I had 14 drivers out of date. It costs upwards of US$60 to add its driver scanning functions (and a bunch of other stuff, too) to its ~US$90 annual subscription fee. I’m not interested in paying more, thanks, but I was glad to learn I had some drivers out of date.

Firing up SDI for the first time is interesting because it needs more just under 37GB of driver files to offer a complete collection of stuff from which to work. Even so, the tool is smart enough to focus only on driver packs (7ZIP files of related drivers) that a target PC needs. For this target PC, that involved just a bit over 3 GB across 8 different archive files. SDI was able to handle all the out-of-date drivers on its own, in about 30 minutes (most unattended, while I did something else).

SDI Benefits and Features (IMO Anyway…)

Snappy Driver Installer is free. It’s easy to maintain a portable version on a UFD you can use for all your Windows PCs. It works with all current Windows versions (I’ve used it across the range of Windows 10 and 11 editions and builds).

For me, SDI does the job nicely and keeps my PCs current without annual subscription fees. And because I routinely shoot an image backup before mucking about with drivers, I can say no such update has ever hosed one of the PCs under my purview.

Like I said at the outset: SDI is worth checking out for yourself. You just might find it useful. Your call…

Note: For timing purposes I fired up SDI on another test PC to see how long it takes to grab the whole collection of driver packs. Right now, it’s 115 minutes in at 50% done. That means it could take as long as 4 hours to complete. It’s clocking between 18 and 85 Mbps as it runs, so it’s apparently throttled deliberately and carefully. Final runtime came in well under 3 hours (just over 155 minutes, or 2:35).

Wait! There’s more: Version forks and controversies

I got a tweet today from David Ballesteros. He let me know there are dueling versions of SDI, including the one formerly linked above (I removed it as I’ll explain). Another is called SDI Origin, which gets an interesting description at MajorGeeks.

WARNING!!! Malware is reported in the SDI fork. Thus, many online posters say — no surprise there — use SDI Origin instead. I’ve not run into any of said reported malware, adware or other potential gotchas, but my PCs are pretty armored up.

Just to be on the safe side it seems like SDIO (SDI Origin) is the best version to use. That’s why I killed the link to the other fork (but it’s easy to find online). And as I look at the filenames on my home drive for Snappy I see I wound up with the Origin version in both subfolders anyway (directory root is named SDIO).

As you can see in this properties Window, even my original exe file is named “Snappy Driver Installer Origin.” Reinforces the old saying: it’s better to be lucky than good. Phew: might’ve dodged a bullet!


Occam’s Razor Cuts My Intel PROset Problem

OK, then: let’s take a short trip back to medieval England (14th century) and drop in on philosopher William of Ockham. His original Latin epigram is “Entia non sunt multiplicanda praeter necessitatem.” That’s often translated as “Don’t add more factors to an explanation than are strictly necessary.” Many people take it to mean “The simplest explanation is usually the best (or correct) one.” From a troubleshooting standpoint, I take a different lesson.  Eliminate the obvious causes before looking for more exotic ones. And indeed, yesterday Occam’s Razor cuts my Intel PROset problem. I discover it’s the software itself that prevents its installation on Windows 10.

Why Say Occam’s Razor Cuts My Intel PROset Problem?

You can see why I had to haul this old blade out of storage by examining the lead-in graphic. It’s from the Release Notes for the latest version of the Intel PROset and driver software for its wired Ethernet adapters, including for Windows Client OSes. Take a close look at that list. Then consider the version of Windows 10 for which I sought to install this latest 28.2 version — namely Windows 10 22H2.

The installer fired up just fine, but then it took quite a while to do anything. Instead of asking my persmission to commence installation, I got this error message instead:

Occam's Razor Cuts My Intel PROset Problem.10-22H2-error

Despite repeated efforts, I got only this when attempting an install on Windows 10 22H2.

After a couple of failed tries, I figured I’d better check the release notes. And sure enough, I saw what’s missing in the lead-in graphic. This release does NOT support Windows 10 22H2. And that, of course, is why I get that error message. Given that 22H2 is the current Windows 10 version and that 21H2 hit its EOL date on June 13 (a couple of months ago), I have to believe this was a mistake on Intel’s part. But it is what it is, and I have to wait for them to fix it. Until then, I’ll keep running the preceding driver version. Sigh.

FWIW, I just summarized this info in a post to the Intel online forums for their Ethernet adapters and software. I’ll be interested to see what kind of response it evokes, if any. Stay tuned!


Achieving Intel Driver Update Silence

I’ve been writing a fair amount lately about updating the Windows OS, apps, applications and drivers. On that last subject — drivers — Intel has an outsized impact on most of my PCs (11 of 13 use Intel CPUs; all of them include at least some Intel chipsets). I’ve been updating Bluetooth, LAN (Wireless and GbE), and Graphics over the last couple of days. I counted anywhere from 5 to 9 mouse clicks needed to work through the various installers. This has me thinking: “What’s Involved in Achieving Intel Driver Update Silence?”

All this said, I’d also like to observe that I use the Intel Driver & Support Assistant (aka DSA) to drive most of my Intel driver upkeep activities. Overall, it does a pretty good job.

Is Achieving Intel Driver Update Silence Even Possible?

To some degree, yes. If you search the Intel site for “silent Intel X install” (where X = one of Bluetooth, Wireless, LAN, Graphic, …) you’ll find articles on how to run installers at the command line in silent mode. I’ll provide a list below, but here’s a discouraging disclaimer from the  Graphic driver how-to (bold emphasis mine).

s, –silent A silent installation that uses default selections in the place of user input. Not all visual indications are disabled in silent mode.

There’s the rub, in the bolded text. Running silent does away with most, but not all, visual indications.

Here’s a list of some very popular how-to’s that cover silent installation:

1. Graphic driver how-to
2. Bluetooth driver how-to
3. Base Driver & ProSET how-to (GbE, etc.)
4. Wi-Fi driver how-to
5. Chipset Installation utility how-to
6. USB 3.0 eXtensible Controller how-to

That’s all I could think of, off the top of my head. Looks like my earlier search formula works pretty well on the Intel site, though. If you need something else, chances are good it will work for that, too. If not, please drop me a line to let me know what else you found or figured out.


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!