We’ve been making some PC changes around the house lately. This weekend, I moved my former test desktop upstairs to my son’s bedroom, having swapped it for an increasingly unreliable Dell XPS 2720 All-in-One. While the Dell had a built-in WiFi adapter, I had to switch the test machine over from its built-in Killer E2200 GbE wired interface to an Asus USB 3.0 AC56 802.11ac WiFi adapter instead. As soon as I installed this device and turned the PC over to its proud new user for homework, it started failing repeatedly. Sigh. Time to start troubleshooting … which ultimately led me to failing WiFi gets driver fix.
When Failing WiFi Gets Driver Fix, Why Does This Fix Work?
At first, I was able to restore WiFi to operational status by unplugging the device, then plugging it back in. But it would run for about two minutes, then fail again. When I looked at my driver options in Device Manager for this device, I immediately noticed two things:
- There were two drivers available for the device, one labeled Microsoft, the other RealTek.
- The Microsoft driver was currently selected and running … sort of.
Then I remembered that we’d just updated this machine to the Fall Creators Update (Version 1709) a few weeks earlier. And though I’d run and used the Asus adapter prior to the upgrade with no problems, the same was no longer true now. Because the Windows Installer uses its own judgment to select and run device drivers when a major upgrade occurs, I immediately surmised that the Microsoft entry had been supplied by MS when I plugged the device in for the first time after the upgrade. I was convinced that the other driver, however, was the one I really wanted to use instead.
When one driver comes from MS and the other from the WiFi chip’s maker, common sense dictates that trying the chipmaker’s version might be a good idea.
The Fix Is In … and It Works!
And indeed my guess turned out to be correct. No sooner did I switch to the other driver than the problems abated completely. Just for grins, I visited the Support page for this device, selected Windows 10 64-bit as my OS, and downloaded the driver and utility file. Guess what? The driver file sizes in that ZIP archive matched the installed file sizes (.cat and .inf) exactly, while the MS versions did not.
Apparently, I’d already installed the right drivers once before and had things working properly. But because I’d upgraded Win10 and the installer had chosen a different driver instead, I ran into the “dropped wifi connection” problem I’ve read about from others who’ve experienced similar travails. At least the fix was easy to figure out, and easy to apply. And so it goes, here in Windows-world!
In the wake of Windows 10 Fall Creators Update (Version 1709), lots of interesting wrinkles are emerging. A raft of Hyper-V changes in this release are spelled out in a new Virtualization Blog post from Microsoft. Dated 11/13/17, it’s entitled “What’s new in Hyper-V for Windows 10 Fall Creators Update?” Among the various new items it spells out, there’s an item that reads “Hyper-V has a Default Switch for easy networking.” Having just tried it out myself, I can affirm that this Default Switch makes Hyper-V networking dead simple.
When picking a virtual NIC in Hyper-V, Default Switch is your new go-to option.
How Is It That Default Switch Makes Hyper-V Networking Dead Simple?
As the foregoing screenshot shows, an option named “Default Switch” now shows up whenever you’re asked to select a network interface or to identify network-based resources. It comes as part of the runtime environment, by default as it were. Having struggled to identify the right NIC on a Hyper-V host with two GbE interfaces (where only one was connected), I’ve had bonehead problems with Hyper-V networking on earlier versions of the software. But with this new default option, you can pick simple, basic networking as a menu item as soon as you turn Hyper-V on. It doesn’t get a whole lot simpler than this, nor easier to use. Highly recommended!
What Else Is New in Version 1709 Hyper-V?
According to the “What’s new” blog post , these other new features for Hyper-V are present in Version 1709:
- Quick Create Gallery: a quick create button in Hyper-V Manager can reference a gallery of pre-defined OS images, to which you can add your own items. This capability is still under construction, though, as the following 11/8 post to the same blog explains “Create your custom Quick Create VM gallery.” I’m waiting for the promised documentation to show up to avoid hand-crafting the necessary JSON documents.
- Easy to revert VMs to their start state: Hyper-V now creates a checkpoint each time you start a VM. That means you will always have a reasonably current checkpoint to which you can revert for all your VMs.
- Host battery state visible in VMs: means that you can tell how much battery life is left from inside a VM running on a battery-powered PC.
- Virtual machines are easier to share: A new “Share” button packages and compresses VMs to make them easier to move to another Hyper-V host using the Virtual Machine Connection facility.
[Note added 12/7/17: Based on a member’s report of issues in getting default switch working on an existing/prior installation of Hyper-V in the Fall Creators Update/Version 1709, it looks like if you encounter problems trying to get it to work, one quick and easy fix is to do the following:
1. Disable Hyper-V
2. Restart PC
3. Re-enable Hyper-V
This sequence is reported as working for at least two people: my colleague and occasional co-author Kari Finn, and the original poster who reported the problem at TenForums.com.]
Yesterday, ZDNet reported another security hole in the Intel Management Engine (ME). It also affects Intel’s Trusted Execution Engine (TXE) and Server Platform Services (SPS). ZDnet writer Liam Tung’s story is entitled “Intel: We’ve found severe bugs in secretive Management Engine, affecting millions.” It links to a note describing a detection tool for Windows and Linux systems. Alas, as another Intel ME security flaw discovered unfolds, several of my systems are affected. Helpfully, this screen shot from the tool’s GUI version spells things out:
All of my newer PCs are subject to this vulnerability. Sigh.
Another Intel ME Security Flaw Discovered: What to Do?
In fact, this particular flaw affects systems using Intel ME firmware versions 11.0.0 through 11.7.0, SPS firmware version 4.0, and TXE version 3.0. The processors that fall under this fairly broad umbrella include:
- 6th, 7th, and 8th generation Intel Core Processor Family:
- Intel Xeon Processor E3-1200 v5 and v6 Product Family
- Intel Xeon Processor Scalable Family
- Xeon Processor W Family
- Intel Atom® C3000 Processor Family
- Apollo Lake Intel Atom® Processor E3900 series
- Apollo Lake Intel® Pentium® Processors
- Intel® Celeron® N and J series Processors
Source: Intel’s Support Note SA-00086 (preceded item list quoted mostly verbatim)
If you like, you can download a detection tool from Intel to check your systems. Simply navigate into the DiscoveryTool.GUI folder. There, run the executable named Intel-SA-00064-GUI.exe. When run, the tool produces output like that shown in the preceding screen capture.
If you’re affected, you’ll need a BIOS fix from your system or motherboard maker to plug the security hole. According to posts on TenForums.com (where this vulnerability came to my attention), some motherboard vendors have already posted patched BIOSes. Alas, neither of my newish Asrock-based motherboards has a fix available yet. Hopefully, that will be addressed sooner, not later or never… In the meantime, grab and run this tool for yourself to see if you should be on the lookout for patches, too.
In the wake of last month’s Fall Creators Upgrade, aka Windows 10 Version 1709, some glitches have popped up. Today’s reported item is minor and easy to fix, but could be vexing nontheless. That’s why I hope my readers can benefit from what I recently re-learned. That is, a Windows 10 upgrade will occasionally reset one’s network status from Private to Public. This locks down access and sharing, and basically turns Remote Access off. That’s why some readers may find they want to restore Win10 Private Network status after performing the upgrade. RDP is handy stuff, especially when it comes to having your fingers and the network do the walking, rather than having to sit down in front of some specific PC.
How-to: Restore Win10 Private Network Status
You can check, and if necessary, restore Win10 Private network status in Settings. The click sequence runs like this:
Network & Internet (Click “Change connection properties) →
Network profile (Check the Public/Private radio buttons; if Public is selected, click Private intead).
If Public is selected, Win10 amps up network security, which basically disables RDP and remote access/asssistance.
Another trick that works is to fire up the homegroup utility (but that’s irrelevant in most workplaces because they use domain-based security anyway). As its first step it automatically changes the network profile from public to private, if it finds public enabled.
Why Did This Unwanted Behavior Resurrect?
I saw this network status change issue pop up quite a bit in Windows Insider releases while transitioning from Version 1607 to version 1703, and intermittently in even earlier phases of that beta test program. What I don’t understand is why this behavior popped back up for a product release to 1709. MS had this one fixed for at least 4 or 5 months before this Fall Creators Update appeared. Why then, did it show up in the production release of the selfsame OS? Another Windows administrivia question for the ages, I guess!
I have to laugh at myself. I just troubleshot an issue with the latest version of the Realtek HD Audio drivers to learn I’d shot myself in the foot. Let me explain, and provide some Realtek HD Audio Driver tips along the way. I visit the Drivers and Hardware forum at TenForums regularly, as a source for posts to this blog. Today, I saw that its Realtek sticky thread points to a newer driver version than I currently had installed. But in using the Microsoft Update Catalog link, I inadvertently downloaded the wrong file. Here’s what I saw on offer online:
Three different sets of versions of the files appear. The version I should’ve grabbed is in yellow.
[Click image to see full-sized view, please.]
Simply put, I grabbed the wrong version of the driver files. I needed the 64bit version (the biggest file: 131.0 MB for Fall Creators Update). I grabbed the 80.8 MB version and didn’t realize it. Finally, I grasped that the error message I got when trying to force install the 32-bit driver told me I was in the wrong, albeit unknowingly. It wasn’t a complete waste of time, though. That’s because working through the process refreshed my memory about a number of useful tips and tricks for dealing with drivers. Because these tips apply reasonably well to any drivers you might fetch from the Microsoft Update Catalog, I recite them here.
A Select List of Realtek HD Audio Driver Tips
 The Latest Realtek High Definition Audio Codecs sticky thread at TenForums remains your best source for these drivers.
 TenForums has a peachy tutorial named “How to Install a CAB File in Windows 10.” If you don’t already know this, it guides you through the process.
 If you’re tempted to force-install a Windows Driver in Device Manager/Update Drivers, pause to investigate before forcing anything. I was clued in that something was wrong for several reasons. First, the browse function came back and said I had the latest and bestest driver already installed. Second, the force function warned me that the driver I pointed at was incompatible with my hardware. That’s Microsoft’s way of telling you trouble may follow soon.
 I realized my error when I went back to look at the CAB file I’d downloaded. It was less than 100 MB in size, when I knew I wanted the biggest one for my 64bit setup. Note to Microsoft: why not label downloads explicitly as 32- or 64-bit?
 Remember you can use Driver Store Explorer (aka RAPR.exe) to check the true name of the .inf file you want to replace when updating. It told me I had the right driver file in the 32-bit directory. I correctly concluded something fishy because Device Manager didn’t like it. That’s how I figured out that the HDXRT4.INF file wasn’t the version of that file that I needed.
Problem Recognized Means Problem Solved
Sure enough, as soon as I removed the original download and replaced it with the correct version, Device Manager was able to find and install the proper driver, no forcing needed. That reminds me, and should remind you, that when the square peg won’t slide into the round hole, the proper response is to stop and think rather than to reach for a bigger hammer. Please keep that in your list of Realtek HD Audio Driver Tips, and general driver update knowledge, somewhere near the top! ‘Nuff said.
Since Version 1607, Windows Server has included support for an image format named FFU. Short for Full Flash Update, this format lays down a runtime image on a physical drive. FFU support comes to Windows 10 as of Version 1709. It can create runnable Windows and recovery images, and a complete system partition scheme in one go. Designed for speed (it proves itself fast in practice) and supports larger files than Windows Image format (aka WIM). This is fully documented at Microsoft’s Hardware Dev Center where two articles specifically target FFU. The first is Windows Full Flash Update (FFU) images, the second WIM vs. VHD vs. FFU: comparing image file formats. Win10 Full Flash Update offers some nice advantages, which I will recite shortly.
Digging into Win10 Full Flash Update
A quick visit to the second cited article above reveals FFU’s key characteristics. It is the fastest tool for capturing and deploying Windows on the factory floor (it’s aimed at OEMs). It is sector-based and uses the highly compact Xpress-Huffman compression algorithm. FFU captures a complete set of drive information including partition data. When FFUtool is used to apply an image, it starts by cleaning the entire drive. When deploying from a source image, the target drive must be the same size as the original (source) drive, or larger. DISM works with FFU images, so they may be mounted for manipulation, then modified, then dismounted to deploy updates and changes. FFU also includes a catalog and hash table to validate signatures upfront before flashing gets underway. A hash table is generated during the capture process, then validated when the image gets applied (neither WIM nor VHD support this added reliability check).
You can use FFU with Windows 10 right now through the Deployment Image Servicing and Management (DISM) command-line utility. Recent ad-hoc tests using DISM and WIM versus DISM and FFU shows off FFU’s speed advantage. On a pair of test technician machines, the speed difference was better than 50% for each one when comparing the time it takes to apply a WIM image as compared to its FFU counterpart (same OS, same modifications, same everything). FFU is good stuff, and worth getting to know for those in the image deployment game.
See the FFU image format article at the MS Hardware Dev Center for depictions of FFU V1 and V2 disk layout schemes. The second version supports multiple data stores so it can accommodate multiple, unrelated images in a single file.
Here’s a potential gotcha I’ve seen popping up with some frequency online lately. When Microsoft releases a new Windows version, a new version of Media Creation Tool come out, too. Alas, the MCT is always named MediaCreationTool.exe. That filename can’t tell what version of Windows 10 MCT supports unless you do some poking around. But whatever MCT version you’ve got, it will always and only download the Windows version to which it’s tied. In the simplest terms, an old MCT grabs an old version of Windows. That’s not always what you want, so it’s smart to check the MCT version before you use it to download and install Win10.
If New Win10 Means New MCT, How to Tell What You’ve Got
There at least two ways to tell which version of the MCT you’ve got. The quick, dirty and less reliable way is to open File Explorer and look at the file date. If it’s older than the current version of Windows 10 (or the version you want), don’t use it. Jump to the Download Windows 10 page, where you’ll click the “Download tool now” button to grab the latest and greatest MCT instead.
A more reliable way to check the Windows version tied to an MCT file is by examining the Details pane in its file Properties window. Here’s a look at two versions of this file from my Downloads directory to illustrate:
Spring Creators Update (1703/15063) left, Fall Creators Update (1709/16299) right.
Of course, identifying what’s what requires having a clue about Windows version and build numbers. You can get those basics from Microsoft’s Windows 10 release info page. In fact, that page tells us what we need to know about the two foregoing MCT versions shown. The current version of Windows 10 is 1709 and is build 16299; the previous version is 1703 and is build 15063. That’s how we know the MCT on the right is the most current version and the one to its left its predecessor. And of course, the file dates tell the same story, too.
Using MCT for Older Win10 Versions … NOT!
The safest way to use MCT for the current version is to visit the Win10 download page. There, grab a fresh copy just before you use it. For older Win10 versions, you’re better off finding an ISO file of the right vintage and building your own installable media. If you must, you could root around in your file system or backups to find a corresponding MCT. Frankly, I think that’s more trouble than it’s worth…
Here’s a nifty new feature for the latest version of Windows 10. The Fall Creators Update, aka Version 1709, now includes a “Where’s my pen?” entry in Settings → Update & Security → Find my device. If you turn this feature on, Windows will use Bluetooth to position your pen on Bing Maps and show you where it last reported in. Hopefully, this will help you run the device down. Ironically, I used my own pen to click the various interface settings to set this up! Even so, the Fall Creators Update finds Surface Pen feature is truly nice-to-have.
Now that my Surface Pro 3 is upgraded, it too can find my pen.
Exactly How Fall Creators Update Finds Surface Pen
The secret to making this work is to toggle the Find my device setting (which is set to ON by default). This provides an option labeled “Save my device’s location periodically” which should also be turned on. Then, you can use it to record your pen’s location via Bluetooth from time to time (because Windows 10 does not natively support GPS). Once this is working, you need only click the link at bottom that says “Go here to track it. ” Presto! Bing maps pops up with your pen’s most recent location highlighted.
Surprise! My pen is at home, where my Surface Pro lives, too.
This is a handy feature, and will probably help the absent-minded. Such folks, including me, are quite likely to need an answer to the question “Where’s my pen?” at least occasionally.
[Note: here’s a shout-out to Mauro Huculak at Windows Central, whose 11/7/17 article “How to find your Surface Pen in the Windows 10 Fall Creators Update” brought this new feature to my attention. Thanks!]
Every now and then, I like to take a look at Windows 10’s so-called “Desktop Marketshare.” This means turning to a variety of sites that track such things. My go-to sites are NetMarketShare, Analytics.usa.gov, and Statcounter. In checking out Win10 desktop marketshare Nov17, I noticed some potent differences across these sources. Let’s look at some numbers, OK?
What’s Up with Win10 Desktop Marketshare Nov17?
Yesterday, November 6, I visited all three of those sites. There, I checked numbers for Windows 10, especially as compared to Windows 7. Here’s what I found, in brief tabular form:
|Comparing Win10 Marketshare, Nov17|
|Site||Windows 7||Windows 10|
I’ve heard plenty of folks call the Netmarketshare numbers into question. I read that they report only on sites that use their visit counting tools or belong to their site network. But I also notice that the numbers for Windows 7 are clustered much closer together (maximum difference 5.36%). By stark contrast, the Windows 10 numbers are more scattered (maximum difference 16.97%). Thus, I can’t help but take issue with Netmarketshare’s Windows 10 share estimate, for being too low with respect to the other two reporting sites.
I am indeed inclined to believe that around 4 of every 10 Windows desktops that access the Internet run Windows 10. This applies especially in the USA, as evidenced by the .gov site. (It’s most likely to attract its visits from within the USA.) But I’m curious to understand other components of the difference. Looks like Netmarketshare sees a lot more XP, Windows 8 and Windows 8.1 that the other two sites do. And for sure, plenty of die-hards do still run older Windows versions.
But, FWIW, I’ll put my credence into Statcounter and Analytics.usa.gov. Over the past couple of years their reporting has tracked my own personal observations more closely than NetMarketShare has. And what I see coming is visualized best at Statcounter, where the upward curve for Windows 10 and the downward curve for Windows 7 look likely to intersect very soon. If not this month (Nov17) then next month for sure (Dec17). Stay tuned!
If you’re running the latest Win10 version (Fall Creators Update Version 1709) and automate Update retrieval, you may be offered bogus printer drivers. Tools like the Microsoft Deployment Toolkit, aka MDT, or even the Windows Update MiniTool, aka WUMT, show Windows 10 images needing print drivers. At the same time, plain-vanilla Windows Update shows no such lack. That makes me label these items as bogus Win10 printer update alerts.
What Do Bogus Win10 Printer Update Alerts Look Like?
The following screen shot from WUMT appeared on one of my test machines this morning. I also observed those drivers failed to install. This TenForums thread applies: “Can’t get rid of Printer-6/21/2006 12:00:00 AM 10.0.15063.0 update.” That’s where I learned that what WUMT showed me also shows up in MDT for others. I expect that means it’ll show up in System Center Configuration Manager, the Windows ADK, SmartDeploy, ENGL Imaging Toolkit, and so forth. It seems to apply only to packages with automated Windows Update checks.
Closer investigation reveals the Print to PDF driver first, aand the XPS print driver second.
As it happens, neither of those print drivers is essential to proper print output anyway. The first one comes into play for the “Print to PDF option” in Office components and other applications. The second driver is an extension of the GDI-based Version 3 printer driver. It goes back to the pre-Vista Windows era (and is seldom used today). Thus, you can cheerfully ignore these offerings in most situations.
That’s why I elected to hide both drivers inside the WUMT interface. Because the program was happy to do just that, I won’t be bothered with this particular driver offer again. YMMV, depending on which deployment tool you’re using for Windows 10. According to one poster to the afore-cited TenForums thread, enabling continuation on error for updates in MDT allows deployment to proceed. It slows things down a bit, though, so consider yourself warned.