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.
For some so-far undetermined reason, I’ll occasionally log into Windows 10 and find myself staring at a black desktop. Because I shoot LOTS of screen captures for articles, books, and whatnot, I usually set my background to all white. So when my background goes dark, I need a quick fix to turn the lights back on, so to speak. It turns out that fixing black Win10 desktop is pretty easy, if you use the Personalization tool. Simply right-click any unoccupied area of the desktop and you get a pop-up men that includes Personalize amidst its entries.
The option of interest shows up at the bottom of the menu.
How-to: Fixing Black Win10 Desktop
Once you click the Personalize entry on that menu, you’ll find yourself in Settings –> Personalization. Normally, when my desktop goes black, that means that Background remains set to Solid Color with a checkmark on the black box.
Getting back to white requires clicking Custom color, then moving the slider all the way to the right to turn black into white. That’s all there is to it for me. This is a big improvement over earlier Win10 versions (and Windows 8) which didn’t offer white as a custom color option. I actually had to capture a white field in a graphics editor, then save it as a file I could designate as my background. This is much easier and faster, too. Should you ever find yourself in this boat, now you know how to fix black Win10 desktop, too!
On October 23, just over a week ago I wrote that my 1709 upgrades to Windows 10 had gone mostly trouble-free. Alas, I was gilding the lily where one of my 1703 upgrades was concerned. At the time I wrote the post, the machine was in its final reboot phase just before handing off control to the new OS. That phase took about a week to complete successfully, as it turns out, and involved considerable research and what-if repair attempts to resolve. Everything I tried failed, until I discovered the cause almost by accident. As it turns out, bad RAM nixes 1709 upgrade completion. It also throws different errors on multiple failures, which makes diagnosis difficult.
When Bad RAM Nixes 1709 Upgrade, Then What?
On Monday, 10/30, I ran the hardware diagnostics from Lenovo Companion on the problem laptop. A Lenovo X220 Tablet, it has been (mostly) a rock-solid, trouble-free machine. The “Quick Random Pattern Test” for memory failed on that PC as soon as the test started. Reasoning that one of the SO-DIMMs might have failed, I popped the first one that came to hand (a Patriot 8 GB PC3-12800 module) and tried again. As luck would have it, the memory test went on to complete successfully using the sole remaining 8 GB module.
Alas, this is not what I saw from Lenovo Companion until after removing the failed/failing RAM module. I got the red X of failure instead.
Guessing that memory problems during the install could have caused my strange symptoms, I ran the Windows 10 Update Assistant one more time. And indeed, this time the OS installed successfully. My best guess is that the Windows Installer only attempted to access memory addresses above the 8192 GB high watermark for the first SO-DIMM during the final phase of installation. And it was only when the system tried to use the second SO-DIMM that things got wonky. Now that I’ve removed the apparently failing module, all is working properly on that PC. I’ve ordered a replacement from Newegg ($62.99 + $0.99 shipping) and will return to 16 GB operation as soon as it shows up at my front door. Case closed!