With the upcoming release of Windows 10 this fall, Version 1809, the Snipping Tool may be no more. Those who run the Skip Ahead version of the Insider Preview can see a warning to that effect. In essence, this says “NoMo Snipping Tool Try Screen Sketch instead.” Here’s how this looks in the Snipping Tool screenshot from Skip Ahead Build 18204.
I was amazed to learn that the old familiar Snipping Tool actually dates back to Windows XP Tablet PC Edition from 2005. I didn’t get to know it until Vista came along in November 2006 myself.
OK Then: NoMo Snipping Tool Try Screen Sketch Instead
In the Skip Ahead preview, you can click the button shown labeled “Try Screen Sketch.” This launches the eponymous application. If you click its “New” button, you make a rectangular screen snip by default. This works much like the old Snipping Tool. Screen Sketch also offers options to crop, annotate or highlight screencaps. Personally, I’ve used tools such as Corel Draw, IrfanView, Greenshot, and SnagIt Editor to work on screen stuff captured using Snipping Tool.
Screen Sketch offers basic capabilities, but its controls aren’t as fine-grained or as comprehensive as those other tools. Thus, I probably won’t use it for image annotation or manipulation myself. For basic capture and annotation it works — as long as you don’t mind “touch writing.” Can’t stand it myself. As a writer, I’m a keyboard guy through and through.
But if you use Snipping Tool now, you’ve been warned. It’s likely to disappear in Windows 10. If not in Version 1809, then in Version 19H1. (That is, I believe, the new version nomenclature that could appear for the first Feature Upgrade of 2019). One version or the next, sometime soon, Screen Sketch will take Snipping Tool’s place. If you’re like me, and make frequent screen grabs, you’ll pin it to the Task bar right away. If you want to get an early start with the tool, you can already download Screen Sketch from the Microsoft Store.
I follow the news at TenForums.com. Among other things, it keeps me up with new Insider Preview releases. It also cover updates and changes in Windows-World. This morning I saw a interesting headline in its News Forum. It reads New Firmware Update for Surface Pro 3 – August 7, 2018. Take a look, and you’ll see it links to an MS Support Note. Check that note, and it says “Run WU and you’ll get the update.” So that’s what I did. But WU found zero, zip, nada. Knowing that there’s always another way to grab MS updates I recalled the Download drivers and firmware for Surface page. Sure enough there’s a link for Surface Pro 3 stuff there. It includes two entries of interest — namely a TPM update tool and a Surface Firmware Tool. And that, dear readers, is how I found that manual download works when WU finds nothing.
Items tend to enter this list at the top, so I was pretty sure these two items were what I needed. So I downloaded and installed them.
Proving That Manual Download Works When WU Finds Nothing
Based on the information in the download description, I knew that the BIOS version was 3.11.2450. Using PowerShell and the Get-WMIObject Win32_BIOS command, I was able to confirm that, after applying the update, that’s what version of the UEFI was running.
A quick jaunt into PowerShell confirms that the most current version of the UEFI firmware is indeed running. Success!
So remember: if the news says an update is available, but WU fails to send it your way, there’s almost always some way to grab it in file form and install it manually. That’s what I did here. It’s also what others can do, too, if they check an appropriate source for downloads. For most updates that’s the Microsoft Update Catalog. For Surface PCs, however, it’s the Download drivers and firmware for Surface page. ‘Nuff said.
One week ago today, I blogged about a clean install on one of my Dell PCs (Venue Pro 11 7130). With Fast Ring Builds 17728 and 17730, another of my Dells has forced this manuever again. That machine is a 2014 XPS 2720: i7 4770S mobile CPU, 16 GB RAM, Intel HD3000 graphics, and a Samsung EVO 250 GB mSATA SSD. I’ve been unable to get past the first reboot with either of those two upgrades this past week. None of three approaches worked. Those included: Windows Update, Windows Update MiniTool (WUMT), and a manual upgrade using a mounted ISO. Today, I bit the bullet and did a clean install. It worked like a charm, and took a major load off my mind. This raises the question: how might one recognize when Fast Ring Win10 builds 17728 and 17730 may require clean install. I’ll explain…
How to Tell When Win10 Builds 17728 and 17730 May Require Clean Install
I was never able to get past the first reboot when trying to upgrade to either of those two Builds on the XPS 2720. It would show a “Restart needed” screen in Windows Update. But one or more restarts never triggered “applying updates” and spinning balls before and after the mandatory reboot. This persisted through any number of attempts using Windows Update or WUMT. I also saw something even more mysterious when I used the UUPDump and UUPtoISO tools. I constructed an ISO for Build 17728 (it failed with UUPDump errors for .esd files from 17730). I saw a status window from the Windows 10 installer I’d never seen before. It’s labeled Windows Installer and simply reads “Windows 10 installation has failed.” Not much to go on there, I’m afraid…
This is similar to the more familiar “Something happened” message, but is a new status message from the Windows 10 installer, as far as I can tell.
Neither the message nor the underlying Panther logs gave me much to go on as to causation or cure.
If you attempt a manual upgrade from a Fast Ring ISO and see this message, I can tell you from recent personal experience that a clean install using a bootable version of that ISO will set the affected PC back to rights. I wish I knew more about how or why this was happening. But with only limited time for deep analysis and troubleshooting, after spending more than half a day trying to get to the bottom of the upgrade install issues I theorized a clean install would catch the PC up more expeditiously. Now that I’ve done it, I’m glad I was right!
Ouch! No sooner did I install the latest Nvidia GeForce driver — namely, 398.82 with an 8/1 release date — than my PC threw a bluescreen crash my way. The detail from Reliability Monitor appears below. This leaves me in something of a dilemma. Should I roll back to the previous version, or wait to see if it crashes again? Fortunately, I’ve got my 9AM backup to roll back to on my production PC. Thus, I’m in “wait and see” mode right now. But gosh! Finding myself in the situation of latest GeForce Driver 398.82 bluescreens PC is something I haven’t faced for at least a couple of years now.
This bluescreen crashed my PC hard enough I had to perform a hard reset to return to computing action. Sigh.
When Latest GeForce Driver 398.82 Bluescreens PC, What to Do?
Surprisingly, the crash was hard enough that the PC stuck on the bluescreen for several minutes. I decided to quit waiting, and did a hard reset to return to computing on that machine. So far, I’ve been running for about half an hour without a recurrence. The error message speaks of an “unknown function.” Presumably this was called in the latest Nvidia driver installer so I believe the error is unlikely to recur. That said, there is a mention of bluescreen when using Alt-Tab between a full-screen game and a video in the Netflix Edge Browser (something else that’s not likely to affect me, either). See this discussion at AnandTech for details: Nvidia releases 398.82 WHGL Game Ready Driver.
If, like me, you’re mildly obsessive about keeping drivers up-to-date, consider yourself warned that there’s at least some potential for trouble with the 398.82 release. My system is a pretty run-of-the-mill and hardly leading edge rig. A Z170 chipset, i7-6700 CPU, and a MSI GTX 1070 graphics card is not likely to suffer from bleeding-edge hardware gotchas. Methinks there’s a bug lurking in the Nvidia installer somewhere. Hopefully, they’ll root it out before the next update hits the Internet.
[PS Added 1 Hour later]: I just finished reported my replicable bug experience to Nvidia through their Nvidia Driver Feedback web page. I’ll be interested to see if this provokes any kind of response from them.
The pace of new Insider Preview feature upgrades has picked up lately. I’ve seen a least half-a-dozen in the last three weeks or so. And with increasing frequency, I’ve also encountered an interesting issue during installation. Sometimes, on some PCs, the upgrade proceeds until a first reboot is requested. Then the OS prompts for a restart to get installation going in earnest. The running OS relinquishes control, and turns over the PC to the OS installer for the serious work. Alas, I’ve have at least 3 such upgrades hang up on me. Each time, a restart did not let the installer take over and actually upgrade the OS. Thus fixing Win10 upgrade stuck on Restart has been a preoccupation for me lately. Here, I report on a couple of fixes that have worked for me with varying degrees of success.
Sure, the warning says a restart is required, and the button says restart now. When WU is stuck, repeated restarts don’t help.
1. Fixing Win10 Upgrade Stuck on Restart with WUMT
One of my go-to fixit tools when problems present with Windows Update (WU) is to try a third-party alternative instead. Named the Windows Update MiniTool, and available for download at MajorGeeks.com, WUMT accesses Windows Updates independently of WU functions built into Windows 10. For whatever reason, I’ve learned that it can often (but not always) download and install updates when WU can’t or won’t do the job. It’s definitely worth getting to know, and adding to your toolkit, just in case problems might present with WU itself. It worked to fix one of my three recent “Win10 Upgrade stuck on Restart” incidents, in fact. For more info on working with WUMT, see my Win10.Guru story “Toolkit Item: Windows Update MiniTool (WUMT).”
2. Fixing Win10 Upgrade Stuck on Restart with Cleanup + WU Reset
Even WUMT can’t always prevail in this situation. Sometimes, WU hangs so badly WUMT makes no headway, either. When that happens, I turn to the excellent tutorial (with automated batch file) at TenForums.com to perform a full-blown WU reset. Before that, based on input from my Win10.Guru partner Kari, I also perform a special “deep clean” operation on my OS files.
2.1 The OS Files Get a “Deep Clean”
Like Kari before me, I’ve tried the TenForums tutorial without taking this cleanup step. We’ve both noticed success is more likely when performed as the initial step in a full-blown WU reset operation. The command is quite simple, but cleans up all drives on a Windows 10 system, with special emphasis on the boot/system drive (usually C:). Please cut and paste this command into an administrative command prompt window:
cmd.exe /c Cleanmgr /sageset:65535 & Cleanmgr /sagerun:65535
This will open a plethora of Disk Cleanup windows — one for each drive present on the system — check ALL boxes to remove everything it finds. [NOTE: the Downloads item includes any files you’ve downloaded into your Downloads Library folder. If you want to save any such stuff, copy it into a personal directory of your making before running this command.] There’s a lot going on here, so it could take up to half an hour to complete.
2.2 Performing a Full-Blown WU Reset
The TenForums tutorial Reset Windows Update in Windows 10 covers this in amazing detail. I follow this method because it provides a batch file that you simply download (and unblock if necessary), then run. After restarting your computer, your WU environment will be completely cleaned up and reset. It took about 3 minutes to run this on my most recently affected test machine and worked like a charm. No reason why it can’t do the same for you. Highly recommended!
For most situations, if WUMT can’t set things straight, the WU Reset method explained here will do the trick. If that still fails to produce the required result, that’s not the end of the road. Those seeking to install an upgrade should consult Kari’s TenForums tutorial UUP to ISO — Create Bootable ISO from Windows 10 Upgrade Files. It explains how to build an ISO from the upgrade files that you’ve been unable to get WU to turn into a working installation. It’s more of a “DIY upgrade” scenario, and seldom, if ever fails. If that goes south, the only option left is a clean install from the same bootable ISO you have already created. Make sure you’ve got a current backup of your working installation, before you start making any of these changes. Then you can always roll back if you learn that rolling forward isn’t working. Happy trails!
Sometimes, the march of progress can be both rewarding and infuriating, where Windows 10 is concerned. Case in point: a series of failed upgrades on my Dell Venue Pro 11 recently turned into a clean install. I switched from a default disk layout with the WinRE partition first, to MS’s preferred layout which puts it last. At the same time, a long-standing gotcha on that PC also fixed itself. It was introduced last January, when the first of several firmware patches for Spectre and Meltdown made an appearance. After installing that patch, my system no longer restarted properly. Only with battery removed, and AC power temporarily disconnected then reconnected, would it start back up again. But late last week, a clean install fixes long-standing Win10 restart issue finally banished this problem. If only I knew how or why this happened, I’d be much happier.
After 7 months with no normal restart ability, a clean 1803 install sets things right again!
[Click image to see full-sized view.]
Clean Install Fixes Long-Standing Win10 Restart Issue Remains Mysterious
I can only guess that something in the first firmware update damaged the boot structure somehow. Perhaps it affected the EFI partition. Because I couldn’t restart the machine properly after that, I couldn’t install the A24 BIOS update released in June, 2018, either. That’s because the BIOS installer schedules a rewrite of the BIOS after restart to give it a clean slate to work on. But no proper restart also meant no BIOS update, either.
When I rebuilt the boot environment from scratch, though, restart resumed working normally. This enabled a BIOS update, as shown in the preceding screen capture from System Information. Interestingly, the OS never lost its ability to restart while performing upgrades. Only when the installer returned boot control to the Windows 10 UI did restart cease working properly. So I knew a fix of some kind was possible. As it happens, a clean install did the trick.
Vindicating Conventional Wisdom on Periodic Clean Installs
This machine had previously been through over 100 Windows upgrades, a sequence uninterrupted since I installed a Technical Preview in early 2015, about five months into that program. Conventional wisdom on Windows is that it’s a good idea to perform a clean install on PC’s periodically. It’s viewed as a clean-up for “behind the scenes” buildup of trash and detritus. I see this welcome return to normal restart operation on the Venue Pro 11 as vindication of such wisdom. Kind of makes me wonder why I didn’t try it sooner, rather than later. But better late than never!
I just clean-installed Windows 10 1803 on one of my test machines. In that install’s wake, I found myself unable to RDP into that machine. “Oho!” I thought to myself “I bet the network is set Public, not Private.” Although my presumption was correct, I had trouble figuring out how to make that change in Settings. A quick visit to Google informed me that a command-line remedy could do the trick in PowerShell (PS). I immediately put it to work. Here’s what that looked like, as a PS cmdlet turns Win10 networks Private:
You need Get-NetConnectionProfile to see what’s up with your network profiles. This drives use of Set-NetConnectionProfile to make the appropriate profile Private.
[Click image to see full-sized view.]
How a PS Cmdlet Turns Win10 Networks Private
Because Win10 PCs can have multiple network profiles — think WiFi and Wired, plus one or more virtual switches for VMs — it’s important to target the right one when making the switch from Public to Private. That’s where Get-NetConnectionProfile comes into play. Use it to target the InterfaceIndex whose NetworkCategory value needs to change accordingly.
PowerShell cmdlets use a verb -noun stucture. The cmdlet’s name represents a verb, or action, that does something. Get-NetConnectionProfile is a verb that lacks a required noun. That’s because it looks stuff up that the system already knows. For Set-NetConnectionProfile, on the other hand, one value identifies a specific profile, and one or more others make changes to associated value(s).
Here’s more detail on Set-NetConnectionProfile syntax, using text from the preceding example. (If the following string breaks across multiple lines, it should appear as a single line in PowerShell):
Set-NetConnectionProfile -InterfaceIndex 17 -NetworkCategory Private
Set-NetConnectionProfile is the verb that indicates we’re going to set one or more values associated with a specific network profile.
-InterfaceIndex 17 identifies the specific network interface whose profile gets a value change. For this PC, the index is 17. It will vary on other machines, including yours.
-NetworkCategory Private assigns the NetworkCategory (Public/Private) the value “Public” for the designated interface index.
It’s pretty darn simple to do this, so worth getting to know.
But Wait: There’s IS a GUI Way to Do This, Too!
After a bit more poking around online, I did eventually find a way to make the necessary change in the GUI as well. By clicking Start → Settings → Network & Internet → Change connection properties, you get to a Settings page with a “Network profile” section at the top that includes radio buttons for Public and Private. It looks like this:
Settings does provide a path to this control, though it isn’t intuitively obvious (or wasn’t obvious to me, anyway).
Given how easy this is, why I did blog about the PS cmdlet alternative? Because I had trouble finding the GUI element myself, and because some people have reported being unable to access the Network profile control through the afore-mentioned sequence of interface clicks. In Windows, there are always multiple ways to get things done. This is one case where having another way can make the difference between completing a desired task, and leaving it undone. When it comes to using RDP with my battery of machines, the latter possibility is intolerable, so I *HAD* to find another way…
Found myself in a bit of a pickle yesterday. Downloaded the 1803 ISO using the Windows ISO Download Tool from HeiDoc.Net. Quickly learned that it includes 13 different Windows 10 images (see below). After I used Rufus 3.0 to build a bootable installer, for some odd reason it installed the first image. Athough an OS pick window should appear, none did. Instead, it installed Windows 10 Home. I fixed that by upgrading Home to Windows 10 Pro. But I also wanted to learn how to extract the right image from a portmanteau ISO. That’s how I learned that DISM Export-Image grabs selected image installer, easily used to update the bootable USB Flash Drive (UFD) that Rufus built.
Notice that Windows 10 Home appears in first place, but Windows 10 Pro in sixth (Index:6).
[Click image for full-sized view.]
Use DISM Mount-Image Grabs Selected Image Installer to Build Bootable UFD
Once I figured out that I needed the Windows Pro image from position 6 in the 1803 ISO file, I needed to do two things. First, I needed to access the install.wim file I wanted. And second, I needed to copy that image onto my prepared UFD. Both things turn out to be fairly easy.
Use DISM Export-Image to Make Its Files Accessible
This particular DISM command exports a specific image standalone. As already noted, I wanted the image with Index 6. On my system, the ISO file named Win10_1803_English_x64.iso lives in L:\MSDN. To access its WIM file, I simply mount the ISO. To do that, right-click the ISO file in File Explorer and select Mount from the resulting pop-up menu. (If that doesn’t work, click “Open with” and select File Explorer from the list of applications.)
On my system, the mounted image shows up as drive M. The file I’m after takes this specification: M:\Sources\install.wim. In my case, I created a folder named WIMTest on the I: drive to receive the desired install.wim file.
Here’s the syntax for my system, which I’ll explain in generic form, too:
DISM /Export-Image /SourceImageFile:"M:\Sources\install.wim" /SourceIndex:6
Note: Even though this line breaks in this blog post, it’s actually a single instruction and should be entered as such in PowerShell or Cmd.exe.
Now, let’s explore the DISM command elements involved.
/Export-Image: Tells DISM to export the designated image file.
/SourceImageFile:"M\Sources\install.wim": identifies the windows image file from which the chosen image is exported.
/Index:6: identifies the index or position of a specific image file in the overall sequence (6, in this case) for export.
/DestinationImageFile:"I:\WIMTest\install.wim": identifies the file for the exported image.
Copy the Result File Over the Old Image File
The Rufus-created UFD has the drive letter O: on my system (YMMV, replace accordingly). All I had to do now was to over-write the old install.wim in the O:\Sources folder with the newly-exported install.wim from the I:\WIMTest folder. Now, booting the installer automatically installs Windows 10 Pro instead of Windows 10 Home. Of course, even though my system is installed the UFD is useful for repairs, too. Problem solved!
This weekend, I learned the hard way that a successful Surface Pro boot requires minimum charge levels. How did I learn this, and what made it hard? My wife and son took our Surface Pro 3 with them to Germany, in case they needed a PC while there. Turns out they didn’t, so it never even left its protective neoprene case during the trip. When I got around to unpacking and installing it in the Surface Pro 3 dock this weekend, I expected to update it immediately. Wrong!
Despite the occasional quirk, my now 4-year-old Surface Pro 3, has been (mostly) a reliable, portable, and handy mobile PC.
What Surface Pro Boot Requires Minimum Charge Means…
Sure, I tried to fire up the device once I stuck into the charging cradle in the dock. But it stubbornly refused to boot, or stay booted. I was able to get past the spinning balls, and occasionally to the lock screen. But then, the device would power off. After three unsuccessful boots in a row, it even when into repair mode, just as it should have. But I couldn’t boot into the recovery partition, either. Over time, I was able to figure out that the Surface Pro 3 — and, from what I read online, other Surface devices with non-removable batteries — won’t boot successfully unless the battery has a 5% charge or better.
It seems that because the Surface Pro’s battery had completely discharged while sitting idle for 3-plus weeks, it wasn’t ready to return to work without a minimal level of charge. Even though the device was plugged into the dock and getting power that way, something about the Surface design keeps it from working (and booting) properly until the battery regains some basic level of charge. By watching the BatteryBar utility, I was able to correlate a successful boot with charge levels of 5% or greater. On my Surface Pro 3 model (i7 4650U CPU, 8GB DDR3 RAM, 256GB Samsung SSD) that took about 10 minutes.
Since encountering this, I’ve heard from other friends and colleagues that such behavior is not limited to surface devices. Other laptops (especially ultrabooks) and tablets with sealed/non-removable batteries seem subject to this kind of thing, including smartphones, certain HP models, and more. It never hurts to be patient, I guess, even when it comes to updating or inspecting mobile PCs and other devices with completely empty batteries.
Jeremy Moskowitz, Group Policy MVP, offers an interesting survey covering Windows 10 migration challenges. It’s entitled “The 2018 State of Windows 10 Migration Challenges Report.” (Sign-up link for download: registration required.) The survey involves over 500 organizations from over 30 countries, of which 80% of respondents came from the USA. By size, 41% of organizations were SMBs (1-500 employees), 13% had 501-1000, 24% had 1001-5000, and 22% employed 5001 persons or more. The top 10 verticals covered include an interesting mix. 23% came from education, 13% government, 10% finance, 9% manufacturing, the same (9%) for professional services. Also 8% came from technology, 7 % healthcare, 6% non-profit, and 5% each for consumer and energy & utility outfits. All in all, this Win10 migration survey reveals 2018 challenges that organizations face today (and tomorrow).
With over 500 organizations reporting in, the survey tilts toward education (23%) and goverment (13%) which together represent over 1/3 of all respondents, about 7% behind their aggregate percentage of GDP (42.9%).
How Win10 Migration Survey Reveals 2018 Challenges
The survey breaks migration into four phases: (1) Planning to move, (2) Pilot only, (3) Mid-migration, and (4) Nearly complete. Here’s how organizations break down in terms of these categories, by organization size:
There’s a surprising degree of parity across all organization sizes, particularly for phases 1 and 2 (planning and pilot, respectively).
Surprisingly, the smallest organizations report the highest degree of completion. Nearly half (42%) of them are already nearing completion or have finished the migration process. Thus, only between 1/4 and 30% of organizations across the board remain in the planning phase. The rest have launched the migration process. Thus, they are somewhere on the continuum from pilot projects through nearly (or completely) done. Moskowitz observes on page 4 that “It’s promising to see such low percentages of organizations still in their planning phases — it means most orgs are taking the upcoming lack of support seriously.”
Listing Key Migration Challenges
A list of challenges that organizations face during the migration process includes the following:
Win10 file or application associations
This refers to linkage between a file extension or type and an application. This is what supports double-clicking a file in Explorer to launch an appropriate application. Certain specific associations caused migration issues. These include .pdf, .html (and associated Web files), multimedia (players), Adobe Acrobat, line of business applications, and miscellany. Surprisingly, a majority of organizations choose to manually update individual systems or leave this task to users.
Standardizing Win10 Start Menu and Taskbar
This involves tailoring the environment to facilitate user productivity and ease of access to key applications. A majority of organizations surveyed rightfully see this as an important element in the migration process. For most organizations this includes Office apps, a browser, various line-of-business applications, and department or job role specific applications. Many organizations solve these issues with group policy settings. Overall, the emphasis is on automating configurations as much as possible.
Standarized Win10 image deployments
Image deployments take teams of 2-5 people, and take from 25-52 hours per person to build and test initial images. Add 17-40 hours per person to repeat the process when images must be rebuilt or modified. Typically, this occurs in the wake of feature upgrades or significant cumulative updates. Thus, this involves significant resource allocations and expenditures. Typical image manipulations include (1) removing non-essentials apps (79%), (2) hardening security (58%), setting up BitLocker (45%), adding printers (43%), miscellany (26%), and turning off (!) Hyper-V (19%).
Local Admin rights reduction or removal
In efforts to boost security, organizations are getting more serious about role-based security and controls. Increasingly, this means revisiting the issue of what Moskowitz calls “whether [or not] to assign local admin rights to low-level users” (pg. 10). He finds that a majority of organizations (57%) still do this, trending upward with the size of the organization “to allow some assignment of local admin rights” (pg. 10). In fact, the reasons for delegation are varied. They include allowing software installation (51%), granting UAC-based elevation of privileges (43%), miscellany (42%), the ability to run admin-level scripts (27%), installing printers (22%), and installing fonts (9%). There’s a great deal more discussion of this topic in the report, which makes for interesting reading.
Net-Net and Takeaways
Indeed, Moskowitz’s report is worth downloading and reading. This goes double for IT pros who work for organization in earlier phases of the migration journey. It might just help them anticipate and deal with common issues more readily and expeditiously. I say this, even though obtaining the report requires registering with the site, and agreeing to accept ongoing email communications from PolicyPak.com. It also further validates two of my recent suppositions. First, it confirms that the wave of upcoming Win10 migrations is nowhere near its peak. Second, it supports the idea that hardware refreshes for a move to a new OS are also likely to continue for some time.