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.

Reverse DNS Lookup Reveals Router Change

I’m pretty fond of the free network scanning tool named Advanced IP Scanner. It’s much more predictable and reliable than the Network facility built into File Explorer. It also makes it easy to do stuff to and over the network. I’ve been noticing on my LAN recently that an increasing number of PCs (and other devices) get DHCP names that end in “.lan” (see the lead-in graphic for more info). So I used a PowerShell script to do a reverse DNS lookup to double-check this. And indeed, this reverse DNS lookup reveals router change in my SAC2V1A Spectrum-supplied router. Looks like it got a recent firmware upgrade that changed its DNS/DHCP behaviors.

How Reverse DNS Lookup Reveals Router Change

I created a PowerShell script to talk to the router and give me DHCP names for all of the nodes it handles, using the ARP (address resolution protocol) as my foundation. If you look at this WinTerm screencap, the pattern is unmistakable:

I forcibly used ARP to drive reverse DNS lookups (from IP address to name from the router’s name table) for all active IP addresses. Notice that every single name here ends with the “.lan” suffix. That tells me Spectrum pushed a firmware update to the box, because it didn’t used to do that consistently for all items.

Why Advanced IP Scanner Shows Some Unadorned Names?

Advanced IP Scanner uses multiple techniques to resolve IP addresses to names. Among this is the NetBIOS Name Service (NBNS), Link-Local Multicast Name Resolution (LLMNR), Multicast DNS (mDNS), SMB/NetBIOS over TCP, and Reverse DNS (PTR lookup). Some or all of these return bare machine names, lacking the .lan suffix. As far as I can, whichever of these lookups responds first is the one that makes it to the name table. And that’s why Advanced IP Scanner shows different name strings than does my script.

Weird and wonderful are the ways of Windows-World. And few are anywhere near as weird, or as wonderful, as the ones that make name resolution work on Windows networks. QED!

Facebooklinkedin
Facebooklinkedin

Device Zombies Roam Among Us

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

  • T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
  • X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
  • Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
  • X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

    1. Remove them from the list while they’re still under my control
    2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
    3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.

Facebooklinkedin
Facebooklinkedin

Understanding UEFICA2023Status=NotStarted

With the introduction of the Windows UEFI Certificate Authority 2023 (CA‑2023), Microsoft updates the Secure Boot trust chain to enhance platform security. As part of this transition, Windows systems may report a registry value under the key HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing named UEFICA2023Status. This value reports the status of the Secure Boot servicing task that migrates systems to the new CA‑2023 trust model. Understanding UEFICA2023Status= NotStarted is important, because it doesn’t mean CA2023 is not in use in the running Secure Boot environment. Let me explain…

What UEFICA2023Status=NotStarted Means

There are two reasons why UEFICA2023Status can take a value of NotStarted. The obvious one is when the CA-2023 certificate is ready to be added to the Secure Boot value stores, and the Servicing Task hasn’t yet been scheduled or run. The other, as I’m about to describe happens when the Windows PC is already up-to-date. Huh?

The UEFICA2023Status value can take on several states, including NotStarted, PendingReboot, Completed, and Failed. A common misconception is that a NotStarted value signals failure to apply the CA‑2023 update. In reality, this value might also mean that the Secure Boot servicing task has not been triggered. Why? Because the system already meets all necessary criteria for CA‑2023 compliance, and that task need not be run.

Specifically, Windows only initiates this servicing task if all of these three conditions are met:
1. The system firmware does not already trust the Microsoft UEFI CA 2023.
2. The EFI System Partition (ESP) does not contain a bootloader signed by the CA‑2023.
3. A servicing stack update or cumulative update requires the migration to complete.

If the system firmware already includes the CA‑2023 certificate and the ESP contains a CA‑2023‑signed bootloader, Windows deems migration unnecessary. In such cases, the registry value remains NotStarted, which is both normal and acceptable. Even so, it took me aback when I checked this value and saw that status (see lead-in graphic). It spurred me to investigate, and led to this very blog post.

As it happens, the BIOS/UEFI flash I conducted to get the MSI MAG Tomahawk B550 motherboard working updated Secure Boot and included the CA-2023 certificate data as well. And, somewhere along the way the EFI partition got rebuilt to include the CA-2023 signed bootloader. My desktop, Flo6, simply doesn’t need Windows to run the UEFICA2023 update task.

Verifying the EFI Bootloader Signature

It’s easy to confirm that the system is booting with a CA‑2023‑signed bootloader. Indeed, one need only examine the signature of the boot manager located on the ESP. This typically resides at S:\EFI\Microsoft\Boot\bootmgfw.efi (where S: is the mounted ESP). Using PowerShell, execute the following one-liner command:

Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List *

If it’s current, the output shows the [Issuer] as Windows UEFI CA 2023. (Otherwise it shows as Windows UEFI CA 2011.) Seeing CA 2023 here confirms that the firmware uses a bootloader signed with the updated certificate authority.

Comparing with the OS Copy

Windows also maintains an OS copy of the boot manager at C:\Windows\Boot\EFI\bootmgfw.efi. This file is not used for booting but may be referenced during servicing operations. It is common for this file to remain signed by the older Microsoft Windows Production PCA 2011 certificate. This does not impact Secure Boot functionality, because the firmware uses the ESP copy. We’ve just confirmed the the ESP copy is current and correct for CA-2023.

This Time, NotStarted Is All Good

Appearances to the contrary notwithstanding, a UEFICA2023Status value of “NotStarted” does not always indicate a problem. Instead, it can simply reflect that the system complies with the Secure Boot requirements for CA‑2023 (and got there before MS could). We verified the ESP bootloader is signed by the Windows UEFI CA 2023. We also confirmed that the firmware trust store includes the appropriate (2023) certificate. Passing these checks means that users can be confident that the system is operating within the latest, current Secure Boot regime despite this “interesting” status. No further action is required unless future updates say otherwise.

Facebooklinkedin
Facebooklinkedin

Flo6 Mobo Switchover Succeeds

On Thursday and Friday of last week, I continued to fight with warm boot issues on my primary Flo6 desktop. The ASRock UEFI stubbornly refused to synch up the MS updates for Secure Boot with its own internal, stored values. Net result: I couldn’t restart Flo6. I could only traverse the shutdown/startup cycle through a deep, cold boot that sometimes required a CMOS reset. After lunch Friday, I took the plunge and tore the PC apart to switch out the ASRock B550 Extreme4 for an MSI Mag Tomahawk B550 WiFi Max. To my great relief and delight, that Flo6 mobo switchover succeeds admirably. That said, I started after lunch Friday and finished after 9M Saturday nite. Phew!

Lessons Learned, as Flo6 Mobo Switchover Succeeds

I made a couple of interesting mis-steps along the way that slowed things down, but the overall process was pretty straightforward. The teardown was easy, but it reminded me how much I now depend on reading glasses for close-up work, since last fall’s cataract surgery.

In putting the new build together, I saw that I’d failed to remove the clear plastic sticker on the CPU cooler during the previous build. Have to laugh, but the results are amazing: no sticker plus a fresh coat of thermal paste took CPU temps down from mid-50s to low-60s to a steady 31°C (Source: Speccy; HWiNFO shows various temps ranging from 32 to 42°C). All show serious improvements over the old build!

Putting the old parts onto the MSI Tomahawk board is where things got interesting. That board offers only LEDs for CPU. DRAM. VGA and BOOT.  I missed the two-digit POST code display on the ASRock mobo, which was more intelligible and easier to read. My first mis-step was mispositioning the 5800x CPU. I was 180 degrees off on the first try. Easily fixed, but took time.

My second mis-step was to put the GPU in the secondary PCIe slot. For some reason I was scared of the metal clad primary. But the PC wouldn’t POST that way, so eventually got that straightened out (the VGA LED did its job). The third stumbling block wasn’t a mis-step, it was more of a design flaw in the MSI board. It wouldn’t start up with more than 2 of the 4 orignal RAM modules (32 GB each) in place. That was a pure trial-and-error exercise.

All the Stops along the Way…

I also had to flash the UEFI (though they still call it BIOS flashing) before I could get past recognizing the CPU. This works with neither CPU nor GPU installed, from a specially formatted USB 2 flash drive. It’s like magic that the board can DIY this process, but it worked like a champ. From that point on, I moved from one proper set-up step to the next. CPU first, GPU second, and proper RAM configuration last.

Note: getting the RGB connector to seat properly on the mobo pins was the most physically challenging part of the build. Close second was working with RAM modules right up against the massive ThermalWright Assassin CPU cooler. But it all got sorted, by guess and by gosh.

Eventually (around 6:30 PM Saturday), I got the setup to boot and it took me straight into Windows, running the same image I’d been using on the old ASRock mobo. Boy, was I relieved to see that happen. And now, for some clean-up notes and good news. Read on…

Booting into Windows, and Beyond…

Once I got into Windows, I had to adjust for the mobo change. To activate Windows 11 Pro, I had to re-enter the same MAK it had already been running on (who knew?). To switchover from the old ASRock to the new MSI drivers, the system loaded an MSI Center app. It cheerfully offered to load “all” necessary drivers, but gave me control over which ones I chose. Needless to say, I skipped the fluff and stuck to device drivers and useful utilities only.

Then I ran Settings > Windows Update, which caught up other key drivers. A fresh run of the Logi app brought back my wireless mouse (I’d been forced to plug in a wired mouse during set-up because I mistakenly grabbed an MS wireless mouse instead of the Logi model, LOL).

Checking Secure Boot and CA-2023

The following image triumphantly confirms that with the current UEFI and recent MS updates in place, Secure Boot and certificates took care of themselves. I didn’t have to do anything!!!

The first PowerShell (PS) command [confirm-SecureBootUEFI] shows it’s in place and working. The second PS command tells me that CA-2023 is in place and in use. That was really the whole reason for the mobo switch, so I’m tickled to death it worked like it was supposed. Added bonus: I can restart, shutdown, and even use “shift+(Settings > Power Button > Restart) to get into the Windows Recovery (WinRE) environment. In short, Windows boot now works just like it should, and Secure Boot is properly doing its thing.

It was a long time coming, and cost me US$150 for the MSI mobo. But God: it was worth it. Case finally, finally closed. I’m thrilled!!!

Facebooklinkedin
Facebooklinkedin

Alexandrine Solution Fixes ThinkStation Diagnostics

In reviewing Reliability Monitor for my peppy and capable ThinkStation P3 Ultra Gen 2, I saw recent repeated APPCRASH errors. If you could drill down into the lead-in graphic — as I did — you’d see 3  between March 11 and 14. So I asked Copilot to tell me more about this error. I learned that this utility is recommended, not required. I also learned that what’s blowing up reflects some kind of telemetry error when the app tried to phone home. So I uninstalled it. This Alexandrine solution fixes ThinkStation Diagnostics (think: Gordian knot) and smooths out my reliability ratings.

How the Alexandrine Solution Fixes ThinkStation Diagnostics

In this context I’m reminded of the well-known DCOM Event 10016 error, which pops up dozens to hundreds of times a day in Windows 10 and 11. It’s not really an error, it’s the result of a design choice that tries a series of component object model (COM) and distributed COM (DCOM) components as it performs routine tasks such as running shell components, search indexing, UWP apps and background services. It appears as an error, even though the actual work to which such errors are tied actually succeeds. Noise, in other words.

In the same vein, the ThinkStation Diagnostics (TD) software is:

1. Recommended, not required
2. The “critical error” relates to the software’s operation, not the system it monitors
3. Copilot reports that Lenovo documents numerous cases where TD fails this way owing to external device voltage issues, unsupported cables or dongles, power state transitions (sleep/resume)

Indeed the error is something on the back end, not in the system itself, and doesn’t really signal an actual problem. Ironically, it’s the system for reporting problems that’s itself causing problems.

Noise, Not Signal Makes Alexander Right

Nobody could untie the Gordian knot, so they couldn’t get in the door, either. Alexander cut it off, and got the door open right afterward. I’m taking the same approach with this tool. It’s not because I don’t want it to tell me useful stuff; it’s because I don’t want it to crash for uninformative reasons.

Here in Windows-World, there’s always a certain amount of noise to go along with valid signals. When I feel like the noise is swamping the signals, I’m glad to remove a source of such noise. There are plenty of ways for me to find out what’s going on, using other means. Basta!

Facebooklinkedin
Facebooklinkedin

PS Version Bump WinTerm Oddity

As is my usual practice, my workday starts off with a cruise over the mini-fleet of PCs here at Chez Tittel. I look for upgrades, updates, changes, and glitches. Today, I ran into something interesting on the Lenovo ThinkPad P16 Gen 1 Mobile Workstation. A PowerShell (PS) upgrade happened — and succeeded — even though its parent WinTerm session shows WinGet reporting “Installation abandoned.” That’s the source of this particular PS version bump WinTerm oddity. Let me explain…

Exploring PS Version Bump WinTerm Oddity

As you can see in the lead-in screencap, the left-hand WinTerm pane is running PowerShell v7.5.5. You can also see that WinGet gets going on a v7.6.0.0 upgrade, but reports “Installation abandoned” at its apparent conclusion. Indeed, most readers might be tempted to conclude from this that the installation failed. Not so!

As you can see in the right-hand pane, opened after the apparent WinGet failure, the PS version there is 7.6.0(.0). The update succeeded but it can’t show itself in the parent pane for a very good reason. PS v7.5.5 is running that pane, and the developers didn’t include logic to halt that process and swap in a new version as part of the way that PowerShell works.

It’s a kind of Catch-22 (“How can you see you have flies in your eyes, if you have flies in your eyes?” as Orr asks in the famous WWII novel). With the older version running, you can’t really get the newer one to report itself right there at that moment. But as the right-hand pane shows, you need only open a new PS Session and presto! the new version is up and running therein.

Self-Update Is a Tricky Thing

This is an age-old gotcha in computer science. When the thing being updated is also running (and indeed, running the update tool in use), certain compromises and workarounds are needed to prevent things from falling over. For PowerShell, that means reporting a cancelled installation even though the installation itself completes and succeeds. The session that did the work simply can’t see and report on that particular change, because it itself would have to change to do that. Start a new session, and a new and changed context lets that happen.

Here in Windows-World, change is a constant. When the changer itself is changing, things get interesting. WinGet’s report of a “cancelled installation” for PowerShell shows how a specific compromise happens at runtime when PowerShell participates in its own update process. Fun!

 

Facebooklinkedin
Facebooklinkedin

WinGet Versions May Affect Installs

I just saw something interesting running WinGet on multiple PCs here at Chez Tittel. On my production desktop (Flo6) running production Winget (Version 1.27.470.0) a Teams update just failed with error message “…system cannot find … file specified (0x80070002).” On my Canary test system (X12Hybrid) running preview Winget (Version 1.29.30.0) that very same update succeeded. Inevitable conclusion: WinGet version may affect installs and updates, including success or failure. Who knew? Let’s discuss…

Why WinGet Versions May Affect Installs

Copilot confirms my suspicion that version differences sometimes affect update or install behavior. It says (and I concur) “some WinGet releases and App installer builds handle extraction and temp paths differently; newer/older builds can succeed where others fail.” Isn’t that strange — but typical — for Windows stuff anyway?

Fortunately, the in-app updater in Teams popped up as soon as I opened the app up. It, at least, was able to update itself successfully. So I applied the old principle: if you can’t do it one way, try another, and got past this hurdle anyway.

Is It a Version, or an Instance?

Then I went looking at my other production level PCs here at Chez Tittel. I looked at 4 other machines in my office all running Windows 25H2 Build 26200.8037 (latest production build). None threw the same error, though all are on the same Windows, Winget and Terminal versions. Interesting! My other production machines, however, did post this warning (in yellow) after the Teams update:
“Successfully installed. Restart the application to complete the upgrade.” (That warning does not appear in the lead-in graphic, which comes from a preview WinGet version instead.)

I’m left with no choice to conclude that it’s the configuration of the particular machine (Flo6) that’s somehow suffering or different. Based on what Copilot told me, it’s likely a PATH issue of some kind. As the old Internet adage goes so well for Windows: YMMV. Indeed, it just did!

Facebooklinkedin
Facebooklinkedin

26220.8062 OOBE Grants New Naming Tools

Amidst my excitement about Restore Point controls in Settings in the latest Beta build yesterday, I missed some other cool new capabilities. Indeed, the Build 26220.8062 OOBE grants new naming tools to installers. As you can see in the lead-in graphic, that means setup now includes a “Name your device” pane with input fields for:

  • Device name: installer can specify device name, instead of the prior MS penchant for long, auto-generated machine names
  • User folder name: installer can specify the base account’s folder name (previously, up to the first five characters in the base MSA)

Good Thing 26220.8062 OOBE Grants New Naming Tools

In the past, one of my typical post-install tasks would be to replace the auto-generated machine name with something more informative. For desktops, these would be DESKTOP-XXXXXX, or for laptops LAPTOP-XXXXXXX, with a mix of 7 alphanumerics (e.g. DESKTOP-UU1KCDG or LAPTOP-AB12CDE). I usually go with something shorter and more descriptive (e.g. Flo6, P16, X380, etc.).

Also, I’ve generally shied away from attempts to rename an account’s user directory because of the number of steps and amount of work involved. (See this ElevenForum.com tutorial to see what I mean.) Of this task Copilot opines:

You can rename the user profile folder, but it’s advanced and risky — follow a tested tutorial step‑by‑step and back up first.

And, FWIW, it too recommends that very same tutorial as the best step-by-step guide to this somewhat tortuous task. Nice that MS has finally made all that effort unnecessary. I’ll be glad when it makes its way from this Insider Preview into more general distribution.

Here in Windows-World, the little things sometimes count (and take more time and effort) than they otherwise might. Kudos to MS for adding these controls; shame on them for not doing it 20 years ago.

Facebooklinkedin
Facebooklinkedin

Build 26220.8062 Settings Integrates RPs

Last Friday, MS released a new Beta Channel build to Insiders. In these insider previews, things of interest do pop up from time to time. Methinks one particular new capability in that release will interest readers. Namely, Build 26220.8062 Settings integrates RPs (Note: I abbreviated Restore Points as RPs here, for brevity). You can see what this looks like in the lead-in screencap. This is fascinating, and I’ll tell you why…

What’s Noteworthy, as Settings Integrates RPs in Build 26220.8062?

Over the past decade, MS has been surely moving functions from Control Panel to Settings. While that pace has been glacial, this marks major movement in that long-persisting icecap. You used to have to work through the “System Protection” tab in the System Properties Control Panel item to handle restore point status and access. No more. As the lead-in graphic shows, it’s now integrated into Settings > Recovery. And there’s more…

If you click the “View or edit” (Restore Points) button at the right of the “Point-in-time restore” item shown above, you’ll get a sub-menu that lets you:

  • Turn RP capture on or off
  • Manage RP frequency (default is “Every 24 hours”)
  • Manage RP retention (default is 72 hours)
  • Fix restore point disk usage
  • Access a list of available restore points (with time stamps)

Here’s that that looks like on my X380 Yoga test PC:

From what I can tell, the upgrade turns RPs on by default. Notice they already consume 7GB of disk space.

This is a major shift in Windows functionality. I checked and the old standby — easily run as SystemPropertiesProtection.exe — remains available in this build. I guess MS will offer them side-by-side for a while as is their usual practice.

Big doings in this latest Beta release. Nice to see another big chunk of Control Panel capability make its way into Settings. Here in Windows-World, that counts as “real news:” now you know!

Facebooklinkedin
Facebooklinkedin

ASUS Router Triggers Security Review

In reading ARS Technica, I couldn’t help but observe that a major exploit around the KadNap is hitting ASUS routers around the world. “Hmmm,” I thought to myself, “Don’t I have one of those?” Indeed I do. But I’m pleased to report that it’s operating in AP-only mode, has the most current firmware available, and not susceptible to drive-by or external attack. Given how many similar devices have been pwned, I’m happy that when ASUS router triggers security review, the overall results are positive. Or at least, not overly scary…

ASUS Router Triggers Security Review:
Now What?

I couldn’t help but notice I bought this device back in 2018. It’s definitely past the “age of replacement!” So now, I’m looking around for something else to take its place. Copilot recommends multi-node mesh devices, but they’d have to integrate built-in switch capability with 2 or more additional RJ-45 ports to be worth installing.

Good news! Many models for Wi-Fi 6E and 7 include two or more 2.5 GbE ports. That lets me use existing RJ-45 wallplates to accommodate them, and lets me retain connectivity to already-present wired devices. Sounds like a plan!

Now all I have to do is come up with the funding. Here in Windows-World, where’s there’s a will — and the money — there’s almost always a way. I’ll add this to my “to buy, and to do” list!

 

Facebooklinkedin
Facebooklinkedin