Category Archives: Windows 11

Insider stuff, PowerShell, Secure Boot, WED Blog, Windows 11

Updating Outdated Win11 Boot Media

August 17, 2026 Ed Tittel Leave a comment

There’s a scenario that may feel familiar to plenty of Windows power users and IT admins. You’ve got a USB flash drive, aka UFD, sitting on your desk. You carefully imaged it months ago using MCT, or a backup too, or Rufus, or whatever. It booted perfectly, it installed or ran cleanly, and life was good. Fast forward to today: alas, that once-trusty UFD is probably out of date. In fact, if you try to boot using that UFD, you may get a “Secure Boot Violation” error message from UEFI and nothing more. That’s why updating outdated Win11 boot media is a real maintenance item, especially after Patch Tuesday rolls through and reshuffles key files inside the Windows boot chain.

Why bother? Because Patch Tuesday updates don’t just patch the running OS on your machines. They also advance critical files that get embedded in installation media — things like Secure Boot policy manifests, component catalogs, and EFI boot binaries. Hence, a UFD built on a pre-patch image may carry stale versions of those files. Indeed, subtle boot-time validation mismatches are possible. Worse, your installation media might silently enforce an older policy against a fully updated target system.

In this post, I’ll walk through exactly what changes, which files on your UFD need attention, and explain how to make things current, step by step. Spoiler alert: I also advise against such repairs unless they’re absolutely necessary. It’s much easier to generate fresh boot media than to repair outdated UFDs.

Why Updating Outdated Win11 Boot Media Matters

One might think of Patch Tuesday as a monthly ritual that involves rebooting workstations and crossing your fingers that nothing breaks. Fair enough. However, other side effects come from updates. That is, they reach inside the Windows installation ecosystem and bump version numbers on files that govern how setup media validates and boots a system.

The most relevant example for this post, and the primary driver for updating outdated Win11 boot media right now, is SkuSiPolicy.p7b. The most recent Patch Tuesday advanced this file from version 3.0.0.16 to version 3.0.0.17. That’s a tiny increment, but carries real significance.

So, what exactly does SkuSiPolicy.p7b do? In short, it’s a Secure Boot SKU policy file. It governs which Windows editions (SKUs =Home, Pro, Enterprise, Education, and so on) that Secure Boot views as trusted and bootable.

When the running OS expects version 3.0.0.17 and your UFD’s boot chain presents version 3.0.0.16, you get validation mismatches. Those mismatches may not always produce a hard error, but they represent a policy drift you don’t want living in your production boot media. Worst case: no boot with the dread “Secure Boot Violation” error message showing (see my August 4 post for an illustration).

Bottom line: whenever SkuSiPolicy.p7b advances, it’s time to audit your UFDs. You may also end up having to update or replace/regenerate them.

Possible UFD Deltas After Patch Tuesday

Here’s the thing: SkuSiPolicy.p7b doesn’t live in just one place on your UFD. It lives in multiple places. Some are obvious, others live inside image files. Plus, other boot-chain components may also need refreshing. The following table lays out that landscape, where the numbered list that follows briefly explains each item.

UFD Component	Location on UFD	Affected by SkuSiPolicy Bump?	Action Required
SkuSiPolicy.p7b	\sources\	Yes — primary location	Replace with updated version
boot.wim	\sources\	Yes — embedded in index:2	Mount, update, unmount/commit
install.wim / install.esd	\sources\	Yes — per-edition indexes	Mount each index, update, commit
efisys.bin / efisys_noprompt.bin	\boot\	Occasionally	Replace if ISO version is newer
bootmgr.efi / bootx64.efi	\efi\boot\ or \boot\	Occasionally	Replace if ISO version is newer
cdboot.efi	\boot\	Rarely	Check version; replace if needed
winpe.wim / WinRE.wim	Varies (recovery partition)	Yes — if recovery env. included	Mount, update, commit

Working through the List

Now let’s go through each item in the same order as the table:

p7b (\sources\SkuSiPolicy.p7b on the UFD): This is the standalone Secure Boot SKU policy file that Windows Setup reads directly during the installation process. As noted, this file advanced from version 3.0.0.16 to 3.0.0.17 on the most recent Patch Tuesday. This is the clearest, most unambiguous indicator that your boot media needs updating or replacing. You must replace it with the current version, which you can extract from a freshly downloaded Windows 11 ISO or from a mounted updated WinPE image.
wim (\sources\boot.wim): This is the WinPE and Windows Setup environment image. It contains two indexes: index:1 is the minimal WinPE environment (the initial RAM disk boot stage), and index:2 is the full Windows Setup environment. Both indexes embed their own copy of SkuSiPolicy.p7b inside \Windows\System32\. Index:2, in particular, participates in Secure Boot policy enforcement during setup and therefore should be updated. Index:1 is discussed separately later in this post.
wim / install.esd (\sources\install.wim or \sources\install.esd): This is the main OS image that actually gets deployed to the target drive. Each edition index (Home, Pro, Enterprise, etc.) embeds its own copy of SkuSiPolicy.p7b inside \Windows\System32\ within the image. Therefore, each applicable index needs to be individually mounted and updated. Note that install.esd files are compressed and cannot be mounted directly — they must first be converted to install.wim format using DISM’s /Export-Image with /Compress:none before mounting.
bin / efisys_noprompt.bin (\boot\ folder): These are EFI boot sector binary files. They are not directly version-stamped by SkuSiPolicy.p7b changes; however, when a cumulative update also updates the broader boot chain, newer versions of these files may ship in the refreshed ISO. Consequently, it’s worth doing a file-date comparison between your UFD’s copies and those in the freshly downloaded ISO.
efi / bootx64.efi (\efi\boot\ or \boot\ folder): The EFI boot manager binaries. The same considerations apply as for efisys.bin: they don’t change with every Patch Tuesday, but when they do advance, you’ll want the fresh copies on your UFD. Always compare versions against a current ISO before deciding whether to replace.
efi: This EFI binary handles optical-media boot paths. If your UFD was created from an ISO (as most are), this file is present. It is, however, less commonly updated than the other EFI binaries. Worth checking, but don’t lose sleep over it.
wim / WinRE.wim — If your UFD includes a Windows Recovery Environment, that image also embeds SkuSiPolicy.p7b. The update workflow is identical to the boot.wim process: mount the image, overwrite the policy file inside \Windows\System32\, commit, and unmount.

Note

Not all of these components will change with every Patch Tuesday. The SkuSiPolicy.p7b version bump is your clearest indicator that a media refresh is warranted. On August 11, for example, the version jumped from 3.0.0.16 to 3.0.0.17. OTOH, EFI binaries may remain unchanged over several update cycles.

How to Update Each Affected UFD Item

Alright — here’s where we roll up our sleeves. The process is methodical, but it’s not complicated. Follow these steps in order, and you’ll have a fully refreshed UFD by the time you’re done.

Step 1: Gather Your Prerequisites

Before you touch any files, have the following at your disposal:

DISM — Built into Windows 10 and Windows 11. No additional download required. Run all commands from an elevated command prompt (right-click > Run as administrator). You MUST run powershell.exe (version 5.1) not PowerShell 7 (the app, or from inside Windows Terminal). Why? Because the DISM wim mount commands don’t work inside the newer PS version.
A fresh Windows 11 ISO — Download the current release directly from Microsoft’s Media Creation Tool at com/software-download/windows11, or from MSDN/VLSC if you have a volume license subscription. Do not use an ISO that’s more than a few weeks old — the whole point is to work from a current image.
Sufficient disk space — Mounting WIM images requires working space. Budget at least 15–20 GB on your working drive (typically C:\) for mount directories, working copies, and temp files.
A writable UFD — Sounds obvious, but double-check that your UFD’s write-protect switch (if it has one) is off. I’ve also learned the hard way that some UFDs work when building Secure Boot compliant media, and others don’t. If you get stuck, try switching to a faster, newer name brand device (I’ve had good luck with never Kington Data Travelers recently, for example).
Ownership and permissions — Some protected files on the UFD or within mounted images may require you to take ownership before overwriting them. We’ll cover that in detail in tomorrow’s post. It’s kind of a doozy!

Step 2: Extract the Updated SkuSiPolicy.p7b from the Fresh ISO

Mount the fresh ISO in Windows Explorer (double-click the ISO file — Windows will mount it as a virtual drive, typically D:\). Then, navigate to D:\sources\ and copy SkuSiPolicy.p7b to a working folder on your local drive. For example:

mkdir C:\work copy D:\sources\SkuSiPolicy.p7b C:\work\SkuSiPolicy.p7b

This extracted file is your authoritative source for all subsequent update steps. Keep it handy — you’ll be copying it into several locations.

Step 3: Update the Standalone SkuSiPolicy.p7b on the UFD

This is the simplest step. Simply overwrite the existing file in \sources\ on your UFD. Assuming your UFD is drive E:\:

copy /Y C:\work\SkuSiPolicy.p7b E:\sources\SkuSiPolicy.p7b

The /Y flag suppresses the overwrite confirmation prompt. Done. One location down, several to go.

Step 4: Update boot.wim (Index:2 — Windows Setup)

This requires DISM to mount the image, copy in the updated policy file, and then commit the changes on unmount. First, create your mount directory:

mkdir C:\mount\boot

Then, mount index:2 of boot.wim from your UFD:

Dism /Mount-Image /ImageFile:”E:\sources\boot.wim” /Index:2 /MountDir:”C:\mount\boot”

Next, copy the updated SkuSiPolicy.p7b into the mounted image’s \Windows\System32\ folder:

copy /Y “C:\work\SkuSiPolicy.p7b” “C:\mount\boot\Windows\System32\SkuSiPolicy.p7b”

Finally, commit and unmount:

Dism /Unmount-Image /MountDir:”C:\mount\boot” /Commit

Warning

Never terminate a DISM mount session midway. If your session is interrupted (e.g. power loss, unexpected reboot) use Dism /Cleanup-Mountpoints to recover before attempting to remount. Partially committed mounts can corrupt your WIM.

Step 5: Update install.wim (Each Edition Index)

The install.wim (or install.esd) update is the most time-consuming step, because you need to process each edition index individually. Start by listing the available indexes:

Dism /Get-ImageInfo /ImageFile:”E:\sources\install.wim”

This will show you something like Index 1 = Home, Index 2 = Home N, Index 3 = Pro, Index 4 = Pro N, and so on — depending on which edition set your ISO contains. For each index you wish to update, repeat the mount-copy-commit workflow:

mkdir C:\mount\install REM — Example for Index 3 (Pro): Dism /Mount-Image /ImageFile:”E:\sources\install.wim” /Index:3 /MountDir:”C:\mount\install” copy /Y “C:\work\SkuSiPolicy.p7b” “C:\mount\install\Windows\System32\SkuSiPolicy.p7b” Dism /Unmount-Image /MountDir:”C:\mount\install” /Commit

Repeat for each index. It’s tedious, admittedly — but it’s the thorough approach.

A note on install.esd: If your UFD uses install.esd rather than install.wim, you cannot mount it directly. Therefore, you must first export it to an uncompressed WIM:

Dism /Export-Image /SourceImageFile:”E:\sources\install.esd” /SourceIndex:1 /DestinationImageFile:”C:\work\install.wim” /Compress:none

Repeat the export for each index you need to update, then mount, update, and commit the resulting install.wim. When finished, copy the updated WIM back to your UFD (replacing the original ESD, or alongside it as a WIM if your media configuration supports that).

Step 6: Replace EFI Binaries (If Newer Versions Exist in the ISO)

Compare the file dates on the following pairs — ISO source vs. UFD destination — and replace only if the ISO version is newer:

D:\boot\efisys.bin → E:\boot\efisys.bin
D:\boot\efisys_noprompt.bin → E:\boot\efisys_noprompt.bin
D:\efi\boot\bootx64.efi → E:\efi\boot\bootx64.efi
D:\boot\bootmgr.efi → E:\boot\bootmgr.efi

If the ISO’s copies are dated more recently, copy them over. If they match, leave your UFD copies alone — there’s no point in replacing identical files.

Garlin’s check_bootmedia Reports a Non-Problem

Here’s the thing: if you run the check_bootmedia script — a tool from Garlin’s GitHub repo that inspects boot media for version consistency across boot-related files — you may encounter a flag that looks alarming at first glance in your freshly-updated UFD. Specifically, the script reports that boot.wim’s index:1 (the base WinPE environment) contains an older version of SkuSiPolicy.p7b than at index:2 (the Windows Setup environment) after you’ve completed Step 4 above. You can see its output for my updated UFD (Drive I:) in the lead-in graphic for this blog post.

Take a breath. This does not actually represent a real problem. Indeed, this UFD booted right into the Windows 11 installer (as it should). Here’s why the info may look scary, but isn’t:

What index:1 actually does: Index:1 in wim is the minimal WinPE environment — the initial RAM disk stage that loads just enough of an operating environment to hand control over to the Windows Setup process. It is responsible for loading drivers, initializing hardware, and presenting the early pre-Setup UI. It does not participate in Secure Boot SKU policy enforcement during a normal Windows installation.
Where SKU policy enforcement actually happens: The actual Secure Boot SKU policy enforcement — the part that p7b governs — occurs at the OS loader level. That means it relies on index:2 of boot.wim and the standalone \sources\SkuSiPolicy.p7b on your UFD. Both of those, as a result of Steps 2–4 above, are now current.
Why check_bootmedia flags it anyway: The script is thorough — admirably so. It compares p7b versions across all image indexes and the standalone sources copy, and reports any mismatch it finds. For completeness and consistency-checking purposes, that’s the right behavior. However, in practice, having an older SkuSiPolicy.p7b sitting inside index:1 of boot.wim creates no functional issue whatsoever during a Windows installation.
Can you update index:1 anyway? Yes, absolutely — and if strict consistency is important to you (perhaps for audit or compliance reasons), go ahead. Use the same DISM mount/update/commit workflow with /Index:1 instead of /Index:2. It won’t hurt anything.

Bottom Line

If check_bootmedia is the only tool reporting a version discrepancy, and the discrepancy is limited to boot.wim index:1, you can safely disregard that flag. Your media is functionally correct. The flag is informational — a cosmetic inconsistency, not a real-world boot problem. I had that situation pop up on a test UFD, and it booted into the Windows 11 Installer just fine (no Secure Boot issues presented).

Wrapping Up: Key Takeaways

Let’s bring it all home. If you’ve made it this far, you now have a solid handle on why updating outdated Win11 boot media matters, what files are involved, and fixed involved. Here’s the condensed version for your notes:

Patch Tuesday can advance p7b and other boot-chain files. The most recent update bumped SkuSiPolicy.p7b from version 3.0.0.16 to 3.0.0.17. That’s your cue to refresh your UFDs.
Multiple UFD locations are affected, not just \sources\. The policy file is embedded inside wim (index:2), inside each edition index of install.wim, and potentially inside recovery environment images as well. All those locations need fixing for a complete update.
The Garlin check_bootmedia flag for wim index:1 is interesting, not definitive. Index:1 doesn’t enforce Secure Boot SKU policy during Windows installation. You can update it for strict consistency, but it is absolutely not required for correct boot media behavior.
EFI binaries deserve a version check, not an automatic replacement. Compare bin, bootmgr.efi, and bootx64.efi from your UFD versus a fresh ISO; replace only if the ISO copies are newer.
Tomorrow’s post covers ownership and permissions for protected files. For good reason, MS goes out of its way to protect boot files and images. Thus, there are certain steps you must take before you can overwrite system-owned files inside mounted WIM images. Stay tuned: I’m writing a whole ‘nother post on this topic. Again: it’s a doozy, and taught me more about ICACLS than I ever wanted to know.
Keeping boot media current is a best practice for Windows IT admins and power users. Stale media isn’t just a minor annoyance — it’s a policy gap. A few DISM commands and twenty minutes of your time is all it takes to close it.

Ask Yourself: Is Repair Really Needed?

Determining repairs took me the better part of day, and then getting things fixed in Windows 11 installation media for the SkuSiPolicy version bump. I could’ve simply grabbed a fresh Media Creation Tool (MCT) from the download Windows 11 page, and built a new UFD in under an hour.

Now that I’ve been through this ordeal, I’ve learned a valuable lesson. Don’t fix a boot media UFD unless you absolutely must. If you can regenerate a fresh, new updated one, do that instead. It’s faster and much, much easier that way. Here in Windows-World, going the long way around sometimes underscores the value and importance of workable shortcuts. My advice: take this shortcut, if you can. Otherwise, you’ll spend real time going the long way!

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…

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

Spiffing Up P3 Ultra WinTerm

August 6, 2026 Ed Tittel Leave a comment

Having just restored the ThinkStation P3 Ultra Gen 2 to a clean, plain-vanilla Windows 11 image, I’m now tweaking things to make them comfortable and right. One of my primary targets for improvement is the command line. In turn, that has me spiffing up P3 Ultra WinTerm to get things the way I like them.

What Spiffing Up P3 Ultra WinTerm Entails

What follows is the four-layer stack I put together on the P3 Ultra to make Windows Terminal customization actually mean something. You can see the results in the lead-in screenshot above: a segmented Oh My Posh prompt, a rendered 7-Zip application icon courtesy of winget sixels, and a gloriously color-coded directory listing from Terminal-Icons. Here’s how it all fits together.

WinTerm Customization: Font Foundation

The very first thing I do after any clean Windows install — before the wallpaper, before the taskbar tweaks, before I remember I’m supposed to be “keeping it minimal” — is set up a proper terminal environment. On the P3 Ultra running 25H2, that meant opening Windows Terminal and immediately confronting the default Cascadia Mono font, which is fine in the way that a gas-station sandwich is fine. It works. You’re not going to brag about it.

The secret to this entire Windows Terminal customization stack is that absolutely everything else — the Oh My Posh prompt glyphs, the Terminal-Icons file badges, the whole visual language — depends entirely on a Nerd Font being the active terminal font. Without one, every single glyph-based feature renders with less pizazz. You get a terminal that looks like it’s having a small crisis. Not the aesthetic I’m going for.

My pick is CaskaydiaCove Nerd Font Mono v3.4.0 — the Nerd Fonts project’s officially patched version of Microsoft’s own Cascadia Code. That lineage matters. indeed, it looks completely native in Windows Terminal because it essentially is Cascadia Code, just supercharged with 10,000+ additional Nerd Font glyphs packed into the private-use Unicode ranges.

I installed it per-user to %LOCALAPPDATA%\Microsoft\Windows\Fonts, then promoted it system-wide since the P3 Ultra session was already running elevated. One JSON edit in Windows Terminal settings (hit Ctrl+Shift+, to open the file directly), setting “face”: “CaskaydiaCove Nerd Font Mono” inside profiles.defaults.font, and that foundation is laid.

OMP Puts Prompts Right

Oh My Posh (OMP) is the tool that turns my drab PS C:\Users\ed> prompt into a segmented, information-dense status bar that actually tells me things I want to know. In my current setup — visible in the screenshot — the left side shows my username (ed), the current directory, a key glyph, the terminal icon, and the last command’s execution time. The right side displays the shell name (pwsh) and a live clock. It looks and feels sharp. Frankly, it’s the main reason I get excited about a new terminal setup.

Speaking of execution time: the screenshot shows a 0ms result for a quick winget list –details 7zip run, which is gratifying. Less gratifying but no unexpected is the 990ms that appears on the subsequent dir command. That’s Terminal-Icons loading its full icon map on first call, not OMP behaving badly. Well. Mostly not OMP behaving badly. The 990ms is the price of a pretty terminal, and I have decided it is worth it in the same way I decided heated seats were worth it when I bought my last car. Once you have the temperature drops below freezing, the idea of going without feels almost uncivilized.

OMP installs cleanly via winget with winget install JanDeDobbeleer.OhMyPosh. Then, getting it running in PowerShell 7.6.4 (the version running on the P3 Ultra, as you can see in the startup banner in the screenshot) takes exactly one line added to your $PROFILE. That’s an oh-my-posh init pwsh call pointing at your chosen theme JSON. That’s it. Minimal friction, maximum visual payoff.

Winget Icons: Sixel Graphics Come to Life

Here’s the one that still makes me do a small double-take every time I see it: that 7-Zip logo in the terminal is not ASCII art. It is not a colored block approximation. It is the actual, rendered 7-Zip application icon, displayed as a real bitmap inside the terminal window, courtesy of sixel graphics support added to winget in Preview build 1.29.50 and later.

Important: Two Different Settings Files

Enabling sixels requires editing winget’s own settings file — opened with winget settings — not Windows Terminal’s settings.json. These are two entirely separate JSON files. Editing the wrong one produces a very confusing non-result, and I say that with the authority of someone who absolutely did exactly that on the first attempt.

Once you’re in the right file, the change is simple: add “visual”: { “enableSixels”: true } to the JSON, do a full restart of Windows Terminal (not just a new tab — a full close and reopen), and then run –winget list -details [packagename] to see the icon appear. Coverage is currently somewhere around 25–30% of installed packages — Win32 (exe/msi) apps show icons reliably. MSIX packages mostly don’t yet. But seeing 7-Zip’s logo materialize in a terminal window never quite gets old.

Terminal-Icons: Color-Coded Dir Listings

The final piece of the stack is Terminal-Icons. This PowerShell module by Brandon Olin transforms your Get-ChildItem output from a monochrome wall of filenames into a color-coded, glyph-annotated directory listing .. Bonus: it’s easier to scan at speed. Folders get folder glyphs in teal. JavaScript files get the JS badge in orange. Binaries, config files, images, and scripts each get their own visual treatment, all driven by the Nerd Font glyph library that CaskaydiaCove Nerd Font Mono v3.4.0 provides.

Installation requires a single PowerShell line: Install-Module -Name Terminal-Icons -Repository PSGallery -Force. Permanent activation requires adding Import-Module Terminal-Icons to your $PROFILE. After that, dir, ls, and Get-ChildItem all pick up the icons and colors automatically — no further configuration needed. It simply works, which in my experience is not always a given with PowerShell modules.

OK, I’m Happy Now…

Installing this stack — CaskaydiaCove Nerd Font Mono, Oh My Posh, winget sixels, and Terminal-Icons — took me about 10 minutes. The result is exactly what you see in that lead-in screenshot: a terminal that looks like it means business, with a prompt that tells me what I need to know, icons that let me spot my packages and files at a glance, and one very satisfying 7-Zip logo that I have already shown to more colleagues than strictly necessary. It is, as I said to myself at the time, a very spiffed-up terminal. Round Rock, TX never looked so good from a command line. Here in Windows-World, I count that as an accomplishment, of sorts…

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

Insider Preview Build Expiration

August 5, 2026 Ed Tittel Leave a comment

In today’s coverage at Windows Central, I found an interesting item. Indeed, the title is a little scary “Windows Insiders have one week to update their PCs, or else.” It seems that Insider Preview builds come with “flight certificates” that include an expiration date, and numerous builds will be hitting that date next Tuesday, August 11. Insider Preview build expiration comes with some gotchas, so it’s a good idea to update in advance to avoid them. Let me explain…

What Does Insider Preview Build Expiration Mean?

Thankfully, any Insider Preview expiration date is easy to find. If you look at the snippet of winver.exe output above, you’ll see it identifies itself as “[t]he Windows 11 Pro Insider Preview operating system…” It also provides expiration data, i.e. “Expires 10/31/2027 6:43 PM.”

As it happens, Microsoft embeds time-limited cryptographic certificates in every Windows Insider Preview build. These are called flight certificates, and when they expire, things get weird, fast. This post covers what flight certificates actually are, how to check whether your build has been renewed, and what happens if you let that clock run out.

Not Just a Pun: Flight Certificates

A flight certificate is a code-signing certificate that Microsoft embeds directly into every Windows Insider Preview build. The name comes from Microsoft’s internal terminology for Preview builds — “flighting” — the practice of distributing pre-release builds to rings of volunteer testers. Think of the certificate as both a seal of authenticity and a built-in expiration thing.

Both of the flight certificate’s jobs are straightforward. First, it authenticates that the preview build you’re running is genuinely from Microsoft. That is, it’s not some 3rd-party repackage of dubious origin. Second, it acts as a gentle but insistent timer. As the certificate approaches its expiration date, the system begins reminding you to update. Let it fully expire, and the nudging stops being gentle.

There are some things a flight certificate is not: it has nothing to do with product activation, your MSA, or installed apps and files. Your activation status is unaffected by certificate renewal. The cert lives at the build level, not the license level.

Flight Certificates Come and Go Regularly

Microsoft renews flight certificates routinely, with an updated cert inside each new Insider Preview build. What’s unusual about the current renewal cycle is its scope. Historically, certificate renewals have mainly been a Canary Channel issue. This time, the renewal covers all channels (Experimental, Beta, and Canary). That’s a broader reach than typical and tells us that the flight certificate now applies across all active Insider flighting channels.

Here’s the thing (and the reason for the clickbait style Windows Central article title). The old certificate expires August 11, 2026. For Beta Channel on 25H2, the minimum renewed build is 26220.9022, which has been available since July 31, 2026. If you’re on that build or later, you’re already good through October 2027.

If not, unpleasant things may happen to your PC if you don’t upgrade in advance. As the Windows Central article states: “You will also stop receiving automatic background updates once the flight certificate expires.” See next section for more icky details.

Finding Flight Expiration Info

Checking your expiration date takes about ten seconds. Press Windows key + R, type winver, and hit Enter. The About Windows dialog that pops up will show an Evaluation copy line near the bottom, followed by an expiration date. If that date is after August 11, 2026, congratulations — you’re already on a renewed build and can stop worrying.

If your date is on or before August 11, 2026, you’ll want to act before the deadline arrives. Here’s what happens if you don’t:

A persistent “This build will expire soon” watermark appears on your desktop. You can’t dismiss, minimize, or right-click it away.
Automatic background updates stop arriving. You fall off the flighting pipeline entirely.
The machine doesn’t stop working, but it does become an isolated island: no new Insider Preview builds, no flight certificate renewal, no path forward except a manual update (clean install).

The fix is mercifully simple. Head to Settings > Windows Update > Check for updates. Then, let it find and download whatever’s on offer, install it, reboot. One update cycle and you’re current. The renewed certificate ships with the build, the watermark goes away, and normal flighting resumes.

I’ll admit: I’ve watched cert expirations play out on test machines over the years. But this one genuinely caught me off guard — not because it snuck up on me, but because my Beta Channel machine had already sorted itself out entirely on its own before I’d even noticed there was a deadline to worry about. Silent competence from Windows Update. Here in Windows-World that counts as success.

Take the Long Way Home

August 4, 2026 Ed Tittel 5 Comments

I’ve been writing about Windows since version 3.1. I remember the floppy disk shuffle. I remember the joy of actually getting TCP/IP running on Windows for Workgroups. You’d think, after thirty-plus years, I’d have an easier time convincing my own workstation to accept a clean OS install. You would be wrong. Instead, in the words of Supertramp I had to “Take the long way home.”

Why I Had to Take the Long Way Home…

My go-to test PC is a Lenovo ThinkStation P3 Ultra Gen 3. It’s a legitimately serious machine, the kind with big SO-DIMM memory modules and a front panel that looks like it means business. It was humming along on Windows 11 24H2 without complaint. Then Microsoft quietly lit up the Windows 11 25H2 branch, and I figured: let’s do this. Simple in-place upgrade, twenty minutes, done by lunch. Instead, I got error code 0xC1900101-0x20017. Twice.

Driver Madness and Mayhem

If you’ve tangled with Windows upgrade failures before, you know that particular error code is frustratingly vague . Indeed, it lives in the SAFE_OS phase of the upgrade process, which means Windows has already swapped out its core OS files. But it chokes when it tries to apply drivers during the rollback-protected transition. In plain English: the driver stack fell over at exactly the wrong moment. I pulled the SetupDiag logs, confirmed it was a driver-related hang in the SAFE_OS phase, and stared at the ceiling for a while.

There’s a particular flavor of irony in being a professional Windows tech writer whose own PC refuses to cooperate with a Windows upgrade. I considered filing it under “job security” and moved on. After two failed in-place attempts, the logs were clear enough: a clean Windows 11 25H2 install was the only sane path forward. OK, fine. Now it’s time to go the long way, and do it the hard way.

Day 2: USB Media Chaos

I grabbed my trusty ADATA S102 32GB USB 3.0 flash drive — the one that has lived in my desk drawer for so long it practically has squatter’s rights. Next, I fired up Rufus to build a bootable installer. Rufus is usually my go-to. Usually.

This time, Rufus misdetected the hybrid image structure inside the Windows 11 25H2 ISO and produced a drive that my P3 Ultra’s UEFI couldn’t see. No error. No explanation. Just a polite boot menu that pretended the USB drive didn’t exist as a bootable option. Lovely.

Switch to balenaEtcher. Flash succeeds cleanly, the drive is recognized, the installer begins to load. Next, it promptly fails because install.wim inside the 25H2 ISO clocks in north of 5 GB. Alas, the FAT32 filesystem that UEFI boot requires has a hard 4 GB per-file ceiling. We’ve known about this limitation for years. It still bites people. It bit me.

The fix is DISM‘s /Split-Image switch, which carves the oversized WIM into a set of smaller SWM files. The command looks like this:

Dism /Split-Image /ImageFile:install.wim /SWMFile:install.swm /FileSize:4000

That produces install.swm, install2.swm, and however many additional slices it needs to keep every piece under the 4 GB limit. The elegant part: Windows Setup natively recognizes and reassembles SWM files on the fly when it finds install.swm sitting on the same drive. This calls for no extra flags, nor manual stitching. You just copy the SWM files onto your FAT32-formatted USB alongside the rest of the installer content and walk away.

For good measure, I also tried my Kingston DataTraveler 70 (USB-C) routed through my Acasis TB5010Pro USB4/Thunderbolt enclosure. That combination booted without a fuss, confirming the Thunderbolt chain was playing nicely with the UEFI boot stack. Good to know for the future.

Day 3: Secure Boot Shenanigans

With bootable media finally usable, I plugged in the drive, rebooted, and hit the BIOS. ThinkStation P3 Ultra runs Lenovo’s UEFI firmware, and if you’ve never spelunked the Lenovo workstation BIOS, know this: it is thorough. Very thorough. There are settings in there I’m fairly certain have never been touched by human hands.

The Secure Boot section alone offers three distinct modes: Setup Mode, User Mode, and Audit Mode. My machine had been enrolled in Secure Boot with Microsoft’s standard production key. That’s normal for a production workstation. Darned if the USB installer didn’t trigger a Secure Boot violation on the very first boot attempt. The system refused to load the installer, flagging it as untrusted.

So, I turned Secure Boot off (Disabled). That’s enough of a foothold to get the installer running. Post-install, I turned it back on and everything was properly locked down again. Annoying? A little. Correct behavior by the firmware? Absolutely.

I also needed to check the Startup tab in the BIOS to confirm boot device priority. As expected, the NVMe SSD was sitting above the USB device in the boot orde. That’s normally what you want and exactly what you don’t want when you’re trying to boot from USB. Bumped the USB device to the top, saved, rebooted. Whoever designed UEFI menus clearly never had to navigate one under deadline pressure. That said, at least the ThinkStation’s implementation is logically laid out once you know where to look.

Day 4: BitLocker’s Takes the Stand

By Day 4, I was feeling cautiously optimistic. The installer booted. The language selection screen appeared. Life was good.

Then Windows Setup looked at my target NVMe drive and politely informed me that it was BitLocker-encrypted and couldn’t be formatted without the recovery key. Of course it was. I had BitLocker enabled on the previous 24H2 install. That’s the default, after all. And, alas, I hadn’t decrypted the drive before starting this whole adventure. Classic.

I retrieved the BitLocker recovery key from my Microsoft account at account.microsoft.com/devices/recoverykey, then dropped into a pre-installation WinPE command prompt from the installer’s repair menu. Using manage-bde, I unlocked the drive with the recovery key and kicked off decryption. Depending on drive size and how much data is on it, this can take a while — budget accordingly.

Building Better Boot Media

With the drive decrypted, I used diskpart to nuke the partition table entirely and start clean:

select disk X
clean
convert gpt

This gives you a genuinely fresh GPT partition table, not just a reformatted volume with old metadata lingering in the corners. Worth the extra two minutes every time.

One more wrinkle worth flagging: the ThinkStation P3 Ultra uses a firmware TPM 2.0 via Intel PTT — the chip Windows 11 relies on for both BitLocker and Secure Boot attestation. Decrypting and wiping the drive before the fresh install prevents TPM ownership conflicts that can otherwise surface post-install, when Windows tries to re-seal the new BitLocker keys to the TPM and finds stale metadata from the previous OS. Getting ahead of that saved me a likely Day 5 headache.

Day 5: Clear Skies at Last

On Day 5, everything finally cooperated. Bootable media: sorted. Secure Boot mode: disabled. Drive: decrypted, wiped, and wearing a fresh GPT partition table. I plugged in the USB drive, rebooted, and watched the Windows 11 25H2 Setup wizard run from start to finish without complaint. It almost felt anticlimactic.

Post-install, the news got better. All Lenovo ThinkStation-specific drivers installed cleanly through Windows Update and Lenovo Vantage. I needed no manual INF hunting, nor saw any Device Manager yellow triangles. The NVIDIA professional GPU drivers (ThinkStation ships with a range of NVIDIA RTX options depending on configuration) updated through Windows Update without drama. The resulting install is fast, clean, and correctly locked down with Secure Boot and BitLocker re-enabled on the fresh volume.

Was it a walk in the park? Not even slightly. It was more obstacle course than OS upgrade — and every single obstacle was one I’ve written about in some form over the years. There’s a certain humbling quality to running face-first into your own documented knowledge. But the system at the end of it is genuinely better for the process: no upgrade cruft, no lingering driver artifacts from the 24H2 stack, no half-migrated settings. Just a clean Windows 11 25H2 install the way the OS was meant to be experienced.

A Looooong Way, Indeed

Supertramp was onto something: sometimes the long way is the only way home. At least when you take the long way, you learn every pothole in the neighborhood. Bonus: you’ll know exactly where they are next time.

Lessons Learned

Disable BitLocker before any OS swap. Decrypt the target drive before you ever launch Setup — it will save you a WinPE detour.
Split WIM files over 4 GB. Use DISM’s /Split-Image switch; Windows Setup handles the SWM reassembly natively.
Undo Secure Boot mode before booting to USB. Disable temporarily if your production keys block the installer.
Use diskpart to clean the target drive. A full clean and convert gpt ensures you’re starting with a genuinely fresh partition table.

This was a wild adventure, and one strewn with interesting gotchas. About par for the course, here in Windows-World. I hope not to walk this road again soon, but if I must, I’ll know how to dodge and duck. Sigh.

Cool Tools, Insider stuff, WED Blog, Windows 11

Understanding Windows Hardware Error Service

August 3, 2026 Ed Tittel Leave a comment

This morning, I ran across an item on the TechPowerUp news forum entitled “Microsoft Denies New Tracking Service in Windows 11.” I was intrigued to learn about Whesvc (the corresponding abbrevation and the name of a folder for storing telemetry data beneath C:\Windows\Temp). Its job, says Copilot is to handle “WHEA (Windows Hardware Error Architecture) events [such as] machine check exceptions, PCIe AER, CPU internal errors, bus timeouts,…” and more. The lead-in graphic shows what voidtools Everything found in that folder.

Surprisingly, Whesvc stuff eats nearly 1GB of storage space.

Why Understanding Windows Hardware Error Service Matters

This folder provides a place where WHESVC keeps information about various related events, including when:

a hardware error is raised
the system is preparing a WHEA telemetry bundle
the OS is about to submit a hardware error report
a WHEA LiveKernelEvent is generated
a PCIe or CPU error needs additional context

Yes, you can indeed report this stuff to Feedback Hub, but I find no documentation to indicate that the OS does this automatically. But it seems like uploads to report stuff would be at least a good idea, if not a given. My best guess it is gets folded into normal Windows telemetry and phone home that way…

PowerShell to the Rescue

Using PowerShell gets you over this particular hurdle. If you want to see what’s in the folder, try this one-liner:

Get-ChildItem -Force -Recurse "C:\Windows\Temp\Whesvc" | Select-Object FullName, Length, LastWriteTime

This produces list of event trace logs (.etl files) you can share with Feedback hub if you’d care to. The following PowerShell will zip it up for you into a file named Whesvc-Diagnostics.zip:

$src = "C:\Windows\Temp\Whesvc" $dst = "$env:USERPROFILE\Desktop\Whesvc-Diagnostics.zip" Compress-Archive -Path $src -DestinationPath $dst -Force

I’d be inclined to label the collection as something like “Whesvc output for dd/mm/yy” when you turn it over to MS for inspection. And indeed some of the object names are pretty interesting, as they include strings like “slow app launch,” “long delay,” “app hang,” and so forth. Sounds like potentially useful stuff!

Given that this is transient info, you need not worry about keeping folder contents around. Once you share it with Feedback Hub (or not), it’s safe to delete. As Copilot says “These are scratch files not persistent logs.” ‘Nuff said.

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

It’s the Layout Not the UFD

July 31, 2026 Ed Tittel Leave a comment

Every so often, Windows administrators run into a problem that looks like one thing but turns out to be something else. My recent adventure with Lenovo’s USB Recovery Creator is a good example. What started as a simple attempt to build a recovery USB stick for a ThinkStation P3 Ultra Gen 3 turned into a deep dive into how Windows, UEFI firmware, and USB controllers decide what counts as “removable media.” Spoiler alert: it’s the layout, not the UFD. To access this tool visit Lenovo Support, plug in your Lenovo PC serial number, go to the Drivers & Software page, then click the Submit Recovery Media Order button.

Why I’m Sayin’: It’s the Layout Not the UFD

If you’ve ever plugged in a perfectly good USB flash drive only to have Lenovo’s recovery tool refuse to see it, you’re not alone. I tried half a dozen drives. They included 32+GB models from SanDisk, Kingston, Mushkin, Transcend, ADATA, even a brand‑new 256GB USB‑C DataTraveler. Every single one failed Lenovo’s removable‑media test. Windows saw them. Explorer saw them. Disk Management saw them. But Lenovo’s tool? Nada. The dropdown menu stayed stubbornly empty.

That’s when the real troubleshooting began.

Why the Tool Rejects “Unspecified” Devices

Lenovo’s USB Recovery Creator is picky. Indeed, it’s far pickier than most users expect. It doesn’t simply look for a USB drive. It looks for a USB drive that reports itself as MediaType = Removable through Windows’ storage stack. Anything else—SSD, HDD, or the dreaded Unspecified—gets ignored.

Here’s the catch: many modern USB flash drives, especially high‑performance ones, identify themselves as fixed disks rather than removable media. This is intentional. Manufacturers optimize for speed, wear leveling, and controller behavior to mimic SSDs. Windows is fine with this. UEFI is fine with this. Most tools , ditto. Lenovo’s USB Recovery Creator tool is not.

When I ran:

Get-PhysicalDisk | Select FriendlyName, BusType, MediaType

every single UFD I owned showed up as:

BusType = USB
MediaType = Unspecified

That’s the kiss of death for Lenovo’s recovery tool. It will never list a device that reports “Unspecified,” no matter how new, fast, or reliable it is.

Proper Cleaning, Formatting and Partitioning Works

Here’s where the story takes a turn. Conventional wisdom says formatting or repartitioning won’t change how a USB device identifies itself. And that’s true — MediaType doesn’t change. But Lenovo’s tool isn’t only checking MediaType. It’s also checking the partition layout, and that’s where things finally broke open.

After trying multiple drives and ports, I decided to go nuclear and rebuild the USB stick’s layout from scratch using DiskPart. The magic sequence turned out to be:

diskpart list disk select disk X clean convert gpt create partition primary size=32000 format fs=fat32 quick assign exit

The moment I did this — and I mean immediately — the Lenovo USB Recovery Creator dropdown lit up and showed the UFD. No hesitation. Nothing ambiguous. No more empty menu.

This was the breakthrough: Lenovo’s tool requires a very specific starting layout before it will accept a USB device, even if the device reports MediaType = Unspecified.

In other words, the tool doesn’t just care about whether the drive is removable. It cares about:

GPT vs MBR
Partition count
Partition size
Partition type
File system
Whether the drive is “clean”
Whether Windows has mounted it consistently

Once the drive was wiped, converted to GPT, given a single 32GB FAT32 primary partition, and mounted cleanly, Lenovo’s tool recognized it instantly. That’s when the lightbulb lit up: it’s the layout, not the UFD.

Why Lenovo’s Tool Needs a Clean GPT/FAT32 Layout

Lenovo’s recovery creator expects to take full control of the USB device. It wants to:

wipe the drive
repartition it
write a bootloader
copy the recovery image
verify checksums

If the drive has:

multiple partitions
leftover boot sectors
exFAT or NTFS formatting
odd alignment
remnants of previous boot media
a corrupted MBR
a GPT with unexpected metadata

the tool simply refuses to show it in the list of acceptable targets. This explains why even brand‑new drives failed: they shipped with factory formatting that didn’t match Lenovo’s expectations. That said, once the layout was corrected, the tool behaved exactly as designed.

The Real Lesson: Modern USB Behavior Requires Modern Troubleshooting

This experience taught me something important: modern USB flash drives aren’t the simple “plug‑and‑play removable media” devices they used to be. They behave more like miniature SSDs, and their factory formatting often reflects that.

Lenovo’s USB Recovery Creator, however, still expects a classic removable‑media layout. When the layout doesn’t match, the tool silently ignores the device. Fortunately, the fix is straightforward once you know what the tool wants to see.

Lesson Learning

If you’re struggling with Lenovo’s USB Recovery Creator, don’t assume your USB flash drive is bad. Don’t assume the ports are faulty. Don’t assume the controller is misbehaving. The real issue is usually the partition layout on the UFD. Clean it. Convert it. Create a simple FAT32 primary partition. Then watch the Lenovo tool recognize it instantly.

In other words: it’s the layout, not the UFD. Here in Windows-World these little details matter. They sucked up my morning and tossed it away. This afternoon, I’m back on the hunt. Whew!