For the last three builds of Windows 10 (10159, 10162, and 10166) the OS was remarkably well-behaved in installing drivers for my newest PC (a less-than-one-year-old Dell Venue 11 Pro 7139 with an i5 4210Y CPU aka Haswell M, 8 GB RAM, 256 GB SSD, NXP, and so forth). Alas that record was shattered with the installation of the current release candidate build numbered 10240.
I’m not sure troubleshooting drivers for half a day counts, but here’s a current Win10 slogan to ponder…
When I finally got around to checking the successful install on Monday of this week, I found a raft of device driver issues in the wake of that installation. Here’s a list:
1. The Dell 1537 a/b/g/n Wi-Fi driver for the wireless network interface failed to load (the device was apparently not recognized and showed up in Device Manager as Unknown Device)
2. The SATA AHCI driver loaded was two generations back from the current installed version
3. The O2Micro SD card reader driver was likewise older than it should have been
4. The SMBus driver for the Synaptics touchpad did not load (and also showed up as an unknown device)
5. The WPD FileSystem driver (which also showed up as an unknown device with hardware ID root/IWDbus) did not load
6. The Bluetooth Bus driver (unknown device with hardware ID root/BTath) also did not load
7. Two Dell pseudo-drivers with hardware IDs “*DellProf” and “*DDDriver” still show up as Unknown Devices and I haven’t taken the time to research how to repair them. I’m pretty sure one is associated with my Dell 2150cdn color printer, and the other with their Diagnostics software, but a quick search turned up no fixes, so I plan to wait for the official RTM to figure out how to resolve these items.
Needless to say, this came as a big, rude, and unpleasant surprise after all my good luck on the three previous installations. In fact, I’m still scratching my head as to why this would pop up unexpectedly after several successful experiences. But in putting my system back together I learned several useful things, too:
1. Intel, NVidia, and other device makers are starting to release drivers that specifically mention and target Windows 10 directly. In truth, I’ve had little problems with all of the Win10 builds getting Windows 8.1 drivers to work with Windows 10 so driver compatibility issues between these two OSes seem to be few and far between. Nevertheless, it’s cheering to see explicitly labeled Win10 drivers as the RTM date is nearly upon us.
2. I was able to go to the Dell Support site and get most of the drivers I needed for the VP11Pro with little muss or fuss.
3. After some Internet research, I learned that for the IWDbus driver, the easiest fix was simply to uninstall what Win10 install had left behind, then discover new hardware in Device Manager, and let Windows take care of the problem (worked like a charm, so I tried this with other Unknown Device items, with varying degrees of success).
4. I had to repair my Intel Rapid Storage Technology (RST) installation because the existing version carried over through the install didn’t work any more (I’m starting to learn it may be a good idea to uninstall this service before upgrading modern Windows OSes).
The bottom line is that it’s a good idea to get your drivers lined up and ready to reinstall on any newer systems that may include devices or need drivers that Windows 10 doesn’t recognize on its own. I use a tool called “DriverBackup! 2” that does a decent job of capturing all the drivers on any machine it targets and creating a backup set of same (some drivers, however, require installation programs and these may not always restore properly directly from the .inf, .cat, .dll and other files that the application captures on your behalf). You’ll probably want to take similar precautions if you’re going to be upgrading a machine from Windows 7 or 8.1 to Windows 10 soon, or converting a preview/release candidate version to the RTM version when it becomes available.
If you’ve been reading this blog for any length of time, you already know I’m a big proponent of Secunia products, most notably Secunia’s Personal Software Inspector (PSI, but they also have a corporate version called CSI as well). Recently, I’ve been noodling about with Win10 because of a persistent warning from PSI that the installed version of QuickTime — Apple’s video playback engine — is out of date on my test machines. Interestingly, running the Apple Software Update scanner has found nothing out-of-date for the past couple of weeks. So when I saw a new version of iTunes available this morning, I figured the QuickTime fix would probably be bundled along with all the other changes involved in updating to a new version.
Long story short: I was wrong. The version I was running on my test machines was 188.8.131.52, and thanks to a bit of poking around on the Internet, I learned the latest version of QuickTime available for Windows 8.1 is 184.108.40.206. That said, the official download available from Apple is version 7.7.7 (released October 2014) and mentions only Windows 7 and Windows Vista as valid install targets.
The official download page for Quicktime for Windows only mentions versions 7 and Vista (a support search turns up no explicit mention of Windows 8.1 for this software)
It wasn’t until I refined my download search to include Windows 8.1 that I learned that version 220.127.116.11 is now available, and has been since July 3, 2015. I found a reliable 3rd party download source (DownLoadx64.com), and grabbed a copy. (Make sure to click the right download link, or you’ll grab stuff you don’t want — a typical “red herring design trick” nearly universal on such sites, which generate revenue by harvesting clicks from misdirected users.) Upon installation, PSI accepted that I’d installed the latest version and turned off its warning for that software item.
Problem solved, but I have to wonder why the Apple Software Update widget didn’t detect this discrepancy, and then fix it automatically. Everything I can find about Apple support for Windows fails to mention Windows 10 (not unusual for a beta OS version), so I can only speculate that the latest and soon-to-be-current version of Windows hasn’t yet been fully integrated with their update/patch utility. Methinks this will have to change soon, with Windows 10 RTM due in less than two weeks. But Apple may prove stubborn and wait until General Availability (October ?) to catch things up. We’ll see!
Ha! Ha! No sooner did I post a blog about a build hiatus for Windows 10 Insider that did Microsoft release an honest-to-gosh release candidate in the form of Build 10240. How do I know this is a candidate for sure? Simple: no more watermark at the lower right of the screen (which labeled the software as an evaluation copy and a preview of some kind or another: technical, insider, and so forth). Also, check out what Winver now shows for the 10240 build:
No more expiration date, no more mention of evaluation or preview of any kind.
In its comments on this build, WinBeta raises some interesting questions about whether or not it’s an RTM version. Whatever its status, all the signs point to something that’s really close to finalized, if not the actual cigar itself. The old Windows installation (build 10166, in my case, for both test machines) still weighs in at just under 20 GB, so it’s still worth cleaning up. I did have to update the RealTek Audio driver after this install, and I also found 72 copies of that driver in the DriverStore after running the DriverAgent installer for same, of which I was successfully able to delete 71 without difficulty. I also found three extra copies of the Nvidia GeForce drivers as well, and tossed them, too. If there’s one thing I’ve learned from all the many Windows 10 installs I’ve done during the preview period, it’s that checking and cleaning the DriverStore afterward is every bit as important as getting rid of Windows.old. Use Driver Store Explorer aka RAPR to get this job done.
In his attempt to woo his future wife in the 1985 sci-fi hit Back to the Future, George McFly flubs his pickup line, saying “I’m your density” instead of “I’m your destiny.” That classic movie quote popped into my head recently as I was thinking about another potential marriage — one between high-density hardware and VDI deployments.
George and Lorraine are kind of like high-density hardware and VDI. George is a significantly more anxious person than most. High-density servers are the same way, but instead of nerves, they pack more compute power into less physical space than the average server.
Lorraine is like VDI; she’s a complex system that needs the right partner to flourish. (Case in point: In Back to the Future Part II, Lorraine breaks down without George and spirals into alcoholism.) Likewise, without the right power behind it, VDI runs into I/O and memory constraints.
In both cases, it takes the right set of circumstances for these relationships to end happily ever after. So how can VDI and high-density hardware work in harmony?
High-density servers are a good fit for VDI in IT shops that have a large number of virtual desktop users and a limited amount of data center space. But compute isn’t often the resource that VDI needs most. Like the movie, there are unforeseen variables around every corner.
That’s why it’s important to consider the other resource constraints that virtual desktops encounter. The most dangerous one is the actual users behind the desktops, who can be very unpredictable. Some users might consume minimal resources whereas others open programs and never shut them down. It’s hard to predict how much memory users require on a given day.
The McFlys’ world isn’t perfect either. George is challenged by his rival Biff, but he eventually musters up the courage to punch Biff in the face, winning Lorraine’s heart.
Get the full story on whether high-density servers and VDI are destined for each other, taking into account some serious obstacles such as a potentially higher cost per desktop.
Update 7/13: We’re only a couple of weeks away now from our public release of Windows 10, and we’re preparing for the world to begin the upgrade process. Windows Insiders have been the first to see our work on Windows 10 at every stage. Now you will also be the first to get a build flighted to you using the channels that we’ll use for targeting and deploying to PCs for our staged rollout.
We’re suspending the availability of Windows 10 builds briefly while we prepare for that, and the next build that we flight to you will be delivered using the production channels. Starting tomorrow, we will also not be delivering any additional ISOs at this point as we really need Insiders to be using, stressing, and validating our distribution and upgrade processes. We’ll make ISOs available again in the future, but for now we ask you to upgrade your current build via Windows Update once the next build is released.
What this means for the time being is that neither build 10162 nor 10166 will be available via Windows Update, and that ISOs for 10162 will likewise be taken down. Somewhat more interesting, pre-release keys for Win10 will no longer activate builds up through and including 10166. I’m guessing this means that the next build to come will be the RTM build or something very, very close to it. Given that MS wants to make sure that insiders will “be using, stressing, and validating [its] distribution and upgrade processes” I can only imagine that this means the company is getting ready to turn the RTM over. That should be sizable audience, that includes not just the 5 million insiders, but also all those many users who registered to receive the Windows 10 upgrade at or around July 29. And, from what I’m reading about the upcoming launch, MS will also be available on 7/29 on new PCs and tablets, too. This population could easily be in the tens to hundreds of millions, which explains why MS is apparently laboring mightily to get everything ready.
Ready or not, world and Microsoft, here comes Windows 10!
Buckle up guys and gals: this could get interesting!
For a while now, I’ve been speculating about what goes on with device drivers each time a new Win10 Build goes onto one of my test machines. In visiting Reliability Monitor (RelMon) this morning, I finally got confirmation that Win10 starts afresh with drivers during the install process, immediately following device enumeration as shown here:
Looks like my i7 4770K machine requires 24 drivers during the install process, and is finding everything it needs.
I’ve got to say that I’m either benefitting from having a less-than-bleeding edge system (it’s about two years old) or MS is doing a bang-up job of finding the drivers it needs (DriverAgent is reporting that all 119 devices on this test machine are correct and up-to-date, without requiring any action from yours truly to make it so). It’s nice to get confirmation that Windows 10 does start with fresh drivers each time a new build installs, but even nicer to have a sense that MS is handling those drivers without too much muss or fuss (remember the Vista driver debacle? Looks unlikely to repeat with this version…). Even my Dell Venue Pro 11 7139 (a much newer system, with 4 drivers showing “behind” on that platform, keeps that status unchanged from one new Windows 10 build to the next — I am unable to update those drivers, either because the results of the update cause the system to fail (a not uncommon phenomenon on notebook and tablet PCs), or because the new drivers won’t install for any of a number of good reasons — which tells me that MS has got the driver thing pretty well figured out for Windows 10.
That’s one thing that those who upgrade to Windows 10 following the July 29 release date probably won’t have to worry about. That’s a bit of unalloyed good news, because nothing brings systems down like driver difficulties.
Having been distracted by other projects for most of this week, I was pleased to have missed the latest Fast Ring release of Build 10166 by only one day. I got it fired up and running almost immediately: it took less than half an hour, all told, to download and install on my trusty desktop test machine. It’s installing on my Dell Venue 11 Pro 7139 right now, and I sincerely hope it fares better during installation than did Build 10162, which failed when installation was nearly complete because of an unresolved driver error of some kind.
Say hello to Build 10166; it really does look like 10176 is likely to be the source for RTM, at this rate.
So far, I can’t tell much difference among the last four builds, all the way back to 10159. I did notice with 10166 that, for the first time, the build came up without apparently having rolled any of my drivers back to earlier versions. I’m hopeful this means MS has finally added some logic to the install to grab more current drivers from what’s already running if they’re available before overwriting them with some canonical, but outdated, notion of what’s needed during installation. Alas, that’s probably too much to hope for, and it simply means that for once MS’s notions of what drivers are current are in synch with DriverAgent’s ideas on the same topic for my desktop test machine.
I also noticed that the DriverStore folder is staying pretty clean following the OS Upgrade. For some time now, I’ve been seeing duplicated drivers showing up post-installation, about which I can only conjecture that MS had been adding drivers during installation, even if they weren’t needed. After this latest install I found exactly two duplicated Nvidia drivers for my graphics card, and one duplicated RealTek Audio driver. This makes it one of the easiest post-install clean-ups ever, and certainly the best one so far for all the Win10 builds I’ve installed.
The Dell got through the initial installation (download, install prep, file unpack and layout) as far as the first reboot, and then into the Upgrading Windows circular progress bar. I’m going to keep this post open until I can report on the outcome of this first installation attempt. After getting farther on that circular progress bar than on any of the 10162 attempts, the installation on the Dell Venue Pro 11 finished successfully, too. Hopefully, that means MS figured out what was up with the driver problem on the last go-round and managed to fix it as well. Good on them!
I’m working on my traveling laptop this week, so I’m on a different PC from usual. It’s my trusty bigger-screen Lenovo T420 (Sandy Bridge 2.8 GHz i7, 16 GB RAM, Plextor 256 GB mSATA SSD, and so forth). In checking over the system, I discovered that File History was turned off, and when I tried to turn it back on I got an error message to the effect that the Service wasn’t turned on or no enabled device was available. Neither of these conditions led me to a working File History, so I started spelunking on the Web.
Finding relief often means knowing what to ask for.
I found relief, as I often do, at answers.microsoft.com, where I learned that Windows Search and Indexing must be turned on for File History to work. After I recovered from that “Doh!” moment, I ran the Indexing and Search troubleshooter which returned the service to normal operation. As soon as I had done so, I was able to turn File History back on, no sweat.
Now, all I have to do is figure out how Windows Search got turned off, and I’ll be able to understand how all this happened in the first place. I will also opine that although many Windows performance optimization and tuning resources recommend turning off Windows Search, none of them that I can recall (e.g. BlackViper is a favorite) point out that turning it off causes File History to become nonoperational.
Sigh. Windows: it’s a living, but sometimes, not a happy one!
As reported on lots of Windows watching sites — WinBeta and betanews, for example — a first Windows 10 build numbered 10176, labeled as a release candidate, has made its debut. Most of these stories originate from BuildFeed.net which tracks Windows 10 builds as a kind of public service. WinBeta speculates further that “if all goes well, Microsoft could have an RTM build of Windows 10 ready by the end of the week…”
That same story also provides an interesting “rough consensus model” for how the latest RTM process will work at Microsoft, which reminds me of how things work at IETF with draft specifications:
If you are unaware how the sign off process works, Microsoft will compile a number of builds they consider ‘worthy’ of RTM, these are called RTM candidates. These builds will be tested, and if the builds are found to have no bugs or issues, will be then voted on by employees. The build which is voted for the most is then selected as the RTM build, and recompiled into the winmain branch. The build number then usually jumps to a number which is divisible by 16 and 100, like 10400.
Needless to say, this is a major departure from the more buttoned-down approach to RTM that MS has employed in the past, even with the RTM for Windows 8.1. This points to the new facts of Windows OS release life, in which the target keeps moving and always remains a work in progress (for a fascinating discussion of what this means for OEMs who must track and release systems to run this stuff, see Paul Thurrott’s story “Dell + Windows 10” which dives into some of the elements of making all of this work for customers who buy new Dell PCs for Windows 10, or who seek to upgrade existing systems to Windows 10).
As for myself, I’m particularly curious about how older but still viable systems released with Windows 7 will fare in the brave new Windows 10 world. For example, I have two pretty thoroughly tricked out Sandy Bridge i7 Lenovo notebooks — an X220 Tablet and a T520 notebook, each with 16 GB RAM, a fast mSATA 256 GB SDD, a second 256 GB SSD, and high capacity SDXC cards that remain pretty capable but face an uncertain Win10 future. I’m pretty sure my newer Haswell tablets will do just fine with Windows 10 (Surface Pro 3, i7, 8 GB RAM, 256 GB SSD; Dell Venue 11 Pro 7139, ditto). But it will be interesting to see how well those older systems take to the newest OS, when the upgrade becomes available. Not coincidentally, I’m also curious to see how well the release candidates that will start showing up over the next three weeks will fade into whatever emerges for RTM. Stay tuned: I’ll keep you posted as this all unfolds.
Confounding all expectations, MS followed up the wham, bam sequence of two Windows 10 builds on June 30 (10158) and July 1 (10159) with a third build yesterday (July 2: Build 10162). I’m hopeful this will be all for a while because it’s been time consuming and a bit frustrating to grind through the process so many times and so quickly of late. I always follow a new build with driver updates, which have fortunately been mostly nugatory with this last three builds on both of my test machines, and with image backups for each system which take an average of half-an-hour to complete on each of those systems.
Here we go again: I get mixed results from the install of Build 10162 on my test PCs.
As always, my i7-4770K desktop has been quietly stellar in absorbing the upgrades. I had no trouble with Builds 10158 and 10159 on the Dell Venue 11 Pro, but hit a snag yesterday on 10162. It hung on the download from Windows Update twice, at which point I gave up trying for the day, resolved to try again this morning first thing. I’m not sure if my patience was rewarded, or if the cold start I forced upon the machine did the trick, but the third try may turn out to be the charm for that machine, which is currently 28% through the “Upgrading Windows” process as I’m writing this paragraph, and just successfully rebooted for the second time while working through installation.
So far, I can’t really tell much difference between the three builds. MS claims that each one fixes issues (hundreds of them for each new iteration. Here’s what Gabe Aul of MS has to say about this hurry-up sequence in the latest Blogging Windows post, aptly entitled “Welcome to the faster fast ring!“:
We just released Build 10159 with our new wallpaper and logon UI on Tuesday, but this is a holiday weekend in the US and we thought that some of you might want to get an even fresher build on your PCs to play with over the long weekend. Build 10162 is another great one. In fact, our testing and internal telemetry metrics show it has better reliability, performance, battery life, and compatibility than any Windows 10 Insider Preview build so far.
And now, I have experienced a driver failure on the Dell PC at about 50% complete during installation, so it looks like the Windows Update version of 10162 is not going to work out on this machine. I also lost my touchpad at that point in the process, and had to install an external mouse (a Logitech 325 with external Unifying receiver, which worked immediately, thank goodness) so I’m guessing it’s the driver at fault here. My next move is to download the ISO files for 10162(which MS has already released even though 10162 has yet to hit the slow ring) and see if those don’t do the trick for me on this machine. I don’t relish rebuilding my usual image after a clean install, but that’s the way the Windows mop flops from time to time. Sigh.