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

Web Extensions Stymie Input

Leave a comment

While trying to conduct a cash transfer online yesterday, I ran into an interesting — and new (to me, anyway) — problem. In attempting to provide account and identity information I found myself unable to enter data into the very input form that was soliciting same. “Hmmm,” I wondered to myself, “Why is this not working?” So I decided to ask Copilot. It immediately informed me that things such as auto-fill. password managers, and related “conveniences” can step all over input fields inside certain web pages. The TL;DR diagnosis, put succinctly, is some Web extensions stymie input.

Copilot recommended that I open an incognito window, and try again. Guess what? That worked like a champ!

Why Web Extensions Stymie Input — In Some Cases

In my case it looked like a combination of Chrome auto-fill and the Norton Password Manager were conspiring against the input page to prevent it from seeing and handling my input as it should. As soon as I got those things out of the way, the input problems disappeared.

I’ve been building websites and writing about markup languages for over 30 years now, and this is the first time I’ve run into this phenom. Apparently I’ve been incredibly lucky, because it happens on a lot of websites, especially those built to handle multiple languages and character sets. It just so happens this particular gotcha never bit me until yesterday, when it bit hard (and drove me just a  tad bonkers).

KISS Remains a Valuable Approach to New/Unfamiliar APIs

KISS is, of course, the acronym for “Keep It Simple, Stupid!” It’s a good approach to keep in mind when working with new and unfamiliar apps, user interfaces, and the code beneath those skins. By simplifying the text handling the browser performed when providing input, I allowed the target web page to do its job without lots of other stuff going on in the background.

A simple, straightforward text entry environment let the web page accept input straight from my keyboard, with no extra processing or data delivery. Apparently, that was just what it wanted or needed to get the job done.

Here in Windows-World, not stepping on yourself is often the key to a successful user experience. Once my browser got itself out of the way, the web page was able to take it from there. I’ll count that as an unqualified success, and an interesting learning experience.

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

Why Switch One 2020 Mobo for Another?

Leave a comment

I’m surprised. I’m actually considering replacing a 6-year-old Asrock motherboard with an MSI of the same age. Basically, I’ve gotten tired of fighting UEFI and firmware issues on the Asrock that serves as the foundation for my production desktop. I see reviews and other online evidence that the MSI MAG B550 Tomahawk Max will solve those problems. It costs US$150, which is a relatively small sum when compared to the days and days I’ve spend fighting with the Asrock board in the last month.

Why Not Switch One 2020 Mobo for Another?

I’m pretty sure I can take Flo6 apart, swap mobos, and get back up and running in an afternoon. I’ve almost had to take the whole thing apart half-a-dozen times recently to pull the GPU, various drives (including the primary SSD), and the CMOS battery. Why not go all the way?

Simply put: I don’t feel like funding a complete rebuild into a new system right now, given prevailing costs for RAM and SSDs. I can make this switch for another US$150, versus US$2,650 for a similarly equipped i714700K based build.

That’ll have to wait for the general exchequer to charge up a bit. Maybe next year? For now, I’ll be happy to get a system that boots properly, and handles Secure Boot without major issues. Let’s see what happens, shall we? I’m giving it a try…

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

Resetting CMOS Has Its Hurdles

Leave a comment

You’d think it would be dead easy. And to be fair, on some motherboards it is. But popping (or replacing) a CR2032 3V coin battery — especially when resetting CMOS — has its hurdles to overcome. At my age, clear visibility can get interesting. Then, there’s often limited space inside the PC case to reach the darn thing. In dealing with recent Secure Boot (and related CA 2023 boot certificates) recently, I’ve been reaching for the CMOS battery rather more often than not.

OK, Resetting CMOS Has Its Hurdles: Name Some…

Beyond the two already noted (visibility and space), I also bumped into various other impedimenta, including:

  • Removal techniques: new sockets may not yield to a fingernail, so I found a small flat-head jeweler’s screwdriver helpful
  • Timing: most guides say to leave the PC alone after popping the battery for anywhere from 10 seconds to 5 minutes. I made sure I had something else to do before removing the battery and erred on the “too long” side of things. Seemed to work.
  • Reinsert the old or replace with a new: If it’s been more than 3 years since I replaced the battery (or I can’t remember) I’ll replace rather than reinsert a CR2032. They typically cost US$5 or less, so if I have to remove it anyway, why not replace it, too?
  • Making room: On at least a couple of desktops, I have to remove the GPU just so I can SEE the CMOS battery holder. On any given laptop at least one deck has to be removed; sometimes other assemblies (e.g. keyboards or storage modules) must also go.

But when a PC goes truly off the rails — especially when BIOS or UEFI becomes inaccessible or non-responsive — a CMOS reset can often set things back to rights. That’s why I find myself digging for my replacement stash from time to time, so I can put a fresh one in to replace the older one at the same time.

Nothing says resetting CMOS has to be easy, here in Windows-World. But lots of times, it’s a necessary step in the troubleshooting process. So it goes…

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

Thunderbolt 5: Video Good, Storage Bad

2 Comments

I finally laid hands on a Thunderbolt 5 NVMe enclosure this week. I shouldn’t have bothered, though I learned something important. Aping Alex Karras’s unforgettable character Mongo in Blazing Saddles, I have to say that for Thunderbolt 5: “Video Good, Storage Bad!” Let me explain.

Why Say for Thunderbolt 5: Video Good, Storage Bad

TLDR version: the channel is fast, but PCIe tunneling bandwidth peaks out at PCI 3.0 x4 levels. I tested a blazing fast Crucial T705 NVMe inside a brand-new Acasis TB501Pro NVMe enclosure (it cost me US$200+tax). It underperformed both the Samsung 970 EVO and the Crucial P3 NVMes I also tried out in that same box.

How can this be? Easy: The current TB5 controller generation from Intel — code name Barlow Ridge — includes a PCIe endpoint block that handles storage transfers to/from the TB5 USB-C port on the PC side of the connection. It’s hard-wired as PCIe 3.0 x4, which limits effective bandwidth for the link to somewhere around 3-4 GBps. Thus, there’s no real advantage in this generation of hardware in buying a TB5 NVMe enclosure.

Indeed, performance from a TB5 NVMe enclosure with a Barlow Ridge controller is the same as the USB-C port on my otherwise mind-blowing ThinkPad P16 Gen 3 laptop (which uses the same controller for TB5/USB4.0 v2). This isn’t going to get better until a next generation of controllers comes out, hopefully with a faster PCIe tunnel to boost NVMe access. This hardware doesn’t do what I wanted and hoped it would: offer 6-7 GBps speeds for external NVMe storage devices. That won’t change until Intel builds something faster for PCIe access.

In the meantime, save your money: you’ll get the same performance out of a TB4/USB4 NVMe enclosure as from this newer model, for around half the price. I’m sending mine back to Amazon, thankful for its “failed to live up to expectations” return policy. Sigh.

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Remote Desktop (RDP), WED Blog, Windows 11

Fixing Failed MSA Remote Login

Leave a comment

Every so often, I run into Windows 11 behavior odd enough to make me scratch my head. Occasionally, I’ll observe that my Microsoft Account (MSA) logins work perfectly at the local console. But they fail constantly if used within Remote Desktop Connection. The error? A familiar one: ‘Your credentials did not work. The logon attempt failed.’ Today, I’ll explain what worked for me when fixing failed MSA remote login.

In the meantime, I’d been working around this issue by setting up a Local account named “LocalOnly.” You can see it mentioned in the lead-in graphic for this blog post. If my upcoming technique doesn’t restore your MSA’s remote access as it did mine, you can use a local account to remote into a balky remote host if your MSA won’t work.

Refusal of Known, Good, Working Login

You may see this message while trying to RDP into a Windows 11 machine using an MSA. If so, you know how frustrating it is. Especially when you know those credentials are correct, and you can use them locally, no problem. What gives?

As it turns out, the answer lies in a complex and sometimes fragile identity stack that underpins Windows 11’s user authentication . Let’s unpack what’s going on under that hood.

Windows 11’s identity model for MSAs is built on three interdependent layers:

  1. SAM (Security Account Manager) – The local account database. It stores user SIDs (Security Identifiers) & basic account metadata.
  2. WAM (Web Account Manager) – The token broker that handles cloud authentication for MSAs. It’s responsible for storing and refreshing tokens so services like RDP can validate your identity.
  3. Ngc (Next Generation Credentials) – This layer handles Windows Hello and TPM-tied credentials, like PINs & biometric logins.

When all these layers are working and cooperating, things go swimmingly. Sometime though, particularly on Insider builds where MS is messing with this identity stack, things can get weird. Over time changes can mean an MSA works locally but not remotely.

A Swicheroo Is Key to Fixing Failed MSA Remote Login

Here’s what was happening on my ThinkPad X380 Yoga. I could log in locally using my MSA. But RDP logins would consistently get refused with the error message that serves as the lead-in graphic. After ruling out more obvious causes (e.g. network issues, RDP settings, firewall rules) I thought about the situation. Because local login worked, SAM and Ngc layers were probably OK. That presented WAM as a likely cause.

The fix, then, was simple. I rebuilt the WAM token cache, to make sure all pieces harmonized. Here’s what I did:

1. Log in locally using MSA
2. Visit Settings > Accounts > Your info
3. Change to “Sign in with a local account instead”
4. Sign out, or Reboot PC
5. Login locally using local account name/pwd
6. Visit Settings > Accounts > Your info
7. Change to “Log in with a Microsoft account”
8. Reboot PC

The switcheroo undid the link between the MSA and the account, made it local, then re-established a new connection. That completely rebuilds the whole infrastructure, including the WAM.

After that switcheroo (MSA > Local > MSA) RDP worked fine from my Flo6 primary desktop into the X380. The odds are good this technique will work for you, if you get caught in this situation. Here in Windows-World, a switcheroo sometimes works wonders. It did here, anyway!

 

 

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

AMD Gets New Chipset Driver

Leave a comment

Here I go again. I read this morning on Neowin that AMD had dropped a new version of its chipset drivers, including the B550 in my Flo6 and RyzenOfc desktops. Time for an upgrade! I found what I needed at the Chipset Driver Release Notes 8.01.20.513 page (a 62.5MB download named amd_chipset_software_8.01.20.513.exe). After applying that file, AMD gets new chipset driver upon reboot. What happened on my ASRock system was a little more vexing…and complicated. Let me explain…

After AMD Gets New Chipset Driver, Comes a Reboot

The UEFI on my ASRock B550 Extreme4 motherboard is a little tetchy. Whenever the firmware or drivers get touched (updated or replaced), it tends to hang on a black screen after a reboot intended to flush out old stuff and bring in new. Sure enough, that’s what happened after the AMD chipset installer fired off a restart with my express permission.

I had to do a deep cold start to bring the motherboard back to life. That meant:
1. Hold the power button down until the system turns off
2. Turn off the PSU
3. Hold the power button down another 10-15 seconds to discharge any capacative devices
4. Turn off, then unplug the power cord from the PSU
5. Wait 2-5 minutes for everything to turn itself completely off
6. Plug the PSU back in, turn on its power switch
7. Use the front power switch to start the PC back up
Fortunately, that worked and the unit came back to life.

Checking the Install

I’m learning to make doubly-darned sure that an update actually gets applied, thanks to some recent misadventures with Secure Boot. I visited Device Manager and made sure no yellow triangle warnings popped up, nor did anything appear under the always-annoying “Other Devices” heading.

At Copilot’s urging, I also checked the install dates for all of my AMD drivers. Copilot also confirmed that those dates matched the latest ones in the afore-linked release note (and hence, should be current).

I used this handy PowerShell one-liner to elicit the data shown in the next screencap:

Get-WmiObject Win32_PnPSignedDriver |   Where-Object { $_.DeviceName -like “*AMD*” } |  Select-Object DeviceName, DriverVersion, DriverDate

Here’s the resulting output:

After checking these against the release notes, reported dates = current dates.

It looks like the chipset update got properly applied. Copilot tells me other UEFIs will reboot after a chipset update without the 7-step polka the ASRock board needed. I wish I had another AMD system around here to verify that claim. But here in Windows-World we don’t always get what we want. Good enough for now, I guess!

Facebooklinkedin
Facebooklinkedin
Uncategorized

Secure Boot Recovery Means New Media

1 Comment

Here at Chez Tittel, I’ve been on something of a Secure Boot tear lately. Late last week, it dawned on me that this might require a change in recovery media, too. I checked: it does. Indeed, MS spells out the notion that secure boot recovery means new media in a couple of MS Learn Documents:

Basically, this boils down to the following data points, all of which determine whether or not recovery media will work properly after enabling Secure Boot:

  • Recovery media must use MS-signed UEFI bootloaders
  • Bootloaders signed with a certificate trusted in db
  • Bootloaders signed with the old 2011 CA blocked in dbx
  • Updated WinRE images (incl. new recovery media) signed with the 2023 CA

What Secure Boot Recovery Means New Media Comes Down to…

Simply put: once a PC has secure boot enabled and reports the presence of CA 2023, it needs matching secure boot media for recovery and repair. Older media won’t work because it lacks the new CA 2023 certificate. Bootloaders will fail, and/or WinRE won’t run. This will provoke a “Secure Boot violation” error or “invalid certificate” message in the bootloader. Sounds bad, eh?

The fix is easy, as long as you’ve turned Secure Boot on, and have installed the CA 2023 certificate (Garlin’s scripts at ElevenForum do this job nicely). With all these pieces in place, your current runtime meets the afore-stated requirements. Then, you can use Windows built in “Create a recovery drive” feature to build new recovery media to match this new state. Done!

Here in Windows-World when things change the supporting infrastructure must change to follow suit. Today that means generating fresh, new recovery media to match Flo6’s “secure boot on, CA 2023 installed” state. Takes only a few minutes, but means that future recovery efforts are far more likely to succeed. Good-oh!

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

Copilot Amazon Differ on TB5 NVMe Availability

Leave a comment

I’m prepping for an AskWoody  story about RAID 1 setups on Windows 11. It had me popping open my half-dozen or so NVMe enclosures yesterday to see what I had at my disposal. Among my inventory, I found two identical NVMes (ideal for a RAID 1 test). I also found a Crucial T705 1TB PCIe x5 drive, which isn’t suited for any of my enclosures. It really needs Thunderbolt 5 or USB4 v2.0 to exceed the 40 Gbps speed limit that TB4/USB4 imposes. Imagine my surprise when Copilot said no such enclosures were available, while Amazon showed me at least half-a-dozen products for sale right now. Hence my claim that Copilot, Amazon differ on TB5 NVMe availability.

If Copilot Amazon Differ on TB5 NVMe Availability, Try Evidence

I work with Copilot near daily, especially on understanding and fixing Windows problems, issues and misconfigurations. Warnings about AI hallucinations are always worth remembering with Copilot. Why? Because it has repeatedly shown itself to be wrong or — as in this case — misinformed.  I reproduce Copilot’s response to my correction in which I provide the simple Amazon search that showed me 6-plus TB5 capable NVMe enclosures for sale at US$190 and up.

One big problem I see with AI information is that it includes no shades of grey. If Copilot and other AI interfaces could include confidence levels or probability of correctness, that might help. But no: Copilot, Google AI, Grok and so forth put forward their information as gospel truth. There’s a huge gap between Copilot’s initial flat statement that no TB5 NVMe enclosures are available, and its later correction to “TB5 NVMe enclosures exist, but most are early‑generation products whose real‑world performance is currently limited by host support and certification status.” Big difference!

As Always, Proceed with AI Cautiously

I don’t use or act on AI provided info unless and until I can confirm it through at least one (preferably, two or more) reliable public sources. This little “No it’s not; Well, yes it is…kinda/sorta” encounter demonstrates pretty well why that’s so. Indeed, for testing purposes I plan to buy one of the very enclosures Copilot told me yesterday didn’t exist. Today, it’s a different story!

Isn’t that just the way things go here in Windows-World sometimes? But at least, I’m going to be able to see if TB5/PCIe x5 Gen5 technology lives up to its billing when the Acasis enclosure shows up. If things work as reported, I’ll have an external USB drive that’s as fast as the internal drive on my production desktop.

Facebooklinkedin
Facebooklinkedin
Uncategorized

Secure Boot Report Card Perfected

1 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
Hardware Reviews, Insider stuff, Recent Activity, WED Blog

P16 Gen3 Firmware Update Hangs

Leave a comment

Imagine my excitement when I got a brand-new Lenovo ThinkPad P16 Gen 3 Mobile Workstation delivered to the door yesterday.  It’s an absolute beast of a machine (more on that below), huge and powerful. As part of my usual intake routine, I apply all pending updates. Alas, one of them — the P16 Gen3 firmware update — hangs during its install. I have to take drastic measures to finish things up. Let me explain…

If P16 Gen3 Firmware Update Hangs, Then?

The system wouldn’t reboot after the UEFI itself got updated. It was stuck, unable to go forward or go back. So I exercised the nuclear option when it comes to laptops lost in limbo.  I unplugged the battery and waited for it to drain completely, as evidenced by the power button and ESC key lights that stayed on late into the night last night.

The update completed successfully after that: I’m now running N4FET47W (1.28) dated 1/23/2025. But it took some doing to get there. Lenovo Vantage downloaded the update but was unable to install it. I also tried Lenovo System Update, which is usually better at handling firmware stuff, but no dice there, either. Finally, I visited the Lenovo Support pages, plugged in the serial number, and got a standalone flash installer named n4fuj05w.exe.

Starting UEFI Update Is Good, Finishing Is Better

The installer does its initial thing inside Windows getting the UEFI, Intel Management Engine (ME), and other update elements unpacked and ready before it reboots the machine. Then the flash installer takes over. That’s what hung on me.

Initially, Copilot advised me to remove the back deck of the unit and unplug the battery to force a cold reboot quickly. But this laptop costs over US$9K and the back deck didn’t want to come off. I had to use more force than I was comfortable exercising just to get the back edge to lift a little. Copilot yammered on I should keep trying and that the unit is notorious for tight clips and challenging extraction.

Nope! I also knew that draining the power over time would achieve the same end, with no danger of scratching the finish. So I waited overnight instead.

Getting Going On Intake

Now that the updates are all in place, WU is happy, winget’s been satisfied, and the Store is caught up, I can pay attention to the machine itself. I’ve got all my apps and tools installed, and am ready to report on what I see about this monster of a laptop.

Here’s a quick summary of key components:
• It’s NOT a Copilot+ PC
• Intel Core Ultra9 275HX (8P-Cores, 16 E-Cores, 24 threads)
• 128 GB DDR5 UDIMM RAM
• Intel integrated graphics Arc Xe‑LPG Graphics (64 exe units)
• NVIDIA RTX Pro 5000 Blackwell Generation (ADA arch, 7,424 CUDA cores, 16GB GDDR6, 58 3G RT cores, 232 4G Tensor cores)
• 4TB SAMSUNG MZVLC4T0HBL1-00BLL (SSD)

Pretty serious complement of components, eh?`

Here are the ports provided on the unit, listed by side as left, back and right:
LEFT (from front, items listed back to front)
• 1xSD slot (full-sized)
• 1xThunderbolt 4 (USB-C) up to 40 Gbps, DP1.4, USB4 compatible
• 1xUSB-A 3.2 Gen 1 (5 Gbps)
REAR (left to right, looking at rear)
• RJ-45 2.5GbE
• HDMI 2.1
• 2xThunderbolt 5 (USB-C) up to 80 Gbps, DP2.1, USB4 compatible
RIGHT
• Kensington lock slot
• 1xUSB-A 3.2 Gen 1 (5 Gbps)

Most notably, this P16’s got Thunderbolt 5 and USB5 (aka 4.2) support! Now I’ll finally be able to test TB5/USB5 stuff.  The internal SSD — a PCIe x5 Samsung model — reports speeds over 11,000 for 1GB block transfers in CrystalDiskMark. A USB4 drive attached to the high-speed USB-C port clocks in over 6,000. It’s the fastest USB I/O I’ve ever seen. Cool!

From the Belly of this Beast

Weighing in right at 6.5 lbs (2.95 kg) this is a massive monster of a laptop. But if you need lots of horsepower, capability and connectivity this could be your mobile workstation, too. Lenovo tells me its MSRP is ~US$9,200. You’ll need some serious financial backing to make this baby yours, too. So far, I like it a lot!!!

 

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness