Category Archives: Windows Update

Nearly Perfect PITR Makes Windows 11 Debut

Point-in-Time Restore (PITR) is one of the most interesting recovery features Microsoft has added to Windows 11 in recent memory. It arrived quietly through cumulative update KB5095093 in June 2026. Yet it brings a welcome new option for users who want a fast way to roll back their systems. PITR works by capturing snapshots of key system areas. These snapshots let you return your PC to an earlier state when something goes wrong. The idea is simple, and the execution is surprisingly smooth. In fact, I’d say MS has delivered a nearly perfect PITR to the OS.

What Makes It Nearly Perfect PITR, and Nor More or Less?

PITR creates restore points that include system files, settings, and some application data. These snapshots live on the local drive. They also tie into Microsoft’s cloud services when available. This hybrid approach gives PITR more flexibility than older tools like System Restore. It also makes the feature more resilient when local files become damaged. With the release of KB5095093, PITR gained a major upgrade: it now appears directly inside WinRE. That means you can access PITR even when Windows won’t boot. You can see it as a Troubleshoot option in WinRE in the lead-in graphic.

Seeing PITR listed in the WinRE Troubleshoot menu feels like a big step forward. It signals that Microsoft wants PITR to serve as a real recovery tool. You can boot into WinRE, choose Point-in-Time Restore, and pick a snapshot to roll back to. The process is quick and clear. It also avoids the complexity that sometimes comes with older recovery methods. For many users, this will be enough to fix common problems.

What Limits Warrant a “Nearly Perfect” Label?

Still, PITR is not a full replacement for image-based backup solutions. Tools like Macrium Reflect and Hasleo Backup Suite offer deeper protection. They create complete disk images that capture every sector of a drive. These images can be mounted like virtual disks. That means you can browse them, copy files out of them, and inspect their contents. PITR cannot do that. Its snapshots are not mountable. They do not support file-by-file access. They also do not cover the entire disk.

This difference matters when you need more than a simple rollback. If a drive fails, PITR cannot help. If you need to recover a single file from a past state, PITR cannot help there either. Image backups shine in these situations. They give you full control over your data. They also let you restore a system even when the internal drive is gone. PITR is faster and easier, but it is not as complete.

Even so, PITR fills an important gap. It offers a middle ground between System Restore and full image backups. It is quick, lightweight, and built into Windows. The addition of WinRE support makes it far more useful. You can now rely on PITR when Windows refuses to load. That alone makes it worth enabling.

Worth Enabling, But Not A Panacea

In the end, PITR is a welcome addition to Windows 11. It is not perfect, but it is close. For everyday problems, it may be all you need. For deeper issues, image backups remain essential. The best approach is to use both. PITR gives you speed. Image backups give you safety. Together, they create a strong recovery strategy for any Windows system.

To check PITR and it settings visit, Settings > System > Recovery > Point-in-time restore. On my systems it’s enabled by default with a single PITR restore point every 24 hours, 72 hour retention, and a space ceiling 2.0% of disk capacity. YMMV. Check it out: seems like a nearly perfect addition to Windows 11’s recovery capabilities.

To learn more about PITR, read this June 23 Windows IT Pro blog post “Point-in-time restore for Windows 11 is now generally available.” Lots of good stuff in there!

Facebooklinkedin
Facebooklinkedin

Patch Tuesday Delivers Odd Recycle Bin Glitch

Take a look at the lead-in graphic. It shows the File Explorer listing for a recently deleted file in Recycle Bin, with the confirmation dialog below. Notice the original filename is Update-UEFI.bat (above) but the confirmation identifies that file as $RXE56IL.bat. All Windows versions with the June 9 updates show such a changed file name. Hence my claim that Patch Tuesday delivers odd recycle bin glitch.

What Patch Tuesday Delivers Odd Recycle Bin Glitch Means

Two things. First, something is exposing the internal filenames that the Recycle Bin always employs to users. Second, the glitch is benign. You can go ahead and confirm the deletions, even though the name appears to point at something unknown and unrelated. It’s just another little Windows glitch. Fortunately, it’s nothing to worry about.

You can read more about it in the Windows 11, June 2026 Issues List. The relevant item is entitled “Deleting a file from the Recycle Bin displays an internal filename in the dialog.” It ties the issue to KB5095051. MS also says further:

We are working to release a resolution in a future Windows update and will provide more information when it is available.

Not Much to See; Go About Your Business

While interesting and possibly amusing or annoying, depending on your inclination, this little glitch doesn’t appear to pose any threats. Even though the name has changed, the recycle bin functions as it always has. As you can see from the lead-in screencap, you can keep things straight by dropping the confirmation dialog atop the File Explorer window in which Recycle Bin is open.

Just another brick in the wall, I guess, here in Windows World. It gave me a chuckle, though. I hope you find it likewise diverting. Cheers!

Note Added 1+ Hours Later…

Just saw Kevin Okemwa’s story at Windows Central right now. It’s equally odd that he and I would come up with nearly identical titles for our coverage of this topic independently. Have to give props and recognition to observe this occurred by coincidence, not copying.

Facebooklinkedin
Facebooklinkedin

Lenovo PC SVNs Can Vary

I have multiple Lenovo machines in my office. This morning I was checking a ThinkPad P16 Gen 3 mobile workstation and a ThinkStation P3 Ultra desktop in the wake Patch Tuesday’s update. Both run Windows 11, with Secure Boot enabled. While poking around in their Secure Boot UEFI settings, I noticed something that stopped me cold. These two machines report different Secure Boot SVN values. Same vendor. Roughly the same generation. Same security feature switched on. So why the difference? As it turns out, the answer is genuinely interesting, and it matters if you manage a mixed fleet of Lenovo hardware. Bottom line: Lenovo PC SVNs can vary. Let’s explore…

How Is It That Lenovo PC SVNs Can Vary?

SVN stands for Secure Version Number — a monotonically increasing counter (meaning it only ever goes up, never down). It’s embedded directly in UEFI firmware. Its job is to record how many Secure Boot security revisions a device has seen over its lifetime.

Let’s distinguish the Secure Boot SVN from two things it often gets confused with. First, it is not the same as the Secure Boot DB/DBX (the UEFI allow-list and deny-list databases that control which bootloaders and drivers are trusted or revoked). Second, it is not the same as your plain BIOS version number. The BIOS version tracks firmware feature releases; SVN tracks security-policy changes.

The practical muscle behind the SVN is its rollback prevention. If a piece of firmware or a bootloader carries a Secure Boot SVN lower than the minimum value stored in non-volatile memory, the UEFI stack simply refuses to load it. That makes it much harder for an attacker to downgrade your firmware to a vulnerable older version — a classic attack vector the SVN is designed to close.

Lenovo P16 Gen 3 vs. ThinkStation P3 Ultra

The lead-in graphic shows the output from Garlin’s check script and the get-SecureBootSVN command on the P16. Here’s what I found on the P3 Ultra, by way of contrast and comparison:

For the P16 Gen3 SVN is 8.0; for the TSP Ultra, it’s 9.0. WTF?

My first instinct was that something was misconfigured. It was not. These two machines serve quite different market segments. The P16 Gen 3 is a mobile workstation, designed for road warriors and power users who demand both portability and security. The ThinkStation P3 Ultra is a compact desktop workstation, built for workstation-class compute in a fixed location, where stability and long-term reliability tend to trump rapid update cycles.

Critically, the two platforms ship from separate firmware engineering teams inside Lenovo, each running its own BIOS release cadence. ThinkPad-family machines — including the P16 series — have historically received more frequent UEFI updates, driven by the constant churn of mobile power-management tuning, thermal firmware, and rapid security patch integration. ThinkStation platforms, by contrast, follow a slower, more deliberate update cadence that prioritizes stability for long-running workloads. Neither approach is wrong. They just produce different Secure Boot SVN trajectories over time. This time, however, the usual order got stood on its head: the ThinkStation preceded the ThinkPad.

How the SVN Update Pipeline Works

To really understand the divergence, you need to know how the Secure Boot SVN update pipeline actually flows. It is a three-layer process, and each layer operates on its own schedule.

  1. Microsoft issues a Secure Boot policy change or DBX update. A concrete example: the revocation of vulnerable bootloaders tied to CVE-2023-24932 (the so-called BlackLotus UEFI bootkit vulnerability). Microsoft publishes updated Secure Boot DB and DBX payloads, and the associated policy mandates a new minimum SVN level.
  2. OEMs like Lenovo incorporate updated SVNs into a new BIOS/UEFI release. Here is where the divergence begins. Lenovo’s mobile and desktop firmware teams each pick up the Microsoft changes on their own schedules. The ThinkPad team typically ships updated BIOS builds faster; the ThinkStation team takes longer to validate the changes against its broader ISV (independent software vendor) compatibility matrix.
  3. Windows Update stages Secure Boot DB/DBX changes to end-user systems in controlled waves. Microsoft doesn’t push Secure Boot policy changes to every machine simultaneously. It uses a staged rollout — sometimes spanning months — so different machines in your fleet can legitimately sit at different SVN levels even if they have all received recent Windows updates.

One more wrinkle worth noting: Lenovo now pre-configures newer-generation machines from the factory with both the legacy CA 2011 and the new CA 2023 Secure Boot certificates already in place. Older units, however, need a BIOS update to pick up those 2023 trust anchors. That factory-level difference alone can produce an SVN gap between otherwise-similar machines.

ℹ️ Key Insight

SVN divergence across a mixed fleet is a normal artifact of the staged update pipeline — not a sign of a compromised or misconfigured machine. The goal is parity over time, not instant uniformity.

What Should You Do?

The good news is that remediation steps here are straightforward. Here is what I recommend:

  • Update BIOS/UEFI on all machines to the latest Lenovo-published version. Head to the Lenovo Support site (support.lenovo.com), search for your specific model, and grab the current BIOS update. For the ThinkStation P3 Ultra in particular, confirm the release notes explicitly mention CA-2023 certificate integration. Do not rely on Windows Update alone to deliver BIOS updates; go direct to Lenovo.
  • Verify CA-2023 is present in the Secure Boot DB using PowerShell. Run the following one-liner on each machine to confirm the 2023 trust anchor is actually installed:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’

A result of True means the CA-2023 certificate is in the DB and your Secure Boot SVN should reflect the update. A result of False means the machine still needs the BIOS update or the Windows Update wave has not yet reached it.

  • For managed fleets, track SVN parity via Intune or MECM compliance policies. Build a compliance rule that surfaces machines whose Secure Boot SVN falls below your defined minimum baseline. That way you can proactively identify stragglers before 2026 certificate expiration forces your hand.

Bottom line: Secure Boot SVN divergence across a heterogeneous fleet of Lenovo machines is normal, expected behavior. It’s no red flag. The firmware update pipeline simply operates in waves, and different product families move at different speeds. What matters is establishing a consistent minimum Secure Boot SVN across all your machines well before the 2026 CA expiration deadline arrives. Start the BIOS update sweep now, and you’ll have plenty of time to close gaps without deadline pressure.

Facebooklinkedin
Facebooklinkedin

Canary Jump Sows Predictable Chaos

After recently clean installing the 2021-vintage Lenovo ThinkPad X12 Detachable Tablet Gen 1 I decided to leave it running a production build.  That means I needed a new Canary channel test machine. So this morning, I upgraded the 2025-vintage ThinkPad P16 Gen 3 to that Insider Preview level. Unsurprisingly, this “Canary jump” sows predictable chaos. Let me tell you what happened, and what I did to recover…

Why Say: Canary Jump Sows Predictable Chaos?

No sooner did I reboot into Canary Build 26300.8246 than did all hell start breaking loose. As is my usual practice, I remoted into that PC from my Flo6 desktop — but not for long. In under less than a minute the PC crashed, and threw a slew of interesting “Critical events” as it went down. You can see them depicted in the lead-in screencap.

Of the 6 items in that list, numbers two through five are relevant. That’s because all cluster in the same minute (11:02 AM) and all are related to my remote session failing, then Windows crashing. The X-Rite Color event simply reflects the program’s unhappiness with running in a remote session (it appears again as item 6, when I start my next remote session).

The others are worth visiting in a little more detail:
• Windows stopped working comes from a bugcheck. Copilot tells me this is most likely owing to firmware or driver issues between the laptop and this bleeding edge release
• This provoked the “not properly shut down” as Windows crashed
• It culminates in the “shut down unexpectedly” as Windows turned itself off
At the start of this sequence an illegal memory reference kicked things off. This is why firmware and drivers are suspects: they’re the most likely perpetrators of such untoward acts.

Chaos Cleanup on Aisle 7!

I now understand my cleanup, had it been performed before upgrading to Canary, might have prevented the crash that occurred. I visited Lenovo Vantage, found a new UEFI update, and installed it. I ran Intel DSA, found four new drivers, and installed them. I ran the NVIDIA app, found new driver version 596.36, and installed it, too.

Now the P16G3 laptop seems to be purring right along. I’ll take it as a lesson learned (and probably re-learned) that it’s a good idea to update firmware and drivers before making major OS changes. Now that I actually stop to THINK about it, that makes pretty good sense. Even in Windows-World, it’s better to plan and aim before firing…

Facebooklinkedin
Facebooklinkedin

OOB KB5086672 Pops Up

I just got back from my morning constitutional. Windows prompted me for a PIN upon login. Then, the “Welcome” screen took 30-plus seconds to spin before I got to the desktop. “Hmmm,” I said to myself, “whaddya bet an update’s been applied to Flo6?” And indeed, upon inspection of the Update History, out-of-band (OOB) KB5086673 pops up at the head of the Quality Updates list.

Why Say: OOB KB5086672 Pops Up?

Flo6 is set up for maximum stability. Thus, it doesn’t sleep. So, for it to prompt me for system entry, I was pretty sure the PC had rebooted. So I asked Copilot to write me a PowerShell check. And sure enough, the results of running said script (see lead-in graphic) show two quick reboots back-to-back just after 1:30 this morning.

The boot type for both shows up as “0x0” which indicates a cold boot that otherwise proceeded and concluded normally. And indeed certain updates — including this one, as shown — do require a pair of reboots to successfully complete their efforts. Copilot says “That 95-second gap is textbook CU finalization timing” and “the reboot…was Windows completing the update you saw in Update History.” Good stuff!

How the Pop-Up Happened

I’ve got the toggle for “Get the latest updates as soon as they’re available” turned on. I’ve also got active hours set from 7AM to 6PM. So when the update triggered last night nothing stopped it from getting downloaded, applied, and rebooting on its own schedule. That’s how the pop-up happened, and why I saw a login prompt when I sat down in front of Flo6 this morning.

Here in Windows-World, things work the way they’re supposed to quite often behind the scenes and (mostly) unnoticed. The login prompt drew my notice, and I’m happy to say “nothing more to see here.” Let’s get back to work, shall we?

Facebooklinkedin
Facebooklinkedin

CU Aftermath: One TPM Update Elicits WTF?

Microsoft’s February 2026 cumulative update, KB5077181, brought most Windows 11 25H2 systems up to build 26200.7840. At least, that’s what I was expecting. But as I rolled out the update across a mix of systems here at Chez Tittel, I noticed something odd. My Lenovo ThinkPads and an ASUS Zenbook A14 quietly updated and rebooted into 26200.7840. The DIY desktop (built on an ASRock motherboard with a Ryzen 5800X) threw a TPM warning and required multiple reboots after a forced cold startup. You guessed it: that one TPM elicits WTF as I must respond to “Update Y/N” for things to proceed.

One TPM Update Elicits WTF, Others Don’t

Let’s unpack what happened. First, the update itself. KB5077181 is a standard cumulative update, but it also includes boot-chain changes that affect Secure Boot and TPM values. On systems with stable firmware and well-behaved TPM implementations, these changes get absorbed quietly. That’s what happened on my Lenovo and ASUS laptops. They rebooted twice and landed on build 26200.7840 without a peep. Copilot tells me that the first reboot is for a servicing stack update, the second for the aforementioned CU.

The ASRock-based Ryzen system, aka “Flo6,” had a different reaction. Upon reboot it froze on a black screen. After I cycled power and forced a cold boot, it presented a UEFI-level prompt. That prompt  warned about changes to the TPM and Secure Boot configuration, and asked me to enter “Y” to confirm, or “N” to deny. This signals that the Platform Configuration Register 7 (PCR 7) that tracks Secure Boot components has detected a change. The system requires manual confirmation to proceed and reseal the TPM, followed with an additional reboot. But man, is that a cryptic message or what? (It appears as the lead-in graphic above.)

Why this discrepancy? It comes down to platform differences. OEM systems like Lenovo and ASUS laptops benefit from tightly integrated firmware, drivers, and update pipelines. Their UEFI implementations are mature. Also, their TPM and Secure Boot configurations get validated against Microsoft’s updates. Thus, they handle PCR changes gracefully and typically reseal the TPM silently with no user intervention.

The ASRock Difference

ASRock, on the other hand, does things differently. Though their firmware is functional and generally reliable, but it’s not as polished or tightly integrated as enterprise-grade or premium OEM systems. ASRock tends to use more standard, out-of-the-box AMI firmware. It offers only minimal validation for Secure Boot and TPM changes. Combine that with AMD’s fTP (known to be more sensitive to boot-chain changes than Intel’s PTT), and you get a prompt for TPM confirmation after updates like KB5077181.

You Get What You Pay For

That’s not to say ASRock is bad. For enthusiasts and DIY builders, their boards offer decent value and performance. But when it comes to firmware maturity and seamless integration with Windows security features, they’re noticeably behind the big OEMs.

The takeaway? Platform matters. As Windows continues to evolve its security posture, particularly around Secure Boot, TPM, and boot checks, users should expect some variation in how different systems respond to updates. OEM systems generally offer a smoother ride. DIY builds like my ASRock-based Flo6, appear to need more attention and manual intervention.

For those who live in the trenches of Windows-World, it’s just another reminder of how things sometimes work, or not. The best antidote is to know your hardware, expect the unexpected, and keep recovery media handy, just in case something goes awry. I’m glad I didn’t need recovery for this update. Indeed, I started wondering when I had to cycle power for a cold start, and an extra reboot to get to the desktop.

Facebooklinkedin
Facebooklinkedin

Chez Tittel Secure Boot Report Card

Here in my house — Chez Tittel, that is — I have 11 computers running. Of that number, 10 have Secure Boot enabled and running. 8 have updated to the 2023 Secure Boot certificate authorities (aka 2023 CA) to replace the soon-to-be-obsolete 2011 CAs. Let’s call this status the Chez Tittel Secure Boot Report Card. Next, I will provide more details.

Presenting Chez Tittel Secure Boot Report Card

You can see that the report card takes the form of a table in three columns. (Open the lead-in graphic in its own browser tab to see the whole shebang.)  Col1 shows the machine name for each PC. Col2 indicates whether or not Secure Boot is enabled. Col3 covers whether or not the new 2023 CA is present or missing.

Here’s a breakdown, with percentages:

  • 10 of 11 machines have Secure Boot enables and running (~91%)
  • 8 of 11 machines have the new 2023 CA in their secure stores
  • 2 of 11 machines are waiting on WU to send them an update. It will add CA 2023 to their secure credentials. (2018 vintage X380 Yoga and the 2020 vintage X12 Hybrid Tablet.)
  • The only holdout is RyzenOfc, whose Asrock B550 motherboard won’t go into UEFI with the ancient NVIDIA GeForce 1070Ti currently installed. I’ve ordered a newer 4070 board and expect to complete the install process to enable Secure Boot and bring CA 2023 on board once it gets here.

Assessing a Mini-Fleet Experience

I was pretty surprised that the OEM PCs made working with Secure Boot and the 2023 CA update more or less routine. I only had to enable Secure Boot on a couple of machines, and the all of their update processes went smoothly. This involved machines from Lenovo (7) and one each from Dell and Asus.

The Asrock B550 PCs were a whole ‘nother story. I now know it’s at least partly because the old Pascal firmware on the 1070 GPUs doesn’t mesh well with UEFI in general. But I also now know that the B550 UEFI itself is a finicky and sometimes cantankerous beast.

Getting the first instance (Flo6, my production desktop) working with SB and 2023 CA  was close to the adventure of a lifetime. I sincerely hope that when the new GPU appears here at Chez Tittel, the second iteration will be easier, less vexing, and nowhere near as drawn-out as the first one was. We’ll see: here in Windows-World anything can happen — and often does!

Facebooklinkedin
Facebooklinkedin

Beta 26220.7262 Update Gets Interesting

Imagine my surprise when I rebooted my old X380 ThinkPad this morning, only to have an Edge window open up on my desktop to proclaim “Your Windows 11 PC has been updated.” And indeed it went on to explain in a series of screens what new stuff I could find should I care to investigate further. I’d just applied the latest Quality Update, only to learn that this Beta 26220.7262 update gets interesting all on its own. You can see the first Edge page as the lead-in graphic above.

How Beta 26220.7262 Update Gets Interesting

In a series of 5 subsequent screens (with a Page Control to match), I saw the following

1. Your PC just got a new sense -- sight
   Try now button
2. Your voice is all you need
   Try now button
3. Stay connected right from the Start menu
   Add either Android or iPhone device from Start menu
4. Transform notes into polished ideas
   Try now button (Notepad gets structure)
5. Unleash your inner artist
   Try now button (Paint offers "creative control")
6. Discover 5 features ... get more from your device
   Discover Windows tips (sub-page with Try now)
   Customize your settings (sub-page with Try now)
   Pin sites to taskbar (sub-page with Try now)

This is all quite interesting, but a little bit disconcerting. The latter, mostly because I wasn’t expecting an unsolicited pop-up on my desktop. Makes me wonder if this is an emerging new kind of post-update behavior for Windows 11. If so — and I hope the team is reading my blog (though I’ll post to Feedback Hub as well) — this is the kind of thing I’d like a Settings option  for under the Windows Update –> Advanced Options hierarchy. Something like “Opt out of post-update notifications” would be nice. If I want to find this info, I already know where to look (that is, in KB5070303, in this case).

Sometimes, surprises in Windows-World aren’t benign. This one is mostly nugatory, if still unexpected. Gosh, you’d think they’d have mentioned that Windows will open an Edge window with update news in the Announcement as well — but they didn’t. Go figure!

Facebooklinkedin
Facebooklinkedin

DISM /Add-Packages Loses Windows 11 Mojo

This week, I’ve been updating a story for ComputerWorld. Along the way, I learned a little about .msu files for the Microsoft Update Standalone Installer. They differ widely between Windows 10 and 11. TLDR version: it’s pretty easy to extract a usable .cab file from Windows 10 .msu from Microsoft Catalog downloads. For Windows 11 .msu, it’s not. That’s why I observe that DISM /Add-Packages loses Windows 11 mojo. Let me now explain…

Why Say: DISM /Add-Packages Loses Windows 11 Mojo

The contents of .msu files for Windows 10 versus 11 updates reveals some stark differences. For recent such updates  I chose KB5066791 for Windows 10, and KB5067036 for 11.

Turns out you can open .msu files in 7-Zip to examine their contents. The two files couldn’t be more different internally. The latest 10 update includes 5 files and is just over 700MB in size. The latest 11 update includes over 100K files and comes in at just under 3.5 GB.

The really big difference is that DISM /Add-package /online (the incarnation of that command that permits working on a running Windows image) REQUIRES a .cab file to do its job. Simply put: Windows 10 makes that easy to find, extract, and use; Windows 11 makes it pretty much impossible.

Where the Mojo Went…

That means you can use DISM /Add-Package on Windows 10 to apply updates to a running image, when Windows Update isn’t working or something goes sideways with some particular update. But if you want to use DISM to add a package to a running Windows 11 image, you must take that image offline, apply the update, then bring the image back online.

The net effect is that a quick and handy alternate update technique that works fine for Windows 10, turns into a slow and cumbersome slog for Windows 11. Better to try something else, instead. I’m sorry to lose a helpful tool from my Windows fixes and workarounds toolbox, but that’s the way progress sometimes works in Windows-World.

Facebooklinkedin
Facebooklinkedin

Driver Upgrade Fixes 0xC1900101 Errors

I’ve seen it  before, and I’ll probably see it again. When I first ran the Beta Channel upgrade to Build 26220.7051 on Friday, it failed during the post-GUI install (aka SECOND_BOOT) phase . Basically, it hung at 10% complete for half an hour or longer, and I force-rebooted the X380 Yoga. When the rollback process completed, WU/Update History showed me an error in the 0xC1900101 range. From long experience I recognized this as some kind of device driver issue. Fortunately, a driver upgrade fixes 0xc1900101 errors. Let me tell you more…

Why Say Driver Upgrade Fixes 0xC1900101 Errors?

Alas, I didn’t record the exact error code string yesterday. I simply grabbed the latest version of Snappy SDIO from PatchMyPC Home Updater, and used it to upgrade the drivers on the X380. (TMI: That’s version R817, as far as I can tell.) This took about half an hour, give or take 5 minutes, and replaced 17 drivers.

The next go-round on the update process took quite  a while to complete (probably a bit over an hour). But it went all the way through, and resulted in a successful installation. The table you see in the lead-in graphic here comes from Copilot after I asked it to tell me about 0XC19001… Windows 11 install errors. It’s pretty informative, so I figured I’d share it.

Here in Windows-World, when a Windows 11 install goes wonky, it’s nice when prior experience retains its relevance for current troubleshooting. Again: I’m glad the tried-and-true technique for this kind of error code still works.

Facebooklinkedin
Facebooklinkedin