Category Archives: Recent Activity

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Windows Neofetch Alternatives

August 25, 2026 Ed Tittel Leave a comment

If you’re ever seen Neofetch, you’re likely to want something like it for Windows. It’s a command-line tool that displays a quick system snapshot. It shows OS version, CPU, GPU, RAM, uptime, shell, storage and more, alongside a rendering of the OS logo as “ASCII art.” But Neofetch is mostly a Linux/Unix thing that requires a Bash shell to run. It was also archived in April 24. It still works, but there are better choices for Windows. For those seeking Windows Neofetch alternatives, the best options are fastfetch and winfetch.

Windows Neofetch Alternatives Are Helpful, or Necessary

Again: Neofetch is a Bash script. That explains most of the friction inherent in running Neofetch on Windows. That is, it requires Git Bash or WSL — neither of which is a native Windows tool. The script itself froze at v7.1.0 when the repository was archived. Worse, going forward Neofetch is dead in the water: no updates, no bug fixes, no future-forward functionality.

Think about what Neofetch actually does: it reads your OS version, CPU, RAM, and a handful of other system facts, then prints them alongside an ASCII logo. Running an outdated Bash script through a compatibility layer to accomplish that feels like overkill. Native tools handle this job more cleanly, more quickly, and without the extra dependencies.

2 Strong Alternatives: Fastfetch and Winfetch

Both of these facilities are actively maintained, and update regularly. Either one can take over for Neofetch without skipping a beat.

Fastfetch

Fastfetch is written in C and installs as a native binary. Speed is its calling card — it fetches and renders system info noticeably faster than Neofetch ever did. Cross-platform support (Windows, Linux, macOS) makes it useful across mixed environments. Install it with any of the major Windows package managers:

winget install fastfetch

Once installed, launch it by typing fastfetch at any prompt. Configuration lives in a JSONC file, so customization is straightforward and version-control friendly. Here’s what it looks like on my AMD-based Flo6 desktop (click image to enlarge):

Winfetch

Winfetch is a pure PowerShell script — Windows-only, and deliberately so. It installs directly from the PowerShell Gallery:

Install-Script winfetch -Scope CurrentUser

For anyone already running Windows Terminal with an Oh My Posh prompt and Nerd Fonts, winfetch slots right in. The output renders cleanly alongside a styled prompt, and the whole setup feels native rather than bolted on. You can see it in the lead-in screencap.

The Winfetch Path Gotcha

What the lead-in graphic shows is me getting past the requirement that the winfetch script must be somewhere in $PATH to work. In fact, after I installed it, I got this error when I tried to run it:

Error

winfetch : The term ‘winfetch’ is not recognized as the name of a cmdlet, function, script file, or operable program.

This happens because the installer drops the script into a specific, pre-assigned folder:
C:\Users\Documents\Powershell\Scripts\
Powershell does not, however, automatically add that folder to the $PATH environment variable. So even though the script is installed, it doesn’t run from the command line. Easily fixed, however, as also shown in the lead-in graphic, through a series of simple steps.

Fixing Winfetch, Step-by-Step

Step 1: Confirm the install location

Run this to verify exactly where the script landed:

Get-InstalledScript winfetch | Select-Object Name, InstalledLocation

Step 2: Run it directly as a workaround

Before touching PATH, you can invoke winfetch immediately using its full location:

& "$((Get-InstalledScript winfetch).InstalledLocation)\winfetch.ps1"

That works, but typing it every time is obviously impractical. The permanent fix takes about ten seconds.

Step 3: Add the Scripts folder to PATH permanently

Open PowerShell and run the following command to append the Scripts folder to your PATH inside your profile:

Add-Content $PROFILE "`n`$env:PATH += `";`$([System.Environment]::GetFolderPath('MyDocuments'))\PowerShell\Scripts`""

Then reload your profile in the current session:

. $PROFILE

After that, typing winfetch works cleanly from any new PowerShell session. No more “not recognized” errors, no manual path juggling.

Tip: Execution Policy

If PowerShell refuses to run the script at all, check your execution policy first: Get-ExecutionPolicy. A setting of Restricted blocks all scripts. Set it to RemoteSigned with: Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Which to Use: Winfetch or Fastfetch?

The choice comes down to how you work, not which tool is objectively better.

Tool	Best For	Install Method	Config Format
Fastfetch	Speed, cross-platform use, binary simplicity	winget install fastfetch	JSONC file
Winfetch	PowerShell-native feel, Windows Terminal + Oh My Posh setups	Install-Script winfetch -Scope CurrentUser	PowerShell config script

Reach for fastfetch when you want something fast, dependency-free, and portable across platforms. Winfetch makes more sense if you live inside PowerShell and want the output to feel like it belongs there — especially alongside Windows Terminal and a styled prompt. Both tools beat neofetch on Windows in 2026. Pick one and move on. Either way, you get a clean, colorful system info display — and you leave a frozen Bash script behind where it belongs. That’s about as good as tradeoffs get here in Windows-World. Cheers!

Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

Open Apps Maximized Is Nice

August 24, 2026 Ed Tittel Leave a comment

With the release of Beta Build 26220.9223 last Friday (Aug 21), MS now includes an “Open apps maximized.” It shows up in Settings > Accessibility > Visual effects, shown in the lead-in screencap. The feature is pretty handy, even for those who don’t work around visual impairment. Indeed, Open apps maximized is nice for all kinds of users, including your humble author. Indeed, I usually work with key tools (e.g. Office apps, text editors, WinTerm, networking tools, and so forth) maximized anyway.

If Open Apps Maximized Is Nice, Do You Use It?

It’s a matter of working style. If you regularly use apps maximized, it can be a small time-saver, that’s for sure. Interestingly, for apps with restricted max window sizes (e.g. PC Manager, CPU-Z, Core Temp, and so forth), the windows still open at their normal sizes. So it doesn’t ALWAYS fill a display with the app windows you open. That only happens for apps that allow themselves to cover that whole space already.

Even better, if you open an app in full-screen mode courtesy of this new Settings option, you can still click the “Restore down” button to return the window to whatever size you had it set at beforehand. At that point, you can still re-size the app window however you like it. Windows remembers this setting, so with “Open apps maximized” toggled on, it will return to the current sizing when you click the middle button in the top right trio (Minimize/Maximize (up) or Restore Down/Close).

Who Needs “Open Apps Maximized?”

Anybody who wants it. It’s a simple and easy UI behavior option. Personally, I like it in concept. I need to live with it for a while to see how I like it in practice. My intuition, such as it is, tells me MS might benefit from refining this further into a per-app control (e.g. Apps > Default apps or Apps> Startup do this already).

Here in Windows-World, setting default behaviors can be good or bad. You must decide what works best for you, and act accordingly. I’m still deciding if the new “Open Apps Maximixed” works for me or not. When I make that decision toggling this setting on could become part of my standard Windows set-up actions, or not. We’ll see. But it’s cool and potentially helpful nevertheless.

Backup/Restore, Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

Managing Macrium Reflect Keys

August 21, 2026 Ed Tittel 3 Comments

Right now, I’m paying for 8 keys’ worth of Macrium Reflect X Home. I just conducted a survey of all the machines here at Chez Tittel and observed that only 2 currently run Reflect X, 2 run Reflect 8, and the rest run something else. Since I’m paying for 8 and currently have 8 machines at hand, I could use them all. As I’ve been managing Macrium Reflect keys, I have to compliment the company’s web interface at manage.macrium.com/. It now works lots better than it did the last time I messed with it.

You can see part of the License info page as the lead-in graphic. Quite naturally, it doesn’t show any license keys. But it does show which ones are available, when they come up for renewal, and more. It also offers controls to add more info or revoke the license for some current installation. Nice!

Better Use from Managing Macrium Reflect Keys

Indeed, the key list now shows status, and provides controls to give each one a ‘friendly name.’ For those of mine in actual use right now, I assigned the associated machine name. That lets me know exactly which PC has which license, which is just what I want. The other licenses show “Available” which tells me I can use them if I want to.

When I tried to free up one license, however, instead of allowing the “Reset License” operation to proceed (that’s what Macrium calls it), it asked me to submit a support ticket. So that’s what I did. I’ll be interested to see what kind of response that engenders, and how soon it appears.

The Round Tuit Has Arrived!

I’ve been meaning to do this for 6 months or more. But I’m glad I’ve gotten my licenses organized. I’m even gladder to use the ‘Friendly Name’ feature to show me which PC is using which license. I plan to stay in that habit going forward. I also plan to install another copy on AsusSnap (my lone Snapdragon X based laptop right now) because Reflect X is unusally adept and speedy at backup on such CPUs.

Here in Windows-World, it’s not always about solving problems and fixing things. Sometimes, it’s about making the time to keep things neat and orderly. I’m glad I got the backup act together here. I’m sure I’ll find other, similar tasks to tackle, when I have time. Stay tuned: I’ll tell you all about it.

That Was QUICK! Note Added 1 Hr Later

The response from Macrium was as quick as such things get. It’s already fixed. They didn’t tell me why I couldn’t reset the key myself, but they did reset it for me. Now that’s what I call great service. And now, I’ve got six (count ’em: 6) Macrium Reflect X licenses to play with. A truly happy ending: thanks Francisco (name of service agent who handled my request)!

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Oh My Posh Shows Real ARM vs x64 Differences

August 20, 2026 Ed Tittel Leave a comment

Following the Oh My Posh documentation, I recently ran oh-my-posh font list on my ASUS Zenbook A14 . It’s a Qualcomm Snapdragon X Elite ARM64 machine running Windows 11. The result? Nothing. No output, no error, no interactive list, just a blinking cursor that eventually handed the prompt back to me. That same command works beautifully on all my x64 PCs and laptops. Thus, Oh My Posh shows real ARM vs x64 differences. Indeed, this sent me down a rabbit hole to figure out what OMP’s font subsystem does under the hood.

How Oh My Posh Shows Real ARM vs x64 Differences

When you run oh-my-posh font list on a working x64 machine, you get a list of available Nerd Fonts pulled live from GitHub. You can scroll that list, select a font, and it copies the name into the paste buffer for subsequent re-use. It’s helpful.

On my ARM64 Zenbook, none of that renders. The command exits silently. No crash, no error code, no partial output. That silence is itself a clue.

Inside the Oh-My-Posh Font Subsystem

OMP is written entirely in Go, and its font subsystem layers several platform-specific APIs and third-party frameworks. Understanding what those are and how they work explains why ARM64 falls short.

The first dependency is Bubble Tea a terminal oriented display and interaction UI. OMP’s font commands use Bubble Tea’s program model to launch, render, and manage the font list. Bubble Tea drives the terminal via ANSI/VT escape sequences and calls into Go’s golang.org/x/term package to manipulate terminal raw mode. On x64 Windows, Windows Terminal’s VT rendering pipeline handles these sequences without issue. On ARM64, subtle gaps in how the ARM64 console host processes certain VT sequences — particularly around alternate screen buffers and raw-mode toggling — can cause Bubble Tea’s rendering loop to fail before it draws a single line.

The second dependency is a live HTTPS call to the Nerd Fonts GitHub Releases API, which is how OMP fetches the current font list. This call goes out over Go’s standard net/http TLS stack. On ARM64, Go’s TLS implementation compiles natively, but the ARM64 binary links against a slightly different set of system crypto libraries. If that HTTP call fails silently, owing to a timeout, a TLS handshake hiccup, or a missing response, Bubble Tea never receives the data it needs to populate the list, and the program exits with nothing to show.

The third set of dependencies covers font installation: GDI32’s AddFontResourceW function (called via Go’s syscall and unsafe packages), Windows Registry writes through golang.org/x/sys/windows/registry, and a PostMessageW broadcast carrying WM_FONTCHANGE to notify the shell that new fonts are registered. These are the plumbing that oh-my-posh font install uses after the list is displayed. They are less relevant to the silent-exit problem, but they represent additional surfaces where ARM64’s native API behavior diverges from x64.

Where ARM Falls Down (or Out)

The core issue is that OMP’s font tooling was developed and battle-tested on x64 Windows. The Bubble Tea TUI path, the live GitHub fetch, and the GDI32 font registration flow all work reliably there. ARM64 Windows is a native platform now — not emulation — but the console host, terminal rendering, and system library behavior still carry edge cases that x64 does not.

Bubble Tea’s dependency on terminal raw mode and VT escape handling is especially fragile on ARM64 because Windows Terminal’s ARM64 build has historically lagged behind x64 in VT conformance. A Bubble Tea program that initializes correctly on x64 can silently short-circuit on ARM64 if golang.org/x/term‘s raw-mode call returns an unexpected result, causing the event loop to spin zero times and exit.

The irony is that OMP itself — the prompt rendering engine — works great on ARM64. The font management tooling sits on a different, more complex stack, and that stack exposes the seam between x64-matured tooling and an ARM64 Windows environment that is still catching up.

Takeaways for ARM Users

If you hit silent output from oh-my-posh font list on an ARM64 Windows machine, you now know it is not user error. It’s a real platform gap rooted in Bubble Tea TUI compatibility, live HTTP fetching, and ARM64 console API edge cases. The workaround for the moment is to install Nerd Fonts the old-fashioned way: grab the zip directly from the Nerd Fonts GitHub releases page and drop the TTF files into your user fonts folder manually. It’s not as elegant as OMP’s interactive installer, but it gets the job done.

This kind of difference is exactly why I find ARM Windows fascinating. The platform is capable, but it still surfaces small, instructive wrinkles like this one. Though I’ve seen nothing to make me question my investment in ARM hardware, oh-my-posh font list returning nothing is about as vivid a demonstration as I have seen of possible impacts of platform differences. That’s a thing worth watching out for, here in Windows-World.

Note: Only newer OMP versions (30.X.X) and higher support the font list capability. If you’re run the bog standard version on x64 (v29.0.2) you won’t see it, either. Winget should get the latest version (30.6.5) into its pipeline soon, after which you can see it, too. On the right kind of PC, anyway…

Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11, Windows Update

The Incredibly Bogus MSI BIOS Update

August 19, 2026 Ed Tittel 2 Comments

Windows Update pinged me yesterday, August 18, with a firmware notification: my MSI motherboard had a BIOS update available. My reaction was less “Great, let me install that…” and more “Wait! I just did.” The week before, I’d downloaded MSI’s latest BIOS package, copied it to a FAT32 USB drive, booted into MSI’s M-Flash utility, and flashed the thing the old-fashioned way. It worked perfectly. So why was Windows Update acting like none of that had ever happened? Thereby hangs the tale of the incredibly bogus MSI BIOS update. Here goes…

Hunting Down the Bogus MSI BIOS Update

The “bogus” here isn’t the update itself. Indeed, Windows Update found it and sought to deliver it. What was bogus was any awareness on WU’s part that I’d already installed it. When I flashed the BIOS using MSI’s UFD-based utility, that transaction happened entirely outside of Windows. No registry entry. Windows Update history records missing. No UEFI firmware capsule delivery for WU to track. As far as Windows Update was concerned, the update had never been applied, and it was doing its best to make sure I got it.

I confirmed the BIOS version in the UEFI settings. Indeed, it matched the version WU was offering. I checked Windows Update history: no entry for the flash, naturally. Optional updates, Driver updates: WU really wanted me to install this update. So I did, and of course it failed because MSI is smart enough to refuse a second install of the same UEFI version (I’ve had this happen on Lenovo PCs/laptops as well).

WU Remains Oblivious to OOB BIOS Updates

Windows Update tracks firmware updates it delivers itself. Typically, they come via UEFI firmware capsule updates. Those hand off to the firmware installer, and WU records the update in its history database. When you flash a BIOS using a manufacturer’s standalone tool (e.g. MSI’s M-Flash, a DOS-based utility, or a UFD flash from UEFI) Windows is completely out of the loop. There’s no handshake, no callback, no “hey, Ed already did this” signal.

The result: WU sees the target BIOS version, compares it against its own records (which show nothing). It concludes the update is needed. It’s not wrong, exactly. It just doesn’t know what it doesn’t know. And because the update failed anyway (I couldn’t figure out how to kill the pending item before it was applied, even with Copilot’s help) it appeared every time I checked updates in WU.

Until I hid the update it kept trying and failing to install after a mandatory restart. Vexatious!

PSWindowsUpdate Hides the Bogus Offer

For this case, the solution wasn’t to install the update again. Reflashing a BIOS that’s already current is unnecessary and might cause problems. The goal was to tell Windows Update, in terms it would respect, to quit offering that item. That’s a job for the PSWindowsUpdate module from the PowerShell Gallery.

I imported the module, enumerated all pending updates to confirm the BIOS entry was there, and then hid it. The complete sequence is in the lead-in graphic, but here it is in text form for easy access (info following # is purely descriptive and need not be entered):

Import-Module PSWindowsUpdate #Invokes PSWU cmdlet set Get-WindowsUpdate -MicrosoftUpdate #Calls WU for upd chk Hide-WindowsUpdate -Title "Micro-Star..." #Hides MSI upd

You can use the Title or the KB number for an update to block it. Then you can use the Get-WindowsUpdate -MicrosoftUpdate -IsHidden cmdlet to show you if your efforts succeeded.

Problem Solved, Mostly

After running Hide-WindowsUpdate, Windows Update stopped flagging the firmware update. No more notifications, no more badge on the WU icon, no more politely worded insistence that I was a BIOS version behind. A quick recheck of Get-WindowsUpdate showed a clean list.

One thing: hiding an update using PSWindowsUpdate is reversible. You can unhide it later with Show-WindowsUpdate if you ever want WU to see it again. And if you’re in the opposite situation (WU is offering a BIOS you genuinely haven’t installed), the Install-WindowsUpdate cmdlet handles that well. Either way, PSWindowsUpdate gives you control that the standard WU interface simply doesn’t.

Here in Windows-World, it’s always something. This time, it was a weird and unwanted BIOS update. Whatever it may be next time, count on me to tell you about it, and how to work with, through, or around it as circumstances might require. Cheers!

Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11

Where’s My WIMMount?

August 14, 2026 Ed Tittel Leave a comment

There I was on my primary desktop Flo6, running what should have been the most unremarkable task in a Windows admin’s day: mounting a WIM image offline with DISM. The command ran. Nothing blew up dramatically. It just… sat there, and did nothing. No cryptic error code, no helpful message, and zero indication of what went sideways. Welcome to the world of WIMMount driver missing DISM failures — where the tool you depend on vanishes without so much as a farewell note. Hence the question: “Where’s my WIMMount?”

DISM mount failures are maddening precisely because they leave no obvious breadcrumbs. You stare at the console, you re-read the command three times over, and everything looks good. Spoiler: the problem isn’t syntax. It’s something deeper and darker. Let me explain…

“Nowhere” Answers “Where’s my WIMMount?”

WIMMount, aka winmount.sys, is kernel-mode filter driver. Windows uses it to mount WIM (Windows IMaging format) files as virtual volumes. It’s the plumbing behind the scenes that works with DISM to let you mount, unmount and operate on images to inspect them, analyze them, or change them. Indeed the driver does the heavy lifting with images at the file system level.

Without WIMMount, mount operations fail with errors like 0x8007007b (“filename, directory name, or volume label syntax is incorrect”) or 0x80070002 (“system cannot find the file specified”). Neither error message tells you “hey, your kernel driver is gone,” which is half the problem. The driver ships both with the Windows ADK (Assessment and Deployment Kit) and, on most builds, inside Windows itself.

Diagnosing the Problem on Flo6

My first instinct was stale mount points. I’ve been burned by those before. So I ran DISM /Cleanup-Mountpoints from an elevated prompt. No joy — it completed cleanly and changed nothing.

Next stop: component store health. Running DISM /Online /Cleanup-Image /ScanHealth returned errors suggesting corruption in the component store itself. Interesting, but not yet the smoking gun.

Then I ran the command that cracked the case open: sc query wimmount. The response was interesting: a big fat nothing. Further investigation showed the service existed nowhere. Indeed, the WIMMount driver was entirely absent from Flo6. Not stopped. Not disabled. Gone. A quick peek at HKLM\SYSTEM\CurrentControlSet\Services\WIMMount in the registry confirmed it: the key didn’t exist. No driver, no service, no mount. Mystery illuminated, though the hard work still lay ahead.

Repair Attempts — What I Tried

First, I reinstalled the Windows ADK, hoping that would drop wimmount.sys back into place. Setup completed without complaint. But running sc query wimmount again afterward returned the null response. The binary was still missing from C:\Windows\System32\drivers\.

I got creative and tried manually registering a service entry: sc create wimmount binPath= "C:\Windows\System32\drivers\ wimmount.sys" type= kernel. The service record was created, but starting it threw error 2 — “The system cannot find the file specified” — because the .sys binary itself was nowhere on disk. You can’t register a ghost.

I ran SFC /scannow, which found and repaired a handful of files. DISM was not one of them; wimmount.sys apparently isn’t tracked by Windows File Protection on this build. I then tried DISM /Online /Cleanup-Image /RestoreHealth — it ran to completion but didn’t restore the missing driver either. The conclusion was unavoidable: the driver binary and its registry entries had been removed or never correctly installed, perhaps a casualty of a failed or partial ADK setup, or an aggressive third-party cleanup utility that decided wimmount.sys looked expendable.

Ultima Ratio Regum: Windows Reinstall

At this point the path forward became clear, if a little painful. With the WIMMount binary missing, no repair tool (e.g. ADK reinstall, SFC, or DISM RestoreHealth) would bring it back. The component store itself must have been partially corrupt, which ruled out any confidence in an in-place repair of individual files.

I went with an in-place upgrade repair install to preserve apps and data. I used Settings > System > Recovery > Reinstall Windows. After the reinstall, I ran sc query wimmount immediately — STATE: STOPPED. DISM mount commands worked on the first try (and STATE changed to RUNNING). The entire diagnostic-and-repair saga, start to finish, consumed the better part of a day that a reinstall would have resolved in under an hour.

Lesson learned, yet again: when a kernel-mode driver disappears entirely from the system, a reinstall is almost always faster than hunting down a manual fix. The math rarely favors the manual route.

If your DISM mount commands start failing and you can’t figure out why, make sc query wimmount the second command you run. Like, immediately after the obvious syntax check. Ruling out a missing WIMMount driver takes fifteen seconds and can save you hours of chasing component-store rabbit holes. wimmount.sys is a small but essential cog in the DISM machinery. When it’s gone, DISM mount abilities suffer, too.

Here in Windows-World, the little things sometimes matter a lot. This was one of those times. I’m glad to have survived!

Hyper-V and VMs, Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11

The Dog Ate My Boot UFD

August 13, 2026 Ed Tittel Leave a comment

I’ve been trying to document how to repair recovery media when MS updates its VBS boot policy (as happened with Tuesday’s updates). Instead I’ve been fighting with UFD oddities that keep me from making the changes I need to bring them into line with said new policy. I’m feeling flustered and flabbergasted by an improbable series of setbacks, which is why I’m saying “The dog ate my UFD.” Honest: it kind of did.

Digging Into Why the Dog Ate My Boot UFD

As it turns out, the first setback was Smart App Control (SAC). It’s a Windows 11 security feature that evaluates application reputation through Microsoft’s cloud-based Intelligent Security Graph before allowing anything to run. When I tried to mount an image using DISM, it kept citing a permission block. Media checks showed no blocks, so it turned into a “whack-a-policy” hunt.

Long story short: my research suggested that turning SAC off might fix things. Alas, it didn’t help my problem. So I had to keep looking.

Next Suspect: HVCI

Once I worked around SAC (more on that in a moment), I ran into obstacle number two: HVCI, which stands for Hypervisor-Enforced Code Integrity. Microsoft also calls it Memory Integrity, and you’ll find it under Windows Security > Device Security > Core Isolation. HVCI runs kernel-mode code verification inside an isolated Virtualization-Based Security (VBS) enclave. It’s essentially a walled-off compartment that the rest of the OS can’t touch. On Flo6, HVCI was enabled by default, which is typical in most new Windows 11 installs.

Here’s the rub: many bootable UFD environments load kernel-mode drivers that predate HVCI’s signing requirements. That goes double for older Windows PE (Preinstallation Environment) images. When HVCI sees a driver it doesn’t recognize or trust, it rejects it. The UFD boot process stalls or silently falls back to the local drive. This is by design, not a bug (I keep telling myself that). Unfortunately, that design choice has zero sympathy for the guy who just wants to test a drive image before his second cup of coffee.

Turning it off didn’t help things, either. So I’ve still got a problem, and must keep looking for the cause. Sigh.

Still No Joy…

I still need to mount a windows image (.wim) file so I can fiddle with its bits to make it current. But first, I have to figure out how (or possibly, where) to make this happen. It comes in service of a story to document how to repair or replace outmoded UFD’s for repair, recovery, restoring backups, and so forth. That’s important stuff, but it’s not surrendering its secrets easily.

I wish I knew exactly what I needed to do. I’m still figuring it out. Since I’ve not succeeded yet, consider this an interim status report. Here in Windows-World, an inordinate amount of head-scratching is sometimes required to fix things.

Stay tuned! When I do get it sorted, I’ll post again here. It’s a fascinating fix hunt, but I’ll be glad to get to the end of this road.

Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11, Windows Update

Pending Update Hangs WinGet

August 12, 2026 Ed Tittel Leave a comment

Yesterday was Patch Tuesday (Aug 11), so I got a change to watch something go down I’d not yet seen. Just before lunch, I fired off a quick winget upgrade --all --include-unknown. I figured it would chew through those updates in time for me to switch to sandwich construction. Wrong! Instead, WinGet got stuck and sat frozen, spinning its wheels on a package install. Only slowly did it dawn on me I’d just gone through the monthly update cycle. Further inspection showed … sure enough … a pending update hangs WinGet (or rather, a pending restart from said update gums up the works). Let me explain…

Why Pending Update Hangs WinGet

The most common culprit is a prior installation that never cleanly resolved or completed. Windows Package Manager tracks install state in its internal database, and if a previous run was interrupted (by a power cut, forced close, network drop, etc.) that package can stay flagged as “installing” or “pending.” As a result, subsequent upgrade attempts collide with that ghost state and stall out.

In addition, App Installer (Microsoft.DesktopAppInstaller) itself may be out of date. WinGet is delivered as part of App Installer via the Microsoft Store, and an outdated build can exhibit hang behavior. That goes double after a major Windows update reshuffles underlying framework dependencies. Therefore, ruling out a stale WinGet client is always step one before you go deeper.

Source index staleness is another common trigger. WinGet pulls its package catalog from indexed sources. When those indexes go stale or become partially corrupted, upgrade queries can time out or loop indefinitely. Finally, UAC and permission conflicts can silently block the installer process. This happens mostly often if you’re running without elevation or if a previous elevated session left a lock on a staging directory. Watch for exit code 0x8A15000F (installer still running). That’s Windows Package Manager’s way of telling you it thinks something is already in flight. (See the WinGet exit codes reference for deets.)

What happened to me yesterday was that the pending restart left some unresolved packages in limbo, including the AppInstaller itself. A quick restart took care of those gotchas, and allowed WinGet to do its thing unimpeded.

Fixing a WinGet Pending Update Hang

Work through these fixes in order. Each one resolves a progressively deeper layer of the problem, so start at the top and stop as soon as WinGet is moving again.

winget upgrade --all --include-unknown winget source update Install-PackageProvider -Name NuGet -Force Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery Repair-WinGetPackageManager -Force -Latest winget upgrade --id --silent winget source reset --force

And, of course, if it’s Patch Tuesday, or some kind of Windows Update has been applied recently, check for an restart notification first. If one is pending, get it out of the way. That’ll keep it out of WinGet’s way, too. Here in Windows-World, it never pays to overlook the obvious. Cheers!

Tip: Check the Logs
When a hang is stubborn, the logs will tell you exactly where the process is choking. Run winget --info to find your log directory, or navigate directly to: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_ 8wekyb3d8bbwe\LocalState\DiagOutputDir (reassemble onto single line to cut'n'paste, or do like me and point Everything at DiagOutputDir). You can also append --logs or --verbose-logs to any WinGet command to capture a full diagnostic trace of that specific run.

Insider stuff, OneDrive, Recent Activity, WED Blog, Windows 11

OneDrive Photos Proves Elusive

August 11, 2026 Ed Tittel Leave a comment

Given the considerable flap that’s erupted online about MS dropping a OneDrive Photos app willy-nilly on Windows PCs recently, I’m having trouble finding same. Indeed, on the 8 PCs running Windows 11 here at Chez Tittel right now, it pops up on only one of them. It could be present on another, but I can’t tell right now. Thus, for me at least, finding OneDrive Photos proves elusive if not outright mysterious.

Why OneDrive Photos Proves Elusive

For one thing, there is no separate “OneDrive Photos” app, all the recent flap nothwithstanding. It’s actually part of the OneDrive executable itself OneDrive.App.exe. That said, it shows up on Windows 11 PCs with work and school accounts, even though it works only with personal MSAs. Thus, uninstalling it on corporate and school accounts is a real concern. For examples, see the coverage at WinAero, Windows Central and Windows Latest for a good sense of what’s been shaking.

I wanted to see the gosh-darned thing, but had trouble finding it. Turns out you have to be running version 26.139.0720.007 (it’s a preview version) AND you must be running a personal MSA for it to show up as such. Then you login into onedrive.live.com with said MSA, click the photos button at top left of onedrive login home and Presto! there you are.

As for uninstalling it if you can’t use it? That’s coming, but not quite here yet. But before I uninstalled it, I wanted to see it in the first place. Thus, as Murphy would have it, first I had to find it. Gosh! I have to laugh at the things that occasionally happen here in Windows-World. It’s a real gut-buster, sometimes…

Backup/Restore, Cool Tools, Insider stuff, Recent Activity, WED Blog

Lenovo Recovery UFD Works, But…

August 7, 2026 Ed Tittel 1 Comment

I’ve been documenting the path away from a stuck (and incorrect) Dev Channel build to a clean install of production 25H2 on my ThinkStation P3 Ultra for nearly two weeks now. Today’s episode is a simple one. After problems getting the device to boot to any UFD, I ordered a Lenovo factory recovery USB directly from Lenovo (see my “It’s the Layout, Stupid” post for more info). Last night, it arrived in a plain padded envelope, and I inventoried it. That’s the whole story. Except, of course, there’s more to it than that. I’ll explain…

Why Say: Lenovo Recovery UFD Works, But…

The first thing I noticed when the envelope hit the desk was the lack of any Lenovo branding on the drive itself. What I pulled out was an ADATA UVI128 32 GB USB 3.2 Gen 1 flash drive (available for about US$8 online; old enough to be unavailable from big US e-tailers). No ThinkStation logo, nor Lenovo red trade dress. No embossed branding of any kind. For a machine that runs somewhere in the neighborhood of four grand, I appreciate the transparency. It’s just a recovery drive, nothing more.

What’s On That UFD, Anyway?

I plugged it into Flo6 (my main Windows 11 PC here at Chez Tittel) and ran a quick PowerShell inventory. That let me see what I had in hand. These numbers came back: 26.41 GB used on a ~29.3 GB drive, with 2.86 GB free. Every major payload file was timestamped August 3, 2026, which tells me this was a fresh burn, not a dusty warehouse pull. That’s genuinely good to know.

7 Folders With Lots of History

The folder structure is straightforward once you know what you’re looking at. At the root you get seven directories: \boot, \EFI, \mfg, \preboot, \RECOVERY, \SWWORK, and \tvtos.

\boot and \EFI handle dual-mode booting — Legacy BIOS and UEFI respectively, with \boot packing 30-plus MUI language files for good measure. \mfg carries manufacturing metadata and a document called W11_RUSB_TEMPLATE_64_DEV.docx that makes absolutely explicit what this thing is: a Windows 11 recovery set. It’s just manufacturing boilerplate, but as internal tells go, it’s a nice one — you can see exactly which template Lenovo’s recovery build team signed off on. \SWWORK is a staging scratch area, and it’s essentially empty.

The real substance lives in \RECOVERY and \tvtos. The \RECOVERY folder holds the actual image payloads — the largest being LCAFKQ2BA0.IMZ at 957 MB, which is the core Windows 11 OS image, plus fifteen or more companion .IMZ bundles covering P3 Ultra-specific drivers and Lenovo’s software suite. Familiar utilities ride along for the restore process: imagex.exe, bootsect.exe, bcdboot.exe, 7z.exe, and a few Lenovo-proprietary tools including hddcln.exe and rcadm.exe. \tvtos is where the bulk of the 26 GB lives. That’s home to the WinPE-based ThinkVantage OS environment, which is the preboot shell that actually orchestrates the whole restore operation.

Python 2.6 Drives the Lenovo Recovery Engine

Here’s where the archaeology gets interesting. The recovery orchestration engine living in \preboot runs on Python 2.6. Python 2.6 reached end-of-life on October 29, 2013 — nearly thirteen years ago. It has not received a security patch since Barack Obama’s first term. I resisted the urge to feel old about this. Mostly unsuccessfully.

The image format is equally vintage. Those .IMZ files are Lenovo’s proprietary compressed image format. Indeed, there’s no public tooling to mount, extract, or meaningfully modify them. They travel with .CRI catalog companions and are handled entirely by Lenovo’s own restore .exe files. You are explicitly not intended to poke around. You are meant to click Restore and walk away while the progress bar does its thing.

ThinkVantage itself tells a similar story. Lenovo quietly retired the brand years ago, replacing it with Lenovo Vantage on the consumer side and Lenovo Commercial Vantage for enterprise. The preboot environment on this Lenovo factory recovery USB is frozen legacy infrastructure now past its expiration date. It’s functional, tested against this specific hardware configuration, and going absolutely nowhere. It works. It just works using technology that’s old enough to have its own nostalgic Reddit threads.

I Meant What I Said, and I Said What I Meant

All that said: it does the job. Boot it using F12 at the Lenovo splash screen, then select the USB from the boot menu. Bam! The ThinkVantage preboot environment launches and walks you through a factory restore of the P3 Ultra to its original Windows 11 configuration, complete with all Lenovo drivers and software. No internet connection required. MSA prompts, nada. No drama, either. On a machine this complex, that’s pretty cool.

The dual-mode boot support, confirmed by both \boot and \EFI folder trees, means the drive works whether the firmware is set to Legacy or UEFI mode. Coverage is thorough: Windows 11, P3 Ultra-specific drivers, the full Lenovo software bundle. All available on one generic flash drive in one plain envelope.

My verdict: label it clearly, drop it in the P3 Ultra’s machine folder with the rest of the hardware documentation. Then, treat this Lenovo factory recovery USB exactly as the break-glass emergency media it is. I wouldn’t try to explore the ThinkVantage environment for entertainment. Why not? Because it’s a straight-up restore wizard, not a sandbox, and it doesn’t reward curiosity. And don’t get any ideas about cracking open those .IMZ files, either. You’ll need AI or serious programming chops in Python 2.6 to get anywhere.

That’s not my thing. Here in Windows-World, I’m OK with treating a black box as such. Shoot! I’m just surprised it came on a USB-A UFD. After my local success only with the USB-C Data Traveler to bring the P3 Ultra back to life, I’d expected the same kind of UFD to show up from Lenovo. I was wrong…