Category Archives: Insider stuff

10 Gbps Flattens Device Speeds

I’m still working and checking out the Lenovo ThinkStation M90a Gen 5 All-in-One (AIO). You can find my initial impression (and its specifications in Strange but Lovable Lenovo AIO, dated Jan 16). I’ve been playing with its many (6) USB-A ports and its sole (1) USB-C port. Because all of them are USB 3.2 Gen2, I’ve now observed that 10 Gbps flattens device speeds. That is, external drives that can run faster than 10 Gbps in a USB4, or TB3/4 capable USB-C port, all run at more or less the same speeds in a 10 Gbps USB-C port.

Showing that 10 Gbps Flattens Device Speeds

Take a look at the lead-in graphic. It shows CrystalDiskMark results for 3 USB storage devices — namely (from right to left):

1. Kingston DataTraveler Max 256GB flash drive USB-A
2. Maiwo 40Gbps USB4 enclosure with PCIe x4 NVMe USB-C
3. Sabrent 10Gbps USB 3.2 Gen1 with PCIe x3 NVMe USB-C

Notice further that the values are similar for all cells across all devices. As you’d expect the faster devices (NVMe vs. Flash) win out in the random reads and writes. Surpisingly, the older Sabrent enclosure with its slower NVMe beats the faster Maiwo/NVMe combination.

Unflattening to 40Gbps USB4 Ports

But because 10 Gbps is as fast as anybody gets to go via USB on the M90a AIO, all those values are constrained by channel speed. That’s what flattens the results on that machine. If run external an external NVMe on a USB4-equipped PC, things go faster for the bulk reads and writes (top half of CrystalDiskMark results). Check it out in the next screencap.

Bulk transfer speeds go up in USB4, but random read/write speeds decline. Go figure!

As a confirmed hardware skeptic, I’m inclined to file this under the “you win some, you lose home” heading. That said, I’ve seen better USB4 performance on the latest generations of laptops, including Snapdragon X and Intel Ultra models. Yet another reason why MS may not totally be smoking something when they proclaim 2025 as “the year of the refresh”…

Facebooklinkedin
Facebooklinkedin

Windows.old Required For Uninstall Window Access

Here’s an interesting Windows gotcha that affects both Windows 10 and 11. There’s an interval setting value in these OSes that controls how long Windows.old stays on your system disk before it gets deleted. It’s called the “OS uninstall window” and it’s set to 10 days by default, though any value from 2 through 60 (days) is legal. That said, you can only see and manipulate this value if Windows.old is present on the target system. That’s what the title means when it says “Windows.old required for uninstall window access.”

Why Is Windows.old Required For Uninstall Window Access?

God only knows (and possibly a few Microsoft OS engineers). That’s just the way it works. Indeed the relevant MS Learn article doesn’t comment on the why; it only documents the how. I had to go to Google to get an explanation for what you see in the lead-in graphic — namely, that when you run the DISM command that tells you the current uninstall window value for Windows.old, it throws an error if there’s no Windows.old present on your system for it to inspect. Weird.

The best explanation I found is at SuperUser.com. The short answer to “Why an error and not a number?” reads simply “No, you are too late.” That is, once Windows.old is removed, the command no longer works the way one might presume it should. In short, if no Windows.old is present, the OSUninstallWindow value is not available, nor can it be reset. Again: Weird.

Even weirder: you’d think there would be a registry value to control this. But alas, as Copilot informs me and my truth-check research confirms “There isn’t a specific registry value in Windows 10 or 11 that directly controls the OSUninstallWindow value.” It’s just another Windows oddity for the ages. Now I know (and now, you do, too). Cheers!

Facebooklinkedin
Facebooklinkedin

DevHome App Faces May Retirement

It was both fascinating and a little disheartening to learn yesterday that the Microsoft DevHome app faces May retirement. I have come to really, really appreciate DevHome for two reasons — namely:

1. It supports easy creation and management of ReFS drives in both Windows 10 and 11.
2. It demonstrates that MS can indeed fully automate the creation of Windows Hyper-V VMs, even though Hyper-V Manager still includes glitches one must work around to bring up such VMs manually.

Initially, I learned about this yesterday from long-time Window developer and watchdog Rafael Rivera via X (@WithinRafael). But this morning, Sergey Tkachenko posted an item at WinAero that shows a DevHome notification to the same effect.

Decoding What DevHome App Faces May Retirement Means

I’ll be darned if I can find the notification that Sergey displays in the WinAero post (and which Rafael included in his initial X info). I made sure Microsoft.DevHome (the app’s WinGet ID) was up-to-date. As you can see in the lead-in graphic, I even uninstalled, then reinstalled DevHome using WinGet just to make sure I wasn’t missing something. No dice.

All this said, I’m guessing that the various extensions and utilities that DevHome makes available, and its ReFS and Hyper-V VM capabilities,  will show up in other parts of Windows 11 around May as well. Sounds like a pretty good platform for 25H1 updates, in fact. What I can’t say because I don’t know is if MS will decide to do likewise for Windows 10, which currently supports DevHome (via the MS Store; it’s pre-installed in Windows 11 starting with 23H1 and thereafter).

I guess it will be interesting to see what happens with these various bits and pieces, several of which have garnered my appreciation. Plea to MS: please, please, please fix Hyper-V Manager so that it will do what DevHome currently does with panache — that is, automate VM install with the added capability to point to on-disk images or ISOs. If you want to understand how things work now, and what workarounds are necessary to bring a VM in Hyper-V Manager, see my September 24, 2024 ComputerWorld story How to set up Windows 11 Hyper-V virtual machines. It’s kind of a mess, frankly…

Facebooklinkedin
Facebooklinkedin

Backing Off Intel Graphics Driver

Ok then: I was operating under the belief that no harm should come to Lenovo PCs after updating to Intel GPU drives via DSA. Apparently I was mistaken: I’ll show evidence that for the ThinkStation P3 Ultra at least, the DSA-supplied Arc & Iris Xe drivers pose problems. Hence, I’m backing off Intel graphics driver on that machine.

Why I’m Backing Off Intel Graphics Driver

Check out the lead-in graphic. It shows Reliability Monitor with 2 crashes on both 1/22 and 1/23 for the IntelGraphicsSoftware Service process. Not good! Indeed, it causes about a 5-point drop in the reliability index in two sharp dips.

To me, that makes it pretty clear that — at least for this PC — the Intel driver is not working properly in its runtime environment. The notion that I picked up was that updating Windows 11 graphics drivers would not necessarily overwrite OEM customizations. FWIW, Copilot confirms this. But the evidence from ReliMon on the P3 is pretty hard to contest. Methinks Intel is still right to post its warning in DSA where such drivers are concerned (with a checkbox for users to explicitly opt in anyway), to wit:

And indeed, now that I’ve uninstalled that driver and reverted to a Lenovo driver dated 10/29/2024, I’ve experienced no further issues with Intel graphics stuff. That said I do have an APPCRASH for the IntelSoftwareAssetManagerServer.exe process. But a quick hop to the Intel Support Community shows that this belongs to PROSet Wireless stuff not graphics. So there’s a problem for another day!

Here in Windows World it’s always something. Lately, those “somethings” have an interesting number of elements with Intel’s name involved. Go figure…

 

 

Facebooklinkedin
Facebooklinkedin

WinGet Boosts Chrome Update Capability

Here’s an interesting item. Previously, WinGet wouldn’t update Chrome on Windows PCs where it was running. Now it will, because WinGet boosts Chrome update capability. It now runs the installer with admin privileges to overcome the maxim “don’t mess with running processes.” You can see it working in the lead-in graphic, where the text reads (in yellow):

The installer will request to run as administrator, expect a prompt.

If WinGet Boosts Chrome Update Capability, Users Benefit

This means users must still Relaunch Chrome to get the update to take, though WinGet applies the update. Previously, WinGet would just skip the whole thing. Now, the next time users open that browser, the new update will take over (or, they can manually use the Relaunch button themselves).

After WinGet does its thing, Relaunch remains required to leave running processes undisturbed.

Will Other Browser Makers Follow Suit?

Here’s a shout out to the dev teams for Edge, Mozilla/Firefox (and variations), Opera, and others. Take heed of this Chrome action and do likewise. Your users — including your truly, most fervently — will thank you.

It’s just another small step for WinGet. But it translates into a big boost for the Windows user base. Keep up the good work, people!

New PowerShell Version Out, Too…

While I’ve got your eye, a new PowerShell version — v7.5.0 — is out. It’s still new enough that WinGet won’t install it yet. If you, like me, are OCD enough to want to run it before it gets into the pipeline, download it from the assets on the Release v7.5.0 page.

Note added 15 minutes later: Nevermind, it’s already showing up in WinGet. I should’ve known @Denelon and the team wouldn’t sit on their hands here. Another attaboy for that group and the PowerShell team. Good-oh.

Here, you can see the old 7.4.6 windows left, and a new 7.5.0 window right. God: I *LOVE* Windows Terminal.

Facebooklinkedin
Facebooklinkedin

Unexpected BIOS UEFI Update Adventures

When Lenovo Vantage popped up a notification yesterday that the ThinkStation P3 Ultra needed a BIOS/UEFI update, I thought nothing of it. But as the process dragged on … and on …. and on some more, I started to get a little concerned. Indeed, I found myself enmeshed in unexpected BIOS UEFI update adventures as what I thought might take 10-15 minutes took about an hour, all told.

But there is a happy ending. Though it took much longer than it ever has before, the update complete successfully. And the machine continues humming along, happily doing what I ask it to. That’s a relief!

Describing Unexpected BIOS UEFI Update Adventures

This may be the third such update I’ve gone through with this machine. Across all my many Lenovos over the years, loaners and review units included, I’ve probably performed over 200 such updates. That’s a big reason why this particular one took me somewhat by suprise.

Here’s a list of symptoms:
1. After the BIOS update completed, the PC rebooted yet one more time. It usually comes back up in no more than 30 seconds. This time, it took between 1 and 2 minutes.
2. Upon restarting the machine showed a black screen — no Lenovo logo for the boot splash screen showed up for at least another 30 seconds. Normally, this pops right up.
3. After the Logo showed up center screen, it took longer than usual for the “Energy Star” and “TCO certified” logos to show up bottom right. Again, this added another 30 seconds or so to the delay.
4. During that first reboot cycle, the PC rebooted itself again (never seen this before). This time the screen stayed black even though the monitor power indicator stayed on. I had to cold start the PC (turn off the power, wait 30 seconds, turn the power back on) to resume start-up.
5. After this second unexpected restart, the P3 took well over a minute to get to the splash screen. Getting to the spinning circle took longer than usual as well, but it booted into Windows 11. It’s now showing 24H2 Build 26100.3894 (current).

Post-update, the P3 takes about 10 seconds from the Lenovo boot splash to show TCO and Energy Star logos. Another 10 seconds to get to the spinning circle. Another 15 seconds before the lock/login screen appears. Thus, total boot time is now around 35 seconds or so. That’s not too bad, actually.

Why the Kerfluffle?

Copilot tells me extended boot delays after UEFI update can arise from compatibility issues, switching all settings to their defaults, “re-learning” of hardware  (I’ve seen this with memory on the P16 but that posts an on-screen message and nothing like that showed up on the P3), and “additional error checking or diagnostics during boot.” I’m guessing this update included a bigger change delta than older ones, and that some of the final category (diagnostics and error checks) also got thrown in.

As for the cold start, Copilot says it happens when the system needs to “properly recognize all components” after a UEFI update. I can see that, particularly if related aspects in the UEFI have changed since the preceding version. That would absolutely force a complete, new device enumeration, which may have been needed in this case.

At any rate, it turned into more of an adventure than I expected. And I learned a few things along the way. Glad the machine is running now, and appears to be working well. Fun, fun, fun here in Windows-World these days!

Facebooklinkedin
Facebooklinkedin

UniGetUI Beta Previews Advanced Features

Yesterday, Marti Climent — the lead developer for UniGetUI (formerly known as WinGetUI) — dropped a new beta version (3.1.6-Beta2) of the program into GitHub. This UniGetUI Beta previews advanced features planned for the next official release, when it transitions into production. Right now, it may be worth downloading and playing with to see what it can do (IMO). But the developer’s “Caution” on this release reads “Prerelease builds can be unstable and should not be used on a production environment.” There: you’ve been warned.

Exploring UniGetUI Beta Previews Advanced Features

A good way to understand what’s in 3.1.6-beta2 is to visit its release page at GitHub. There you’ll see that info listed under “General Changes.” Minutae appear in the detailed changelog (summarized under “What’s Changed” on the GitHub page). Highlights:

  • Downloads provide more detailed status info, including download and install phases
  • Multiple downloads can now proceed in parallel
  • Immediate package download triggers upon right-click of any item in the update list

I’m especially intrigued to see that UniGetUI will soon gain parallel download capability. It already launches a separate process for each download/install session but does them in series. In the next release, it will do them in bunches, instead of one at a time. Good-oh!

Production Release 3.1.5 Also Worth Trying

For those seeking a good alternative to WinGet (and 9 other package managers, including Scoop, Chocolatey, NPM, PIP, and more) UniGetUI is worth checking out in its own right. The lead-in graphic shows a recent download session on my production Windows 10 PC. There, it’s ready to download and install 6 packages (Dropbox, Chrome, Java SE SDK, PS 5.x and 7.x PSGalleries, and Snagit 2024). The whole process takes less than 10 minutes to complete.

UniGetUI should be of especial interest to organizations and development teams that use sources not available to WinGet but readily available to some or all of the other package managers mentioned in the preceding paragraph). Indeed, UniGetUI finds and updates items that WinGet at the command line does not, because of that wider range of available update sources, even on plain-vanilla Windows 10 or 11 PCs.

If you like what you see in version 3.1.15, keep your eyes out for the final cut of 3.1.16. It promises to be faster and more capable than the current production version. One more thing: if you’d rather let UniGetUI do its thing without bothering you try this super-silent command line invocation:

UniGetUI.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /NoAutoStart

This suppresses interactions and messages, and puts off any restarts that might otherwise be initiated if working UniGetUI through its actual UI. Works like a charm, in total stealth mode. Good stuff!

 

Facebooklinkedin
Facebooklinkedin

Further Intel DSA Follies

So I’m working on the new loaner unit here at Chez Tittel: a Lenovo ThinkCentre M90a Gen5. As part of my management process, I routinely install the Intel Driver and Support Assistant — aka DSA — on PCs with Intel CPUs. That includes the M90a because it sports a beefy i7-14700. In catching up the device on the latest Bluetooth, Wi-Fi and GbE drivers this morning, I found myself engaged in further Intel DSA follies following (and during) installation. Let me explain…

Fostering Further Intel DSA Follies

My first folly occurred as DSA was getting installed. Even though it wasn’t quite done, it popped up a notification of available updates. I’d never seen this before, so I bit on that offer. It got me downloading the aforementioned communications drivers, and I started that sequence with Bluetooth. Imagine my surprise when the install refused to run because “another installation is underway.” For me, then, Folly #1 is “Don’t start on updates until DSA install is finished.”

Folly #2 reflects a recent UI change in DSA. Once it completes any driver install, it shows installation history. Because one is installing drivers in sequence, that means one must click the “Refresh” button to see any and all remaining drivers that still need to be installed. Repeat until all desired drivers are updated. I’ll summarize Folly #2 as “Remember to click ‘Refresh’ as each install completes, to see remaining pending installs.”

Folly#3 is extreme user engagement in the various driver installers. I counted from 7 to 10 mouse clicks per driver install to get through that process. This bothers me enough that I’ve already blogged about this (April 2023: Achieving Intel Update Driver Silence). Given that Intel has documented this capability for most of its drivers, I’m apparently not the only DSA user to find this irksome.

Done and Dusted: Follies Behind Me

The M90a is now caught up with all of the Intel drivers I choose to update. Even though it’s not supposed to matter, that brings me to Folly #4: The Intel Arc & Iris Xe Graphics warning (appears as the lead-in graphic above, in fact). Intel says elsewhere that since 2022 or thereabouts, its drivers do NOT trample upon OEM customizations. Yet it continues to flash this warning and require user opt-in before enabling install. Sheesh.

Here in Windows World, it’s always something. Today, it’s Intel DSA follies. Who knows what tomorrow will bring? Wait til then, and I’ll let you know…

Facebooklinkedin
Facebooklinkedin

Weird Win10 Insider Mismatch

When I report a Windows puzzle, I usually like to provide a solution. But I just noticed something odd I may not have time to solve today. It looks to me like a weird Win10 Insider mismatch. Let me explain: my production PC is signed up for the Beta Channel, as you can see in the lead-in graphic. But a quick Winver run shows that PC running version 19045.5371 (see below). Alas, the current Beta Channel Insider Preview Build is 19045.5194. And there’s the mismatch in plain sight!

The Build number on this supposed Beta Channel PC corresponds to the current public/production release.

Fixing Weird Win10 Insider Mismatch

Upon closer examination, the Beta build is lower than the current production build. Looks like I want to switch to the Release Preview channel at Build 19045.5435 instead. Let me try that… No joy.

So then, I do some more poking around online, turns out I need to re-select the Beta Channel item (see lead-in graphic) and open its subsidiary window. That lets me switch to the Release Preview channel. Then when I pop back up two levels to re-run an update check, I get what I want:

Turns out my problem is an error in understanding how to switch from Beta to Insider Preview channel: problem solved!

Looks like the download and install are working. I’ll be rebooting soon: installing has reached 100% but not yet flipped over to “Restart pending…” Now it’s installing again … 20% … taking much longer … 45% … 73% … 88% … done. Restarting now… AAAAND winver now shows 19045.5435.

Turns out it wasn’t a channel mismatch: I was on the wrong channel FWIW, Copilot tells me that MS is shutting down Beta Channel, but is continuing to release into the RP (Release Preview) Channel. Hence, my need to change channels to get to the right build level. Apparently, I missed that memo. All fixed now!

As always here in Windows-World, fixing things is easy when one knows what to do. This time, it took me a while — and some new info — to figure out what that was. Go figure!

Facebooklinkedin
Facebooklinkedin

Overcoming KB5050009 Update Errors

I’ve seen it before. And I’m grimly resigned to seeing it again. Every now and then, a Windows PC has issues with some Windows Update (WU) item. Mostly, though, I’ve seen this with Cumulative Updates (CUs) rather than security, MSRT, or servicing stack items. Indeed, this very situation popped up on a brand-new review unit from Lenovo following Patch Tuesday this week which brought KB5050009 to Windows 11 24H2. On all four of my other production level 24H2 PCs, no problem. On the ThinkCentre M90a (see yesterday’s intake review) however, I spent some time overcoming KB5050009 update errors. Let me explain…

Escalating Steps When Overcoming KB5050009 Update Errors

I’ve been through this kind of thing often enough that I’ve got a series of steps I follow when a WU update fails and throws an error. Here it is:

1. Write down the error string ( 0X800F081F in this case)
2. Run the WU update again (helpfully, it offers a “Retry” button)
3. If it fails, note the error message. Record only if different from 1.
4. Download and run the batch file from Eleven Forums Reset Windows Update tutorial (Batch file named Reset_Reregister_ Windows_Update_Components_for_Windows11 .zip).
5. Try again. It it fails. note the error message if different from 1.
6. Download the self-installing update file (.msu) from the Microsoft Update Catalog, then install.
7. If it fails, note the error message. Record only if different from 1.
8. Visit UUPdump.net. Create an ISO file for the target Build (26100.2894, as per KB5050009 support note).
9. Perform an in-place upgrade repair install on the affected PC. This applies the already-integrated CU as part of that process.
10. If that fails, perform a clean Windows install using the UUPdump ISO.

I’ve only had to beyond step 5 in a small number of instances in the 30-plus years I’ve been using Windows. This was one of those cases. To my surprise the catalog download failed the the same error message as before. Next, it took an hour and half to download and build the 26100.2894 ISO, and another 50 minutes or so to install that image on the ThinkCentre. Ouch!

One Step Short of Clean Install Works

But when the PC rebooted, it came up with no errors. Interestingly, the Update History does not show KB5050009, even though it must be present for the build number to reach 26100.2894. You can see this in the lead-in graphic, which shows that very build number, but not the CU entry for KB5050009. That’s because it was part of the install image when the upgrade repair install occurred, not added separately via WU.

But it does go to show that here in Windows-World, when WU won’t work, there may sometimes be a way to work around its failings. This is such a tale…

PostScript: About the 0X800F081F Message

Here’s what Copilot says about this error message, thanks to info from answers.microsoft.com:

The error code 0x800F081F typically occurs when the Deployment Image Servicing and Management (DISM) tool is unable to find the necessary source files to repair the Windows image. This can happen during Windows updates or when running the DISM /Online /Cleanup-Image /RestoreHealth command.

To me that indicates there was some WU issue with the files included in the update package that got downloaded from the WU servers. Curiously it also seems to have affected the Catalog item. I’ve never had that happen to me before. Go figure!

Facebooklinkedin
Facebooklinkedin