Tag Archives: featured

Diving Into Recovery Media Rabbithole

I went down a number of dead ends yesterday, trying to restore WinGet to proper operation on my Flo6 AMD desktop. One of the more interesting and frustrating alleys I banged around in involved building bootable recovery media for Windows 11. At first,  I tried to get Copilot to steer me through, but found myself wandering in circles. So I turned to the built-in RecoveryDrive.exe tool. Diving into recovery media rabbithole took longer than I wanted, but gave me what I needed. I’ll explain…

Diving Into Recovery Media Rabbithole Requires Escape

Copilot had me formatting two partitions (UEFI: 1024MB; NTFS: rest of UFD), copying files, creating boot configuration data, and more. Only problem I had was that creation and management of the runtime environment ramdisk kept falling over sideways.

After my third failed attempt to create such a drive from scratch, I turned to the built-in Recovery Drive facility inside Windows 11 itself. (Visit Settings, search for “recovery drive” and it’ll take you right there.) This took a long-ish while to complete (about 45 minutes, all told). But it did what I needed it to do, and let me attempt AppX provisioning and repairs on a quiescent Windows image. That didn’t work out so well for me, but it did make it possible for me to learn some new PowerShell and Command Prompt tricks. I even got a couple of chances to dig into Safe Mode boot on my production desktop.

File layout for the Recovery Media looks like a typical Windows Setup disk (it can do that, too).

Desktop Fights Alternate Boot-ups: I Fight Back

At first, I was a bit stymied by the unwillingness of the Windows repair boot screen to field function keys (F1 for UEFI, F11 for boot menu, and so forth). But after a while, I learned how to work around those hurdles. Msconfig came in handy for getting into Safe Mode, while various flavors of the shutdown command let me access UEFI, alternate boot options, troubleshooting menus, and more.

The day was not a total loss, but it did throw me behind schedule on some project work. Today, I’m nosing the grindstone as I start to catch up. And isn’t that just the way things too often go, here in Windows-World?

 

Facebooklinkedin
Facebooklinkedin

Primary Desktop: Something Profoundly Wrong

I’ve been fighting dragons here at Chez Tittel all day long. On my primary desktop, something profoundly wrong is dogging my steps, and docking my productivity. I can’t boot to a recovery drive to fix a relatively simple problem with application package provisioning. Behind the scenes, something is amazingly weird, and blocking my every move to try to get things fixed. Let me explain…

More About Primary Desktop: Something Profoundly Wrong

It all started with WinGet. It (Microsoft.AppInstaller) wouldn’t update  properly . I went through a lengthy and trying series of misadventures (that took the best part of a full day). I only slowly determined the ed@edtittel.com account profile was thoroughly messed up.

First, I went through three iterations building a WinRE (Windows Recovery Environment) bootable USB flash drive. I realized something fundamental and serious was broken. Copilot says it’s not because of any of these:

  • Not a bad install.
  • Not a missing EXE.
  • Not a PATH issue.
  • Not a system‑wide problem.

Rather, it’s a borked reparse point. It’s coupled with missing shims inside user-level WindowsApps and Winget folders.

A Wilderness of Errors

Here are some of errors I’ve fought today:

  • “The system cannot find the path specified”
  • Winget working in one account but not another
  • App Installer reinstall not fixing anything
  • PATH looking correct but still failing
  • Winget.exe present but nonfunctional
  • Commands failing instantly with no useful error text
  • Ephemeral pop‑ups and disappearing error dialogs

TLDR: I couldn’t build a bootable WinRE UFD that worked. I’ve switched to another PC. Now, it’s the Lenovo ThinkStation P16 Gen1. It’s frustrating… But at last a bootable UFD via the Windows 11 Download page and msconfig to get into “Safe Mode” worked. That said, I never got WinGet working on my primary MSA.

An Alexandrine Solution

I’ve now been up and down, and back and forth, over the same ground. I can’t make WinGet work in my primary login. It works fine in an alternate MSA. After spending a long, long day trying to fix this, I am throwing in the towel. I can run WinGet from the old MSA, and for now, that’s good enough for me.

Sigh. Another wasted day (at least 8 hours) here in Windows-World. Sometimes, all the effort just doesn’t produce the desired outcome. It’s a real pickle!

 

Facebooklinkedin
Facebooklinkedin

Tiny Quiet Capable ThinkCentre neo 50q

OK, then. I finally got around to unboxing and setting up the 1L (1000 cc) mini PC that Lenovo sent to me a couple of days before Christmas. I’m pleased to say the unit is reasonably speedy, tiny and amazingly quiet in operation. Indeed, the tiny, quiet capable ThinkCenter neo 50q is the first — and only — mini-PC built around Snapdragon X that I’ve been able to lay hands on. First, Qualcomm bailed on its developer kit; second, Geekcom last year promised but never delivered a mini-PC with Snapdragon X innards. Now I finally get to see how this Qualcomm CPU and chipset serves outside the laptop space…

Deets: Tiny, Quiet Capable ThinkCentre neo 50q

It’s a bona-fide Copilot+ PC. Here’s what’s inside (including ports):

  • CPU: Snapdragon X X1-26-100 (2.97 Ghz, 8 cores)
  • OS: Windows 11 Pro (24H2 Build 26100.7462 delivered)
  • RAM: 1x16GB LPDDR5 8448
  • NVMe: Samsung OEM 1TB M.2 2280 PCIe Gen4 TLC Opal
  • Wi-Fi: Qualcomm Wi-Fi 6E & Bluetooth 5.3
  • Dimensions: 179×182.9×36.5mm (Lenovo says “1L”; it’s ~1.2L)
  • Front ports: USB-A (10Gbps), USB-C (10 Gbps), mini-RCA
  • Rear ports: 4xUSB-A (10 Gbps), HDMI 2.1, DP 1.4a, GbE (RJ-45)

What’s startling here is no high-speed USB-4 (or 5) ports. No Thunderbolt, either. That means no high-speed video links via USB-C. That’s not great. But it also means no access to USB4 or Thunderbolt 4 docks from this unit. That’s not great, either.

A similarly equipped unit, but with 32GB RAM (not 16GB) goes for US$559 at the Lenovo Store right now. That seems like a good value proposition for a machine like this one. That said, I don’t understand why USB4 is MIA from this unit, even if only through a front port. On the plus side, there’s an open M.2 2280 NVMe slot into which you can plug another drive.

Initial Impressions: Speed, Capacity & Oomph

This is a peppy little PC. It blasts through a restart cycle (restart, boot, Windows startup, desktop) in 30-35 seconds right now. CrystalDiskMark shows decent but not killer numbers from the OEM Samsung MZVL81T0HDLB-00BLL 1TB PCIe x4 SSD:

During initial setup, I was able to download and install what I needed without experiencing any delays or noticeable (local) lag. A quick trip into DriverStore Explorer (RAPR.exe) showed only two out-of-date drivers amidst a collection of 269 items (1.24 GB total size: fairly small). The OS was pretty much up-to-date, but I did have to kill and clean up McAfee (which Lenovo ships pre-installed in trial form). Lenovo Vantage didn’t show an update button, so I had to download and install the Service Bridge and Lenovo Update to check the device to make sure everything was caught up (it was).

Net-Net: Nice But No Powerhouse

Whaddya expect for US$550? It’s pretty much on precise par with the ASUS Zenbook A14 I just picked up (for the same price, give or take, though the ASUS offers 2 USB4 capable USB-C ports at Best Buy). It looks like an eminently capable mini-desktop for run-of-the-mill users who don’t need lots of horsepower or storage space.

But so far, the Neo 50q seems like a great choice for SOHO and plain-vanilla home users. My wife has had aDell OPtiplex 7080 for 5 years now and loves it (curiously, it too qualifies as a “1L” mini-PC). I’m sure she would feel likewise about the Neo 50q, too.

As I get to know this PC better, I’ll write more.It’s been a small and quiet joy to set up and learn about so far…

Facebooklinkedin
Facebooklinkedin

Copilot Assisted RAPR Analysis

Yesterday, I found myself revising a story for ComputerWorld. The topic: cleaning up Windows driver bloat using DriverStore Explorer, aka RAPR.exe. Along the way I found myself wanting to count the drivers in that store, and to identify duplicates for possible removal. Performing what I’m calling Copilot assisted RAPR analysis, I had it craft some Powershell for me. Came in really handy, so I’ll explain and illustrate what I used…

Enumerating Copilot Assisted RAPR Analysis Items

I used two one-liner PowerShell commands, plus one script, to do the following:

  • Provide a count for the number of drivers in the store (found in C:\Windows\System32\DriverStore\FileRepository)
  • Display the total file size of the store’s contents (same place)
  • Enumerate and identify the duplicates in the store (script)

These items are helpful because running the first two one-liners let me quickly count items and obtain their overall file size. Handy for before and after comparisons. The script was useful because it let me identify duplicates in the store, which RAPR does not always remove when you use the “Select (Old Drivers)” and “Delete Driver(s)” buttons for clean-up purposes.

If you look at the lead-in screenshot it shows the one-liners for making a count and getting size verbatim, and calls a script named dupdrv.ps1. The results also appear as well. These all represent post-cleanup results, FWIW.

PowerShell Details: One-Liners and Script

To obtain the count, PowerShell runs through all instances of signed PnP drivers in the store, and tots them up:

(Get-CimInstance Win32_PnPSignedDriver).Count

To get the size of the overall DriverStore, PowerShell examines each file, gets its size, adds it to a growing sum, then shows it in GB units:

(Get-ChildItem "C:\Windows\System32\DriverStore\FileRepository" -Recurse -File | Measure-Object -Property Length -Sum).Sum / 1GB

The script is longer and a little more complicated. Basically, it iterates through all files in the DriverStore, builds a table of unique entries by name, and counts all instances it finds. It reports only on instances that have counts of 2 or more (indicating duplicates).


pnputil /enum-drivers |
Select-String "Published Name","Original Name","Provider Name","Driver Version" |
ForEach-Object {
if ($_.ToString() -match "Published Name\s*:\s*(.*)") { $pub = $matches[1] }
if ($_.ToString() -match "Original Name\s*:\s*(.*)") { $inf = $matches[1] }
if ($_.ToString() -match "Driver Version\s*:\s*(.*)") { $ver = $matches[1] }
if ($pub -and $inf -and $ver) {
[PSCustomObject]@{
PublishedName = $pub
InfName = $inf
Version = $ver
}
$pub = $inf = $ver = $null
}
} |
Group-Object InfName |
Where-Object { $_.Count -gt 1 } |
Select-Object Name, Count, @{n="Versions";e={$_.Group.Version}}

These tools come in nice and handy when using RAPR to clean up a driver store. Indeed, they even extend its capabilities beyond finding old and obsolete drivers. They also identify duplicates as well. Sometimes, those too can be cleaned up. Good thing that trying to delete a driver in actual use in RAPR won’t succeed unless the “Force Deletion” option is checked. I don’t recommend using that unless you know you must for some good reason. I certainly didn’t need that here.

Benefiting from Copilot Assist

For updating this story, Copilot made it faster, easier and more convenient for me to do what I needed to anyway. That’s good. But it also let me step beyond what I’d been able to do by way of driver debloating in the past, and tackle duplicate elements as well. That’s about as good as things ever get, here in Windows-World. I’m jazzed!

Facebooklinkedin
Facebooklinkedin

More Spurious Win 11 Reclaimables

Don’t ask me why. But every now and then, MS drops a couple of old, outmoded, and obsolete packages into its Windows 11 updates. They also show up should you perform an in-place upgrade repair (“Reinstall now” via Settings > System > Recovery). Ditto for a clean install. I call them spurious reclaimables because they shows up in DISM … /cleanup-image if you run /analyzecomponentstore. Well, they showed back up on my Lenovo ThinkStation P3 Ultra yesterday. With more spurious Win 11 reclaimables to clean up, that’s just what I did. Here’s how…

Handling More Spurious Win 11 Reclaimables

Through repeated exposure to this phenomenon, and repeated prior cleanups, I’ve learned the names of the packages involved. I’ll also note they come in both AMD64 and ARM64 flavors. If you look at the lead-in graphic you can suss those names out. I repeat them here for readability:


Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
Microsoft-Windows-FodMetadataServicing-Desktop-Metadata-Package~31bf3856ad364e35~amd64~~10.0.26100.1742

These go into the following DISM command for easy removal (if they’re not present, the command will fail gracefully with no damage to a Windows image):

dism /online /remove-package /packagename:

Paste the package name right after the colon at the end of the string (no spaces). For ARM64 installations change the “amd” in “amd64” in the preceding package names to “arm” (e.g. “arm64”). That’ll do it.

Note: upon double-checking this info on another PC just now, I observed that removing the rollupfix package also removes the FodMetadataServicing package. Thus, a manual attempt to remove the latter fails. Never fear: a quick check of reclaimable packages in DISM shows the count at zero (0). Good-oh! On ARM64 PCs, however, both items (with the stipulated replacement above) MUST be done separately.

Why Do These Spurious Reclaimables Occasionally Come Back from Oblivion?

Copilot explains this as something that’s a “known defect baked directly into the original Windows 11 24H2 installation media.” Apparently this means they will come back in 24H2 and 25H2 images from time to time. When updates that include them are applied, it’s like the movie Poltergeist: “They’re heeeeeere!”

When that happens you can leave them alone. Or, if you tend toward OCD in seeking clean Windows images, you can use DISM to return them to the oblivion they so richly deserve. That’s the way things go occasionally, here in Windows-World. I enjoy such things, in case you can’t tell…

Note: I’ve written on this topic repeatedly. Run this Google search if you’d care to scan some of my other musings on these little zombies.

Facebooklinkedin
Facebooklinkedin

Notification Reveals RDP Recall Gotcha

Here at Chez Tittel, there are 9 PCs in my office (6 laptops, 3 desktops). I tend to remote into 8 of those 9, working from my primary desktop. It’s running an Asrock B550 Extreme 4 with AMD Ryzen 7 5800X CPU, 128GB RAM, and an NVIDIA 3070Ti GPU. When I remoted into the ASUS Zenbook A14 this morning, a seemingly innocuous notification popped up in the RDP window, lower right. That notification reveals RDP Recall Gotcha that reads “Recall: Sign-in with Windows Hello to resume, no snapshots are being saved.”

When Notification Reveals RDP Recall Gotcha , Then What?

I followed the notification’s instruction: Walked up to the laptop, and let the camera log me in locally via facial recognition. When I fired up the RDP session again, there was no such notification showing. So, I checked Windows Hello status, and it shows that facial recognition is enabled and working for my phiz.

Then I checked Recall settings. It shows two interesting facets to what is apparently a real and present RDP gotcha:

1. For RDP to work, it’s necessary to turn off “Require Windows Hello login” in Sign-in Settings (aka “enhanced sign-in security”). For Recall to work this must be enabled.

2. Lack of enhanced sign-in security apparently makes the RDP session behave as if Windows Hello is neither enabled nor defined on this system.

Can you say “Catch-22?” Looks like if you want to use Recall on a Copilot+ PC, you can only do so through a local login. At least for me, it doesn’t work through RDP. Good to know! Though I can’t say I like this much, it is important to understand the limitations of Recall for users who might wish to take advantage of its capabilities.

Looks like Recall requires local operation. My conclusion: To use Recall (and I presume other AI features) go local, or go home. It’s always something, here in Windows-World.

 

 

Facebooklinkedin
Facebooklinkedin

Manual Store Update Clears Ongoing Errors

Here’s an interesting one. I just took a look at Reliability Monitor on one of my Canary channel test PCs (the venerable ThinkPad X12 Hybrid Tablet). As you can see in the lead-in graphic, it shows 14 days’ worth of “Warnings.” All of them mention Windows Terminal and YourPhone with a “Failed Windows Update” summary. But a manual Store update clears ongoing errors, and everything is hunky-dory now. Let me explain…

Why Manual Store Update Clears Ongoing Errors

I’m in the habit of leaving Windows Terminal open on many of my PCs. That’s because I run WinGet and other CLI utilities on them on a near-daily basis. But although this strategy is convenient, it sometimes means that Store updates won’t complete successfully because they don’t want to affect a running and related process.

Running a manual store update (Click Upates & downloads in the left column, then click the “Check for updates” button at upper right) forces the Store to interrupt things and start with a clean slate (Copilot calls this a “clean install path”). That means it restarts the Store install service, flushes any stale metadata, closes the running Terminal processes, pulls dependencies in the necessary order and forces a high-priority update job.

Thus, what’s stuck inside the automated daily update tasks that Store handles in the background is stuck no longer. The update goes through and the program shows itself running the latest version — namely, 1.23.13503.0 — without issues. And indeed, the same thing applies to Microsoft.YourPhone (showing the same error over the same period — it runs in the background automatically).

Not All Automatic Updates Always Succeed

This heading is the “moral of the story.” It emphasizes that occasional manual intervention may be needed, especially for processes that run in the background by themselves. But hey — that’s the way things go here in Windows-World sometimes. Happy New Year!

Facebooklinkedin
Facebooklinkedin

OCuLink versus Thunderbolt

I just learned something new (to me, anyway). In reading about a mini-PC at Neowin today, I ran across mention of an OCuLink port. It looks alot like DisplayPort (full-sized) but it’s not. As Sydney Butler at How-to Geek explains things “OCuLink…[is] short for ‘Optical-Copper Link,’ [and] is a peripheral connection standard that allows you to connect PCIe devices using an external cable rather than an internal slot.” Thus, it uses raw PCIe signaling instead of protocol based channel communications, which makes it faster and cheaper than Thunderbolt 4 (but not 5. where it’s cheaper but slower).

Why Compare OCuLink versus Thunderbolt?

OCuLink can do many of the same things that Thunderbolt does — notably make fast NVMe and eGPU connections — often more cheaply. It can handle external GPUs (eGPUs) faster than TB4 (not TB5), and at lower cost.

OCuLink is not as widely used in laptops, however, and depends on a PCIe (X4 or X8 usually) adapter to make such ports available for use. A new standard, called CopperLink, is on the way to support PCIe 5.0 and 6.0 (and compete directly with TB5). Indeed you can even buy an OCuLink eGPU dock with dual OCuLink and TB5 ports, an M.2 NVMe SSD slot, 2.5Gbe (RJ-45), and even dual USB 3.0 Gen 2 (10 Gbps) ports for US$240. That’s about half the price of a TB5 dock (e.g. CalDigit, Anker, Lenovo, etc.) nowadays…

Does Slow Thunderbolt Uptake Open a Door?

A good TB4 enclosure costs upward of US$60 these days, and includes a cable. A good TB5 enclosures costs upward of US$150 and includes a cable. A decent OCuLink enclosure costs US$40 or so, but needs a US$20-40 cable to work. It runs faster than TB4 but slower than TB5. The same general scenario applies to running external GPUs: here again, OCuLink falls between TB4 and TB5.

For desktop and mini-PC users with access to open PCIe X4 slots, OCuLink is worth considering. Laptop and tablet owners will probably opt for TB4 because that’s what the majority of OEMs support nowadays. In the future, it’ll be interesting to see if CopperLink gains traction at the expense of TB5. It’s an Open Standard, so OEMs don’t have to pay to license the technology for inclusion in their devices. On such small factors big decisions sometimes rest here in Windows-World. Let’s see what happens!

 

Facebooklinkedin
Facebooklinkedin

Windows 10’s Long Goodbye

Officially, it’s been “out of service” since October 14. And indeed, Windows 10 market share has been falling for some time now, with 11 ascendant. But, in unwinding Windows 10’s long goodbye from the desktop OS scene, there’s no sign yet of a spiraling vortex as the old OS goes down the drain. Remember, too, that older OSes — inlcuding 7,  XP and 8.x versions all show up in a range from just under 3% (7) to under 0.3% (XP, 8, and 8.1). Apparently old OSes never fade away completely…

Unwinding Windows 10’s Long Goodbye via 7

As I think about what’s going on here, I can’t help but use Windows 7 as a lens through which to view Windows 10’s upcoming decline. This actually shows itself quite nicely in a Copilot-generated desktop share graph (source: Wikipedia’s summary of StatCounter data 2015-2025).

2015, of course, was the year in which Windows 10 made its debut. It was also the same year in which Windows 7 transitioned from “mainstream support” to “extended support.” That’s what Windows 10 did this year, in slightly different terms.

Notice the shape of the curve imposes modest steps until the midpoint. It shows more serious declines since then. My gut feel is that Windows 10 will experience a similar fall-off. That said, I also believe the curve will drop more precipitously. That’s because MS has long sworn to limit extended support for 10 to 3 years, whereas it didn’t end ESU for 7 until the 5-year mark (2020) came along.

That would put the half-way mark three rather than 5 years out, with faster dropoffs after that. That said, with RAM and GPU prices currently on a steep rise, the impetus to buy new hardware to meet Windows 11 requirements may have hit a steep wall. Here in Windows-World the path from A to B (or 2025 to the New Year and beyond) isn’t always straight or simple. Let’s see what happens, shall we?

Facebooklinkedin
Facebooklinkedin

Notepad++ Update Stalls WinGet

Ha! I just learned something new. Because Notepad++ uses a Win32 installer, when WinGet tries to update the app, it will hang if Notepad++ is open. That’s how a Notepad++ update stalls WinGet. Fortunately, I was able to get over that hump pretty easily. Let me explain…

Why Say: Notepad++ Update Stalls WinGet?

WinGet stayed on the first update until I realized the program was open. Then I closed it, and about 30 seconds later, progress resumed. According to Copilot, Notepad++ uses a “classic Win32 installer” that’s downloaded and run silently. That installer tries to replace files in C:\Porgram Files\Notepad++, including notepad++.exe. If the file is running, Windows won’t let the installer overwrite that file.

So it waits a while (30, 60 and 90 seconds, according to Copilot) and retries after each interval expires. When the third try fails, the installer reports failure and closes. I was able to close the app before the second try, and then that attempt succeeded, which is how it took a while to complete the update process.

Moral of the story: when certain apps pop up in response to WinGet ugprade it’s a good idea to make sure they’re closed. Indeed, if such updates fail, they’ll most likely succeed if you close them before a retry. And man, isn’t that just the way things work here in Windows-World? Some of the time, at least…

Another Stall, Another Reason…

I ran WinGet again on another PC and once again it hung. But Notepad++ wasn’t open on that PC. So I went digging into the log file named WinGet-2025-12-29-11-42-19.224.log. There, I found a long sequence of the following two information lines (I skipped the timestamp info for brevity:

[REPO] Attempting to open pinning database: C:\Users\ed\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db
[CLI ] Terminating context: 0x8a15002b at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:be

This started at 11:42:22.609 and ended at 11:42:22.929 (0.320 seconds) and repeated every .002 seconds (160 times). It seems that, for some reason, WinGet couldn’t access its pinning database during that time period. Thus, WinGet stalls until that condition is addressed. Another stall, but another reason, too. Cheers.

Facebooklinkedin
Facebooklinkedin