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.
Last week, I posted a blog here entitled “MS Publishes Big Free Command Line Reference.” It explores a revision to Microsoft’s recently revised and re-released command line info ws-commands.pdf. It’s 948 pages long, and documents 270-plus Windows commands. Over the past four days, I’ve conducted an experiment with each of those commands, to make some Windows Command Line Reference observations. In particular, I’ve tried to oberve the following:
- Commands that work on Windows 10 in both PowerShell and cmd.exe
- Strings that don’t work in PowerShell, but do work in cmd.exe
- Commands that don’t work in Windows 10 at all
- Strings with PowerShell aliases
Making Windows Command Line Reference Observations
Along the way, I also learned something interesting and useful: one can launch the command prompt from inside PowerShell. Simply type cmd or cmd.exe and you’ve got a command line session running inside PowerShell. You can tell by the prompts what’s what, as I show here:
If the prompt starts with PS, it’s PowerShell; if it starts with C:\ (or %SystemDrive%, to be more precise) it’s the command prompt.
[Click image for full-sized view.]
Here’s what I ran (and recorded) for all of the commands in the Command Line Reference:
1. Ran Get-Alias in PowerShell to see if the command had a PowerShell alias. (I counted only 17 unique aliases from the 270-plus commands, over a total of 22 commands. 5 of that total — like cd and chdir — mean the same thing in cmd.exe, and thus also ditto for PowerShell.)
2. Ran the command in PowerShell to see if it worked. (92 commands did not work out of 273, approximately one-third of all commands. Of those 92, 36 aim at Windows Server not Windows client OSes. 15 of the commands are deprecated, of which 13 don’t work on Windows 10 at all.)
3. If it didn’t work in PowerShell, I checked to see if it worked in the command prompt. (12 of those 92 commands worked in the command prompt even though they didn’t work in PowerShell. Some of these are batch file controls such as the shift command.)
All in all, it was a fascinating exercise that showed the majority of commands work with equal facility in PowerShell and the command prompt. For me the biggest benefit was learning that the command prompt inside PowerShell is never more than four keystrokes away (c-m-d-Enter). Just remember to type exit to shell back out into PowerShell when you’re done with cmd.exe!
Next week, I plan to post the complete table of results with additional analysis and lots of links to make things easy to find therein over at Win10.Guru. When I do, I’ll update this post with a link to that article.
I’m active at TenForums.com. I spend at least 90 minutes a day there, reading user posts and responding when I can. There’s a class of errors that show up in the Windows Event Viewer for all Windows 10 machines. The event source is “Microsoft-Windows-DistributedCOM” aka DCOM, and the event ID is 10016. Some borderline OCD Windows users obsess about the presence of any and all errors in the Event Viewer, and attack these DCOM errors with a vengeance. There are various fixes possible that involve hacking the registry or using the Component Services admin tool. These either grant users the missing permissions that provoke the errors, or turn DCOM error logging off completely. But now we know that Win10 DCOM 10016 errors are mostly benign. This revelation comes thanks to f14tomcat, who turned up a Microsoft Support note that explains things nicely.
Header of the support note that confirms these errors occur by deliberate design and may be safely ignored.
[Click on image for full-sized view.]
How Do We Know That Win10 DCOM 10016 Errors Are Mostly Benign?
It’s all laid out in the Microsoft Support note “DCOM event ID 10016 is logged in Windows.” These errors are explained there as follows (verbatim quote):
These 10016 events are recorded when Microsoft components tries to access DCOM components without the required permissions. In this case, this is expected and by design.
A coding pattern has been implemented where the code first tries to access the DCOM components with one set of parameters. If the first attempt is unsuccessful, it tries again with another set of parameters. The reason why it does not skip the first attempt is because there are scenarios where it can succeed. In those scenarios, that is preferable.
Furthermore, the same note asserts that “These events can be safely ignored because they do not adversely affect functionality and are by design.” I’d long suspected this was the case myself. Why? Because even after making the various possible repairs, it never made any difference in system stability or behavior. Also, the errors blithely returned with each feature upgrade. That told me that MS didn’t think they mattered. And now, of course, this is explicitly confirmed in the afore-linked Support note.
You wouldn’t believe how often this comes up at TenForums and elswhere. A quick search there shows 174 hits on “Error 10016.” I’ve sent an email to the main forum moderator asking for a pinned post on this topic. I’ve even volunteered to write it up, to let everybody know what’s up. Yes, it’s an error. But it occurs by design on ALL Win10 systems, and can be ignored. End of story, so fuggedaboutit!
OK, then. With the release of Windows 10 Version 1803 (April Update) HomeGroup is gone, gone, gone. I’m not sorry to see HomeGroups disappear, because it was an enormous pain to kill off an old HomeGroup to create a new one. But I didn’t realize it had been supporting some networking capability on my LAN. With HomeGroup’s demise, all my local PCs disappeared from the Network pane in File Explorer. And that’s why I had to figure out how to bring back basic Win10 1803 networking. As it turns out, it’s not at all difficult. But it does require two steps to get there. At least, that’s how it worked on my LAN anyway. Note: if you never used HomeGroups, none of these contortions should be needed.
Two Steps to Bring Back Basic Win10 1803 Networking
Step 1: Make sure Network Discovery is turned on
HomeGroup doesn’t need network discovery to find other nodes on a LAN. One of its few pluses was that it used the IPv6 Neighbor Discovery protocol to figure out who (or what) is “out there” on a local network. But with HomeGroup now MIA, Windows networking works best if Network Discovery is turned back on. Open the Network and Sharing Center, click “Change advanced sharing settings,” and be sure the radio button for “Turn on network discovery” is selected under the Private network heading (you can, and probably should, leave it in the “off” position for Guest or Public networks, though).
With no HomeGroup, you need Network Discovery turned on for private/local networks to make computers visible in File Explorer (and elsewhere).
[Click image for full-sized view.] I turn off file and printer sharing because all my printers are networked.
Step 2: Turn on Function Discovery Services
The two Windows services that support Network Discovery are Function Discovery Provider Host and Function Discovery Resource Publication. By default in Version 1803, they’re set to Manual startup. That needs to be changed to “Automatic (Delayed Start)” for things to work properly in File Explorer (and elsewhere in Windows 10). Otherwise, you won’t see local computers on the network under the Network heading there.
Click Properties for each of the two Function Discovery services, then change its startup type as shown.
[Click image for full-sized view.
What’s in a Network Map?
I like to see the computers on my LAN in File Explorer. This also lets me navigate into them, and access the files to which my account gives me access. If you follow the two simple steps I’ve outlined here and use a Workgroup (not Domain) based Windows 10 network, you should be able to see (and do) likewise. Enjoy!
[Note: thanks to the various posters at TenForums who put me on the trail of this solution, especially those who posted to the “1803 disable finding computers by name?” thread. Their suggestions led me to observe that switching the Function Discovery services to Automatic or Automatic – (Delayed Start) was essential to regaining the appearance of local PCs under the Network display/map in File Explorer.]
Last Friday, my partner in crime at Win10.Guru, Kari Finn, sent me a link to a very interesting document. It comes from the Microsoft Download Center and shows up with very little descriptive information or fanfare. It’s a 948-page PDF file that includes comprehensive and current coverage for ALL commands from the Windows command line. Most of these items work in both PowerShell and in the old cmd.exe “Command Prompt” window. I don’t know why, but it wasn’t until I saw Martin Brinkmann’s ghacks.net article this morning, that the value of this not-so-little item struck me. It’s also what led to the headline for this blog post — namely “MS publishes big free command line reference.”
There’s not enough information to really clue readers into what’s inside this document. It covers hundreds of common commands of interest to admins and power users.
[Click image for full-size-view. Command Line Reference download link.]
Why MS Publishes Big Free Command Line Reference Is a Big Deal
A few simple observations will explain the preceding assertion.
1. The document is 948 pages long, 4.6+ MB in size, and covers commands relevant to Windows 8.1 and 10, and Server versions 2008 through 2016 (including R2s ).
2. Though MS describes the document as a “complete listing of Windows commands” I must quibble. It doesn’t include bootrec or dism. But those are .exe files, so I understand why Microsoft might not include them in a command reference.
3. I count 273 individual commands documented in the PDF file, where at least another 100 sub-commands have subsidiary entries.
4. If you follow any of the linked references in the PDF, it takes you to the Windows Commands online reference. For those who want to access current info online, this link is also handy.
Great stuff, though, all the way around! Grab a copy of the PDF, and add the online reference to your bookmarks or favorites today.
Last Monday, April 30, MS unleashed Version 1803, aka the “April Update,” to the general public. Though many folks believed it would only trickle out via the Media Creation Tool, it appeared through Windows Update, the Windows 10 Update Assistant, and MCT that same day. Since then, lots of people have been installing, analyzing and digesting the new release. Indeed, it does come with a few gotchas — see Martin Brinkmann’s excellent ghacks story “All the issues of Windows 10 version 1803 you may run into” for the most complete rundown I know of. But not too many of them are serious, nor potential showstoppers. One item could be pretty major, though. As Brinkmann reports from his own personal experience, 1803 may drop Spectre Patches on some PCs — Ouch!
If 1803 May Drop Spectre Patches on Some PCs, Does That Affect You?
Turns out that only those systems that got their Spectre v2 protection courtesy of Microsoft security updates can be affected. Here at my house, almost all the PCs got firmware updates from their system or motherboard makers (Lenovo, Dell, and Asrock, as that turned out). Thus, none of those machines upgraded to 1803 lost their Spectre/Meltdown protection as a result. Other makes and models may be affected, though, if Mr. Brinkman’s experience is any indication.
How can you tell if you’ve been bitten? It’s easy. Simply run Steve Gibson’s excellent InSpectre utility on your PCs. If you see something like this you’re OK:
If you see something like this instead, you’re not:
The only system here that’s affected is one for which a vendor patch was never provided: my wife’s Jetway-based mini-ITX system. Be sure to check yours after you make the upgrade, to see if you need additional mitigation or remediation.
Is Their an 1803 Spectre Patch in the Offing?
I’d have to give this a very high likelihood of showing up soon. By the time many of the IT pros who decide to try out 1803 for possible future deployment fire up this latest OS version this issue may be moot. But it’s easy to check, so be sure to grab a copy of InSpectre (it’s free) to make sure your PCs are covered.