Cool Tools, Insider stuff, Recent Activity, WED Blog

Magician Internal Updater Lags Behind

Leave a comment

I have to chuckle. In making my morning rounds, I see at TechPowerUp.com that there’s a new version of Samsung Magician out — namely, 9.0.1. So I jump into Magician and check its internal updater, which tells me I’ve got the latest version: 9.0.0. Alas, as Copilot tells me, it’s not unusual for the utility to do this. Indeed, as a matter of observed practice, the Magician internal updater lags behind Samsung’s software release schedule. It’s all laid out in the lead-in graphic. Let’s explore…

Why Magician Internal Updater Lags Behind

Apparently, Samsung waits until a new release has been out for some while before updating its xml-based manifest to make it known to the Magician updater through its update servers. According to Copilot, Samsung has been ill-served during previous release cycles by “buggy Magician releases,” “firmware-pushing issues,” “NVMe driver conflicts,” and so forth.

Thus, the company releases the new software first through public channels such as TechPowerUp, MajorGeeks, SoftPedia and other file-sharing sites. It then watches user responses from early adopters for up to a few days, and sees what the uptake and reactions are like. It’s not unusual for the manifest to lag behind by hours or days.

As you can see from the lead-in graphic, 9.0.1 was released today (3/30/2026). So it could be later today,  tomorrow, or even later this week before the built-in updater catches up. Unless Samsung pulls 9.0.1 back and decides to push out another, hopefully better release later on.

Here in Windows-World, the release paths for software often tell a story. The one for Samsung Magician is pretty interesting, and shows the value of lessons learned from prior history. You might say “Better later than sooner, especially if problems present!”

Note Added 2.5 Hrs Later: It’s Here!

Reading over ElevenForums traffic in the Devices & Drivers forum just now, saw a user report that Magician is offering 9.0.1 now. Just checked here and — there it is! Installing now, and glad to see it was a matter of hours, not days (or a pullback, either).

Works, too! Looks like we get to do things the easy way this time.

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

PS Version Bump WinTerm Oddity

Leave a comment

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
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

WinGet Versions May Affect Installs

Leave a comment

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
Insider stuff, Recent Activity, WED Blog, Windows 11, Windows tools

26220.8062 OOBE Grants New Naming Tools

Leave a comment

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
Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11

Build 26220.8062 Settings Integrates RPs

Leave a comment

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
Cool Tools, Insider stuff, Networking, Recent Activity, WED Blog

ASUS Router Triggers Security Review

2 Comments

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
Insider stuff, Recent Activity, USB devices, WED Blog, Windows 11

Stuck Inside Boot Alert Kills Whole Day

Leave a comment

I mounted a full-throttle attempt to fix my “new CPU detected” boot warning, and lost a day to wandering in the wilderness. You’ve seen this screenshot before, in my February 27 post. I saw it a LOT more yesterday through at least 15 cold boots, plus various changes. Indeed getting stuck inside boot alert kills whole day, as I try to put my flaky startup situation right.

Why Stuck Inside Boot Alert Kills Whole Day

I’ll admit it: it was my own damn fault. I had to turn TPM off to attempt the warning breakout, but mistakenly also turned Secure Boot off as well. Big mistake. I’m *STILL* trying to recover from the latter, though I’ve managed to fix the former.

Along the way what wasted hour after hour was the impact of trying to boot in a half-open, half-closed Secure Boot environment. I kept getting stuck at Post Code 00 (nothing happened), Post Code 22 (graphics won’t initialize). I had to pop the CMOS battery out twice yesterday to reset the runtime to recognize all the hardware. Once I even had to disconnect all USB, network, and display peripherals.

A Trying Day Here at Chez Tittel

Chasing my tail is not always my idea of fun. Chasing the same trail of gotchas and glitches I’ve chased at least twice before is downright discouraging. But today, the machine booted (with the alert warning shown) and I’m up and running. I’m going to try one more time to get into UEFI, turn on Secure Boot (my only remaining hurdle to seal things back up) and see what happens.

Wish me luck. I’m going to need it. Here in Windows-World, there may not be enough time to do it right, but there’s always plenty of time to do things over and over … and over again until we get them fixed. Stay tuned: I’ll keep you posted.

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

Ongoing Reboot Issues Affect RDP

Leave a comment

I’m still struggling with reboot issues on Flo6. Lately, I have to go through the infamous “new CPU detection” alert, then deny it, before I get into Windows 11. After multiple such reboots just now, I elected to stay logged in and get some work done. No such luck: my ongoing reboot issues affect RDP. On the way to a working session, I got the mysterious error window you see as the lead-in graphic.

Why Do Ongoing Reboot Issues Affect RDP?

It seems that multiple successive reboots in Windows 11 can impact RDP. This can lead to stale RDP capability caches, stale virtual device handles, TPM/Hello falling shy of full initialization, mismatched channel GUIDs, and more. In short, things get shook up and need to settle down.

What’s interesting — and amusing — about this error is that it’s not really an error. Closer inspection reveals it carries error and extended error codes that are null (0x0) in value. And indeed, right after the error window popped up, an RDP session into P16  opened up and worked like a champ.

What Happened Here?

Though it’s reported as an authentication error, it actually occurred during virtual channel negotiation between Flo6 and P16. Naturally, that indicates both devices were working just fine, thanks, and trying to get together. Copilot speculates — and I concur — that the most likely culprit is a Windows Hello redirection problem. (That’s mostly guaranteed by my turning fTPM off on one boot to kick start that process, then turning it back on.)

Boy howdy, things do sometimes get strange here in Windows-World, though. On the whole, I’d rather have a bogus error that fixes itself (or isn’t really an error) than have a serious glitch that requires further troubleshooting. I’ve had enough of that already today, thanks very much!

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

Clearing X-Rite Error Proves Interesting

Leave a comment

I’ve got a terrific new loaner unit from Lenovo, a P16 Gen 3 Mobile Workstation. I’m still learning my way around this powerful beast of a laptop, as I discovered this morning. After login, I couldn’t help but notice that the built-in X-Rite Color Assistant failed — namely it opened a dialog box that told me the app couldn’t run because of an “unexpected error.” Mildly disturbing, and not terribly informative. Indeed clearing X-rite error proves interesting, as I first try–and fail–to fix the app through a basic uninstall/reinstall maneuver. Then I notice something…

Why Clearing X-Rite Error Proves Interesting

While I was checking over the P16 Gen 3 for clues, I noticed that Lenovo Vantage had a new firmware update pending. “Hmmm,” I wondered: “Maybe a firmware update (and reset) will also make X-Rite happy?” I quickly installed same (and then waited for the usual update process to grind to completion, and the post-install reboot to finish).

Guess what? The firmware update did the trick! After the reboot, I was able to launch the X-Rite Color Assistant. And it turns out it’s a “background app” on that Lenovo model (which uses a software or virtual color control, because the unit lacks a built-in color sensor). So I had to go through the Notification area, and right-click on the app to get it to open.

Below, you can see the About info from the app itself. According to Copilot, the UEFI/firmware refresh helped to bring X-Rite back to life because it resets the basic runtime environment, including the GPU to system connection. Good to know!

After a quick UEFI reset, X-Rite Color Assistant ran without error.

Here in Windows-World, the right ingredients for a happy and working laptop include the underlying firmware and drivers, as well as the OS and its software. Luckily for me, by fixing the lowest level stuff, the higher-level app came back to life. I’ll count this one as a win.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Device drivers, Insider stuff, Recent Activity, Troubleshooting, WED Blog

DDU Fixes GPU Driver Disasters

Leave a comment

Today’s blog post is a paean to a tool named Display Driver Uninstaller, popularly known as DDU. It’s long been part of most Windows admin and power user toolboxes. DDU comes from Wagnardsoft, but well-known 3rd-party mirrors also include Guru3D and TechPowerUp. DDU remains a useful tool at completely replacing GPU drivers and their Windows infrastructure when graphics go wrong. It’s also a great way to switch from one GPU type to another. Say, from NVIDIA to AMD, or vice-versa, or even from one of them to Intel ARC. TL;DR version: DDU fixes GPU driver disasters and lets you switch types with little muss or fuss.

Why Say: DDU Fixes GPU Driver Disasters?

Over the past 9 days, we’ve seen an unusually fast series of NVIDIA Game-Ready GPU drivers (with one evanescent Studio driver on February 26). That Thursday saw both versions make an appearance that provoked immediate issues and outcry; version 595.59 was withdrawn less than two hours after its release.

Then on Monday, March 2, NVIDIA fired off Game-Ready version 595.71. Users soon began reporting diminished performance from this driver (especially for certain, GPU-intensive games). Further inspection (using tools like GPU-Z) observed that it imposed voltage caps on RTX 50-series GPUs to limit damage potential. At the time, I wondered if this wasn’t like putting “chewing gum on top of baling wire” to fix things.

On March 4, 2026 (Wednesday), NVIDIA dropped a hotfix to address these issues, in the form of 595.76. It addressed the voltage capping, and a variety of other game-specific glitches and gotchas. Since then, things on the NVIDIA Game-Ready driver front are steady, if somewhat uneasy. This is the first time in YEARS that the company has had two unstable Windows Hardware Quality Labs (WHQL) designated drivers follow in quick succcession.

Rollback Versus Deep Cleanup

So far, users have been able to recover from these updates without lingering issues. In the past, GPU driver glitches have resulted in black or stuttering screens, serious and ongoing display disturbances (aka “screen artifacts”), driver store damage, or bothersome system or GPU installer instability or crashing. When those things happen, that’s when DDU comes into its own. It cleans up all of the old GPU driver stuff and gets rid of whatever’s causing problems, then lays down a brand-new, clean and (hopefully) reliable replacement runtime to get your GPU(s) working properly once again. Hopefully, it’s obvious this capability also makes DDU excel at “out with the old, in with the new” actions when switching from one GPU type to another.

Did the recent NVIDIA debacle call for DDU? No it did not. I personally observed that the rollback facility in Device Manager took my system back from 595.59 to 591.74 (Studio). Other users have consistently reported that Game-Ready drivers also rolled back successfully as well (591.86 in most cases).

Even though this latest spate of Game-Ready drivers has caused some commotion, it hasn’t seemed to cause much need for DDU. Not this time around, anyway. But it’s good to know that DDU is out there should you need it. Or should you be switching from one GPU type to another. Here in Windows-World it’s better to have such tools and not need them, than to need them and not have them!

Facebooklinkedin
Facebooklinkedin

Author, Editor, Expert Witness