Burned by Acrobat and Windows Update…on the same day!

I’m starting to hate Windows Update. No matter how many times I try to disable the Automatic Updates feature it somehow manages to re-enable itself, often with disastrous results.

Case in point: This week’s “Patch Tuesday” batch of updates for Server 2008. I went to manually check for the updates and force a download only to discover that they were already 95% complete – this despite the fact that I had very deliberately disabled Automatic Updates when I first installed Server 2008 as a “Workstation” OS. Worse still, once the download had completed I started getting those “nag” screens about how I needed to reboot my PC, etc., to complete the updates.

Since I was in the middle of working on something, I clicked the “Postpone” button. When the “nag” screen appeared again, I reset the “Reminder” interval to 4 hours (the default is 10 minutes) and again clicked the “Postpone” button. I figured by then I’d be done with my day (it was already late evening) at which point the system-initiated reboot could proceed unhindered by my constant interference.

Unfortunately, I never got the chance to execute my plan. A few minutes after clicking the “Postpone” button a second time, Windows decided that enough was enough and proceeded forcibly reboot my system without my consent – this despite the fact that I was still actively typing at the keyboard! I was left to watch helplessly as my unfinished web posting disappeared in a blur of closing windows and fading UI effects.

After a longer-than-usual boot cycle (due to the large number of updates being applied), I finally got to log back in and assess the damage. To its credit, Windows tried to ease the pain by re-opening some of the applications that had been running before it so rudely intervened. However, nothing could bring-back my now vaporized web posting. I then checked my system’s Windows Update settings and, lo and behold, it had been reset to Automatic again. I’ve since disabled the entire Windows Update service in Control Panel. I can only hope that’ll be enough to slay this monster once and for all.

They say that calamities travel in packs, so it was no real surprise when, shortly after my system was forcibly rebooted, it hung solid. The culprit: Adobe Acrobat Reader. I had noticed for some time that, whenever I opened a PDF file, my mouse pointer would mysteriously “disappear,” only to “reappear” just as mysteriously a few seconds later. I chalked it up to some minor flakiness in Adobe’s rendering engine. The bug seemed harmless enough – until I made the mistake of actually moving my mouse to try and resurrect the pointer.

Suffice to say that Windows Server 2008 hung-up quite nicely at that point. In addition to the missing pointer, my keyboard was now dead. I tried disconnecting/reconnecting the mouse dongle (I use a Microsoft Wireless Notebook Laser Mouse 7000), pressing CTRL-ALT-DEL, the works. I finally realized that I was in fact screwed when the system’s “soft” power button didn’t respond (normally it should trigger a graceful shutdown). I ended up having to execute the infamous “ACPI override” technique (hold down the power button for 5 seconds or more) in order kill the beast.

My next stop – after waiting through another painful Windows reboot cycle – was Google. A quick search on the term “Adobe Acrobat disappearing cursor” brought up a host of message board complaints about this very same phenomenon: The cursor going missing during PDF loading, and sometimes never coming back, leaving the user with a locked-up desktop.

I’d like to assign sole blame to Adobe for the bug (I’ve since dumped Reader in favor of Foxit’s free alternative), but the fact is that no application should be able to lock-up the Windows desktop in this fashion – at least not since the mass migration from DOS/Windows to the Windows NT code base. As those familiar with early NT design parameters will attest, a major robustness selling point was the introduction of asynchronous, per-process input queues for mouse and keyboard I/O. In fact, this was one of the marketing bullets used by Microsoft when pitching NT as a competitor to OS/2. The latter used a shared input queue model that was susceptible to lockups from a misbehaved application. NT’s model was more reliable, though it did wreck havoc with window focus assignment in certain instances.

Frankly, I thought we were beyond this sort of thing with Windows. However, given the amount of “kludging” that’s gone into the code base since Microsoft “unified” its desktop offerings under Windows XP, I wouldn’t be surprised if they compromised this feature in the name of some consumer-focused requirement, like improving video game input throughput under DirectX.

Regardless, it’s sad to see my once robust NT reduced to a quivering mass of bloated Vista hacks and compromises. And since I normally run Windows Server 2008 as my desktop, this latest crash does not bode well for Microsoft’s enterprise reputation. After all, nobody should be able to take-down a multi-million dollar server farm simply by loading a PDF document at the system console.