The last couple of days have been exciting in my part of the world, mostly as a consequence of downloading, installing, and absorbing the latest Windows 10 build, 10122, which made its debut two days ago. As per current usual practice, Gabe Aul documented its release at Blogging Windows, in a post entitled “Announcing Windows 10 Insider Preview Build 10122 for PCs.” Dealing with the necessary steps of installation, driver tweaking, and familiarization, 10122 has been something of a “good-news, bad-news” scenario as is not atypical for a late-stage Windows OS beta release.
The Winver output for build 10122 shows an expiration date in October, 2015.
The good news about this release is pretty good indeed, on the whole. Whereas my Dell Venue 11 Pro has experienced install issues with the last three previous builds (a cold restart after the initial reboot screen ultimately proved to be the fix for this issue, but I learned that only after a countless number of other, failed possible workarounds), the Fast Ring “update install” worked fine this time. Ditto for my homebrew i7-4770K desktop test machine (which had no problems with any of those previous installs, either). The weird touchpad insensitivity issue I’ve been wrestling since MS released a new Synaptics driver version last week (version 18.104.22.168, straight from the manufacturer via MS itself) turns out to have been related to sensitivity settings easily addressed using the Mouse Properties widget available in the Control Panel.
Some cleanup following the install of Build 10122 is probably a good idea: I shed 20+GB on the Venue 11 and 19+GB on the desktop following the install, using the “Old Windows installation” checkbox item that makes itself visible in CCleaner (always grab “slim” version), or by clicking the “Clean up system files” button in Disk Cleanup available directly from Windows 10 itself, via drive properties. The old build is big enough to be worth removing if the upgrade works, particularly on tablets or PCs with smaller boot/system storage volumes at their disposal.
The bad news about this release has been documented online as consisting of difficulties installing on Surface Pro 2 and 3 models (see this NeoWin story for a workaround hitherto unknown to me that cleans up drivers and DLLs). Also, users who have non-Nvidia/non-Intel graphics adapters on their test machines have also reported difficulties in using the new build as well, particularly with the new Edge browser (see this NeoWin “known issues” story for more info). I’ve run into something that has popped up in other prior releases — namely, that program entries in the Start menu appear as they should, but don’t respond to mouse clicks or touches by launching the related executable. The workaround is to jump into the Program Files or Program Files (x86) folder hierarchy, then find the executable, and double-click the .exe file to fire it off. OTOH, the high-priced Windows 10 version of Stardock’s former Start8 , now called Start10, continues to work just fine, so perhaps that item isn’t as nugatory as I had previously thought: and perhaps Stardock paid attention to my qvetching and moaning when buying an Object Desktop subscription was the only way to get that software, because you can now download and use a 30-day trial for free, or pay $4.99 to buy only Start10 by itself. Good on you, guys!
I’ve also noticed that Build 10122 will freeze or hang on me for as long as a minute at a time upon occasion, particularly when the CPU load shows “maxed out” 100% utilization on all available threads, but also when jumping into or out of a Remote Desktop session (I often remote into my Win10 test machines from my primary production Windows 8.1 desktop, when writing articles or blog posts, testing various OS features and functions, or fooling around to look for potholes and gotchas). I’ve experienced a couple of blue screens when mucking around with drivers, particularly on the Dell Venue 11 Pro when trying to clear the “Out-of-date” flag on its Bluetooth driver with which DriverAgent presents me on that machine. I did notice that the new build does not apparently draw on up-to-date drivers from its predecessor during the install process, which set me to wondering why that isn’t a primary source for driver data when upgrading from one related Windows OS version to another. On the other hand, the desktop machine upgrade experienced no similar loss of “driver smarts” upon its completion, so it could just be a function of the age of the gear involved: the Dell is less than 6 months old, while the test desktop includes no components less than 18 months old.
On the whole, Build 10122 seems quite solid and is working well for me. I can only hope other beta testers fare as well, and have an equally enjoyable overall experience.
[Note added 5/25: I’ve now discovered that the issue with clicking entries in the Win10 Start menu relates to search index issues. If you visit Indexing Options in Control Panel, then click the Advanced button, then click Rebuild (for Rebuild index), the menus return to normal working order. This fix restored proper behavior on both of my Windows 10 test machines in under a minute (rebuilding the index comes with dire warnings about time required to rebuild them on machines with lots of storage and things to index; warnings notwithstanding, the rebuild process was quick, even on my desktop test PC with over 5 TB of storage). Thanks to this article at WinBeta.org that set me haring off on this trail: “How to: Rebuilding your search index in Windows 1o,” I was able to confirm that menu access issues apparently stem from search stuff.]
I’m using a Dell Venue 11 Pro 7139 as one of my two primary Windows 10 test machines at the moment, and it has become a recent focus for some interesting driver issues. Late last week, MS unleashed a new Synaptics HID TouchPad driver through Windows Update for Windows 10. As soon as I applied the driver, the touchpad stopped working properly (the cursor appears on screen and the touchpad buttons work, but the cursor does not move in response to motions on the touchpad once the system finishes booting up; interestingly it works fine during boot-up, but not afterward, once I establish a log-in). A quick trip to Device Manager, where I go to the driver Properties, Driver tab, and clicking the Roll Back Driver button takes care of the problem, and things go back to normal.
Until MS, or Synaptics, or Dell, fixes the standard driver not working problem on the 7139, I’m going to see this in WU.
Why is this a problem? The reason is that Windows Update in Win10 doesn’t give me the option to hide driver updates, so I can’t tell WU not to apply this update. Every time the system reboots, it checks for updates, applies the new (non-working) Synaptics driver, and bang! there goes my touchpad into “out of order” mode. I can, of course, use an external mouse (I have both Bluetooth and Unifying receiver-based meese at my disposal) or I can zip back into Device Manager and roll back the driver each time WU re-applies it for me. Just for grins, I decided to give Dell Tech Support a call to see if they knew anything I didn’t. Once they found out I was running Windows 10, they punted in Microsoft’s direction and urged me to post my issue to the Windows 10 Insider Hub/Windows Feedback (I have already done so) but were unable to offer any other solutions that might fix the problem once and for all. I spoke to a very nice service technician, and her boss, both of whom agreed that the issue essentially boils down to a lack of means or functions to selectively refuse driver updates from Windows Update in Windows 10. I hope that Microsoft will address this kind of general functionality in the RTM and/or GA releases, perhaps by making such drivers optional (which gives users the ability to refuse them, and hide them to prevent further auto-installation attempts).
[Note added 5/25: Last Friday (May 22), I visited the Synaptics widget in Control Panel, and by increasing the touch sensitivity of the touch panel, I was able to restore it to proper working operation. Something about the driver update caused the settings to be massively decreased, to the point where the touchpad really couldn’t function. Monkeying with those settings, and getting them to an apparently more normal range, allowed me to regain use of the device. Go Figure!]
In my last post here, I observed the number and frequency of updates for Windows 10 arriving via an unthrottled and untrammeled Windows Update. By far, the biggest number of items in the 15-day list concerned Windows Defender, with well over half the individual events resulting in an update of some kind targeting that application. And in fact, Defender was the only application to regularly receive multiple updates in one day, and as many as three updates on some days.
“If at first you don’t succeed…” may be a mantra for overcoming difficulties; that said, it shouldn’t apply to a one-or-more-times-a-day update like that for Windows Defender.
This morning, I discovered that both of my test systems were failing to apply Updates related to Defender. Further investigation revealed that in cases where Windows Update delivers more than one Defender update at the same time (as was the case with Update Versions 1.197.2868.0 and 1.197.2856.0) queued up at the same time), an interesting pattern manifested itself. The first such update would succeed, but the second would fail producing a variety of different error codes along the way. The fix was bone-headed and time-consuming but it worked: although Defender doesn’t require a reboot following its updates (nor should a set of routine security and antimalware additions), a reboot after each update when more than one Defender update is queued up for application was the only way I could get them to apply themselves successfully.
Looking back through my update history through early May on both machines, I see 9 failures on the homebrew PC and 7 failures on the Dell Venu 11 Pro: all of them involve Windows Defender. There are no other update failures in either record, in fact, which suggests to me that Defender is a culprit (or perhaps, a victim) for some kind of update problem. I’ve reported this to MS through the Windows Feedback app, and see that this has been reported many times over the past three months or more. I hope this is something they’ll fix prior to the upcoming RTM release: it’s bad enough that some updates require reboots to complete their successful application; it’s worse when updates that shouldn’t require reboots end up demanding them to work around as -yet-unknown bugs in their normal application process.
[Note added 5/25: Since recording these observations a week ago, I’ve been able to reconfirm them on several occasions for both of my test machines. I’m not sure that constitutes a sufficiently large pool to make a quorum, but from my perspective this now looks less like an interesting anomaly and more like a bug, and I’m reporting it as such to Microsoft through the Windows Feedback widget.]
In the brave new world of Windows 10, updates are no longer batched, but pop up when and as they appear. I decided to take a look at what that means by examining the Update Histories for my two current Windows 10 PCs, in terms of types and frequencies of updates involved. But first, of course, some caveats:
1. Windows 10 is a beta OS so it’s probably more subject to updates in general than a stable production OS would be.
2. Furthermore, Windows 10 is a beta OS that’s in the headlong rush to RTM sometime in the next 2-4 weeks or so, so perhaps what we see is waaaay outside the realm of what’s likely after GA comes and goes.
3. By way of comparison, the last Update Tuesday (May 12) deposited from 40 to 48 updates on my half-dozen or so Windows 8.1 PCs and tablets here at Chez Tittel. That works out to a daily frequency of roughly 1.3 to 1.5 updates, not including Windows Defender.
On Windows 10, Windows Update is handled through the Update & Security widget in the Settings app.
With all this in mind, take a look at what showed up on my two test PCs for the period from May 1 to 15 (I ran Windows Update just after logging into both machines on the 15th, but that day is far from over it still being early morning as I write this blog post):
|Windows 10 Updates May 1-15, 2015|
|Date||Dell Venue 11 Pro||Homebrew i7-4770K|
|5/3||Defender (3)||Defender (3)|
|5/5||Update KB2062095||Update KB3062095|
|5/6||Defender (2)||Defender (2)|
|5/9||Synaptics driver update||Defender|
|Realtek HiDef Audio driver update|
|5/11||Defender (3)||Realtek HiDef Audio driver update|
|Malicious SW Removal Tool||Malicious SW Removal Tool|
|5/14||Feature on Demand for X64 (.NET 3.5)||Feature on Demand for X64 (.NET 3.5)|
|Intel HD Graphics driver||Security Update KB 3051768|
|Security Update KB3066002|
|5/15||Security Update KB 3051768|
|Security Update KB3066002|
The data suggest some interesting take-aways from a new and upcoming Windows Update regime. First, I find it interesting that on some days Windows Defender gets as many as three distinct updates (the rhythm for other endpoint security solutions varies, but this is not unheard of in enterprise environments, either, and is usually separate from the normal controlled update deployment regimes in place). Second, it was fascinating to see device drivers arriving more or less at random: though the Windows qualification scheme is reasonably well-managed for drivers that pass through WU, I can’t imagine enterprises passing them onto clients without prior testing, because driver failures are as likely, if not more likely, to cause blue screens than any other kind of botched update. Third, it was interesting to see the monthly Malicious Software Removal tool show up solo on my Windows 10 machines — in fact, that’s what clued me into checking up for updates on my Windows 8.1 PCs.
The total number of updates for May so far, not including Defender (which I don’t consider to fall under the normal aegis of update management and deployment, anti-malware updates being of a somewhat different nature) was 7 for the Dell, and 6 for the homebrew PC, of which 3 for the Dell and 1 for the homebrew PC were drivers, the rest security and other Windows updates for each machine. This is not an insane number, but their irregular and unpredictable frequency and composition (drivers versus other updates, for example) means that enterprise IT pros will still be collecting them as they show up, passing certain critical items through on a high-priority basis (these might have been identified as “critical out-of-band security updates” in the old, pre-Win10 WU world; it will be interesting to see how they get labelled and handled in the new, post-Win10 WU world), and working and testing the remainder to see which ones make the cut for the next scheduled update deployment time slot. Given what I see here, I don’t believe that the recently-announced Windows Update for Business is going to have much of an impact. It should be interesting to wait and watch to see how it all plays out!
Realizing that yesterday was “Update Tuesday,” I opened up my update history on a production Windows 8.1 PC this morning, and found 40 (!) updates of varying shapes and sizes had been installed thereupon. You can read all about what hit yesterday in the MS Security Bulletin Summary for May 2015 if you like, but you’d best set aside at least half an hour to chew your way through its formidable contents. Suffice it to say here that you’ll find two critical items (MS15-043 and MS15-044) that could permit remote code execution, one that provides a cumulative security update for IE, the other that patches TrueType font driver related issues for Windows, .NET, MS Office, MS Lync, and Silverlight.
The big bulletins for May pose interesting vulnerabilities for IE and “TrueType fonts everywhere.”
Just for grins, I jumped over to my Windows 10 test machines and found a single common update from the herd of Windows 7/8 items had propagated over to the new desktop OS — namely, the usual monthly update to the Windows Malicious Software Removal Tool (KB890830). I’m not sure how many of the other updates released for earlier desktop OSes yesterday had already been applied to Windows 10, nor how many common elements may still be forthcoming. It seems fairly obvious, however, that ongoing streaming of updates instead of batching them up for monthly release will definitely lower the Wow! factor for those who have updates applied automatically when they log in the day after “Patch Tuesday” — err, rather, “Update Tuesday,” as Microsoft’s new nomenclature would have it.
The upcoming delivery of Windows Update for Business (see my May 6 blog post for details) means that enterprise admins will be able to permit some updates to propagate to end-users if they so choose, while holding back others for testing and safety/compatibility checks. My best guess is that enterprises will stick to their current approaches and toolsets, trusting to their own tried-and-true update handling techniques for some time to come, as they work with and try out WU4B to see if it does them any better than their own methods already do. The jury will be out on that question for some time to come, because it all hinges on large-scale, wholesale upgrades to Win10, which often don’t happen until 1-2 years after initial release to the general public. I’m wondering if Win10 will bring enough compelling new features to the party to accelerate things a bit, or if the impending retirement of Windows 7 and the lackluster response to Windows 8 might not prove a more telling impetus in the long run. We’ll see!
I’ve blogged repeatedly here about a great little free software tool called DriverStore Explorer (RAPR.EXE). In Windows environments all the way up to and including Windows 10, any drivers that have been loaded and installed on the current Windows OS (or prior OSes that have been upgraded) reside in a directory named %windir%\System32\DriverStore. As an experiment, I’ve been cleaning up that directory on one Windows 10 installation (on my Dell Venue 11 Pro 7130) and leaving that directory alone on another installation (on my i7-4770K homebrew desktop). Upon reading an observation from one Windows 10 beta tester over on the Windows 10 Forums this morning about a Windows install over 50 GB in size (!) I found myself wondering if DriverStore might not be playing a role in that burgeoning disk consumption.
So I decided to compare the size of those two directories on my cleaned-up versus untouched versions. On the untouched version the size of that folder is a whopping 26.1 GB; on the cleaned-up version, it consumes just 1.4 GB. Here’s what those folders look like in WinDirStat, just for a quick visual comparison:
Dell above, homebrew below: you can fit the smaller box into the bigger one more than 18 times!
(I reduced pixel count by 50% on both images to better fit most WordPress displays)
In case the moral of the story isn’t already clear, especially for those who want to run Windows on a smaller SSD or hard disk, you really can recover a lot of storage space by keeping your DriverStore cleaned up. If you need further proof, following a quick cleanup with RAPR on that directory, it consumed only 1.3 GB. I found over a dozen duplicate Nvidia drivers therein, but it was the 120-plus copies of the RealTek sound chip drivers that really sucked up the space, as the subsequent reclamation of 24.8 GB of disk space unequivocally illustrates. All I can say is “Zounds!”
In the wake of recent MS conferences like Build 2015 and Ignite, the pundits and prognosticators seem surprisingly unanimous with two short-term predictions. First, Windows 10 seems bound for general availability (GA release) by the end of July; and second, a new, improved and fanless Surface Pro 4 (SP4) model seems destined to hit markets at around the same time. Sean Cameron at WinBeta, Mary Jo Foley at ZDNet, and Brian P. Rubin at readwrite, among many others — including yours truly — have all recently opined about what it’s gonna take to turn the already formidable Surface Pro 3 into a market-leading monster upon its impending release.
What’s missing from the Surface Pro accessory collection is a plug-in keyboard with hinge like this one, to turn it into a clamshell PC.
I think I’ve got the answer (with which Sean Cameron concurs, as his afore-linked WinBeta story will attest): a clamshell style keyboard dock. The Type cover is fine, but I am continually frustrated by the kickstand with floppy keyboard whenever I try to work away from a desk or tabletop. Though MS delights in proclaiming the kickstand-plus-Type-cover as “lappable” ( or is that “lapable?”) I do not find the device to be such, nor terribly workable away from a hard, flat surface upon which to park it.
So far, I’ve owned two tablets that included clamshell keyboard plug-ins, both with added batteries to improve the runtime of the devices that plug into them. One, I got rid of — the Fujitsu Stylistic Q704 — primarily because its Haswell-era i7 processor produced enough heat to overwhelm the tiny unit’s built-in cooling capacity, and kept having to be throttled back to keep it from overheating. Its clamshell keyboard dock was great, if a bit heavy, and really made the unit much more useful (and thus also, likely to be used) over time. The other is my Dell Venue 11 Pro 7130, which includes a Broadwell M i5-4210Y CPU, and doesn’t need active cooling to operate. It too, has a nifty clamshell keyboard dock (which appears in the preceding photo), and I use it all the time both as a light-duty traveling machine and as a book reader/media player. Even with the keyboard attached, it’s light enough that I have recently traveled with a Lenovo T520 for work, an iPad to read on the plane with, and the Venue 11 Pro for personal use and entertainment, all in the same old beat-up but still serviceable Targus computer briefcase I’ve carried for over a decade now.
If MS doesn’t already have something like this in the pipeline, we won’t see such an accessory when the newest Surface Pro model ships in the next few months. But I sincerely hope MS decides to build something like this for the Surface Pro models, because it would make the difference between me watching my wife and son use the Surface as our household’s go-to mobile PC at home, and me turning that unit into my road machine and primary desktop replacement at home. Are you listening, Microsoft? I sure hope so…
One of the most interesting tidbits to emerge from the Ignite conference so far has been Microsoft’s announcement of its “Windows Update for Business” service. Terry Myerson himself, Microsoft’s EVP for Operating Systems, made this announcement — and offers an equivalent Blogging Windows post on the topic — which shows that the company really gets how important handling updates at the enterprise level truly is, and has put some serious thought into accommodating a very different set of needs and priorities when it comes to staging and deploying such updates in a business environment.
With Windows 10, MS will finally offer a different kind of Windows Update for business users, emphasis on enterprise-class deployments.
[Click image for full-size view, if the “fine print” is too challenging.]
What does Windows Update for Business involve? There’s a lot of hoopla in the announcement about matters related to protection, for devices, identity, applications, and information, but I’ll let the announcement handle those details. What I — and most enterprise IT organizations — care about even more is support for how updates get managed and deployed. Historically, the consumer-grade version of Windows Update has been totally at odds with business needs in that it’s endpoint driven, automatic, and more or less involuntary. In enterprise environments, the first concern about change management is to ensure that introducing change does not also introduce unwanted side effects, particularly those that might affect the proper operation of mission-critical line of business and custom applications. Perforce, there’s no way for MS to test against such things before unleashing updates on the world, so enterprise IT organizations have no choice but to test such things themselves, and only to permit updates that don’t create negative impacts to be deployed in their production environments. In addition, most enterprise IT organizations have only short intervals during which update deployment is scheduled to occur (usually on a monthly or quarterly basis) and they must be able to stage and deploy safe updates within the time windows available to them, or roll back problem or incomplete updates before the update time window closes, so as to leave their production environments in a stable, working state for employees, contractors, and partners to use when production work resumes immediately thereafter.
The MS announcement takes strong cognizance of these needs and the enterprise update situation. To that end, it includes the following capabilities:
1. Distribution rings: a means whereby IT can specify which devices go first in an update wave, and which devices will come later (this provides an opportunity to pilot new or changed elements to power users, developers, and the like, to enable issues to manifest and be solved, before rolling updates out to the entire world of production).
2. Maintenance windows: enables IT departments to establish the dates and times when updates may occur, and — more important — when they may not occur.
3. Peer-to-peer delivery: permits IT to deliver updates to branch offices and remote sites only once, after which they can fan out to individual nodes and devices at the edge of the network. This is essential to conserving bandwidth across private or high-cost WAN links from central, highly-connected corporate sites to the network edge.
4. Integration with existing tools: permits management tools and environments (e.g. System Center or Enterprise Mobility Suite) to continue to function as the “single pane of glass” through which to manage update deployment along with the myriad of other functions needed to care for and troubleshoot enterprise IT environments. I’m curious to see how well this will play in enterprises that use non-MS tools to perform such functions (where connectors may need to be built before full-scale integration is possible), though MS platforms already seem to be covered.
As somebody who’s witnessed a few holiday weekend exercises in update deployment, with a battery of experts on tap to escalate and shoot the inevitable trouble that often pops up as the time window expires, I’m delighted to see that Microsoft is getting with the program that has been in place in enterprise IT environments since the beginning. All I can say is “About time!” And again, it will be fascinating to see how the elements described above play out in actual high-volume deployments once Windows 10 has been deployed in sufficient numbers to make it suitable to put Windows Update for Business to work in the real world.
Like many other beta testers for Windows 10, I reported early on (around build 9879, if memory serves) that the deployment image servicing and management facility, better known as the DISM command, wouldn’t work without an explicit sources reference in the command line (see TechNet and MSDN for syntax and semantics info). I’ve been checking this capability with each new build since then, and hadn’t seen any progress until Build 10074 was released last week. Here’s a screen cap of the CMD (command prompt) window, with some visual proof for this assertion:
No more error messages when you run the default DISM with /Cleanup-Image and /RestoreHealth options!
For those not already using DISM, the tool is designed to replace the pkgmgr, PEImg, and IntlConfg tools retired with Windows 7. It provides a centralized console from which to create and manage Windows images, package them for deployment, maintain them with updates and added post-install executable elements, provide additional fonts and language support and, in the words of the infamous and notorious old Ronco ads: “Much, much more!” The particular command above is useful to restore the health of the currently running image on a Windows PC, and should be an early go-to in any Windows admin’s fix-it routines and procedures. That’s why it’s so welcome to see its defaults finally working as advertised or promised in Build 10074.
Whoa! Has it really only been two days since the last time I posted? It seems like a lot more time has gone by than that, but perhaps that’s because I’ve been pounding away at Win10 issues over most of the intervening days and hours. No sooner did I finally got my Dell Venue 11 Pro up and working with build 10061, than along came build 10074, and a new name for the current state of Windows 10, both in connection with this week’s Build 2015 conference held in San Francisco.
No more “Technical Preview,” Now it’s an “Insider Preview”
At the conference über-Windows guy Gabe Aul explained that “In fact, Insider feedback has become so valuable to our engineering process, we’ve decided to rename ‘Windows 10 Technical Preview’ to ‘Windows 10 Insider Preview.’ It’s the same OS as before” [I picked this gem up over at the Windows Ten Forums, where it appeared in a news item early on May 1, one day after Aul’s Blogging Windows post introduced the nomenclature update]. Here’s that headline, for your delectation:
Here is a new name straight from MS [click image to see full-size screencap].
From Build 10061 to Build 10074, and beyond!
So, just after getting the Dell Venue 11 Pro up and running on 10061, I found myself immediately upgrading to 10074. This one proved a great deal more interesting than the last upgrade for a whole slew of reasons, which I will now elaborate:
1. As usual the desktop upgraded smoothly and painlessly from old to new build, and the Dell once again hung after the initial shut-down that precedes the first restart once the new OS in place. Having now learned that a cold start will prevent this problem from pausing progress, this time I popped the battery out of the unit after the shut-down occurred, and was then able to boot right up into the “getting Store apps, setting a few things up, …” post-install clean-up during the finishing phases of the OS install. Having been through this 5 times in the past 10 days, I now believe there’s some issue with the start-up behavior of the Venue 11 Pro, possibly related to the BIOS or low-level boot blocks used in the earliest phases of start-up during or immediately after BIOS execution, that’s hanging during the restart that occurs during the installation process. The workaround of forcing a cold and complete shutdown, then a clean restart seems to fix whatever issue is causing the problem.
2. There’s no question that Windows 10 is getting bigger. For build 10061 I had 24.2 GB reported in the Windows.old holdings as available for post-install cleanup (you can clear these files in Disk Cleanup by selecting “System files” during its enumeration phase, or you can elect “delete old Windows installation” in Piriform’s CCleaner program: I am inclined to use the latter because it’s 3-4 faster to completion than the built-in utility). For build 10074, Windows.old was reported at 34.0 GB instead, an increase of almost 10 GB!
3. For the second time with any Windows 10 install, I found driver issues following the installation. It’s normal when performing a clean install of a new OS for the first time for there to be anywhere from a few to a couple of dozen device drivers in need of update or attention. But this is the first upgrade install of Windows 10 since the first build went out where I actually lost a half-dozen drivers following the upgrade (normally drivers are preserved from one build to the next, apparently unmolested during the upgrade process). On the Dell Venue 11 Pro, I found a handful of unknown devices in Device Manager following the install, which turned out to include these items:
- Intel Watchdog Timer
- Intel 82802 firmware flash hub (which turned out to be an Intel 28F320C3 Flash Update Device, when properly recognized)
- O2 Micro Integrated MMC SD card reader
- Intel Display Audio
- Intel Virtual Buttons
Fixing those missing items turned out to be the most interesting part of the “getting back to work” effort following the 10074 installation. DriverAgent helped me fix 3 of the 5 items reported as Unknown Devices, but I had to resort to old fashioned detective work to fix the other two. In each case I used the “Hardware Ids” string from the Details pane in the Properties window to search for the device that needed a driver. In both cases, the search was pretty straightforward, and I was able to find the necessary software to bring those devices out of terra incognita and endow them with current, working drivers. Very interesting!
So far, I like Build 10074 better than 10061. It is more stable, offers more interesting graphics and layout, permits running 32-bit applications from the start menu without workarounds, and generally seems pretty well-behaved. I’ve even been able to make new system image backups and system refresh images for both the desktop and the Dell Venue 11 Pro without incident. If I should accidentally trash something, as my experimenting sometimes causes, I’m pretty sure I can get back to a known, good working state on either machine pretty quickly. In the wonderful but whacky world of Windows beta OS work, it doesn’t get any better than that!