All posts by Ed Tittel

Full-time freelance writer, researcher and occasional expert witness, I specialize in Windows operating systems, information security, markup languages, and Web development tools and environments. I blog for numerous Websites, still write (or revise) the occasional book, and write lots of articles, white papers, tech briefs, and so forth.
Insider stuff, Recent Activity, Troubleshooting, WED Blog, Windows 11

It’s the Layout Not the UFD

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!

Facebooklinkedin
Facebooklinkedin
Device drivers, Insider stuff, Recent Activity, WED Blog, Windows 11

Bitlocker Makes Transplanted NVMe Inaccessible

Leave a comment

Here’s a scenario that trips up even seasoned Windows power users. You yank a perfectly healthy NVMe drive from your desktop or laptop, slide it into a USB or Thunderbolt enclosure, and Windows either refuses to unlock it or asks for a BitLocker recovery key that doesn’t unlock anything. A BitLocker NVMe enclosure combination produces what looks like data loss — but isn’t. Not yet, anyway. Understanding why this happens requires a quick tour of how BitLocker actually seals your data to your hardware. The point, however, is worth noting: using Bitlocker makes transplanted NVMe inaccessible. You can’t read it unless you put it back whence it came.

After an initial warning asking for a Bitlocker key that WILL be rejected, the affected drive shows up as “Unknown” in Disk Management. That’s what you see as the lead-in graphic for this blog post.

Why Bitlocker Makes Transplanted NVMe Inaccessible

BitLocker doesn’t just encrypt your drive and hand you a recover key. By default, it uses the TPM (Trusted Platform Module) — the dedicated security chip on your motherboard — to seal the VMK (Volume Master Key) against a specific hardware fingerprint. That fingerprint is a set of PCR (Platform Configuration Register) measurements recorded at the moment BitLocker was first enabled. Think of it like a wax seal on an envelope: the seal was made using your exact hardware setup, and it can only be broken by that same setup.

The most important register in modern configurations is PCR7. It tracks the Secure Boot policy state — specifically, the UEFI firmware’s Secure Boot signature databases (db and dbx), the boot manager, and the OS loader’s cryptographic signatures. When your PC boots normally, the TPM recalculates PCR7 from scratch. If that fresh measurement matches what was recorded at sealing time, the TPM automatically releases the VMK, BitLocker decrypts the drive in the background, and you never see a prompt. The entire process is silent and seamless. That’s the design goal.

When the PCR7 measurement doesn’t match — because something in the Secure Boot chain has changed — the TPM refuses to release the VMK. BitLocker then falls back to prompting for a recovery key. That’s expected behavior. A drive enclosure, however, is a different problem entirely.

Why the Enclosure Breaks Everything

When you move the NVMe to an external enclosure, the TPM doesn’t come along for the ride. It’s soldered to your original motherboard. The enclosure presents the drive to a completely different environment — or no TPM at all, if you’re plugging into a machine without one, or directly into another system as a USB mass storage device. There is no trust anchor. No Secure Boot validation chain. No PCR match is even possible.

To appreciate the full picture, it helps to know the other key registers. PCR0 captures the UEFI firmware code itself. PCR2 captures option ROM measurements — the firmware on expansion cards and storage controllers. PCR4 records the boot manager. PCR11 is BitLocker-specific, covering its own policy settings. Normally, all of these must match the original sealed profile for the TPM to cooperate. In an enclosure, none of them can be reproduced. This is not a bug. It is precisely the theft-prevention feature Microsoft designed BitLocker to deliver.

The VMD/RST Complication

There is a subtler wrinkle that catches power users off guard: VMD (Intel Volume Management Device) and RST (Rapid Storage Technology). Many modern Intel-platform systems configure their NVMe storage through the VMD controller, which routes NVMe drives through Intel’s RST driver stack during the boot process. That RST driver participates in the boot chain and alters the PCR measurements — particularly PCR2 and PCR0, which capture option ROM and firmware behavior.

When you pull that NVMe and attach it to a plain USB or Thunderbolt enclosure, the RST and VMD stack is completely absent. Even if you moved the drive to another Intel machine with a TPM, the PCR profile would not match because the storage controller mode is different. The sealed measurements were taken with VMD/RST in the picture; your new environment has neither. Many users never realize their BIOS storage controller mode is part of the BitLocker trust equation. Now you know.

Why The Recovery Key Doesn’t Work

Here’s the misconception that causes the most panic. Your recovery key isn’t being rejected because it’s the wrong key. The deeper problem is that BitLocker in TPM-only mode never even reaches the stage where it checks the recovery key in a normal boot flow. The TPM unsealing fails first — and in an external enclosure, there’s no TPM at all. BitLocker can fall back to recovery-key mode, but only if the drive’s key protectors actually include a recovery password protector. If BitLocker was configured in TPM-only mode with no recovery password added, you are looking at an encrypted brick. The data is mathematically inaccessible.

This is why Microsoft’s guidance is emphatic: always back up your recovery key. Store it in your Microsoft Account, print it, or escrow it to Active Directory or Azure AD. Every one of those options beats learning this lesson the hard way at 2 a.m.

Pro Tip

Before pulling an NVMe from an encrypted system, run manage-bde -protectors -get D: to review the drive’s protector configuration and PCR profile. Confirm a recovery password protector exists. Then decrypt fully with manage-bde -off D: before removal. Re-encrypt after reinstallation in the new system. That sequence keeps your data safe and accessible every time.

BitLocker’s hardware binding is a feature, not a flaw — and a pretty powerful one. A TPM-sealed VMK means a stolen drive is worthless without the original motherboard’s trust environment. But that same strength makes casual NVMe swaps treacherous if you aren’t prepared. Decrypt before you disconnect. Check your protectors before you assume. And for everything else, learn more about BitLocker recovery options directly from MS before you need ’em.

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

Overhauling WU Orchestrator and Arbiter

Leave a comment

Windows Update (aka WU) has always been something of a “black box.” One clicks “Check for updates,” and watches a progress bar lurch along. At it sticks at various points along the way to completion, one wonders what’s going on inside the PC. The answer comes from two little-known components that handle updates behind the scenes. These are the Windows Update Orchestrator and Arbiter. As MS promises it’s overhauling WU Orchestrator and Arbiter, it’s a good idea to dig in and understand what they are, and what they do. Buckle up! Here we go…

Why Is MS Overhauling WU Orchestrator and Arbiter?

Simply put, the progress bar as it currently works doesn’t do its job. Also, when the update process finishes, post-update cleanups don’t exactly bring Windows up to full performance any time soon. TLDR version: this overhaul intends to address those things, probably in the upcoming August 11 Cumulative Update, due next Patch Tuesday.

What Is the Windows Update Orchestrator?

The Windows Update Orchestrator — formally the Update Orchestrator Service, or UsoSvc — is the scheduling brain of the entire update pipeline. It decides when your PC checks for updates, when downloads begin, and when installation kicks off, all without direct user intervention.

Think of the Orchestrator as an air traffic controller. It coordinates between your active hours, battery and network conditions, and Microsoft’s own delivery servers. When conditions align, it clears the update to land.

The Orchestrator talks to Windows Update’s policy engine, reads Group Policy and MDM settings on managed machines, and queues work for downstream services. It runs quietly in the background, even when you’re not thinking about updates at all. You can see a schematic of this workflow as the lead-in graphic above.

What Does the Arbiter Do?

If the Orchestrator is the scheduler, the Arbiter is the referee (as its cognomen is meant to declare). The Arbiter’s job is to resolve conflicts between competing update requests — for example, when a driver update and a cumulative security patch both want to run at the same time, or when a pending restart faces an active user session.

The Arbiter also decides which updates take priority. It weighs patch criticality, determines if a reboot is already pending, and whether or not the device is on a metered connection. When the Arbiter approves an update, it signals the Orchestrator to proceed. Without that handshake, nothing moves.

Together, the Orchestrator and Arbiter form a tightly coupled scheduling and arbitration layer that sits above the actual download and install services — but below what you see inside Settings.

Why They’ve Frustrated Users for Years

The problem has never been that the Orchestrator and Arbiter do their jobs poorly. Generally, they do not. The problem is that they remain nearly opaque to the progress reporting layer that feeds  Settings. It’s more than a bit of a disconnect, in fact!

For example, you might see the Windows Update progress bar freeze at 0 percent, spike to 74 percent, then crawl back to 12 percent. That odd behavior is not the update failing. It’s the Orchestrator and Arbiter operating normally. Alas, their internal state isn’t accurately mapped to a UI percentage value. The progress bar has essentially been guessing. When it guesses wrong, things jump around. That happens…pretty regularly.

Post-update sluggishness is a related phenom. Once installation completes, Windows leaves temporary staging files, old component-store fragments, and residual update scaffolding behind. It then cleans up lazily over the next few minutes. On lower-powered PCs (the kind that technically meet Windows 11’s TPM 2.0 and CPU requirements but aren’t exactly fast) such cleanup makes some systems feel broken right after reboots.

What Microsoft Is Fixing Right Now

In builds 26200.8968 and 26100.8968 Microsoft has shipped two targeted improvements. These represent the latest Release Preview updates for 25H2 and 24H2, respectively and just appeared last week.

First, progress reporting among the Orchestrator, Arbiter, and the Settings UI is rebuilt. The percentage displayed now reflects actual download and installation state rather than a guesstimate. Going forward, a progress bar that stalls at 45 percent genuinely means the update is 45 percent complete. It’s no longer because the Orchestrator just stopped talking to the UI.

Second, post-install cleanup runs more aggressively at the end of the update cycle rather than spreading work across the next several minutes. Systems should reach full responsiveness faster. This should be a welcome change for anyone who reboots after Patch Tuesday and wonders why things feel sluggish for the next 10 minutes (or more).

When Will Orchestrator and Arbiter Change?

These changes are in Release Preview now and should show up for mainstream Windows 11 users via a Patch Tuesday cumulative update within one to two months. I’m thinking August 11, but it could be September 8, depending on telemetry from these latest Release Preview CUs. MS will hold them back if it needs to tinker some more. Hopefully, it happens sooner, not later.

Neither fix is glamorous, but both address complaints that Windows users have logged for years. A trustworthy progress bar and a snappy post-update experience are not unreasonable expectations for a modern OS. Here in Windows-World, we’ll wait and see how things go. Stay tuned: I’ll keep you posted…

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

PC Manager Browser Space Is Mostly Volatile

Leave a comment

I just ran PC Manager’s Deep Cleanup on my Flo6 desktop. As usual, it cleaned a lot of what it found: 11.4 of 14.6 GB wound up gone. Also, as usual it shows around 3GB remaining for my three browsers — namely, Firefox, Chrome and Edge. So I asked Copilot: why do these programs show up in their numbers? It opines (and I concur) that PC Manager Browser space is mostly volatile. Indeed the figure is kind of illusory. It’s worth understanding before treating browser cache cleanup as a valid way to recover disk space.

Take a look at the final results from my Deep Cleanup just now from the lead-in screencap. Notice that it shows 1 GB for Firefox, 1.6 GB for Chrome and ~277 MB for Edge. Keep those numbers in mind.

Why Say: PC Manager Browser Space Is Mostly Volatile?

Here’s the core issue: browser cache is engineered to be ephemeral. It’s written, read, and purged in a continuous cycle governed by cache-expiry headers, per-origin storage quotas, and the browser’s own self-management routines. The moment you fire up your browser after a cleanup and start clicking around, the cache begins refilling. Within 30 to 60 minutes of ordinary browsing, most browsers will have rebuilt several hundred megabytes of cached content — sometimes more, depending on how media-heavy the sites you visit are.

Chrome and Edge both enforce internal storage quotas and will self-evict stale or low-priority cache entries automatically when those quotas are approached. In other words, the browser is already managing this space on your behalf, without you lifting a finger. Firefox operates similarly under its own quota management framework.

In short: you didn’t “save” 2 GB when you cleared browser cache. You borrowed 2 GB temporarily — until your next browsing session rebuilt most of it. Sort of like the storage equivalent of pushing water uphill.

Check out these numbers: they represent the memory footprint for my three browsers.

Note that those numbers fall near the potential savings that PC Manager reports for each one. That’s no coincidence, it simply represents reclaiming space that the browsers will suck back up as soon as you turn them back on, and open some tabs.

What Real, Valid Savings Look Like

Contrast browser cache with the categories that represent genuinely permanent space recovery. Windows Update cleanup files — the old installer packages and superseded component stores left behind after updates — can run anywhere from 500 MB to 2 GB, and once deleted, they do not return. Windows Error Reporting logs are similarly non-regenerating under normal conditions. The Recycle Bin is obvious. Orphaned app data left behind by software you’ve already uninstalled is another solid target. Thumbnail cache does rebuild, but far more slowly than browser cache, so it offers a more durable short-term gain.

A typical monthly cleanup on a moderately used Windows 10 or 11 machine might yield up to a 5 GB of truly permanent, non-regenerating space. That’s a lot less dramatic than the headline figure PC Manager flashes at you — but it’s real. And it stays real.

Do You Need to Clean Browser Cache?

Maybe, but go into that effort with adjusted expectations. Clearing browser cache could deliver a brief responsiveness improvement. Thus, if the cache has grown bloated with stale or corrupt entries, or to make room in storage-intense scenarios, such as recording a long screen capture session, installing a large application, or freeing up breathing room on a drive that’s genuinely running tight. Otherwise, don’t expect much either in the short or long term.

If you’re truly short on disk space, PC Manager’s Large Files finder and the Windows Update Files cleanup row are far more useful targets. The browser cache, left alone, will look after itself. That’s the point!

Here in Windows-World keeping things clean does have its reward. But some things are more worth cleaning up than others. Browser cache is near the end of that list, and best left alone.

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

Jumping WinGet’s Install Technology Hurdle

Leave a comment

Wow! It’s hard to believe that WinGet has been around for over 6 years now (it made its debut on 5/19/2020). Over those years I’ve seen the upgrade block shown in the lead-in graphic many times. I’ve also learned to deal with it in more roundabout ways. Let me call this jumping WinGet’s install technology hurdle, so I can explain one particular technique worth investigating.

What Jumping WinGet’s Install Technology Hurdle Means

The text at the head of the screen cap recommends “Uninstall each package, then install the newer version.” This will work if there’s no other way. But if — as you can see is the case with Oh My Posh (OMP) — there’s an internal update mechanism, this often works just fine without requiring wholesale removal (uninstall old version) and replacement (install new one).

Indeed, it just so happens that OMP will happily update itself at the command line using the built-in command

oh-my-posh upgrade --force

So that’s what I did instead of running one WinGet command to remove the old package, and another to install the new one. This situation pops up when WinGet detects that a normal upgrade is not feasible. It blocks upgrades whenever the install technology changes from one release to the next. That’s how it avoids potential problems with the package and its supporting infrastructure that might otherwise occur.

But the teams who develop such packages know their inner workings. They can (and often do) support such upgrades because they understand how to hand off from the older install technology to the newer one. When I run into this situation, I look for a built-in update mechanism in the package (or its related app) itself. It will often jump the hurdle for me, and let me keep using WinGet thereafter. Indeed, I’ve done this myself with Adobe Acrobat too. Furthermore, GitHub documents similar cases with MS Edge, PowerShell 7, Oracle VirtualBox, LocalSend, and other packages as well.

But Wait…There’s More!

Even after I got to the latest version, I found a couple of older versions of OMP also installed. Ultimately, I DID have to uninstall those to make them go away. That’s because OMP lets multiple versions run in parallel. This time, I used msiexec and the GUIDS (for the no-longer-wanted versions) for that purpose

msiexec /x "{97557535-43B6-44EF-BA97-86563C1AC80A}"
msiexec /x "{85B43182-5A11-40E5-9E09-7EF6EB1CFDF7}"

Now, I’ve got just the one (updated) version and a clean Oh-My-Posh setup. Here in Windows-World, it’s always something. Thank goodness that Copilot was able to help me steer through the wreckage, and clean up the older versions properly. Now I see only the latest version when I run winget list, and OMP is working as it should be. AND I solved a problem I didn’t know I had. Good-oh!

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

MVP Status Renewed thru June 2027

4 Comments

I’m pleased and delighted to report that a much-anticipated email from MS popped into my inbox last Friday. Such was the press of work that day (Fridays have been unusually busy all month) that I didn’t even see that missive until after lunch. Long story short: the powers that be informed proclaimed MVP status renewed thru June 2027. Of course, I’m glad to be so honored, and happy to receive another year of benefits.

What MVP Status Renewed thru June 2027 Means

It means this website and my weekday Windows blog posts will continue for at least another year. It also means I’ll keep exploring new Windows OS tools and facilities, Windows apps, and other Windows related stuff so we can all learn — and sometimes laugh — together.

I first started using Windows when I “moved up” from DOS 6.x to Windows 3.1 in 1992. It’s been a wild and interesting ride over the past 34 years since then. I’ve seen a lot of versions come and go. Some of them I’ve loved and others despised. But one thing has persisted throughout that interval: a burning desire to understand how things work, and to fix (or work around) them when they don’t do what they should.

The MVP Story So Far…

I got into a fork of the MVP program in 2018 when I became a “Windows Insider MVP.” That lasted until 2024, when MS folded that fork into the main branch. I’ve been a “Microsoft MVP (Windows)” since 2024, and my status is good through June 20, 2027. As I keep moving forward, I keep learning more about how the program works, what it lets me do, and how I can share such information with my readers as the terms of my NDA agreement allow. That covers a lot of great stuff, and I’m happy to use it to write about what I’m seeing and learning.

Thanks for your support and interest over the years. I provide content for over 80K individuals per year here at EdTittel.com. I reach another half-a-million or so through my articles for the likes of ComputerWorld, Tom’s Hardware, WindowsLatest and others. Just this morning I got a big shout-out from WindowsLatest on a recent and fascinating hobby-horse named Secure Boot.

For the future I plan to keep finding, fixing, and reporting on things that break or don’t work as I think they properly  should, and exploring Windows Insider releases as they emerge. Here in Windows-World, that gives me a nearly infinite fund of topics. Stay tuned! If you’re of a similar bent, you can’t apply to the Microsoft MVP program directly. But if you know an MVP who’s already in the program, you can ask them to nominate you. Check the Microsoft MVP Home page to learn more about the program and all of its accoutrement.

Facebooklinkedin
Facebooklinkedin
Uncategorized

Dodging a BIOS Bullet By Design

Leave a comment

I’ve been dreading a recent moment for years. Whenever you update the BIOS (UEFI) in a PC or laptop, the maker usually throws dire warnings about maintaining power. The unthinkable happened to me this morning: the lights flickered, then went dark. And, as fate would have it, the Lenovo ThinkStation P3 Ultra Gen3 was in the middle of a firmware update (about 65% complete showing) as that happened. I was poleaxed, fearing a fully bricked PC. It wasn’t. The machine came back up cleanly, and I ended up dodging a BIOS bullet by design. I’ll explain…

Note: the lead-in graphic is a mock-up I put together. I didn’t capture the actual screen on my iPhone as it appeared.

Dodging a BIOS Bullet By Design

I was running a routine BIOS update as part of a routine Windows Update (WU) sequence. The firmware update screen had been up for a couple of minutes, progress bar inching along, and then — boom. A power fluctuation in my home office killed the display and dropped the machine cold. The Lenovo firmware screen itself had been displaying the standard warning in big, friendly (okay, slightly ominous) letters: “Do not power off or unplug the machine during the update.”

The progress bar was sitting at 65% when everything went black. That’s prime corruption territory — far enough in that the old BIOS image has been partially overwritten, but not far enough that the new one is complete and verified. If this had happened on an unprotected consumer board, I’d have been looking at a paperweight. Fortunately, on  a workstation-class PC, this story gets a happier ending.

Why the P3 Ultra Gen3 Didn’t Brick

Here’s where things get interesting — and where Lenovo’s engineering team deserves credit. The P3 Ultra Gen3 didn’t survive by accident. It survived because its design planned for this event. Several overlapping layers of firmware resilience kicked in automatically. Let me break them down in basic terms:

  1. Dual BIOS / Backup BIOS Chip. Lenovo workstations — like many enterprise-class machines — carry a secondary, read-protected BIOS image alongside the primary one. Think of it as a golden master copy that the system keeps locked away. If the primary BIOS region shows corrupted at POST time, the firmware controller automatically detects the bad state and boots from the backup image. No user intervention required. The system just comes back up, potentially with the previous firmware version, but alive and functional.
  2. Flash BIOS Button / Crisis Recovery Mode. Some ThinkStation models — including variants in the P3 line — include a dedicated Flash BIOS Button on the chassis. In a true recovery scenario where even the backup region is compromised, you can create a crisis recovery USB drive and use that button to force-reflash the firmware from scratch, completely bypassing any need for a working BIOS. It’s the ejector seat of firmware recovery.
  3. UEFI Firmware Resilience (NIST SP 800-193 / Platform Firmware Resilience). This is the standards-level framework underpinning everything. NIST SP 800-193 defines a three-pillar architecture for firmware protection: Protect (prevent unauthorized modification), Detect (identify corruption or tampering), and Recover (restore a known-good state automatically). Lenovo has formally committed to this standard across its Think commercial product line, which means the recovery behavior I experienced wasn’t a happy accident — it was a tested, certified design outcome.
  4. Intel BIOS Guard. Underneath all of that sits Intel BIOS Guard, a hardware-enforced mechanism that prevents any unauthorized or incomplete writes to the BIOS flash storage from being committed without cryptographic verification. Even if a flash operation is interrupted mid-write, BIOS Guard’s atomic-write design means that an incomplete image cannot silently corrupt the chip’s protected regions without detection.
“ThinkPads detect corruption of all primary BIOS code regions and recover the corrupted region by booting from the backup region, then restore the primary region with the verified binary in the backup.” — Lenovo BIOS Security Statement LEN-20208228 Feb 28, 2020 (no longer active: former URL https://www.lenovo.com/us/en/pdf/product_security/Lenovo_BIOS_Security_Statement_
20200228.pdf)

 

In short: these systems are built with layered defenses specifically because power failures, bad actors, and Murphy’s Law are all real things that happen to real machines in the real world.

What Does It All Come Down To?

Even with all of these protections in place, I’m not going to tell you to start flashing BIOS updates casually while thunderstorms roll in. Here’s what I’d recommend taking away from this little adventure:

  • Use a UPS. Full stop. An uninterruptible power supply is the single most effective insurance policy for any workstation-class firmware update. Even a modest desktop UPS gives you the runtime buffer to either complete the flash cleanly or gracefully abort. My home office UPS setup failed me here — lesson painfully reinforced.
  • Check your service manual for dual-BIOS and crisis recovery support before you update. Not every machine has these features. Know what your hardware can and cannot do before you find out the hard way. Lenovo’s support site documents this clearly for ThinkStation models.
  • Use Lenovo Vantage or Lenovo System Update rather than manual executables. These tools handle pre-flight checks, staged delivery, and rollback behavior far more gracefully than dropping a raw executable and hoping for the best. They’re there for a reason — use them.
  • Know where your Flash BIOS Button is before you ever need it. Locate it in your chassis documentation now, not while you’re in crisis mode at 11 PM staring at a dark screen.

PRO TIP: Before any major firmware update on a workstation, run Lenovo System Update to confirm you’re pulling the current validated image, verify your UPS is holding charge, and note the current BIOS version in case you need to reference it during a recovery. Two minutes of prep, potentially hours saved.

After a Moment of Blissful Relief, Thank the Engineers

Avoiding unplanned downtime is a major design goal in the ThinkStation P3 Ultra Gen3 ‘s design. Today’s tale of averted woe is as clear a demonstration of that design philosophy as you’re going to get outside a Lenovo engineering lab.

I hit what should have been a fatal event, and the machine shrugged it off through a combination of dual-BIOS architecture, Intel BIOS Guard, and NIST SP 800-193-compliant firmware resilience. That’s not marketing copy. That’s a machine doing things right. If you want to dig into the specifics for your own ThinkStation model — crisis recovery procedures, Flash BIOS Button location, and backup BIOS behavior — head over to Lenovo’s support site and pull up your model’s Hardware Maintenance Manual. It makes for surprisingly reassuring bedtime reading.

Here in Windows-World dodging bullets is something that happens occasionally. Today, I’ll gratefully accept a happy ending to what I thought might involve hours of recovery. Three cheers for the engineers!

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

WinGet Shows More Icons

Leave a comment

Here’s an interesting and welcome observation. Installing updates this morning, I noticed that 7 of 10 packages showed icons as Winget did its upgrade thing. (And this came from the 2018 vintage ThinkPad X380 Yoga!) Anecdotally, that’s way up from when icons first started showing up Windows Terminal in early March of this year. I’m delighted to see that WinGet shows more icons than ever before. Mostly that happens as more developers start including the necessary image references in their package metadata. In my sample screenshot (5 packages) every one has an associated icon. I’m jazzed!

Why WinGet Shows More Icons Nowadays

Lots of popular apps now include icon Url fields in their metadata (that’s where those images come from: e.g. VLC, Chrome, FireFox, NotePad++, MTPW, etc.). Microsoft has definitely upped its support for icons as well (e.g. Edge, PowerToys, Terminal, VStudio, .NET runtimes, and more). Indeed, there seems to be a growing wave of developer support as more and more packages now sport icons as WinGet interacts with them.

At the same time, says Copilot, “the WinGet backend now caches and serves icons [more] reliably.” These days icons are cached in the content delivery network (CDN), retrieval is faster and better, and broken URLs are getting fixed. The net-net is that more icons are appearing because there are more of them around, and the mechanisms to show them are working better, too.

Here in Windows-World, that counts as progress. Plus, I love the eye-candy that icons provide within the mostly monochrome Windows Terminal environment. How could you not? Good stuff!

If you’ve not yet turned icons on in your Terminal evironment just yet, never fear. I posted about this on April 10 (2026) in an item entitled How to Light Up Winget Icons. Follow its instrux if you’d like to see them for yourself.

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

Understanding Occasional dllhost.exe Crashes

Leave a comment

Every now and then, I drop into Reliability Monitor on my primary desktop PC (Flo6). Aka Relimon, this built-in tool provides rough and ready summaries of recent system events. Placement puts emphasis on errors and warnings. In looking over recent stuff, I observed that dllhost.exe has “stopped responding” 4 times in the period from July1 thru 18. I turned to Copilot to aid in understanding such dllhost.exe crashes. Though that frequency may sound ominous or concerning, seems like it’s pretty typical. You can see the latest report for July 1-20 in the lead-in graphic.

Why Bother Understanding Occasional dllhost.exe Crashes?

In examining the critical errors shown in ReliMon’s three-week time window, I saw that dllhost.exe “stopped responding” item on July 1, 8, 17,  and 18. So I shared that info with Copilot and asked “Should I be concerned?” It responded as follows:

Four dllhost.exe crashes over an 18‑day span is well within the “normal Windows background noise” range. It’s not a sign of system instability, corruption, or anything you need to lose sleep over. Let me break down what that frequency actually means in practical terms.

dllhost.exe (COM Surrogate) is invoked constantly—every time Explorer generates thumbnails, previews, metadata, or runs certain shell extensions. On a typical Windows system, dllhost.exe may spin up hundreds of times per day.

So:

  • 4 crashes / 18 days ≈ 1 crash every 4–5 days
  • That’s extremely low for COM Surrogate failures
  • It suggests occasional thumbnail/preview hiccups, not systemic trouble

Driving the Bus Means Wear and Tear

Given that running dllhost.exe during file access can easily cause error events to protect Explorer itself, I’m comforted to know that this occurs by deliberate design. I’ve run into a variety of .com related error events over the years that can be safely ignored (e.g. 1601, 1603, etc.). With information from Copilot in hand, and references to back it up, I’m OK with seeing this in my reliability monitor output.

Here are some useful and interesting supporting materials:

Here in Windows-World, Copilot can be a valuable source of information and insight. But I’ve learned through experience that you must check its sources to separate fact from fiction. If you use it for the same purposes, be sure to check its work (and assertions). In this case, I’m comfortable with the information it’s drawing upon and inclined to trust its veracity. Good stuff!

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

Cloud Rebuild Requires Registry Access

Leave a comment

When I read about the incorporation of a Cloud Rebuild feature in Windows 11, Experimental Build 26300.8772 on July 6, I had to have it. First, of course, I had to upgrade a machine to that release. Alas, I hit a few snags on the way (see my July 15 post for deets) but eventually I got there. Then I used the “Create a recovery drive” facility to build a brand-new bootable WinRE for that PC (a honkin’ ThinkStation P3 Ultra Gen 2). But when I booted to that media, WinRE did not appear amidst its menus. The only way to see it is to use Settings > System > Recovery > Restart Now, and then to select that option under the Troubleshoot menu when on-disk WinRE boots instead. Why? Because getting to Cloud Rebuild requires registry access. I’ll explain…

Accessed via on-disk WinRE, there it is!

Why Cloud Rebuild Requires Registry Access

Cloud Rebuild is a new WinRE recovery option that downloads a fresh Windows installation directly from Windows Update and reinstalls it onto the machine. It preserves nothing — no apps, no settings, no user data. Think of it as the “nuclear but automatic” option: positioned for situations where Reset This PC fails or the local recovery image is corrupted beyond use. It does, however, require an active internet connection and relies on Windows Update to supply appropriate NIC drivers. In short, the cloud does the heavy lifting so you don’t have to carry a USB installer everywhere.

So where does the registry come into play? When you create a recovery UFD from a machine running build 26300.8772, Windows faithfully copies the host’s WinRE.wim to the drive — byte for byte. The Cloud Rebuild code is therefore physically present on that UFD. So why doesn’t the tile appear?

When you boot from the UFD, WinRE runs as a fully isolated, self-contained instance. It has no path to the host machine’s registry — that OS partition might not even be mounted. The enablement check silently fails, and the Cloud Rebuild tile simply doesn’t appear. No error, no explanation, no tile. Additionally, Cloud Rebuild is riding a Controlled Feature Rollout in this build, which means not every enrolled Insider machine receives it simultaneously. That adds yet another variable into an already narrow set of conditions.

Here’s the Catch!

The following insight matters, when it comes to planning how to make best and proper use of Cloud Rebuild. Its registry dependency means this feature is available in a narrower slice of real-world failure scenarios than one might hope. Walk through this landscape:

  • Scenario 1 — OS corrupted, disk intact: Native WinRE auto-triggers after two or three consecutive failed boots. The registry is still readable. Cloud Rebuild appears and does its job. This is the sweet spot the feature was designed for.
  • Scenario 2 — Recovery partition (or files) deleted or corrupted: Native WinRE is unavailable, so you reach for the UFD. However, Cloud Rebuild won’t appear on the UFD because the isolated WinRE instance can’t reach the host registry. You’re on your own with whatever tools that generic WinRE environment provides.
  • Scenario 3 — SSD or NVMe failed or dead: Nothing works. Not Cloud Rebuild, not native WinRE, not the UFD for anything disk-related. At that point, the conversation is about replacement hardware, not recovery software.
  • Scenario 4 — BCD or boot files corrupted: Startup Repair may intervene and restore enough of the environment for native WinRE to launch. Cloud Rebuild visibility in that scenario is uncertain and depends on how much of the OS partition structure survived intact.

Microsoft’s own documentation quietly confirms this scope by requiring that the device have “a healthy Windows Recovery Environment” for Cloud Rebuild to function. The architectural intent is clearly to cover soft OS failures — driver corruption, bad cumulative updates, damaged system files — where the underlying disk is intact and the recovery partition is alive. That’s a real and valuable use case. It does not, however, cover every use case.

Cloud Rebuild’s Place in the Recovery Toolkit

For Cloud Rebuild to be a genuine lifeline, your recovery partition must survive whatever broke Windows in the first place. That’s a reasonable bet against driver corruption, a bad update, or OS file damage. But it’s not a bet you should make against disk failure or deliberate partition cleanup.

Additionally, you should test Cloud Rebuild from within a running Windows session before you need it for real. The path is simple: Shift+Restart → Troubleshoot → Recovery and uninstall → Cloud Rebuild. If the tile appears during a deliberate test, you know the feature is enabled on your specific machine. On Insider builds especially, confirm this for yourself. That’s because Controlled Feature Rollout means the tile may simply not be there yet on your hardware, regardless of build number.

If you want to test Cloud Rebuild without committing to a full reinstall, entering WinRE via Shift+Restart lets you verify tile visibility and back out safely. Do this now, on a good day, so you know exactly what you’re working with when a bad day happens.

Closing Thoughts

Cloud Rebuild is not vaporware, and it’s not a gimmick. Within its intended scope — soft OS failure on a machine with a healthy disk and a live recovery partition — it’s a useful automatic recovery mechanism.

The trouble is, “within scope” is doing a lot of work in that sentence. Knowing where that scope ends is the difference between a recovery plan and a recovery hope. The best time to discover that Cloud Rebuild registry access doesn’t extend to your UFD is during a Friday afternoon test with a cup of coffee in hand — not at 2 a.m. during an real recovery. Test deliberately, kit accordingly, and you’ll be fine.

Here in Windows-World, it not only pays to be prepared. It’s also essential to know what you’re doing, and to understand what the tools in your kit can (and can’t) do. ‘Nuff said.

Facebooklinkedin
Facebooklinkedin