Here’s something freaky about Win10 that seemingly comes up more often by accident than by design. Based on periodic OMG posts on TenForums and answers.Microsoft, and my own experience, it strikes from time to time. It rests on a three-key sequence: Ctrl, Winkey and the letter “C.” Struck together, they toggle a Win10 display between grayscale and normal color. That means if the display is in normal color mode (as it will be by default), this causes the display to switch to black-and-white. For those who don’t do it on purpose (or, as I read in at least one case, whose cat treading on the keyboard did it for them) it seems like something’s gone wrong to leach all the color out of windows. Because Ctrl+Winkey+C toggles Win10 display to grayscale mode, you need only repeat the toggle to return to full color.
Here’s a side-by-side comparison using three Google News items to illustrate:
Full color version on top, grayscale version on the bottom. [Click either image for full-sized view.]
How Ctrl+Winkey+C Toggles Win10 Display to Grayscale Mode
This behavior comes enabled in Windows 10 by default. But it’s easy to reverse (as long as you remember the secret key combo). You can also turn it off by typing “color filter” into the Windows 10/Cortana search box. This opens the “Color Filters” page in Settings. There, you can turn color filters off if they’ve been mistakenly turned on. The checkbox labeled “Allow the shortcut key to toggle filter on or off” can also be disabled, if you like.
A slider and a checkbox control the presence or absence of color filters, and the efficacy of the three-key-sequence.
For those bitten by this phenomenon by accident or mistake, unchecking the checkbox prevents an unwanted recurrence. Instead of remembering the key sequence that returns your system to normal, you must instead remember the Color Filters page. There, you can manage color filters manually. It’s kind of an interesting trade-off, isn’t it? Personally, I’m sticking with the three-key sequence myself.
Nir Sofer is a prolific developer of Windows tools for all kinds of uses. His NirLauncher utility console brings over 200 tools together, at last count. After massive reporting of LAN issues for Version 1803, I re-discovered his excellent NetBScanner utility. It scans local subnets nicely, and produces readable reports on what it finds. My LAN is on a private Class C subnet 192.168.1.x. The tool quickly scanned through all 256 LAN addresses and produced a table of the occupied addresses. Because the data is nicely pruned and formatted, NirSoft NetBScanner offers Win10 LAN insights that are immediate and useful.
Only occupied IP addresses show up, with all the useful and interesting values ready to hand.
[Click image for full-sized view.]
How NirSoft NetBScanner Offers Win10 LAN Insights
The problem with built-in command line tools is that they make it difficult to pair up NetBIOS names, IP addresses, MAC addresses, and adapter vendor info in a single glance. NetBScanner does all that in one swell foop, and provides NetBIOS Master Browser status as well. This tool came in very handy as I was trying to make my LAN nodes visible to the other Windows 10 hosts on the network after upgrading to 1803 earlier this month. I’ve also read online that numerous other regulars and members at TenForums have benefited from using this nice little tool, too.
Although NetBIOS has a deserved reputation as something of a “Zombie protocol” (the protocol that wouldn’t die), it’s still around. And it’s still the cornerstone for LAN access and use among Windows PCs. Thus, ready access to this tool will help you see and figure out what’s up on your Windows LAN, should trouble rear its ugly head. And indeed, it helped me figure out that several of my nodes had switched from private to public network status after applying the 1803 upgrade. A quick switch back, and some tweaks to the Defender Firewall, and I was able to see and interact with my entire LAN cohort, as shown in the preceding screenshot.
If it worked for me, chances are pretty good it will work for you, too. Give it a try, please!
I don’t normally write much about the Insider Preview builds for this blog post. Practicing Enterprise admins have enough on their hands keeping up with current branch versions of the OS. But when I see new features of potential benefit, I break that restriction happily. As of Build 17682, the built-in Deployment Image Servicing and Management (DISM) command gains an interesting new capability. At the command line, you can tell it to alter the default 10-day retention period for keeping Windows.old around. That means when the next version of Windows 10 goes into production, you can set a rollback period of your choosing simply and easily. Thus, it’s piece of cake to set Win10 R5 rollback retention interval however you like it.
How to Set Win10 RS5 Rollback Retention Interval?
Here’s a PowerShell screen capture that shows me:
- inquiring about the current interval
- re-resetting that interval to 12 days
- showing that changed value
DISM /ONLINE is a given, because we’re working on a loaded (and running) Windows image. The new cmdlets are Get-OSUninstallWindow and Set-OSUninstallWindow.
[Click on image for full-sized view.]
The syntax for Get-OSUninstallWindow is dead simple. By itself, it shows you the current number of days the OS will keep Windows.old around, thereby allowing rollback to occur. Set-OSUninstallWindows takes an integer value for the /Value attribute. It resets the retention interval to whatever number of days you specify. Thus, I show the intial value as a default of 10 days. I reset that to 12 days, and use Get-OSUninstallWindow again to show the change has been applied.
What’s Your OSInstallWindow Choice?
It’s whatever you want it to be. If you build canonical images for deployment, you can use this DISM command on a running instance of that canonical OS to make this change while it’s online. Note that MS Docs “DISM operating system uninstall command-line options” includes this warning: “OEMs shouldn’t use this setting in imaging or manufacturing scenarios. This setting is for IT administrators.” That said, I don’t see a downside to changing this in a canonical image prior to its deployment to testing or production. And then, your rollback interval will be whatever you choose!
What If These Commands Don’t Work? [Added 6/25/18]
If you don’t have a Windows.old folder on your PC you can’t use the Get or Set -OSUninstallWindow parameters on DISM successfully. I can’t say why MS did this, but if you run either command on a Windows 10 1803 or higher PC that has already been cleaned up after its most recent upgrade, you’ll get an error that reads “The system cannot find the path specified.” That’s because the command goes off looking for Windows.old. If it doesn’t find that entry, you get the error. If it does find the entry, get shows you the current size of that window in days, while set lets you change the value from its default of 10 days. You’ve been warned. Go Figure!
I’ve found myself shaking my head in disbelief over the past weeks as stories about incredible uptake rates for Version 1803 have appeared. Usually credible writers such as Peter Bright at Ars Technica and Liam Tung at ZDNet have been taken in on some numbers based on observations from AdDuplex which describes itself as a “leading cross-promotion network for Windows Phone and Windows applications.” Alas, as my old buddy and fellow Windows Insider MVP Ed Bott observes, “the inclusion of Windows Phone, a now defunct product … should be a red flag” when it comes to assessing AdDuplex’s credibility and veracity as a broad base for statistical anything. In fact, Mr. Bott convincingly argues at ZDNet that characterizing AdDuplex-based Win10 uptake projections mostly bogus is absolutely correct.
It’s impossible for half the user base to have updated to 1803 already.
Why Say AdDuplex-based Win10 Uptake Projections Mostly Bogus?
AdDuplex’s numbers extrapolated to the entire Windows installed base indicate that half that population has already updated to Version 1803. As Mr. Bott observes in his article (and I had independently concluded on my own) this is flatly impossible. Microsoft has just reported on June 1 at its Build 2018 meet-up, as per this Neowin story, that “there are over 700 million active Windows 10 devices.” Thus, that would mean somewhere in the neighborhood of 350 million devices already upgraded to 1803. Simply put, that’s not true (or possible).
Here’s why. The extrapolation comes from data collected on about five thousand Windows Store apps with the AdDuplex SDK embedded inside them. Bott reports a principal at AdDuplex puts the number of devices sampled at “over 100,000.” As Bott observes, that’s less than 2.14 x 10-6 (0.00000214) of the total Windows population. (I adjusted his 600M baseline to the 700M baseline confirmed by MS this morning.) The kicker is that only AdDuplex apps use the SDK. Many of those apps are mobile (a mostly defunct and vanishing platform). In fact, they focus primarily on what Bott describes as “casual games … and some utility apps.”
A Shaky Foundation for All Windows Users
What kind of basis is that for making projections about the Windows user base? Bott submits, and I concur, that it’s not a very good one. For one thing, it completely omits the 200M enterprise/business users of Windows 10 (as reported in this 5/8 ComputerWorld story), none of whom are likely to have anything to do with AdDuplex data acquisition. For another, the mobile focus in AdDuplex represents an odd and vanishing subset of Windows 10 users. And finally, there’s the practical observation that MS deliberately stages its release of new feature upgrades, and withholds the upgrade through Windows Update for older and potentially more problematic PCs. It also blocks the update for machines with known gotchas (such as the Intel 600p series SSDs, which didn’t work with 1803 until KB4100403 was released on May 23) until fixes are ready.
Flatly stated, there’s no way in heaven or hell that half of the user base is at 1803 just yet. It’s simply not possible, and thus, completely unlikely as well. As the old data analysis maxim goes: “Garbage in, garbage out!”
Hey! I just learned a cool Windows 10 installation trick for dual or multi boot scenarios. Turns out there are two different versions of setup.exe on a typical bootable USB flash drive (or other installation media). One resides at the root of the drive, the other in the \sources folder. Run the version at the root while Windows is running, and you’ll launch into a typical in-place upgrade repair install scenario. This is great for system repairs. Run the version in the \sources folder, and you can launch a separate install that targets some partition other than the current boot/system partition. And that, dear readers, is why I entitled this post two Win10 Setup.exes offer differing capabilities.
How Do Two Win10 Setup.exes Offer Differing Capabilities?
Upon closer examination, although both setup.exe files share the same name, they do differ. Here are the properties Details for each one, side-by-side:
\sources version on the left, UFD root version on the right. Notice the difference in file sizes (272 vs 78.8 KB).
[Click image for full-sized view.]
Just for grins, I ran the file comparison command (FC) and the old WinDiff utility against the two versions. Because they’re binary files (which I didn’t attempt to reverse compile) all I can see is that there are indeed lots of differences between the two files. Also, the \sources version has a lot of stuff in it that the root version does not. That’s what I’d expect, based on the difference in file sizes.
The key distinction comes from the uses to which these two different setup files may be put. The \sources version works to set up dual- or multi-boot at runtime inside Windows 10 itself. No need to boot to alternate media and run the installation outside your normal, comfortable runtime. The root version is for performing upgrade installs (or repairs) to the OS that’s currently running. Good to know!
[NOTE] Here’s a shoutout to TenForums.com fellow guru and regular NavyLCDR, who in turn credits rescue media maven Kyhi for this trick in thread#7 of a post entitled Boot 2 copies Win10 Pro in Separate Partitions. Thanks, guys!
How’s this for irony? Two days ago, I wrote a story for SearchEnterpriseDesktop explaining what to do if a mouse and/or keyboard go missing in Windows. Yesterday morning, when I sat down at my primary PC, my user interface was totally bollixed. Ultimately, I determined the cause was a failing wireless mouse. But there were a few wrong turns before that diagnosis became crystal clear. It definitely woke me up, but it also wasted most of my morning. If you’ll recall, HID stands for human interface device in Windows-speak. And that’s why I entitled this post HID woes cause overkill Win1o repair. If this story has a moral, it should be “swap the hardware first” whenever devices get weird.
This cheap and colorful little mouse ultimately rode to my rescue, but only after some spinning of the wheels.
How Did HID Woes Cause Overkill Win10 Repair?
My problem was that I jumped to a software diagnosis for what was a purely hardware problem. Had I followed my own advice from the preceding day’s story, my second step after restarting the PC (I did do that) should have been to “Try a substitute device.” Had I done that, the story would have come to an immediate, positive and workable solution. But no! Problem is I’ve been reading so much about driver issues for mice and keyboards on Windows Version 1803 (aka Spring Update) that I immediately assumed I’d been bitten by a driver problem. Wrong!
The nearest I can figure, what REALLY happened is that the RF transmitter in my Logitech M325 mouse started failing intermittently. It worked to some extent most of the time, but would cut out completely 3-4 times a minute. Unfortunately, this caused my keyboard to act weird as well. I think it was fighting for USB bus access with the failing mouse radio. They share the same USB 2.0 hub on my production PC, as fate would have it. So when the mouse starting picking up and dropping, and picking up and dropping, the keyboard also started having issues communicating with the PC. Ouch!
After completely removing and reinstalling only generic HID device drivers, my problem remained. And then, when that didn’t change after I performed an in-place upgrade repair install, I knew it HAD to be the hardware (nothing else was left). So I ran upstairs, borrowed my son’s high-end wired Razer gaming mouse, plugged it in, and Presto! my problems vanished. I ruefully remembered one more reason why intermittent failures are the hardest to find and fix. So my new M325 ($13 + tax at Fry’s) banished all remaining ills — for the time being, at least.
Last Friday, I observed in a post here that machine names appeared case sensitive in RDP. Indeed they are — kind of — and in other places, too. This includes the ancient and venerable PING command, a go-to utility to check connectivity between IP hosts. In trying to get all of my PCs to show up on the LAN, I turned to PING to see who was reporting in and who wasn’t. Along the way I observed some fascinating and surprising case sensitivity in PING itself. Here’s an illustrative screen capture from PowerShell:
An abridged version of PING attempts using the same base string, with differing upper- and lower-case chars.
Why I Insist That NetBIOS Names Get Weirder and Weirder
The following table sums up the results from the preceding sequence of PING attempts (plus another item I chose not to include). It basically shows that NetBIOS name resolution has its apparent quirks.
|Variations on a NetBIOS name: DellVP11|
|Name string||Ping result||Capitalization map|
|DellVp11||succeeds||ClllClnn (not shown)|
To me, there’s one captivating thing about the outputs. The only string that DOESN’T work is also the same string that PING uses itself — namely, DellVP11. That’s ClllCCnn, in the notation of the table. This denotes: initial cap, followed by three lower-case letters, two more cap letters, and two digits, in case you wondered.
A Surprising Finding for NetBIOS Names
It turns out there’s good reason for PING to use that specific NetBIOS name for the Venue Pro. The Microsoft Developer Network Documentation says this about NetBIOS names (emphasis mine):
Neither [RFC1001] nor [RFC1002] discusses whether names are case-sensitive. This document clarifies this ambiguity by specifying that because the name space is defined as sixteen 8-bit binary bytes, a comparison MUST be done for equality against the entire 16 bytes. As a result, NetBIOS names are inherently case-sensitive.
There’s only one way I can find to get the “real NetBIOS name” for a Windows 10 computer. It requires checking the Computer Name field in the Control Panel’s System element. On my Venue Pro, that field reads “DellVP11” (ClllCCnn). Go figure! It’s the only name that DOESN’T resolve in PING. This makes no sense to me whatsoever, but it’s indisputably true — on this particular PC at least.
On some of my other PCs, PING accepts all variants of the machine name. The case of individual letters doesn’t matter. On others, it does. As I’ve already reported for my T520 Lenovo laptop, “T520” doesn’t work but “t520” does– and the latter is the apparent actual NetBIOS name string. For my X220 Tablet, “X220T” doesn’t work, but all three other possible variants do (“x220T” “X220t” and “x220t”, of which “x220t” is the actual NetBIOS name string).
Again: weird! I sure hope MS comes up with some kind of fix for this. Because most IP utilities report the machine name in upper case only, seems like that should be the canonical form for such names. We’ll just have to wait and see how it all plays out…
The old putatively Chinese curse goes “May you live in interesting times.” And in that sense, interesting is the adjective I’d apply to networking in Window 10 Version 1803 of late. My previous blog post explained my difficulties in resolving a NetBIOS name, only to figure out that it was case-sensitive when it shouldn’t be. Today, I’m discovering that some upgraded systems lose their ability to respond to a PING from the LAN. This took some sleuthing, but I figured out how to bring back PING in Win10 1803.
How to Bring Back PING in Win10 1803
I can’t replicate this on all my upgraded machines. But I have observed that at least two PCs here on the Chez Tittel LAN have lost their ability to respond to PING requests in the wake of the 1803 upgrade. As it happens, PING relies on the ICMP Echo command to do its thing. And sure enough, in investigating the potential causes of a “missing PING response,” firewall settings head that list. On my two affected machines, both running Windows Defender and its firewall, the Inbound rules for File and Printer Sharing (Echo Request) for both ICMPv4-In and ICMPv6-In were not enabled for any profile: Local/Private (what I wanted), Public (left disabled) and Domain (also enabled). Here’s what the resulting set of rules looks like after the change:
I enabled Private and Domain for both IPv4 and IPv6, but left public turned off. A PING response on a Public network is an invitation to attack!
[Click item to see full-sized view.]
If you find yourself in the situation where you can see a local PC using arp or nbtstat, but it won’t respond to a PING, odds are excellent that this fix will help you, too. Keep this in mind as you upgrade to 1803 going forward. By the time your organization or company takes the plunge, it may be moot. But I still believe that forewarned is fore-armed!
More Win10 Network Follies A’Comin…
As I was digging into this issue, I discovered a couple of other interesting networking gotchas. I haven’t had time to tackle them yet, but will do so as soon as I can. Gotcha #1 is that on at least one of my PCs (one running the Insider Preview), IPv6 has gone missing. Gotcha #2 is that my T520 machine (the subject of my previous post) will now happily connect to or ping either “t520” or “T520.” But alas, my X220 Tablet works only as “x220t” not as any of the other possible permutations: “X220t”, “x220T,” or “X220T.” Weird!
I had the devil’s own time using the Remote Desktop Connection to get to one of my laptops this week. The machine name for that PC is T520 and it just wouldn’t “take” in the interface to the program (see screencap below). On a whim, I tried the string “t520” instead. And presto! I got a certificate warning page from RDP. That’s usual after each feature upgrade in Windows 10. It also led me to the explanation of why Windows machine names are case-sensitive in RDP. Let me explain…
I was stumped by RDP’s inability to see my T520 machine, until I tried the string “t520” instead. Who knew?
Why Windows Machine Names Are Case-Sensitive in RDP: It’s the Certificate!
The only thing I can figure is that the first time I connected to this machine, I used the lower-case version of the machine name instead of the upper-case version. Turns out that while machine names in Windows are completely case-insensitive, certficate names are case-sensitive. And because a certificate is used to negotiate the connection between the host and the client when using Remote Desktop, case matters. I’m just glad the T520 name only allows for two variations, or it might have taken me a while to figure out exactly what string I needed to use to get from Point A (my production desktop) to Point B (the T520 laptop).
Once I realized what was going on, I was able to find confirmation in a Microsoft TechNet blog post. It popped up when I searched on “RDP machine name case-sensitive.” It’s entitled Remote Desktop Connection (RDP) – Certificate Warnings and is very much worth a read-through for those who, like me, work with RDP a lot. The following comment is where I confirmed my observations, though:
Here’s confirmation for you. Further experimentation with other local machine names vs. certificate labels provided further proof.
[Click image for full-sized view.]
Of course, in my case I didn’t get a warning. The connection simply wouldn’t form. But that was enough information for me to figure things out quickly. I’m just glad I stumbled into a test case where only two variations were possible! Now that’s some “dumb luck!”
It’s now become apparent that Win10 1803 Bluetooth (BT) has undergone major upgrades and revisions. This comes thanks to some clever sleuthing work from the folks at MSPowerUser.com. I’d pretty much figured out that something must be up, because of rampant squawking about BT in 1803 at TenForums, answers.microsoft.com, social.microsoft.com, superuser.com and elsewhere. But the MSPowerUser story nicely depicts the differences between 1709 and 1803. It also shows that when Win10 1803 gets new Bluetooth version, mischief and mayhem may follow!
Items in bold represent new or updated items in the 1803 BT stack.
[Click item for full-sized view. Source: MSPowerUser.com.]
When Win10 1803 Gets New Bluetooth Version, Trouble Follows
In the afore-mentioned Windows forums, there’s been plenty of BT-related traffic in the wake of the 1803 release. Most of it recounts lost, missing or non-functional BT devices. This seems to afflict mostly USB-attached BT devices. But it apparently applies to plenty of built-ins as well (most of which use USB under the hood anyway). To some extent, users have been able to solve a subset of problems. By replacing new Microsoft generic drivers (new stack, new drivers) with older drivers from the device manufacturers, they’ve returned to work. Of course, this says sayonara to new features and functions. But most users appear convinced that a working and less capable BT device is better than a more capable but non-functional one. Go figure!
For more information on what’s up, you can check out this Bluetooth declaration at the Bluetooth Launch Studio. It shows that on April 10, 2018, MS got no less than 11 different Windows 10 products certified for BT. You might also find this MS list of Supported Bluetooth profiles interesting as well. My special thanks to MSPowerUser Surur, who did all the hard work of comparing the 1709 and 1803 versions of this list and who put together the table included in this blog post, too. It also shows that when Win10 1803 gets new Bluetooth version, results do not necessarily benefit all users.