Unauthorized Changes to Windows 7 Automatic Update Settings

It's happened again.  Periodically, and it's not often, but often enough to be memorable, Windows Update decides to reset the settings from "Download updates but let me choose whether to install them" to "Install Updates Automatically (recommended)."  Yes, I understand the risks;  Microsoft may have detected a flaw that needs urgent patching.  My machine is vulnerable until I get around to launching the update. But what I'm consciously trading off is productivity.  What's lost is a complex desktop of settings --with Office applications, browser windows and specialized applications in particular states not easily reconstructed.  It takes 30-45 minutes to restore the desktop back to something resembling its previous state -- and sometimes that isn't feasible due to the dynamic nature of the applications and associated web content.


When researching this on previous occasions, I recall that Microsoft insisted that users must have been changing other settings.  This was certainly not the case here.  And there was no message from Windows Update to be responded to, and the machine was left in an idle state overnight.   No scripts were scheduled.  There should have been little unscheduled activity other than backup scripts running on servers, and those backup scripts do not touch local drives.


I acknowledge that Windows Update is a complex beast and that sorting out dependencies and update sequencing is anything but trivial.  Based on previous responses, I don't expect a solution, only denials.  But I thought I'd post this message so that you know you're not imagining that the settings "changed themselves" again.


24-MAR-2011 Happened again on today's updates to Windows 2008 Standard.

MS05-051 "broke" Vista: HRESULT was 8007043c eventsystemobj.cpp

I pride myself on keeping my most critical Vista box well patched and happy (from a Microsoft point of view). I plan to use Vista for many years -- I even bought the "retail" version.

Imagine my surprise when I noticed that it was no longer accepting peer to peer network connections. "Hmm, I guess I'll try rebooting," I frowned. But Mr. Ultimate Vista refused to start up. It displayed the Vista logo, then, without any message or notice, rebooted itself again. This would have gone on indefinitely if I had not intervened.

I booted into safe mode, (luckily that worked!) looked at the System log (not a minor accomplishment, since some of the other log flavors were not viewable due to "could not connect" errors). The error that got my attention was "The COM+ Event System detected a bad return code during its internal processing. HRESULT was 8007043c from line 45 of d:\rtm\com\complus\src\events\tier1\eventsystemobj.cpp." And a probably related message, "System log:The following boot-start or system-start driver(s) failed to load: ACPIaswSPspldrWanarpv6." Deeper frown.

I looked at the Reliability Monitor, and it showed nothing unusual for the past couple of months.

A TechNet forum post suggested a closer look at the Microsoft KB entry that is the title of this post. In short, the problem is with permissions policies -- apparently some critical Windows applications were locked out from the Registration directory.

This is an understandable "bug." What is less understandable is how this problem escaped the automated test tool sniffers one imagines that Microsoft has at its disposal. After all, the easiest problem for a test script to detect is a boot failure.

Before the era of web- or email-enabled newsgroup / forum posts, my system could have been down for days as I sorted this out.

One other thing: the Microsoft warrantee for Vista is 90 days after it's activated.