Uncategorized

Secure Boot Report Card Perfected

Leave a comment

On February 4th, I recounted the Secure Boot status of my local fleet, along with machines possessing CA 2023 secure boot certificates. At that time, I had 3 of 11 PCs with no CA 2023 secure boot certs. One also couldn’t enter UEFI with Secure Boot enabled. My secure boot report card is now perfected. All 11 machines have secure boot enabled AND CA 2023 certs in their credentials stores.

How Did I Get Secure Boot Report Card Perfected?

Short answer: time, effort and (in one case) a hardware purchase. Now for a somewhat longer answer. Both holdout machines with SB enabled, but no CA 2023 present were two ThinkPads. First, the X380 Yoga, a 2018 vintage 7th-gen Intel-based laptop. Second was X12Hybrid, a 2020 vintage 10th-gen Intel based tablet.

The same fix worked for both machines. The inestimable long-time member at ElevenForum.com named @Garlin has a terrific thread. It’s entitled garlin’s PowerShell scripts for updating Secure Boot CA 2023. It includes a script named Check_UEFI-CA2023.ps1. If you run that script it not only tells you if the CA 2023 cert is present or absent. If CA 2023 is absent, it also provides two commands to put it in place. That worked for both of my ThinkPad holdouts.

Note: The lead-in graphic for this story shows the following:
1. Invocation and output from the Check script just mentioned.
2. Execution of the reg edit and scheduled task to add CA 2023.
3. Final check string to show CA 2023 is present in the SecureBoot UEFI db (database).

The Third Holdout Proves a Bit Trickier

The old NVIDIA GeForce RTX 1070Ti installed in the upstairs ASRock B550/AMD Ryzen 5 5800X desktop named “RyzenOfc” wouldn’t enter UEFI with Secure Boot enabled. Turns out the firmware on its older GPU just couldn’t coordinate with TPM changes. I bought a Gigabyte RTX 5060 because it was compact enough to fit the smallish RyzenOfc Antec A-201 case. That got me back into UEFI where I could install the default keys and get secure boot working properly.

After that, the same Garlin script cited above also got CA 2023 into the credentials store on RyzenOfc. It’s taken a good chunk of the last two weeks, and cost me a chunk of change — I also bought a new mouse and keyboard that skips USB enumeration issues and Fn key gotchas in getting to UEFI, plus the GPU — to finish this journey.

Just for grins I checked CA 2023 status on the ThinkPad P16 Gen 3 that showed up on Monday. It didn’t have the new certs, either, so I fixed it with commands from the Garlin check script, too. All good!

But at last, all my machines are Secure Boot enabled with the CA 2023 certificate installed in that environment. What a long, strange trip that turned into. I’m glad it’s over, and I learned a LOT along the way. I also heartily recommend the Garlin scripts to anybody facing uncertainty or issues in getting CA 2023 Secure Boot certs onto their PCs. Great stuff!

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

Chez Tittel Secure Boot Report Card

1 Comment

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
Uncategorized

Buying New(er) GPU For RyzenOfc

Leave a comment

Back in late 2021/early 2022, I bought a pair of motherboards for side-by-side PC builds. One for me, one for my son to use at home. I also bought an NVIDIA 3070Ti GPU so he could game away. But that latter plan didn’t turn out because his PC case — an Antec A201 — was too small inside for that GPU. We stuck with our older 1070Ti models because they fit. Just recently, I’ve been working to get Secure Boot running on those PCs. I wasn’t able to get it up on Flo6 (my office desktop, now in a bigger case) until I swapped the 1070 GPU for that 3070 model. I still haven’t been able to get back to UEFI on the upstairs model (his former desktop). That’s why I’m buying newer GPU for RyzenOfc (desktop machine name). Let me explain…

Why Buying Newer GPU For RyzenOfc Could Help

The older 1070Ti has Pascal generation firmware, while the newer 4070 has Ada generation firmware. The 1070 firmware is 11 years old, or thereabouts, and lacks features and capabilities that newer firmware environments — including UEFI, TPM and Secure Boot — need. Copilot put a feature table that lays things out nicely for easy perusal and comparison.

Basically, I was unable to get past the graphics output protocol (GOP) phase during boot-up with the 1070 installed. The PC froze there every time. I could still get to Windows (straight to the lock screen, in fact) but I never could see the Asrock initial boot-up logo, nor could I use Del or F2 to get into UEFI.

Can’t Do Secure Boot Except via UEFI

That last little bit is a dealbreaker. If I can’t get into UEFI, I can’t turn secure boot on. Nor can I load the default Secure Boot keys, essential to resetting TPM to let the whole Secure Boot infrastructure get put in place. Bit of a problem, that…

So I ordered a used compact NVIDIA 4070 GPU to replace the 1070Ti. It’s due in next week. And I’m betting a reasonably substantial sum that when I pop the new GPU into the PCIe x16 slot the 1070 currently occupies, I’ll be able to get through Secure Boot installation.

We’ll see: I’ll report back then. Stay tuned, and check your own PCs for status. On older builds you, too, may need to start making some changes. In PowerShell, Confirm-SecureBootUEFI  shows “True” if it’s on, “False” if it’s off. Likewise, Get-SecureBootUEFI -Name db will show you if you have the new UEFI CA 2023 certificate installed or not (the old 2011 certificates expire later this year, so it’s time to get ready).

Here in Windows-World the old saw from Roseanne Roseanna-danna often applies: “It’s always something!” And indeed, this time it could be something somewhat costly, as well. Sigh

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

KB5074105 Brings On Secure Boot

1 Comment

Just when I’d more or less given up, along comes KB5074105 on January 29. In its “Normal rollout” fork, the first item to appear is entitled [Secure Boot]. That item (partly depicted above) also explicitly mentions boot manager updates for UEFI CA 2023. And indeed, after I installed and rebooted from that update, I was finally, finally able to get Secure Boot working on the Flo6 desktop. It ain’t necessarily easy or quick, but KB5074105 brings on Secure Boot capability to at least some machines that need it.

With Some Effort, KB5074105 Brings On Secure Boot

You’d think it would be as easy as falling off a log to get Secure Boot (SB) working after the update. You’d be wrong. I had to go through eight (8!) steps after that to set things to rights:

1. Reboot into UEFI and enable Secure Boot
After KB5074105 updated the boot binaries, I could finally toggle Secure Boot ON without triggering a pre‑GOP (graphics output protocol) stall. This was the first sign the trust chain was now compatible with the 2023 CA.

2. Switch Secure Boot Mode to Custom
This exposed the key‑management interface, allowing me to directly manipulate PK, KEK, db, and dbx. Standard mode hides these controls.

3. Install the factory default Secure Boot keys
Reloaded the OEM/Microsoft default PK, KEK, db, and dbx. This rebuilt the entire Secure Boot hierarchy from a known‑good, signed set.

4. Save and reboot to exit Setup Mode
Once the keys were installed, the firmware left Setup Mode and re‑entered User Mode, meaning Secure Boot enforcement was now active.

5. Boot Windows with Secure Boot enabled
Windows successfully validated its updated boot chain (thanks to KB5074105) and completed a full boot under Secure Boot for the first time on Flo6.

And That’s Still NOT the End of the Ride…

6. Rebuild the TPM trust state
Because Secure Boot changed the PCR profile, Windows had to re‑establish TPM‑sealed secrets. This required signing in with my password and letting Windows reseal keys.

7. Reprovision Windows Hello for each MSA
Both my primary and secondary MSAs needed fresh Hello containers because the TPM and Secure Boot trust anchors had changed. Each account required a password login followed by PIN setup.

8. Rebuild WAM tokens for Store/Xbox/MSA services
Once Hello was re‑established, the MS Web Account Manager (WAM) regenerated its token sets. This cleared the Xbox PIN loop and restored cloud‑service authentication. Indeed WAM allows apps to silently authenticate using Hello-based credentials.

A lot of this is new to me, because I’ve never had to set up SB on a PC before. My other PCs from Lenovo and Dell have done a fine job of doing it for me. This is the first time I’ve done it for myself… and it’s been much more of an adventure than I expected. Wow!

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Secure Boot Oddities Accumulate

Leave a comment

Although I’m resigned to living without secure boot on the B550-based desktops here at Chez Tittel, that doesn’t stop me from trying other fixes from time to time. Indeed, I discovered a great thread about secure boot keys at ElevenForum, and learned more about what’s going on under the hood. Along the way, I gave myself a terrific scare as I saw more secure boot oddities accumulate. Here’s what happened…

Registry Key Change Helps Secure Boot Oddities Accumulate

One must provide Windows with a a couple of instrux to ask the OS to update secure boot key certificates, to wit:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40

Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”

One is then instructed to reboot Windows twice to get those instructions to work as they’re intended to. What it doesn’t say is that strange things might happen before the first reboot occurs.

Black Screen, No UEFI — No Nothin!

I about had heart failure when I rebooted my PC this morning and the Flo6 came up black with no normal boot sequence. No Asrock logo, no instructions to hit Del or F1 to load EFI, no F11 for boot menu. There’s not much one can do to fix a Windows PC that won’t do anything, short of taking it into a shop.

So I turned off the power supply, then hit the power button for 10 seconds to make sure all the capacitors got discharged. Then I took a break and walked away from the machine for 10 minutes. Then I powered on again. Phew! This time, the Asrock logo appeared, and it booted into Windows 11.  To my great relief, the second reboot was no big deal, and I was glad.

Here in Windows-World, you can make big changes without incurring at least some risk. This morning, I wondered if I’d bitten off more than I could chew. I even wondered if I’d bricked the Flo6. Thank goodness, I had not. I’ll take that as a win, even though you can see in the lead-in graphic that 2023 keys remain absent on this PC. Go figure!

 

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

Returning Spurious Reclaimables Removed

Leave a comment

For the past couple of years, I’ve watched various Windows updates and upgrades introduce and re-introduce what I call “spurious reclaimables.” These are windows packages that show up in the component store that (a) don’t need to be there and (b) refuse removal using dism /online …. /StartComponentCleanup. Just yesterday, Copilot helped me figure out how to yet again make them go away. That’s because I saw a familiar set of returning spurious reclaimables removed on the ARM-based ThinkPad T14s Gen 6.

Getting Returning Spurious Reclaimables Removed

There are two such packages in this mix, each with characteristic, fairly unique substrings — namely “RollupFix” and “FodMetadata.” So that’s what I used to find that stuff in the package store:

dism /online /get-packages /format:table | findstr /i “RollupFix”
dism /online /get-packages /format:table | findstr /i “FodMetadata”

Those commands let me find the precise package names that I would go on to use to remove the spurious ones from the package store. Indeed, Windows 11 24/25H2 continues to surprise even seasoned Windows hands with its servicing behavior—especially on ARM64 systems. Here’s a short but hopefully illuminating dive into how ARM64 handles staged vs. installed packages, and why some packages appear removable even when they aren’t.

Working Through the Process: RollupFix

Here’s my starting point — namely, two RollupFix Packages. One is staged and the other installed. On the T14s laptopn  DISM /get-packages listed two versions of the RollupFix package:
– A staged version: 26100.1743.1.3
– An installed version: 26100.7674.1.3
Both appeared to be reclaimable. So I started with the older, staged version, and provided a DISM command to remove it:

dism /online /remove-package /packagename:Package_for_
RollupFix~31bf3856ad364e35~arm64~~26100.1743.1.3

(Note I stuck a CRLF into that line to make it lay out better. To cut’n’paste that item, stick into Notepad and turn it into a one-liner.)

DISM happily complied with that command and responded with: “Processing 1 of 1 – Removing package … The operation completed successfully.” So far, so good. But the next step revealed something interesting, as I attempted to remove the newer, installed RollupFix package (same syntax as above, new package name).

This time, DISM responded with an error message, to wit: “Error: 0x800f0825 — the package is permanent or not applicable.” That means once the staged version got removed, the installed version became the baseline and couldn’t be removed. This mirrors AMD64 behavior, though ARM64 expresses things more forcefully. Removing the superseded version effectively locks in the newer one, making it “permanent” and non-removable.

Further into the Process: FodMetadata

The T14s also offered up two versions of the FOD metadata servicing package, one staged, the other installed:
– Staged: 10.0.26100.1743
– Installed: 10.0.26100.7674
Again I started with the staged version. This time DISM responded with Error 0x800F0805 “the staged package is already gone.” ARM64 appears to auto-clean the staged FOD metadata package when the staged RollupFix package is removed.

That’s a subtle but important difference from AMD64, where the FOD metadata package is removed automatically only when the installed RollupFix is removed. Thus, removing the installed version worked as it should, and that operation completed successfully.

Final Check: Clean Component Store

When I ran a followup /analyzecomponent store check in DISM after those various attempted and successful removals, I got clean store billing, as reported in these output lines for that command:

Number of Reclaimable Packages: 0
Component Store Cleanup Recommended: No

That means the component store is clean, and there are no more reclaimable packages, spurious or otherwise, to get rid of. That’s what I like to see! You can see further confirmation in the lead-in graphic which shows only “Installed” versions for the two packages that previouly included older, obsolete staged versions prior to the cleanup moves I described above.

 

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Understanding El-Cheapo Windows Licenses

Leave a comment

Every so often, a new round of bargain‑basement Windows license deals makes the rounds. You’ve seen them: Windows 11 Pro for ten bucks, Windows 10 Pro for even less. They pop up on StackSocial, StackCommerce, and a handful of deal‑driven tech sites. And like clockwork, the obvious question arises: Is this for real, or too good to be true? Neither and both: indeed, understanding el-cheapo Windows licenses hits both sides of this common wisdom.

More On Understanding El-Cheapo Windows Licenses

As someone who’s been around the Microsoft ecosystem for a long time — and who has more legit keys than I’ll ever need thanks to MVP status — I find the whole phenom fascinating. Not because I need another license, but because these offers sit right at the intersection of Microsoft’s licensing rules, its activation infrastructure, and the gray‑market economy surrounding both.

Here’s the key (pun intended): activation and licensing are not the same. Activation is a technical handshake with Microsoft’s servers. Licensing is a legal framework that governs how a key is properly obtained and used. Those two systems overlap, but they don’t enforce each other as tightly as many expect and assume.

Most $10 keys fall into one of three buckets. The first is unused OEM keys pulled from bulk hardware purchases. Perfectly valid keys, never activated on their original devices, but not transferable under Microsoft’s rules. The second bucket is decommissioned or oversold MAKs (multiple activation keys) — volume license keys with high activation counts that get resold repeately. They activate until the pool runs dry. The third bucket is region‑restricted retail keys, bought cheaply in low‑cost markets and resold elsewhere. They activate just fine, and Microsoft rarely retroactively enforces region boundaries.

None of these keys is counterfeit. They’re simply not authorized for retail distribution and sales. And that’s the crux of the matter. A key can be technically valid and still not legitimate under Microsoft’s licensing terms. That’s why you see disclaimers like “Microsoft may deactivate this license” — something never attached to a true retail key.

Why Not Stop This Madness?

So why doesn’t Microsoft shut this down? Because enforcement is aimed at organizations, not individuals.  Say a corporate MAK pool gets audited and is found to be leaking keys. Then, the consequences fall on the organization that holds the license — not the end user who bought a $10 key online. Microsoft’s activation infrastructure is built for compatibility and ease of deployment, not aggressive policing. As long as the upstream license pool stays quiet, the key will likely keep working.

That’s why you see technically savvy users reporting years of trouble‑free activation. They’re not wrong. They’re simply describing the operational reality, not the licensing reality.

In the end, these cheap keys occupy a curious middle ground: not fake, not fully legitimate, but functional and low‑risk for individual buyers. They’re a reminder that Windows licensing is strict on paper, pragmatic in practice, and full of gray areas that only get more interesting the deeper you dig.

Here in Windows-World one perforce gets comfortable with gray areas. This one seems a bit more gray and shadowy than most, but there you have it!

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

Copilot: Driver’s Education

Leave a comment

If you read yesterday’s blog, you already know that I spent most of the weekend with my Flo6 desktop in UEFI, booting, or at the command line in WinRE/WinPE. On the other PC next to my desk chair, I keep a Lenovo P16 Gen1 Thinkpad. I was running Copilot on that PC, looking for insight into making Secure Boot work on the Flo6. Simply put, you can’t ask for help in Windows when that OS isn’t running. During that process I ended up in class for Copilot: driver’s education became quite a concern as I had difficulty scrolling down to read longish replies to my prompts and queries.

What Copilot Driver’s Education Is About

Turns out my scrolling attempts were misguided. I didn’t really understand how the touchpad on the P16 works. As you can see in the prompt window I’m using in this post for a lead-in graphic, the P16 touchpad is  more oriented to gestures than to driving screen controls.

While I was working over the weekend, I simply popped in a wired mouse — complete with scroll wheel — and used that to speed scrolling while interrogating Copilot on the P16. After I had time to dig in a bit deeper, I learned that a two-finger gesture works for scrolling that touchpad quite nicely (two-finger sweep up to scroll down, down to scroll up — shades of Doc in the movie Cars).

Hah! I’ve been using Copilot since it first showed up over two years ago (June 2023) and didn’t know that this till this weekend. Probably because I still mostly drive with a mouse and not a touchpad. Now I know. Here in Windows-World, it’s the little things that sometimes make a big difference…

Facebooklinkedin
Facebooklinkedin
AI, Insider stuff, PowerShell, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Secure Boot Pursuit Undone

2 Comments

We’ve been (and still are, I kid you not) snowed in here in Central Texas. With Winter Storm Fern bearing down on us, we started hunkering down here last Friday (1/23). On Saturday we had rain, sleet and snow, and woke up to snowy sights Sunday. Figuring I had time on my hands, I decided to see if I could get Secure Boot working on my Asrock B550 Ryzen 7 5800X Flo6 production desktop. Alas, after much wrestling with hardware and software, I saw my Secure Boot pursuit undone early, early this morning. Let me explain…

Why Is My Secure Boot Pursuit Undone?

Through all kinds of contortions (see list below) I couldn’t get the PC to boot with Secure Boot enabled. Let me enumerate some of them so you can appreciate what I tried and failed to get done this weekend:

  • 2 repair  installs of my current running OS
  • 1 “dirty install” (do not format partitions, but run installer which moves old OS into Windows.old and creates a new one: IDKYDT)
  • At least 2 each dism /restorehealth, sfc /scannow & chkdsk
  • Remove boot/sys drive from its M.2 slot to wipe NVMe config data from UEFI (have to remove GPU to access slot, sigh)
  • Swapped out old, soon-to-be obsolete 1070 Ti for 3070 Ti GPU.
  • spent over 30 hours fiddling with UEFI and Windows configs

After the “dirty install” I realized I’d hosed the primary MSA login on my main work machine. Not acceptable!! This morning, I built a new Macrium Reflect X Rescue disk, extracted the drivers from the Flo6, and restored my most recent backup (Friday afternoon, after I’d reorganized the boot/sys drive partitions).

Back in Business, Back to Work!

I learned a bunch about boot configuration data and related commands. I’m definitely completely up on booting the Flo6 into WinRE, Windows installer media, and the Macrium Rescue Disk. I’m much better acquainted with the Asrock UEFI than I’ve ever been before.

I also learned that my old MS Comfort Curve 4000 keyboard can’t (or won’t) send Fn key data to UEFI. Working on the ThinkPad P16 Gen 1 I soon figured out scrolling Copilot output was MUCH easier with an external mouse with scroll wheel than using the touchpad. Who knew?

And finally, I learned that Copilot will lead you all over the place trying to solve problems, heedless of time involved and consequence entailed. Sure, AI will tell you pretty much anything about Windows you want to know, but I wasn’t happy with the circuitous routes it took me on, and the circles it spun me through. Then it occurred to me: the words mendacious, malicious, utopia, and paradise all include AI, as do the phrases folie a deux and waste of time. Here in snowed-in Windows-World this weekend, I saw all those things play out. It was oddly engaging, but I’m glad it’s over.

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

Catching Up Can Be Hard to Do

1 Comment

I’ll admit it. I’m lazy. When I hooked up the Lenovo ThinkCentre Neo 50q Tiny PC a couple of weeks ago, I cheated. How? By hooking up the power, networking, video, keyboard, mouse and camera that had previously been driving the ThinkStation P3 Ultra Gen 2 mini-PC. Yesterday, I had some free time so I unhooked the former and reconnected to the latter. Given the hiatus a storm of updates followed (as expected). When I checked Reliability Monitor (ReliMon) this morning, I found a couple of unexpected errors for the Lenovo TSSIOMonitor (aka Super IO Monitor). When I asked Copilot for help reading those tea leaves, its response: “Catching up can be hard, especially after a prolonged idle period.”

Why Catching Up Can Be Hard

As I look at ReliMon for yesterday afternoon, I see a steady stream of updates and installs that start at 3:38PM and run through 4:09PM (60 in all). According to Copilot, TSSIOMonitor.exe is a Lenovo executable that’s constantly monitoring hardware. Its job is to throw errors when things don’t look or work correctly.

One potential cause of the error is when sensor data is invalid. Another is when driver data doesn’t match what the monitor expects. That’s precisely what happens when chipset drivers update, ACPI tables get rebuilt, embedded controllers reinitialize, and Super I/O registers may be unstable. Basically, the monitor was  using stale data to analyze a fresh situation, and erroring because of inevitable mismatches. Good to know.

Copilot Offers Insight, But I Must Assess Same

I’m getting used to asking Copilot to opine on system stuff when I need help understanding what’s going on. It certainly has more access to deep Windows arcana that I do, but I do notice occasional hiccups and hallucinations as it recites specific details. Indeed it sometimes goes off on tangents that don’t relate to my specific situation, but do play into the general circumstances and experiences around it.

This time, Copilot’s explanation makes good sense. And it helps me understand why such errors might occur when they did. It’s even comforting for it to tell me what I already knew: that a one-off or two-off error while a bunch of updates are underway isn’t terribly concerning. But we both agree that if it kept on happening (TSSIOmonitor.exe has been quiet ever since updates finished) there would be cause for concern, and possible action.

What Ronald Reagan said about nuclear arms monitoring apparently also provides to ingesting information from Copilot: “Trust, but verify.” Words to live by, here in a brave new AI-informed Windows-World.

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness