Category Archives: Windows 10

Windows 10 Copilot Remains Elusive

There’s a new KB in circulation that claims to extend the reach of Copilot in Windows 10. That would be KB5033372, released December 12. But alas: on the lone eligible  physical PC and various Windows VMs here at Chez Tittel, Windows 10 Copilot remains elusive. It runs fine inside Edge, but will not show up as a Taskbar or Start menu item on any of their desktops. Sigh.

Why Windows 10 Copilot Remains Elusive

A quick visit to the KB announcement (link in preceding paragraph) gives me an excellent idea why my PC isn’t getting Copilot. Because some multi-monitor set-ups are subject to “mysterious icon migration” across or among desktops, MS has blocked it for such configs. Here’s what they say:

To prevent users from encountering this issue, Copilot in Windows (in preview) might not be available on devices that have been used or are currently being used in a multimonitor configuration.

And wouildn’t you know it: my Windows 10 PC runs with dual Dell UltraSharp 2717 monitors. That definitely accounts for my physical PC’s lack of Copilot. But I’m not so sure about the VMs. It may stem from my typical mode of access to them (using one of the two just-mentioned monitors) or it may be something else.

A Ray of Hope?

In the same KB announcement already cited MS also says that they’re “working on a solution and will provide an update in an upcoming release.” Here’s hoping that release is upcoming sooner rather than later!

And once again, I’m a Johnny-come-lately among all those already in the vanguard. But hey: that exactly the way that things go here in Windows-World. Once more with feeling, I guess!!


Counting MS 2006 Drivers

Yesterday’s post about generic, MS-supplied device drivers got me thinking. These drivers bear an issue date of 6/21/2006, which coincides with Windows Vista’s RTM date. To be more specific, I wondered how many such items might appear in the Windows DriverStore. With counting MS 2006 drivers in mind, I asked Copilot for a PowerShell script to count them for me. Just for grins I compared that count to the total items as well.

Scripting Out Counting MS 2006 Drivers

You can see the results of my query to Copilot in the lead-in graphic. That query was “Write me a PowerShell script to display number of Windows drivers dated 6/21/2006 and total driver count.” As it turned out, on my Lenovo X380 ThinkPad running Windows 11, those numbers were 517 (2006 count) and 701 (total count). On my i7Skylake homebuilt system running Windows 10, those numbers were 511 and 672, respectively.

I’ll show the PowerShell commands below, but first I want to observe I had NO IDEA that MS supplies roughly 5 of every 7 drivers that Windows uses (over 70%). From looking at the items in the DriverStore more closely thanks to PowerShell, I see that this is because many of them are class, bus and service drivers. You can thus understand them as part of the driver stack between the OS and the function driver (at the bottom of the stack, it actually interacts with devices).

Here’s how MS shows this architecture in its MS Learn article “What is a driver?

Counting MS 2006 Drivers.diagram
The driver at the bottom of the stack that communicates with a device is a function driver; according to the MS Learn item, filter drivers do “auxiliary processing” which may involve monitoring, verifying, translating, or otherwise manipulating in- and out-bound stack communications. By convention app to device communication moves down the stack, while device to app communication goes the other way.

PowerShell Details

Here’s the PowerShell that Copilot handed to me in response to my query, including comments (start with a # character):

#Get all the drivers from the online Windows image
$drivers = Get-WindowsDriver -Online -All
# Filter the drivers by the date of June 21, 2006
$drivers_2006 = $drivers | Where-Object {$_.Date -eq "6/21/2006"}
# Count the number of drivers with that date
$drivers_2006_count = $drivers_2006.Count
# Display the number of drivers and their names
Write-Output "There are $drivers_2006_count drivers dated 6/21/2006 in the online Windows image."
Write-Output "The names of the drivers are:"
$drivers_2006 | ForEach-Object {Write-Output $_.OriginalFileName}
# Display the total number of drivers
$alld = $drivers | Where-Object {$_.Inbox -eq "True"}
Write-Output "There are $alld.count total Windows drivers in the online Windows image."

Some of the lines shown above break across two lines in the browser, but are actually single PowerShell commands. If you run them, you must put them on a single line. I just ran the commands in sequence, one at a time as you can see in the lead-in graphic. I cheated, though: I simply output $alld.count in the last line shown. The PowerShell shown above wraps this in some explanatory text.


Windows 10 Lifecycle Changes

If I’m reading its HTML metadata correctly, Microsoft updated its Lifecycle FAQ = Windows document yesterday (December 5).  That’s when they added information about Extended Support Updates (ESUs) beyond the Windows 10 EOL date of October 14, 2025. ESU is a paid-for kind of support that allows licensees to get updates even after that cut-off date. Let’s explore what these Windows 10 Lifecycle changes  could mean.

Exploring Windows 10 Lifecycle Changes

For previous versions of Windows (e.g. 7) MS offered ESUs only to MS customers with existing paid-for support or licensing agreements. If I’m reading the afore-linked FAQ’s text correctly (see lead-in graphic), ordinary users (“individual users”) will also be eligible to pay for and receive these updates. That should be interesting.

I asked Copilot this question “How much did MS charge for ESU on Windows 7?” Here’s how it answered (superscript numbers 1-3 link to the sources for this information):

According to the web search results, Microsoft charged different amounts for Extended Security Updates (ESU) for Windows 7 depending on the edition and the year of purchase. For Windows 7 Professional, the ESU prices were $50, $100, and $200 per device for the first, second, and third year respectively1For Windows 7 Enterprise, the ESU prices were $25, $50, and $100 per device for the same period1However, some customers could get ESU for Windows 7 for free through Windows Virtual Desktop or other support contracts23.

Given that EOL for Windows 7 was January 14, 2020, let’s factor in some inflation. That makes it exactly 5.75 years between that date and the Windows 10 EOL. Using a low-ball average inflation rate of 2.5% over that period means adjusting the foregoing numbers by 14.4% or thereabouts. That means $50 becomes $57, $100 → $114, $200 → $228. You can do the math for the rest (but I think the Professional prices are the ones to go by).

Are They Ready to Rumble?

I’m forced to speculate that MS is adding individual consumers to its upcoming ESU coverage because they believe they left money on the table during the Windows 7 extended service period. This essentially brings businesses and users who are willing to pay for coverage, but who don’t have a licensing agreement or equivalent already in place with MS. It could easily be as big a revenue stream as the covered Windows 7 population was when EOL rolls around.

Inertia is indeed a strong force in business affairs. And sometimes, smaller businesses — especially sole proprietorships — can strongly resist change. This should be interesting to watch and try to figure out. I’m not sure if I should be impressed or appalled. Stay tuned: I’ll tell you…

PS Thanks to Sergey Tkachenko at for bringing this to my attention. I figured out the date info on my own…


Windows 10 Copilot Limitations

Dang! I’d have to call my desktop experience “a swing and a miss.” I jumped on the KB5023378 Preview update, expecting to get Copilot out of that amendment. Wrong! Among the first words in the afore-linked update Support note, key Windows 10 Copilot limitations emerge. This includes this scoping statment: “This [Copilot addition] only applies to devices that run Home or Pro editions…” (emphasis mine). As you can see from the lead-in graphic for reasons that are too long and tedious to explain, this PC is running Windows 10 Enterprise. Sigh.

Bitten By Windows 10 Copilot Limitations

Sigh. It just goes to show that my personal dark cloud hasn’t quit hovering in the vicinity. I’ve often observed that if MS slides an update out as a gradual release, my PCs are invariably in the rear guard. This is something of a spin on this all-too-familiar situation, but nontheless an amusing one.

Fortunately, my physical desktop is not the only Windows 10 image I can run. I just jumped over to the ThinkPad P16 Mobile Workstation where I have a couple of Win10 images from which to choose. My cleanest one (installed last week for an AskWoody column) is installing same right now. When it reboots, I expect to see a Copilot icon in the Taskbar. Here goes…

Overall, install time on a 4GB Gen2 VM was quick. The whole thing took under 3 minutes to download, install, then cycle through post-reboot update processing. Good stuff. But did I see Copilot on the Taskbar when it was all done? Nope.

I had to turn on and relaunch the VM to come back from the update reboot. And another reboot didn’t bring it up, either. Nor did a right-click in the Taskbar show a Copilot control. No Copilot item under Settings → Personalization, either. Very interesting. I’m obviously going to have to learn more to get Copilot working on my Windows 10 Pro VMs. Should be fun: stay tuned!

That Old Familiar Sensation

I see in the Windows Latest coverage (Mayank Pamar) that “Microsoft has also warned that the feature may not be available on devices with compatibility issues, including devices with an incompatible app.” Why do I get the feeling that includes either my ThinkPad P16 Mobile Workstation or its Hyper-V runtime environment for my 2 Windows 10 VMs on that machine?

Note Added December 6: Maybe I should be grateful none of my Win10 PCs got Copilot? I’m seeing numerous reports that MS has put updates for both 10 and 11 on hold because of Copilot issues. I guess waiting is better than troubleshooting problems of Microsoft’s making. Isn’t that just the way things go here in Windows-World?


Recent Windows Terminal Follies

It’s always a humbling experience to work and work with Windows. This week, I’ve been relearning how Windows 10 works with Windows Terminal (and sometimes doesn’t). I had to stand up a squeaky clean Windows 10 instance in a VM for some WT testing and research. Tongue planted firmly in cheek as I went through some recent Windows Terminal follies, I realized I’d forgotten more about WT than I’d ever known. Let me explain…

History Underlies Recent Windows Terminal Follies

Today, my production Windows 10 installation has been running since 2016, when I stood up my present primary desktop PC. There have been a LOT of changes to Windows since then. And indeed, Windows Terminal (WT) is one of the things that has changed the most. But because I’d gone along with those changes — growing more experienced and wise to the ways of WT — I really didn’t remember all of the little twists and turns along the way.

Thus, installing a clean Windows 10 OS image came as a series of shocks where WT was concerned. Let me list a few of them:

1. Windows 10 made its Insider Preview debut in 2014, WT didn’t come along until May 2019. Thus, it’s not set as the default command line environment in Windows 10.

2. WinKey+X, to my consternation, kept launching an older PowerShell version (v5.1.19014.3570). And the only version of WT present was an older Preview that I didn’t want.

3. Thus, I found myself visiting the MS Store to grab the latest copy of WT, installing it, then setting it as my default terminal application (see lead-in graphic: notice further than this version needs an upgrade).

Eventually, I got things sorted and where I want them to be. But it did come as something of a shock to understand how much change I’d been introducing to my desktop runtime, step by little step. Only when I had to jump the whole stretch in a single bound did I see how far things has really come.

Some Unexpected MSA Bonuses Also Present

OneDrive picks up files from my User folder as part of what it keeps in the cloud. Apparently this includes my PowerShell Profile, because an invocation to OhMyPosh showed up as I fired off the new WT install for the first time. That made setting up OMP even faster and easier than usual.

The moral of today’s story is that one doesn’t really recognize how far one has come (or how much things have changed) until one is forced to recover the same ground and see what’s different. That’s one good reason why — for me, at least — Windows-World is always an adventure.


Upgrades Are Over, Activation Still Works

I read yesterday at that MS was no longer supporting free upgrades from Windows 7 or 8.1 to Windows 10 or 11. “Holy smokes,” I thought to myself, “That’s been a long time coming.” That offer supposedly expired in 2016 but had been working until recently. My next question was: “Does that mean you can’t activate a new Windows 11 install with a Windows 7 key any more?” Based on a hurry-up experiment I just finished, I’m bemused to report that if upgrades are over, activation still works. I’ll explain…

Though Windows 7 and 8.1 Upgrades Are Over, Activation Still Works

Here’s what I did. I downloaded a Windows 11 Pro ISO, I fired up Hyper-V Manager, and I created a new VM using that ISO. When the time came to provide a license key, I plugged in an entry from the list of Windows 7 Ultimate license keys I keep around for testing purposes. Guess what happened?

It worked! In fact, the screencap at the head of this blog post shows the newly stood-up VM with an Activation state of “Active” from that very Windows 7 Ultimate key (anybody else remember that edition?). Thus, though it may no longer be possible to upgrade from running Windows 7 or 8.1 instances, it seems like their keys will still suffice to crate a valid, activated instance of Windows 11 from scratch. Good to know!

Straight from the Source: MS

Mr. Thurrott cites a Microsoft Device Partner Center communication as the source of this information. That item is entitled Windows Ends Installation Path for Free Windows 7/8 Upgrade. It bears a publication date of September 20, 2023. For the moment, though the upgrade path may be closed, it looks like the keys still work for activation. I wonder if this loophole will remain open, or close sometime as well. Stay tuned: we’ll see!

Clarification Added September 30

Thanks to a more recent story from Sergey Tkachenko at WinAero, I now have a better idea of what’s going on. The 7/8 keys still work for versions of Windows 10 and 11 through 22H2. You can’t, however, use those keys to activate a new install of 23H2.  I tried only Windows 11 22H2, not a preview of 23H2 (AFAIK, it’s not out yet in any other form). NOW I get it…


Avoiding Windows Self-Update Traps

Think about it. When a program needs an update, sometimes what’s doing the update and what’s getting the update may be related. This gets interesting. Windows itself is a pretty good example. This explains why reboots are required to install  an OS, and often when updating same. Simply put, the pieces being working on cannot also do the work on themselves in many cases. Applications, apps, and so forth can also fall prey to the same things (think about installing an installer). Thus, avoiding Windows self-update traps is something of a balancing act.

Example: Avoiding Windows Self-Update Traps

I saw a great example of an artful dodge around this problem yesterday, as I was using Winget to update Windows Terminal (WT). Take a look at the lead-in graphic. It shows the WT update progress. Note that the last instruction at the end of that process reads:

Restart the application to complete the upgrade.

That’s exactly the kind of maneuver that’s necessary. It allows the currently running code for a program (or OS) stop running. Then, the newly-updated or installed code for the same program (or OS) can take over and start doing its thing.

Counter-Example: PowerShell

Back in June, I wrote a blog post here entitled WinGet Upgrade PowerShell Shows Cancelled. It shows what can — and sometimes still does — happen when the tail end of the installation process fails to complete and exit cleanly. I know the PS team is working on this, but this shows that self-updates do pose occasionally tricky problems.

I’m glad to see the WT take the high road and suspend the final steps of install or upgrade until it’s safe to do so. I’ll be gladder still when the PS team eventually follows suit (as I’m sure they will). In the meantime, I did find a workaround: if you open a Command Prompt session and run the winget PS upgrade there, no “cancelled” (or other error messages) result. Good enough for me, for now!


Snappy Driver Installer Worth Considering

I know. I know. Lots of Windows experts and pundits, including at AskWoody, TenForums and ElevenForum, don’t recommend or support driver update tools. That said, I find Snappy Driver Installer worth considering anyway (at least, the Origin fork). Let me recite some recent experience. Then I’ll enumerate the reasons why I’m so grateful for Snappy Driver Installer…

Why Say: Snappy Driver Installer Worth Considering

First let me explain why I’m grateful for this tool and its labor-intensive project. Almost alone among such tools, Snappy Driver installer (SDI) is open source (GNU GPL v3.0 license). Most decent driver update tools cost upwards of US$30 per year, some more than that.

Just this morning, Norton (still running it on my production PC, but I plan to bid it adieu with my next desktop build) told me I had 14 drivers out of date. It costs upwards of US$60 to add its driver scanning functions (and a bunch of other stuff, too) to its ~US$90 annual subscription fee. I’m not interested in paying more, thanks, but I was glad to learn I had some drivers out of date.

Firing up SDI for the first time is interesting because it needs more just under 37GB of driver files to offer a complete collection of stuff from which to work. Even so, the tool is smart enough to focus only on driver packs (7ZIP files of related drivers) that a target PC needs. For this target PC, that involved just a bit over 3 GB across 8 different archive files. SDI was able to handle all the out-of-date drivers on its own, in about 30 minutes (most unattended, while I did something else).

SDI Benefits and Features (IMO Anyway…)

Snappy Driver Installer is free. It’s easy to maintain a portable version on a UFD you can use for all your Windows PCs. It works with all current Windows versions (I’ve used it across the range of Windows 10 and 11 editions and builds).

For me, SDI does the job nicely and keeps my PCs current without annual subscription fees. And because I routinely shoot an image backup before mucking about with drivers, I can say no such update has ever hosed one of the PCs under my purview.

Like I said at the outset: SDI is worth checking out for yourself. You just might find it useful. Your call…

Note: For timing purposes I fired up SDI on another test PC to see how long it takes to grab the whole collection of driver packs. Right now, it’s 115 minutes in at 50% done. That means it could take as long as 4 hours to complete. It’s clocking between 18 and 85 Mbps as it runs, so it’s apparently throttled deliberately and carefully. Final runtime came in well under 3 hours (just over 155 minutes, or 2:35).

Wait! There’s more: Version forks and controversies

I got a tweet today from David Ballesteros. He let me know there are dueling versions of SDI, including the one formerly linked above (I removed it as I’ll explain). Another is called SDI Origin, which gets an interesting description at MajorGeeks.

WARNING!!! Malware is reported in the SDI fork. Thus, many online posters say — no surprise there — use SDI Origin instead. I’ve not run into any of said reported malware, adware or other potential gotchas, but my PCs are pretty armored up.

Just to be on the safe side it seems like SDIO (SDI Origin) is the best version to use. That’s why I killed the link to the other fork (but it’s easy to find online). And as I look at the filenames on my home drive for Snappy I see I wound up with the Origin version in both subfolders anyway (directory root is named SDIO).

As you can see in this properties Window, even my original exe file is named “Snappy Driver Installer Origin.” Reinforces the old saying: it’s better to be lucky than good. Phew: might’ve dodged a bullet!


Interesting OMP Winget Gotcha Is Easily Fixed

I have to laugh. When I opened Windows Terminal/PowerShell yesterday morning, I got a notification that a new version of OhMyPosh (OMP) was available. So naturally, I tried to see the update. When that failed, I tried to update OMP directly, and that failed, too. But thankfully, this interesting OMP gotcha is easily fixed. I’ll explain …

But first take a look at the lead-in graphic above. It starts with the notification. That happens when loading PS causes the OMP environment to start up, too. But running winget upgrade shows an issue with accessing the winget database. Ditto for trying an explicit, directed upgrade on the string “Oh My Posh.” What to do?

OK, Here’s How Interesting OMP Winget Gotcha Is Easily Fixed

First, the fix: I went to GitHub, where developer Jan DeDobbeleer always maintains a current version under its “Latest” link. For the record, I downloaded and installed his install-amd64.exe file there and the upgrade completed without a hitch.

But what went wrong with OMP in the first place? I sent Jan a Twitter (X) message and he replied: “Yes, unfortunately winget, just like the Store, is slower in processing new versions.” I took this to mean the changes were already posted to the manifest database, but that those changes had not yet been committed.

It’s Just a Matter of Time

And indeed, I just checked one of my other test PCs with OMP installed. Running winget just now, it shows — and stands ready to — upgrade OMP to the latest version. Looks like the notification beat the update yesterday, but they’re now back in synch. Here’s visual proof:

Interesting OMP Winget Gotcha Is Easily

This morning’s check works as expected. Database is caught up!

And boy howdy, as we say here in Texas, isn’t that just the way things sometimes go, here in Windows-World. You bet!


Registry Hack Cleans Out Stale RDC Items

Wow! I guess there have been more changes in the PC fleet here at Chez Tittel than I thought lately. I kept seeing stale entries in the drop-down list from Remote Desktop Connection. So I found a Microsoft Learn article that explains how to remove or replace them. It’s entitled How to remove entries from the Remote Desktop Connection Computer box. Its registry hack cleans out stale RDC items. Let me explain…

More Info: Registry Hack Cleans Out Stale RDC Items

Visit the following registry key inside Registry Editor (regedit.exe):

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default

Indeed, you can cut’n’paste this string into the address line in regedit, and save yourself the toil and trouble of typing it in. When you get to that key, you should see something like the lead-in graphic underneath the leaf-node (…\Default).

As you can see it includes 10 values named MRU0 through MRU9. To remove any such value, right-click and select ‘Delete’ from the resulting pop-up menu. In my case, I had old values that kept showing up, but also new values I wanted to include. So instead of deleting stale values, I right-clicked their keys, and modified the associated string values to match the machine names of new machines I’d added. As shown in the lead-in graphic that meant adding P1Gen6. Next, I deleted lenyog7i (MRU7) because I’ve returned that unit to Lenovo.

To see what registry changes look like, you must close and then re-open regedit. Here’s what it looks like now (notice that MRU7 is now missing):

Registry Hack Cleans Out Stale RDC Items.updated

Note that MRU7 is missing, now that it’s deleted.

As you add and remove items using this hack, the registry automatically renumbers them. But unless you change the number of items from the default count of 10, you’ll only ever see items MRU0 through MRU9 (10 items, all told). Great fun!