I’m always curious when Microsoft lets another OOB update loose (OOB = out-of-band–that is, a non-Patch Tuesday update release, this time on 5/25/2011, when the company let slip KB2541014). This time, the affected software item is for the Diskdump.sys file that manages data capture whenever a kernel mode error occurs on a Windows machine. It apparently occurs on PCs that use the SCSI miniport device–a Microsoft-supplied driver that defines the interface between a SCSI miniport driver and the OS–that have trouble hibernating (their machines restart instead of going into the deepest sleep mode defined for Windows) or that fail to write a memory dump file (either to the minidump or a full-blown memory dump file) when Windows 7 experiences a kernel mode error.
Should you be concerned about this? Surprisingly the answer is “Yes,” even if your systems aren’t experiencing the problems this update is supposed to address. As it happens, many storage devices–including SSDs, USB flash drives, network storage devices, and even conventional SATA or IDE hard disks–actually include Plug and Play SCSI Miniport drivers among their Host Bus Adapter capabilities. This could be one of those surprising updates that might (or might not) cause heartburn on end-user machines. A little time with this puppy in the test lab on standard configurations is probably in order. So far, all of my test machines appear to be working OK in the wake of the update, but you can’t know about yours until you try it out in the lab.
OK, so midnight last night was the culmination of a huge project I’ve been devoting nearly every waking hour to for the past 15 days (yes, you read right: 10-plus hours a day for over two weeks). And indeed, midnight last night was also when we finally put the document that resulted from those mighty labors to bed, and called it a very late night. I hit my desk at 6 AM yesterday, so when midnight rolled around I was more than ready to crash.
And, as Murphy would have it no other way, yesterday was the day that gremlins of nearly every possible description came calling, just to make the final rough slog to completion all the more “interesting.” Here’s a list of the things that I had to deal with while already overly occupied with getting things done:
- The report that represented the fruits of my labor was in MS Word, and a draft was being passed around among a half-dozen reviewers for comments, changes, word-smithing, and so forth. It was also around 100 pages long. Man, do big Word docs with lots of revisions and “Track Changes” turned on get flaky in a hurry! Reformatting and messing with formatting weirdness consumed too much of the day yesterday.
- Members of the team were working from San Diego, Philadelphia, Pittsburgh, Houston, Salt Lake City, and Round Rock (me and Kim, my invaluable project manager and yesterday’s document coordinator). E-mail was our preferred means of communication. Wouldn’t you know it? My e-mail service provider was up and down like a yo-yo yesterday. Not only that, but I started my day with the realization that Yahoo had changed its e-mail service substantially enough that my forward from them to my spam filtering service (my primary e-mail address is at Yahoo, and I filter all of my half-dozen or so e-mail addresses through the spam filtering service for delivery to my Outlook inbox) quit working. What with all this e-mail hoopla I found myself behind the 8-ball on at least four occasions yesterday.
- Just to make things more maddening I also learned the symptoms of a loose DVI video connection on my secondary monitor yesterday. I’d been messing with my production desktop and hadn’t tightened down the screws on the DVI connector all the way into the graphics card. Sure enough, my monitor starting blinking on and off rapidly and repeatedly on several occasions. I’ve long since learned that color weirdness is the symptom of a loose VGA connector, but Murphy made sure I learned the equivalent DVI lesson yesterday — the hard way, too, of course.
Sigh. It’s enough to make you hate big hairy deadlines even more than your natural inclination might cause you to do. But now, at least, that big hairy deadline has come and gone, and things can get back to what passes for “normal” around here. Thank goodness!
On May 6 I posted a blog entitled “Windows Hardware Problem Fixed: Mystery Started” that recounts my problems with the fingerprint scanner on my HP dv6t-2300 notebook PC. In that posting, I reported that my problems were fixed by the latest round of additions to Windows Update. And indeed, that’s exactly how things looked until I took my notebook on the road for a business trip this week.
The issue with the device going off-line when the unit goes to sleep is definitely resolved. But that issue remains present when the unit hibernates. Upon its wake-up (and all subsequent wake-ups) from hibernation, the fingerprint scanner fails to be detected when Windows does device enumeration during boot-up. The only way for me to regain access to the device after that is to restart it, or to shut it down all the way, after which the device does get detected the next time I boot up the machine.
So clearly, the issue is with what happens to the driver when the device hibernates. I can live with this situation, because when I’m on wall socket power in the office using that machine, it’s set not to hibernate. Hibernation only kicks in when the unit is running off battery, as a default setting in the HP Recommended power management scheme for that machine.
It just goes to show you that not all apparent fixes are what they seem. I’d hoped all my issues with the driver for that VFS301 fingerprint sensor from Validity Sensors were over and done with, but apparently HP, Validity Sensors, or whoever’s responsible for making sure devices show up after hibernation during device enumeration, still have some work to do. But that’s life in the Windows trenches. If and when I find a fix, I’ll report back.
After the burgeoning baskets of security updates for the previous two Patch Tuesdays, May’s collection comes as something of a welcome relief. There are really only two ( or perhaps five) updates that are truly worthy of note, as this Executive Summary table from the May 2011 Microsoft Security Bulletin illustrates:
I learned about items numbered three through five from Ed Bott’s ZDNet blog for today “Patch Tuesday fixes a trio of Windows 7 SP1 glitches,” wherein he recounts that another couple of the updates in today’s collection help to address SP1 installation errors for Windows 7 and Windows Server 2008 R2 (KB2534366 and KB2533552). He also discusses KB2529072, which deals with a failure on Windows’ part to update binary files for some USB drivers after installing Windows 7 SP1 or Windows Server 2008 R2 SP1. The first two won’t have any impact except on systems where installation issues related to the specific error codes in those two KB articles come into play. The third applies when USB speeds drop down from 2.0 to 1.1 levels following an SP1 installation. And of course there were some additional customary elements, including the monthly update to the Outlook Junk Mail filter, and a May 2011 edition of the Windows Malicious Software Removal Tool.
It’s nice to have Patch Tuesday come and go without a major influx of patches and updates for a change. Enjoy the lull: it can’t last!
On April 27, I mentioned one particular update as of great interest in the “Second Patch Tuesday” for that month. It appears in that blog as Item 7: “KB2515325: Windows Explorer may crash in Win7 or WinServ2008 R2.” I go on to comment about this update as follows:
I sincerely hope this update will solve those problems (which also include a refusal to update the display, even with a forced View refresh, when adding or renaming files and folders in some situations) and improve my only lingering Windows 7 system issue on those PCs. I’m going to keep an eagle eye on this, and remain optimistic, and plan to report on those observations in a week or so.
The week is up (and more, actually: it’s been 12 days since 4/27 when I wrote those words) and I’m very pleased to say that all of my reported problems with Windows Explorer have vanished in the wake of this update. I’d really only noticed all of them on one machine (my 32-bit Windows 7 Professional installation on my production machine), but had also noticed the display update issue on folder changes or additions on a couple of other x64 installations as well. As of this morning, despite repeated attempts to recreate the problem on all of these machines, none of them is misbehaving as it was before the KB2515325 fix came along. What a relief!
Although working with Windows always involves vexations of one kind or another, it’s heart-warming to see a nagging problem finally fixed. Troubleshooting the Explorer environment is pretty darn difficult, as I’ve learned when trying to identify and extirpate misbehaving Windows Explorer plugins, even with the help of Nir Sofer’s excellent ShellExView program. It’s great that MS finally got this issue fixed, and to see Windows Explorer working properly again. I repeat: what a relief! Working around the previous problems meant navigating up and down the folder hierarchy just to see changes made (or folders added) within a drive or folder. Now, everything’s updating just as it should be.
Last February or March (2010) I purchased very nice HP notebook PC for about $1,100: it’s a dvtt-2300 CTO Entertainment Notebook PC with a Mobile i7 Quad-core processor (720QM 1.6 GHz), 6 GB RAM, nVidia GeForce GT 320M graphics, and a 7,200 RPM 500 GB hard disk.
This unit also includes a USB-attached fingerprint scanner made by Validity Sensors, Inc. model VFS301. Ever since I bought this notebook, and despite several calls to HP Support early on after I’d purchased it, the fingerprint sensor has failed to “report in” every third time I start the machine up from a sleep or hibernation state. Following resumption of activity, the notebook would inform me on those occasions that it failed to detect the fingerprint scanner, and thus, that it could not be used. Every time, that is, until I installed the latest round of Patch Tuesday updates. Then the problem went away.
At first, I thought there might have been a driver update that snuck past me for the device. Nope. The driver date is 5/4/2009. Because it’s connected via USB, I next checked to see if any USB drivers had been updated. Nix: all those drivers predate the release date for Windows 7. Sleep and hibernation fall under the control of ACPI, so I checked to see if any of those drivers had changed, either. Nada. Same 6/21/2006 date as for USB (probably associated with Windows Vista).
So why did something that was working hit-or-miss all of a sudden start working without a hitch? It’s been 10 days now since the second round of updates for April hit that machine (released 4/26, updated on 4/27 on the dv6t) and not once has the fingerprint scanner gone missing at boot-up or upon wake-up from sleep mode. As far as I can tell, the only possible culprit is Update for Windows 7 (KB2492386) another of the legion of poorly documented (read the Knowledge Base article, if you think you can read between the lines better than I can) Application Compatibility Updates that Microsoft occasionally releases.
You’re probably wondering why I bothered to dig into something that fixed a problem rather than causing one. Surely, that’s reason for rejoicing, rather than investigation? I can’t help it, I’m terminally curious about what causes changes in the behavior of my systems. I’m just as intrigued (and a little bit piqued) to have a problem fixed mysteriously as I am to have a new problem show up on one or more of my systems. If anybody else has other ideas on what might have changed the fingerprint scanner from occasional bad boy to good to go, I’d sure like to hear them. Please comment!
OK, so I’ve been slowly rotating my Windows 7 PCs (of which I currently have 7 at my disposal) from IE 8 to IE 9, thanks mostly to the elevation in status at Windows Update from optional, manual update to automatic or pushed update. By and large, this transition has gone reasonably well, but I do still have some gotchas with WordPress to contend with (I blog 40-plus times per month, of which only 4 or 5 posts occur outside the nearly-ubiquitous WordPress umbrella — in fact, I’m writing this very blog using WordPress right now).
I’m also writing it using Chrome 11.0.696.60, because IE 9 remains unusable with this software. Why? Simply put, the cursor based button controls don’t work, and thus I can’t insert hyperlinks into my posts unless I decide to edit the HTML by hand (insert explicit <a href=”link” …> markup myself, in other words — not gonna happen: I *like* automation). So while I’m waiting for the powers that be to figure out what’s up and how to fix it, I’m using Chrome. And I must say, it’s doing its job quite nicely.
But the other day, when I applied the most recent Patch Tuesday updates to a machine that had been sitting idle for a while, I found myself in an infinite loop situation with IE 9. When you install a new IE version over an old one (this time it was going from IE 8 to IE 9), it copies the old preferences, favorites, and other settings from the old version to the new as part of the upgrade. I’m loaning out my old HP “Dragon” to a pool-playing buddy and I was updating that machine to the latest and greatest of everything. But when that process completed, and I tried to run IE 9 for the first time, something about tht install caused the browser to crash every time it tried to load the default home page for the Google search engine at www.google.com.
IE 9 tries to automatically recover when such things happen, so it closed the open (and only window), then tried to reload the Google page again, only to crash again. Repeat ad infinitum, and ad nauseum. The only way I was able to stop the madness was to jump into task manager and kill all active iexplore.exe processes.
Fixing the problem required some interesting contortions, too. I had to jump onto another machine and download a standalone browser installer for the Dragon because it had no working Web browser installed (IE 9 remained hosed, and I had just cleaned all the extraneous software off that machine for my buddy, so he could gunk it up however he chose). I couldn’t get the Chrome standalone installer to work on that machine, so I ended up using Opera instead. It let me visit the Microsoft Download Center where I grabbed a clean download for 64- and 32-bit IE 9, believing that something was wrong with the install that Windows Update left on my machine.
However, Windows detected that IE 9 was already installed on my PC, and wouldn’t let me install the older Download Center version on top of the newer but non-operational version. So I had to go into the Programs and Features widget in control panel, then use the “Turn Windows features on or off” to disable IE 9. After a reboot, I was then able to successfully install the Download Center version, and re-apply the now-missing updates from Windows Update between the release of the initial version and its current state. No more issues with loading the Google search page, and finally back to IE 9 status quo, such as it is.
My point here is that you are still likely to encounter the occasional gotcha with IE 9 in your users’ desktop environments. I have to agree with Windows mavens like Ed Bott and Paul Thurrott, both of whom still recommend that enterprises hold off on IE 9 upgrades until the program settles down a bit more, and gets additional bugs shaken out. At the very least, you’ll want to test your user runtime environments long and hard, and make sure IE 9 survives those tests gotcha-free, before inflicting the latest Internet Explorer version on your user community. Otherwise, you’ll just wind up making more work for yourself in the long run (and for your hapless help desk counterparts).
Unisys VP Sam Gross has been in the news quite a bit lately since he posted a blog last week (April 28, last Thursday) entitled Busting Windows 7 Migration Myths. His reports on a recent Unisys customer survey indicate that more than twice as many respondents (53%) either “haven’t started” or are “not migrating” to Windows 7, as compared to those who are currently migrating to the newest Windows desktop OS (21%). It’s not clear if that means the remaining 26% not covered in those categories have already migrated, but I suspect that’s the case as that number squares with other reports on Windows 7 migration rates in the business community.
Some analysts and commentators have taken this report as evidence of pique from Unisys — a major Microsoft partner, and one heavily involved in business computing services, including numerous high-profile, large-scale upgrades to Windows 7 — but I’m not sure that’s really what’s going on here. In this blog posting, Gross goes on to recount five myths about Windows 7 migration that he and his team have undoubtedly encountered in selling and delivering their services to the business marketplace. These not only make interesting reading, but they also point to a situation that spells increasing interest and unbridled optimism about what Windows 7 can do for enterprise networks:
- Businesses begin with an accurate sense of migration scope. Gross quickly debunks this myth, and recommends that organizations spend up to 3 months conducting an in-depth inventory “that includes all the hardware and software that touch the desktop.” He also recommends upgrading “high-dependency apps prio to the migration,” with “sufficient time to test applications prior to rollout.”
- Windows 7 fits seamlessly into current desktop architectures. Any time a new OS hits the network, it’s necessary to “…verify compatibility, and upgrade or replace aging or outdated components…” and to “…add network capacity as needed.” I agree with his observation that desktop infrastructure always needs work when a new OS hits the network, its servers, and support and management tools involved.
- Windows 7 extends the life of current PCs. Maybe, but not necessarily a good idea! Extending the life of older PC hardware can increase TCO, according to Gross, and fails to enable organizations to exploit newer graphics hardware, higher RAM capacities, faster, bigger disks, and faster CPUs to boost productivity. His advice: “Be sure to build time and cost into your migration project plan to allow for hardware refreshes.”
- Migrating to Windows 7 automatically lowers IT costs. Sure, Windows 7 can “…improve efficiencies and cut computing costs,” as Gross observes, but that doesn’t translate into reduced IT overhead and costs unless the entire infrastructure is upgraded along with the OS, and that takes time and effort, and costs money, too. Processes and procedures often must also be tweaked (and carefully monitored) to maximise efficiency and productivity. There’s nothing automatic about any of these things: hard work, careful planning and deployment, and ongoing maintenance are all required.
- Windows 7 automatically reduces the management burden. The OS does not manage a desktop environment for or by itself. A migration can (and should) provide an opportunity to rethink and rebuild desktop infrastructure to make desktops more standardized and more manageable, but here again, there’s a lot of time, effort, thought, planning, and investment involved in getting things right. Nothing automatic here, either.
To those who say Gross sounds unhappy with the rate of Windows 7 adoptions, I say “bunk!” His blog, and the Unisys business plan, read a lot more like a savvy, experienced IT services company trying to cultivate more business, than a complaint against slow Windows 7 migration at the enterprise level. Trust me: It’s not a problem, it’s a real opportunity, and one that I believe Unisys wants to ride to improved financial results.
Lots of IT professionals have been wondering about the footprint and capabilities of the Windows Thin PC product that Microsoft released for a community technology preview (CTP) in March, 2011. The stated goal of this Windows OS is to enable older and less capable PCs to enjoy and use Windows 7 core features, so that frugal organizations and companies can convert existing PCs into thin clients running a stripped down version of Windows 7.
When I’d read about this technology, I’d hoped it might mean older PCs with less than 1 GB of RAM, or older and slower single-core CPUs, might be able to tune into this Windows 7 version. Alas, Andrew Cunningham’s review “Windows Thin PC: Windows, Slimmed Down” puts paid to any such foolish notions. System requirements for Windows Thin PC are identical to those for all other Windows 7 versions (as shown in this table from his article):
“What’s the appeal for this product?” is something readers may be wondering at this point. Windows Thin PC (which I’ll abbreviate as WTPC henceforth) lets businesses use all the MS goodies they’ve got seamlessly, such as the typical combination of AD, private Windows Update servers, image creation and deployment tools, and group policy objects to define, update, manage and secure these clients the same way they handle all their other desktops. WTPC also works with the latest version of Remote Desktop, including those available on Windows Server 2008 R2 boxes running SP1. WTPC even includes a special Enhanced Write Filter that prevents end users from changing their OSes permanently, thanks to storing all such changes in a partition separate from the base Windows OS partition.
On the plus side, WTPC is supposed to become available to MS volume license customers for about $100 per copy per year. On the minus side, it will only be made available through a VPA or other similar legal scaffolding, and not through normal retail or OEM channels. Cunningham’s article also performs a detailed analysis of WTPC resource consumption, including RAM (505 MB versus 621 MB for Win7 Ultimate), disk space (2.7 GB on disk vs. 8.64 GB for Win7 Ultimate), but with no real change in base-level performance. And other than some Microsoft programs and utilities (which detect the OS and inform users that they are not compatible with WTPC) Cunningham was able to install and use a wide variety of third-party programs on a machine running WTPC as well.
What does this mean for enterprise use of WTPC? It may give older hardware a longer lifecycle thanks to an ability to run the new OS on older gear, but it reminds of Perry the Platypus on Disney’s “Phineas and Ferb” (“They don’t do much, you know…). Except in situations where there is both the need and the desire to keep using old PCs, I don’t see much business application for this technology.
As I was poking about for a topic for today’s blog, I stumbled across Ed Bott’s ZDNet posting from yesterday entitled “The other Patch Tuesday brings crucial fixes for Windows.” I’d already noticed a login prompt when I sat down at my production PC this morning, and had wondered if MS had pushed some out-of-cycle updates out the door yesterday. Indeed, they had. What I didn’t notice (but confirmed through careful perusal of my Windows Update history over the past year) is that Bott’s observation that Microsoft seems to be getting into a twice-a-month Tuesday push on the 2nd and 4th Tuesdays of the month is right on the money. I guess that means it’s really a “Patch Tuesday Twofer regime” these days, rather than a single Patch Tuesday as Microsoft has sometimes proclaimed to be the case.
Here’s what hit my machine this morning, straight from the Windows Update history page:
Here’s more information on the items involved:
1. Microsoft Keyboard: an update to Intelli-Type showed up, along with more typical Patch Tuesday stuff.
2. KB2492386: Application Compatibility Update for XP, WinServ03, Vista, WinServ08, Win7, and WinServ08 R2
3. KB2506928: A link in an HTML file opened in Outlook doesn’t work in Win7 or WinServ08 R2
4. KB982018: Improve compatibility with Advanced Format Disks for Win7 and WinServ08 R2 (4KB sectors)
5. KB2522422: Cannot print from IE9 using some Canon printers
6. KB890830: Update to MS Windows Malicious Software Removal Tool
7. KB2515325: Windows Explorer may crash in Win7 or WinServ2008 R2
I’m not really too sure about Items 1-6 in the preceding list as to their urgency for an out-of-cycle update, but I’ve been struggling with Windows Explorer weirdness on several of my Windows 7 machines for the past 2-3 months. I sincerely hope this update will solve those problems (which also include a refusal to update the display, even with a forced View refresh, when adding or renaming files and folders in some situations) and improve my only lingering Windows 7 system issue on those PCs. I’m going to keep an eagle eye on this, and remain optimistic, and plan to report on those observations in a week or so. Number 7 in particular bears hard scrutiny and roll-out testing potential, prior to the next Patch Tuesday on May 10th, IMHO.