Category Archives: Cool Tools

Phased Updates Norton 360 Strike

It’s not like I’m unfamiliar with this sensation. No, not at all, based on oodles of history with phased feature roll-outs for Insider Previews on Windows 10 and 11. But Friday, I got bit for the first time on a Norton 360 upgrade. That translates into what I call a phased updates Norton 360 strike. Let me explain…

What Phased Updates Norton 360 Strike Means…

I found a Norton update notification dated February 4, 2023 online. It includes a telling sentence that reads in part as “…this version is being released in a phased manner.” Alas, SUMo doesn’t care: it thinks the release is generally available. So here’s what it tells me about my production PC:

Notice the second (orange) item indicates that is available. True enough in some general sense, but not true for my PC. Here’s what Norton tells me when I attempt to update it through the Norton Update Center:

Just for grins, I positioned the open Norton 360 home window underneath the results of the Webscan that says “no product found.”

Trip a Little Reboot, and…

Of course, one can’t have the 360 window open without running said software. So I knew something was flaky about the Norton AutoDetectPkg.exe that I’d just downloaded. A quick reboot later, and the following message appears instead (and confirms my preceding hypothesis):

Am I Frustrated, or What?

Yes, indeed I am. But because I have long, sad and weary experience behind the curve on phased releases I know this means my turn has not yet come for release I’ll wait as patiently as I can for same, since Norton won’t make it available any other way. Otherwise, I’d just force install it, and make the SUMo warning go way.

And boy howdy, is that ever the way things go sometimes, here in Windows-World … with a bullet, this time!

Note added February 22

In the past little while (it’s been 9 days since I wrote this post), Norton has quietly updated itself to the new release. Here’s what the about information says now (notice the version number: indeed, it is now at

My phase has come in the form of a recent and silent upgrade to

‘Nuff said!


Win10 Enterprise Image Repair Mismatch

I’m flummoxed. As part of my production PC repairs the other day, I ran an in-place upgrade install. It didn’t fix my problem, but it ran to reportedly successful completion. Here’s the thing: I used a Windows 10 Pro image for build 19045.2546 (from to make those repairs. I’m surprised it worked!

Why Say: Win10 Enterprise Image Repair Mismatch?

As you can see in the lead-in Winver graphic, this PC is clearly running Windows 10 Enterprise (2nd text block). Yet the filename and download info at UUP Dump clearly identifies the Windows version as Pro:


Targeting install.wim from the Sources directory, DISM unambiguously identifies the Windows version as Windows 10 Pro.

Yep: it definitely says the image is Windows 10 Pro.


IDKYCDT = “I didn’t know you could do that.” But apparently, you can. Indeed the MS Answers advice on this technique says only that one must

download the latest .ISO file available for Windows 11 or Windows 10.

It says nothing about version. Likewise, the TenForums tutorial on this topic simply says

  • If you have a 32-bit Windows 10, then you must use a 32-bit ISO or USB.
  • If you have a 64-bit Windows 10, then you must use a 64-bit ISO or USB.

Again, there’s nothing here about version, simply that a valid ISO is required. I don’t where I got the idea that the version and kind of ISO used for repair had to match the repair target. But it does NOT have to match. I got explicit evidence to the contrary earlier this week with my own eyeballs, on this very PC.

Thus, I learned something useful and can pass it on to you, dear reader. Any valid Windows 10 ISO works for Windows 10; ditto for Windows 11. Cool!

This is actually pretty handy because you can use to cobble together an image for the current build number for Windows (10 or 11) including all recent updates and CUs. Then, when you repair the image it should work for Home, Pro, Education and Enterprise even if you — as I did — download the Pro-only ISO. No further updates will be required, when that repair completes.


Why Give PowerToys Admin Access?

I found myself looking at a suggestion from PowerToys on a test PC yesterday. It popped up when I opened Windows Terminal as Administrator, as per usual practice. It warned me that Fancy Zones and other PowerToys tools might not work properly unless I gave PowerToys admin access, too. Hence the question: Why Give PowerToys Admin Access?

Why Give PowerToys Admin Access?
Because other apps use it…

I turned to MS Learn. There I found an item entitled PowerToys running with administrator access. It pretty much explained everything. Here are the salient points from its second heading:

PowerToys only needs elevated administrator permission when interacting with other applications that are running in administrator mode. If those applications are in focus, PowerToys may not function unless it is elevated as well.

These are the two scenarios PowerToys will not work in:

  • Intercepting certain types of keyboard strokes
  • Resizing / moving windows

Seems pretty straightforward to me, and makes perfect sense. Here’s how to get to admin mode in PowerToys from its default “Running as user” mode.

Making the Switch: User to Admin

You must open PowerToys in admin mode to switch to admin mode. If PowerToys is running, right-click its taskbar icon and select exit to terminate its runtime instance. Next, right-click the PowerToys icon in the start menu, and select “Run as administrator.” In Settings, Administrator mode, move the “Always run as administrator” slider from off (as shown in the lead-in graphic) to On. That’s it!

Now, you can run some of your tools and programs in admin mode without warning messages from PowerToys (or concerns that its tools might not work as they’re supposed to). I like it, and I like ready access to simple, intelligible explanations as to why things must change to work properly.

One More Thing: v0.67.1 Is Out

As I write this item, MS has just released PowerToys update to v0.67.1. While you’re poking around inside Settings/General click the “Check for updates” button. If your PC isn’t yet caught up to this latest version, it’ll take care of it for you. Or, try this command

Winget upgrade Microsoft.PowerToys

if you prefer. Cheers!



Unscheduled Restore Drill Ends Well

Oh boy! I found myself fighting several interesting Windows issues yesterday. Long story shot: my unscheduled restore drill ends well at the final conclusion. But first: I have to rebuild my boot configuration data and create new Macrium Rescue Media before I can actually boot into the restore environment. It’s always something, right? Let me tell you what that meant yesterday…

After Initial Obstacles, Unscheduled Restore Drill Ends Well

First, a benediction:  I remain grateful that I take a scheduled backup at 9AM every morning, 365 days a year. If it weren’t for that backup, I would have been in real trouble. Indeed, I tried an in-place upgrade repair install during my recovery sequence. That’s when I observed that while it fixes OS files perfectly, it does not fix self-inflicted file system or Registry issues.

My first hint of difficulty came when I tried to restore my 9 AM backup. The timestamp on that file is actually 9:52 so that tells you how long it took to complete as a background task. Turns out my Macrium Rescue Disk wouldn’t or couldn’t boot successfully. It would simply get as far as the bootloader, spinning balls against a black screen, and never get any further. Yikes!

BCD Complications

Next, I unthinkingly added a Macrium Rescue Media element to the boot menu. This did neither harm nor good. But alas, it extended the time it takes to reboot by a good 2 minutes. In a situation where I was rebooting a LOT, that really didn’t help things much. Sigh.

Note: when I did eventually restore the 9AM backup it perforce rewrote the whole boot/system disk, so that little BCD change got undone. Yay! I really don’t need it anyway…

Restore Requires Working, Bootable Rescue Media

Eventually, I turned to the excellent Macrium user forums to find insight on my hung restore. I switched from a faster, bigger NVMe drive in a USB enclosure, to an older, slower, and smaller USB flash drive. That ultimately did the trick.

For some reason, I had to build the rescue disk twice to get it to work. I may have forgotten to check the “Check for devices missing drivers on boot” checkbox the first time around. I was sure to check it on the second try (see lead-in screencap: it’s unchecked by default). After that, the Macrium restore operation proceeded automatically and the process ground through to its lengthy conclusion.

It had been long enough since I did a restore that the time required came as a quasi-revelation. All told, it took about 70 minutes from firing off the restore inside the damaged Windows 10 installation to return to the desktop inside the 9AM image snapshot. That’s quite a bit longer than the 14 minutes or so it takes to backup in single task mode (52 minutes as a background task).

But wow, was I relieved to get over that hump! And now, I have working proof that my backup/restore regime produces its intended outcome. It was an interesting ride in the meantime…


PowerToys Application versus App

I’ll be darned. This has been going on for awhile, but I just recently learned about it. If you look, you too can find a September 18, 2021 story. It says: PowerToys are now available in the MS Store. I spent some time this weekend switching over from the GitHub version (installs as an application) to the Store version (installs as an app). This led me to considering the differences between PowerToys application versus app.

Switching from the application version to its app counterpart is also neither documented nor obvious. Neither installer knows about the other, so it doesn’t clean up old stuff from “the other fork,” either. Let me explain later on here…

Understanding PowerToys Application versus App

In Windows, Applications live in two primary folder trees. 32-bit applications (of which there are fewer and fewer, now that Windows 10 is mostly 64-bit, and Windows 11 completely 64-bit) live in:

C:\Program Files (x86)

Their 64-bit counterparts, alternatives, or replacements live in:

C:/Program Files

Apps live in their own corner of the preceding folder tree — namely:

C:/Program Files/WindowsApps

Distinguishing Application from App

The only way you can tell if you’re running an application or app version of PowerToys is by where it lives in your Windows installation. If it shows up in Programs and Features, it’s an applicatioon. If it shows up under Installed Apps in Settings, it’s an app. Otherwise, they look — and behave — identically.

You can see the Settings-based App info to the left, and the Programs and Features-based Application into at the right, in the lead-in screencap above. Same name, same size, same version, same date.

So why go with the app version rather than the application one? Two primary reasons I can think of:

1. Apps get updated via the Microsoft Store automatically. You have to use the Update function inside PowerToys Settings/General to update the application version.

2. Apps are supposedly more secure than applications, because they run within a sandboxed environment. FWIW, I haven’t seen or read about that playing into the presence or absence of security exploits.

Making the Application to App Switch

First, visit Programs and Features and uninstall PowerToys there (or use your favorite third-party uninstaller: e.g. Revo Free). Then visit the Microsoft Store, search for PowerToys and install the version that comes up there (v.0.67.0 as I write this). Done!

If you try to install the app without removing the application, you’ll end up running both side-by-side. It’s much easier to follow an “out with the old (install), in with the new (install)” approach. How do I know this? I went the other way at first and had to clean up the resulting overlap. Save yourself that trouble, please!


PowerToys v0.67.0 Gets Quick Launch

Here’s a nice little tweak for a great set of useful tools. That’s right, the venerable PowerToys v0.67.0 gets Quick Launch in that release. You can see what you get by default on the left of the lead-in graphic. At right, you can see what comes up under the “More” selection scrolled to the top.

What Makes PowerToys v0.67.0 Gets Quick Launch News?

You’ve always been able to launch individual PowerToys using key combinations, once those tools are enabled. You can find those various key combinations (aka “shortcuts”) in the PowerToys documentation files (right-click PowerToys, choose Documentation from the resulting pop-up menu).

What’s new here is that you need now simply left-click PowerToys and the Quick Launch menus shown above become available. This is a great boon to me, because it means I don’t have to learn or remember the various keyboard shortcuts anymore. It takes fewer clicks and key presses, too. Always good! Be sure to check this out for yourself after you update to v0.67.0.

Installing PowerToys…

If you don’t have them already, you don’t need to grab PowerToys from GitHub unless you want to. GitHub does, however, remain the only source for the Preview version of PowerToys. Instead, you can grab the stable version of PowerToys from the MS Store. That’s what I did on the test machine where I captured the screencap(s) above. I couldn’t believe this PC didn’t already have it installed, but it gave me a terrific opportunity to take the MS Store install path. Works like a charm!


MS AI Survey Shows Strong Appetite for Automation

Hmmm. A story today at MSPowerUser pointed me to a recently published (but infuriatingly, undated) survey from Microsoft. It’s entitled Four Ways Leaders Can Empower People for How Work Gets Done. Notice, AI appears nowhere in this string. Even so, this MS AI survey shows strong appetite for automation.

That is, the survey documents increasing demand from rank-and-file workers for technology based empowerment. What does this mean? Workers want low-code tools to DIY basic software so they don’t have to wait on the IT/development backlog. They also want “artificial intelligence tools that let them focus on what’s important” to quote from the survey’s tag line. Wow!

How MS AI Survey Shows Strong Appetite for Automation

I’m just going to gloss over some of the survey results in this piece. Those seeking more depth or details will definitely want to read the original MS Briefing. Here are some key elements:

  • To make workforces more efficient and flexible, workers need tools that deliver maximum results from minimal effort.
  • MS surveyed 2,700 employees (in-house) and 1,800 business decision makers (out-of-house) in the US, Japan, and the UK.
  • Questions posed included: (quoted verbatim)
    • Do people feel empowered by the tools they currently have?
    • Are teams equipped to collaborate effectively in a world of flexible work?
    • Can new technology like AI and low-code and no-code tools help solve their challenges and open up new opportunities?
  • 9 of 10  respondents want simpler ways to automate daily tasks, to focus on more important work.
  • 4 key principles to guide business leaders to empower workers: (paraphrased for brevity)
    1. Empower people with more say in choosing new technology
    2. Use collaborative apps to connect workers so  they can share info in workflows
    3. Equip everybody with low-code tools to accelerate innovation
    4. Implement AI to automate busywork: this improves worker satisfaction and engagement

There Is No East or West in AI Empowerment

The most interesting findings show that the majority of workers (and mostly a supermajority, at that) agree that AI and automation can help them do more, better and faster. I have to believe this “AI dividend” is what’s driving MS to invest tens of billions into AI tools and technologies. They’re already convinced — in large part because of their own experiences and observations in-house — that the payoff will more than justify their investment.

Personally, I can’t wait to start seeing more of that payoff for myself in my own daily life and work. For more insights and info, though, please read this survey brief for yourself.



Updating WingetUI Brings Follow-On

I have to laugh. When I wrote yesterday about Winget moving up to version 1.4, I should’ve known it would carry items in its wake. Hence my update to the GUI front-end for Winget this morning — namely, the Github project known as WingetUI. I might have guessed, but did not, that updating WingetUI brings follow-on packages in its wake.

Instead I simply fired off the update process for WingetUI this morning, and moved onto another open window. I was happily surfing some traffic at when outta nowhere an install window for the Microsoft Visual C++ 2015-2022 Redistributable popped up on my screen. You can see the trace it left behind in “Programs and Features” (dated 1/31/2023) in the screencap above.

If Updating WingetUI Brings Follow-On, Then What?

I guess it makes sense that if Winget is updated, WingetUI should follow suit. I’m not sure if the new C++ Redistributable is a natural consequence of the update, or just a coincidence. But gosh! I’m of the opinion that if one program needs to install other stuff so it can work, it should at least notify you beforehand. Or even, ask permission.

But what do I know? Thus, I was a bit taken aback when the install window for the C++ Redistributable popped up today. It seemed kind of random and unexpected to me. Maybe it’s my fault for covering up the WingetUI install window with something else. Maybe it’s just one of those things that sometimes happens when you update software here in Windows-World. You tell me!


Obtaining Winget Version Info

A couple of weeks ago, a new version of Winget popped up on Github. Pretty much since then, I’ve been slowly but surely making sure all 11 of my Windows PCs are running this latest and greatest version (e.g. 1.4.10173). For me that naturally raised the question: How does one go about obtaining Winget version info? That led me back into the MS Learn documentation, about which I’ll now report.

Obtaining Winget Version Info Is Dead Easy

Turns out that winget is just another package, like all the others that the tool can download, install, upgrade, delete and otherwise manage. Thus a simple and basic winget command told me what I wanted to know:

winget –info winget

The lead-in graphic for this story shows this command and its resulting output. Note the first line after the command reads:

Windows Package Manager v1.4.10173

That matches the “Latest” version number at Github, so it’s the most current version around AFAIK (not counting previews). And indeed, I’m pleased to report that using standard winget upgrade commands has ensured that winget is current on all my PCs.

More than One Path to Enlightenment

I also noticed that winget syntax errors will report the version running before conveying its error message info. Thus, omitting the dashes before “info” in the preceding command will also tell you its version number (after which a pageful of syntax guidance follows). I guess you could deliberately mistype a command to produce the version number. But heck, I’d rather do it the right way if I can remember how.

One More Thing: Winget -v

Turns out that Winget -v (or -version) will produce just the info needed in compact readable form. Thanks to Demetrius Nelson (@DenelonMs) for pointing this out to me on Twitter! Why didn’t I think of that… Here ’tis:

Obtaining Winget Version Info.-v option

Hmmm. It doesn’t get any easier than this.
Moral: RTFM (with more care)!


16 Month Pause Between Audio Updates

Whoa! I finally hit paydirt yesterday. I’ve been checking for updated drivers for my Realtek® Audio (UAD) device for some time now. As I’ve just calculated, there’s been a 16 month pause between audio updates on my production PC. Undoubtedly that’s because it’s an i7 Skylake (Intel Gen 6) CPU that made its debut in 2016. Could this be another sign that it’s time to retire this PC? Probably!

Why a 16 Month Pause Between Audio Updates?

Please look at the intro graphic. Because I just updated the ASRock Realktek audio driver yesterday, you can see two versions of the corresponding setup information (INF) file, hdxasrok.inf. Note the dates: the newer one reads 12/27/2022 while the older reads 8/3/2021. Do the math, and that’s 16 months plus over 3 weeks. Wow!

I’d been visiting the ASRock Support website and my favorite alternate driver source — namely— for a long, long time before I finally struck gold. Before I dug into this ZIP file and realized it covered my audio chipset, the vast majority of recent updates were for Nahimic audio chips, not the plain-vanilla Realtek chips in my now-aging motherboard.

Frankly, I don’t know why it took so long to find a newer version. My best guess is that older motherboards (and chipsets) don’t get the same love and attention that newer ones do. I have to guess that’s because driver updates require time and effort to create, and older stuff is less likely to be in demand than newer stuff. The just the way of Windows-World: older hardware eventually gets no love at all. Mine is pushing that envelope, clearly.

Thanks Again, RAPR!

The Driver Store Explorer (aka RAPR.exe) once again comes in handy for inspecting driver status on my Windows 10 production PC. It’s the source of the screencap at the head of this story. It does a stellar job of showing Windows drivers, including their number and status on targeted PCs. This search proved an excellent stimulus for me to update RAPR itself, too. Thus, I’m now running v0.11.92 (uploaded to GitHub on 1/6/2023). Previously, I’d been running v0.10.58 (internal file date: 4/10/2020).

Thus, the need to upgrade one thing (the Realtek driver) also reminded me to upgrade another (RAPR). Now, I’ll need to distribute this around my entire PC fleet. Good stuff!