On January 8, 2024 Wi-Fi 7 went public. That’s the same day the Wi-Fi Alliance introduced its Wi-Fi Certified 7 program. USB4 version 2.0 goes all the way back to October 18, 2022. But only with the release of Insider Preview Canary Channel Build 26063 in February 2022 did MS start testing support for related Wi-Fi 7 drivers. (USB4 version 2.0 has been baked in since Build 23615 in the Dev Channel, released January 11, 2024.) Neither has appeared in a production version of the OS. Thus, a valid question for Windows 11 Wi-Fi 7 & USB4v2 has to be: What’s going on? TLDR answer right now is “Not much just yet.” There are lots of good reasons why so please let me explain…
What’s Afoot with Windows 11 Wi-Fi 7 & USB4v2?
One way to look at this is from a market availability standpoint. Precious few devices for sale right now support either or both of these standards. As I write this item, I see exactly 2 network adapters (one USB, the other PCIe x4) that support Wi-Fi 7.Ditto for Wi-Fi 7 routers. I can’t find any laptops that offer built-in support for either standard just yet. Many new models are promised later in 2024, and could change that.
Though it’s being proclaimed as something of an oversight it’s really just a function of supply and demand. (See this Tom’s Hardware news item by way of illustration.) Basic economics and recent history with Wi-Fi 6 and USB4 version 1.0 show that it takes about two years for these new standards to make their way from introduction and into more general adoption. I don’t see this latest iteration as terribly different.
Shoot! I didn’t lay hands on my first PC with built-in USB4 capability until the Panasonic Toughbook FZ-55 showed up here at Chez Tittel late last year. Just before Christmas, in fact. If it takes that long to hit my hot little hands again, I’m looking into late 2025 before a personal encounter might happen.
Oh well: it happens sometimes. One of my two test PCs on the Insider Preview Canary 26063 throws install error right near the end of the install process. It’s one I’ve seen before –namely:
Failed to install on 2/22/2024 - 0xc1900101
It’s something of a grab-bag error in that it can come from insufficient disk space, driver conflicts (esp. from external USB devices), an out-of-date driver on the target PC, AV conflicts, and more (see this MTPW Backup Tips note for all the deets).
When Canary 26063 Throws Install Error, Then What?
I’m trying a two-pronged strategy this morning. First thing is a simple retry. And when I ran that option in WU, it thought for a while, then jumped from the download phase to the GUI install phase. So obviously, it checked over yesterday’s UUP downloads and found them satisfactory. Right now, WU is 49% into installling 26063. Here’s hoping that works.
But on the other prong, I’m downloading the 26062 ISO from UUPDump.net. I’ve observed that when a WU-based install fails, sometimes a local install using setup.exe from a mounted ISO will work. It may also provide more useful error messages in local logs should it fall over near the end of the process yet again.
FWIW, this seems to be a pretty substantial update, too. And indeed on the other test PC — the one where the upgrade worked –it says 24H2 in the Winver window. I guess that means MS is floating Windows vNext to Insiders right now.
Lookit that! 26063.1 says “Version 24H2.” It’s arrived…
More to Follow…
Now, the WU install is at 64% and UUP is building images and stuff for the upcoming ISO file. Based on yesterday’s experience, this will still take a while. I’ll jump back in and update when it gets wherever its going. Stay tuned!
It’s been weird. I had trouble accessing my Lenovo ThinkPad P16 Mobile Workstation for an attorney call last Friday. I couldn’t see it while it was hooked up on Ethernet but it worked OK in Wi-Fi. Today, i finally figure out why that was happening and RDP absence P16 fixed as a result. Deets follow…
How to Get RDP Absence P16 Fixed…
The ever typical error message that shows up when RDP can’t find a PC by desigation (computer name in this case) appears in the lead-in graphic above. Because I already fixed my P16 problem, I used “P15” as the machine name. Since there ain’t no such beast on my LAN, of course it provokes the old familiar “can’t find the computer…” error message shown. But that’s what I was seeing for the P16.
Took me a while to figure out why. If you follow this blog you know I had a Panasonic Toughbook FZ-55 on loan here for some time (unboxing post). While it was hooked up to the LAN it used the Ethernet port my P16 normally uses. On the P16 I switched to Wi-Fi.
That was the problem: with a new NIC for Wi-Fi the P16 also got a new set of IPv4 and v6 addresses. When I hooked back into Ethernet, RDP knew nothing about this. So when I accessed the P16 by name it went looking for it on its Wi-Fi associated IP address. No go!
Fixing the Mix-up
Removing info from RDP requires deleting associated keys in the Registry. I had to visit the key named
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default
to reset the RDP roster. With the old (and incorrect) entry removed I had to go through initial RDP connection set-up again for the P16. But that was easy (provide a password for the Windows login I use) and done. Now things are working again on the Ethernet connection. Only problem is, I’ll have to remember to do this again if I switch back to Wi-Fi (or just use the IPv4 address, which is how I got back in and ultimately how I figured things out).
And isn’t that just the way things go in Windows-World sometimes. If it ain’t one thing, it’s another!
OK, then. I’ve been trying to figure out why, on some of my test PCs, I get an error message when PowerShell loads my profile and tries to import the PowerToys WingetCommandNotFound (CNF) module. You can see that error message in the lead-in graphic above (from my ThinkPad P16 Mobile workstation). Thanks to some fiddling around, this CNF conundrum gets some love — finally!
I haven’t figured out how to fix the problem properly just yet. But for the nonce, if I go into PowerToys, visit CNF, uninstall and then resinstall same, it returns to work. This happens every time I open a fresh PowerShell session, so it’s at least mildly bothersome. But I’m starting to make progress on figuring things out.
How CNF Conundrum Gets Some Love
The error message keeps changing on me as I add things to the folder where the profile resides — namely %user%\documents\PowerShell. First, it complains about not being able to find the module itself. I copy it into that folder. Then it complains about a .DLL. I copy that, too. Finally, it complains about an error handler not being able to field a thrown exception.
It’s not fixed yet, but I now know that this issue comes from my PowerShell modules path set-up. Something is wonky between those search paths (there’s one for the system, and one for my login account) and PowerToys. This happens for one of my Microsoft Accounts (MSAs) every time I use it to log into Windows, because this information is shared across those instances through OneDrive.
I’ve got to research how I should be setting things up in the OneDrive environment to get PowerShell and PowerToys to get along with each other properly. I’ll be contacting the WinGet crew (Demitrius Nelon’s team at MS) to request additional info and guidance. That’s because my online searches have only clued me into what’s going on, but not how to fix it properly.
Stay tuned: I’ll keep this one up-to-date. And I’ll probably post again, when a resolution is formulated. This just in: OneDrive is reporting multiple copies of the PS profile in its file store. Could this be related? I have to think so. Again: stay tuned…
At the beginning of this month, I performed an in-place upgrade repair install on my Windows 10 production PC. It’s now running Build 19045.4046. You can see that this repair install fixes instability on the PC in the lead-in graphic. Over the past 20 days I’ve had only one critical event — mostly self-inflicted when testing winget Chrome update behavior (see last Friday’s post for details). Otherwise, this 2016-vintage system has been rock solid of late.
When in Doubt, Repair Install Fixes Instability
Gosh! I’ve long been a believer that an in-place upgrade repair install (IPURI) is something of a Windows cure-all. Reminder: an IPURI runs setup.exe from a mounted ISO for the same version of Windows that’s currently running on a PC. Thus, it requires the host OS to be running well enough to replace itself. See these terrrific TenForums.com and ElevenForum.com tutorials for all the details…
Thus, you can’t use this technique if you’re having boot problems, or the OS isn’t running well enough to get through the GUI phase of a Windows upgrade. But for situations where the OS is running (but most likely, not as well as you might like) this technique works extremely well. My earlier Reliability Monitor trace, before the February 1 IPURI, looked something like a sawtooth wave on an oscilloscope. Ouch!
How to Get the Right ISO
I still use UUPDump.net to match build numbers between what’s running and the ISO I have it build for me. Then, I mount that ISO, and run setup.exe from the virtual DVD drive ID Explorer puts out there for me. Lately it’s been showing up as the E: drive; but this morning it comes up as P:. But you’ll most likely see it labeled with the initial characters of the image label like this:
Here’s what Explorer shows me when I mount the ISO I used on February 1 for an IPURI: Virtual DVD Drive P:
For the record, I also use the excellent Ventoy project software to boot into my various ISOs when an IPURI won’t do. Admins and power users will want to keep a USB handy with their fave ISOs for repair and recovery scenarios. I do that on a 1 TB NVMe SSD inside a USB3.2 drive enclosure. Lets me keep dozens of ISOs around, ready to boot into any of them on a moment’s notice. Good stuff!
As far as I can tell, I’ve been blogging here about the Windows Package Manager — Winget, that is — since May 2022. Indeed it’s received regular mention ever since (nearly a third of all posts). I finally observed the other day that winget won’t update a browser with any of its processes running on the target PC. Also the browsers I use (Chrome, Firefox, Edge) still make you “Relaunch” to complete any update. This includes instances when Winget updates them successfully. Hence my assertion: Winget browser updates may be curious. And I mean both in terms of effect and outcome.
If Winget Browser Updates May Be Curious, Then?
It doesn’t stop me from trying, but the update doesn’t happen at all when any related process is running. Thus, for example, if any chrome.exe items show up in Task Manager>Details view, winget breezes past the update package and does nothing. Ditto for Firefox and Edge. But it’s a good flag for me to jump into each one’s Help>About facililty which is usually more than happy to update from insider the browser itself. And again, to request a “Relaunch” when that process comes to its conclusion.
It’s all part of the learning process in working with winget to keep Windows up-to-date. Sometimes — indeed nearly all the time — winget handles update packages quite nicely on its own. At other times (less often) winget acts as a sentinel to warn me that an update is available, which I then must figure out how to install.
Here’s a short list of such programs above and beyond the browsers already mentioned: Kindle for Windows, Discord, certain EA game executables, Teams Classic, Windows Terminal (now fixed), and even Winget itself from time to time. But gosh, it’s always fun to see what’s out there and what happens when winget wrangles update packages. It’s made my life ever so much more interesting (and updates easier) since it emerged in 2022.
It’s a small change but a helpful one. In Canary Channel Build 26058 Explorer brings button labels back. That is, instead of simply showing labels and forcing you to do one of these:
- Remember what they are and what they do
- Mouse over the label icon and read the text tip
- Pick one and hope for the best
Explorer once again shows text to accompany the icons so users know what they’re doing. These show up at middle in the lead-in graphic, with icon buttons above and text below. To wit: Scissors button/Cut, overlaid pages/Copy, Text “A”/Rename, Block with pointer/Share, and Trashcan/Delete. Good stuff!
You can see what the old way looks like in the production Windows version (Build 22631) below where the icons appear at the bottom of the Explorer right-click context menu for files inside a folder. Much less intelligible, IMO.
Notice the line of icons at the bottom of the content menu. Mouseover will show tip text.
Rejoice When Build 26058 Explorer Brings Button Labels Back
It’s not a huge change to see text show up with a button, unprompted. But it is a comforting usability improvement. I’d always wondered why MS adopted this ultra-compact approach. But given the presence of tip text on mouseover, I’d always been able to suss things out if I wasn’t 100% what was what.
This latest improvement saves the time and effort involved in mousing over. I definitely appreciate it. On the one hand: thanks! On the other: Why’d it take so long?
And if those aren’t among the major dueling dualities here in Windows-World, I haven’t been paying attention for the past 30-plus years. Yeah, right…
Here’s an interesting one. I’ve noticed recently that when PowerShell gets an update, the next time it launches PowerToys “Command Not Found” (CNF) drops an error message. Hence this post’s title: PS Update Orphans PowerToys CNF.
You can see how this story starts in the lead-in graphic. It shows the error message that CNF.psd1 did not load “because no valid file was found in any module directory.” Seems like an impasse, don’t it?
NOTE Added February 15: It’s the profile not the PowerShell!!! The following observations are correct — the profile and the reference to CNF are indeed mismatched — but it’s NOT PowerShell’s fault. It’s because I’m backing up my profile stuff in OneDrive and the location in the profile is incorrect. Uinstall/reinstall fixes that issue until the next time OneDrive replaces the (correct) local profile copy with the (incorrect) cloud-based one. Sigh. I’ll write about this on Monday, Feb 19, after I’ve had time to figure all the angles!
PS Update Orphans PowerToys CNF Easily Fixed
I superimposed the CNF panel from PowerToys Settings for a reason, though. Even though its status messages and detections all show green, it turns out the real problem is that PowerShell itself can’t find the CNF module.
Here’s the easy fix. Uninstall CNF (click the Uninstall button at center right). Then it changes to an Install button. Now, click that and CNF gets reinstalled. Now, the next time you open PowerShell everything is copacetic, with CNF back at work, as shown in response to my now-standard “vim” test string:
After uninstall/reinstall CNF in PowerToys, close and then re-open PowerShell. [Click image for full-size view.]
Sometimes, when certain little things get you, other little things can set them back to rights. In this particular case, that’s how I’d generally describe the path to an error-free PowerShell startup after update, with a working PowerToys CNF as well. Cheers!
OK, then: the ‘net has been abuzz since last week as upcoming Windows 11 24H2 requirements come clear. Indeed, that OS won’t run on processors that don’t support the POPCNT instruction . IMO this POPCNT fuss is more fizzle than it is a major obstruction. Let me explain…
Why Say: POPCNT Is More Fuss than Fizzle
The POPCNT instruction has nothing to do with stack processing as its name might suggest. Rather, it counts up all 1-values in a binary sequence. It’s part of the SSE4.2 instruction set. These were introduced in 2008 to both AMD and Intel processors — namely:
- AMD K10 (codename Barcelona), released in April of that year
- Intel (codename Nehalem), released in November same year
That means the oldest processors that DON’T support SSE4.1 (and POPCNT) are more than 15 years old. Not terribly suitable for running Windows 11 anyway and likely to fail owing to lack of support for TPM, Secure Boot, and other reasons as well.
You can use Franc Delattre’s excellent CPU-Z tool to check your CPU to see if it supports SSE 4.2 or not. Check the lead-in graphic next to “Instructions.” It pops right up even on my 6th-gen 2016 vintage Skylake CPU (still running Windows 10 BTW).
For all but the most diehard long-haul PC users running a machine more than 5 years old is pushing things (and 15-plus years is highly unusual). This very Skylake is my oldest at 8 years, and it’s due for retirement soon, soon, soon.
WTFuss? No Workaround
The problem with POPCNT is that it’s absolutely, positively mandatory for 24H2 to work. Whereas the other impedimenta — e.g. TPM, Secure Boot, UEFI and so forth — have all been cleverly worked around, there’s no known (or likely) workaround for this gotcha. Thus, older PCs that have been shoehorned into Windows 11 upgrades will not be able to advance past the 23H2 upgrade level. Hence such fuss as has emerged in the blogosphere since this news came out last week.
My best guess that that less than 1% of PCs in the US (and perhaps 5-8% of PCs elsewhere, mostly outside the first world) might be subject to the POPCNT limitation. Just another sign that even here in Windows-World, time keeps marching on.
Remember that scene near the end of The Incredibles where one older cop says to the other “No school like the old school?” That snippet of wisdom crossed my mind as I decided to switch from an MS wireless Mobile Mouse 4000 to an MS Basic Optical Mouse 2.0. Why? Because a wired mouse means no stutter, lag, or hesitation when working on my desktop (or playing Gnu Backgammon or MS Solitaire, two of my fave diversions). Sigh.
Why Wired Mouse Means No Stutter?
I’m pretty sure the fault is mine for the wireless mouse issue. I had its transceiver mounted on my Luxo lamp, right next to a couple of monitors and less than 2 feet away from my Asus 802.11ax router. Not to mention further, it’s in close range of 3 laptops and my desktop as well. Your basic signal-rich, if not downright noisy, wirelesss environment. That said, I didn’t have these problems with the older MS Mobile Mouse 3000 (but alas, they don’t make them anymore).
But now that I’ve got a more isolated communications channel between desktop and mouse, there’s no more stutter or delay. Sometimes, the old school is the only school that works without issue. I have a feeling this may be one of those times. Plus: it was really bugging me. Go figure!
While you’re doing that, I’ll be taking the occasional break for backgammon or solitaire, content in believing that my ancient but unhampered wired mouse will remain snappy enough for my needs. Thank goodness!