Terrible Tuesday

Microsoft publishes updates to its Windows operating systems on the second Tuesday of every month. I have only half-facetiously been calling that day "Terrible Tuesday," but this past Tuesday (8 May 2012) was far worse than most. I encountered not one, not two, but four updates that would not install: one to Silverlight and three to .NET Framework 4.

As is so typical of Windows 7, in the course of researching fixes to those two problems [I consider the Silverlight and .NET problems as separate because their solutions were radically different], I encountered a third: I could not access or open the Event Viewer log window, open the Services window, or perform some several other related Windows functions even when I logged on to my admin account.

I will address these issues one by one. I will not regale you with any of the procedures that I tried but which ultimately failed. There is often some learning value even with failed attempts, but in the interest of keeping this post to a manageable length, I will forgo describing those unsuccessful efforts and limit my description only to what worked.

Finally, be aware that the problems I describe occurred only on my children's Windows 7 laptops. The updates all went smoothly on my ancient workhorse desktop running Windows XP. And for reasons that I still have not figured out, they also went smoothly on my own Windows 7 laptop. Go figure.

1. Event Viewer Window Failed To Open

On the second Tuesday in May 2012, Silverlight and .NET Framework 4 updates failed to install during Microsoft's monthly update process. My first thought was to open the Event Log to see whatever warning and/or error messages might be present on my computer to help me diagnose the problem.

[Note: in order to open [or attempt to open] the event log, click the sequence "Start orb | Control Panel" and then the link "View event logs" immediately under the "Administrative Tools" label.]

If your "Event Viewer" window opens successfully, you are good to go. Unfortunately for me, the Event Log would not open at all. Instead, I encountered the following error message:

"Event Log Service is unavailable. Verify that the service is running."

"No big deal," I thought to myself. "I'll just open the Services window and re-start the Event Log Service."

[Note: To open the Services window, it is necessary to click "Start orb | Control Panel | System and Security | Administrative Tools" and then double-click the link to "Services" in the right-hand panel.]

When I did that, I encountered more failure. Now my error message read as follows:

"Windows could not start the Windows Event Log service on Local Computer.
Error 4201: the instance name passed was not recognized as valid by a WMI data provider."

I was clearly stuck: I could not perform basic functions that any system administrator should be able to.

I immediately suspected that this problem was a self-inflicted wound. A week or two before, I attempted to copy the Windows folder contents onto my external hard drive for backup using the old tried-and-true drag-and-drop method in Windows Explorer. After a significant amount of time, the process finally ended but with precious few files and folders actually copied.

After repeated failed attempts and out of sheer frustration, I impulsively seized control of the "Windows" folder under my own administrative user name. Bingo! I was finally able to copy all the Windows folder files and sub-folders to my external hard drive for backup.

I naïvely thought all was well. Wrong! The Event Log problem and the Services functional problems [and who know what else!] were lurking beneath the surface. How to fix them?

The short answer: insure that the "SYSTEM" entity is included in the "Groups or user names" field in the Security tab of the Property window for the following folder:

"C:\Windows\System32\LogFiles\WMI\RtBackup"

I know what you're probably thinking: if that is the short answer, you'd hate to see the long answer. Yes, that was a mouthful, but bear with me just a bit longer.

I actually found two methods to accomplish this objective. The first method I am about to describe should more clearly illuminate the long-winded statement I made above:

• In Windows Explorer, navigate your way to the folder "C:\Windows\System32\LogFiles\WMI\RtBackup"
• Right-click on the folder and select the "Properties" menu at the very bottom
• In the resulting window, select the Security tab
• Click the "Edit..." button
• In the resulting "Permissions for RtBackup" window, click the "Add..." button
• In the resulting window, type the word "SYSTEM" (without quotation marks) into the field that says "Enter the object names to select (examples):"
• Click the "OK" button
• You will now be back in the "Permissions for RtBackup" window. Make sure that "SYSTEM" is selected in the "Group or user name" field. The bottom field should be labeled "Permissions for SYSTEM." If it is not already checked by default, click on the "Full control" option.
• Click the "OK" button to save your new settings

You should now be back in the "Security" tab of the "RtBackup Properties" window. An entry for "SYSTEM" should now appear among the groups and user names listed in the top field, and if you select that "SYSTEM" entry, all options associated with full control should now be checked in the "Permissions for SYSTEM" window.

The second and much easier method: simply delete the folder

"C:\Windows\System32\LogFiles\WMI\RtBackup"

altogether and restart your machine.

As an alternative, if you are like me and are hesitant to delete system folders, simply rename the folder to something like

"C:\Windows\System32\LogFiles\WMI\RtBackup_original"

and then restart.

With either approach, when you restart your computer, Windows will re-create the missing folder and magically include the requisite "SYSTEM" entity among the groups and users along with the appropriate permissions.

You will now be able to open both the Event Log and the Services window. All this work just to overcome the first hurdle of three. But don't stop now: there's more fun to come...

2. All .NET Framework 4 Updates Failed

This actually turned out to be the easiest problem both to diagnose and to fix. To make a long story short, here are the steps to take:

• Click "Start orb | Control Panel | Programs | Programs and Features"
• In the resulting "Uninstall or change a program" window, select "Microsoft .NET Framework 4 Client Profile" from listed programs
• Click the "Uninstall/Change" label at the top of the listed programs
• Select the option "Repair .NET Framework 4 Client Profile to its original state"
• Click the "Next" button and proceed with the repair

Eureka! When I returned to Windows Update and tried again, the three updates involving .NET Framework 4 succeeded.

On the down side, I had to also install four additional updates to .NET Framework 4. My guess is that "Repair .... to its original state" is a euphemism for something akin to a fresh re-install. That might explain why I had to install seven total updates instead of just the three I was expecting.

Whatever the case, this repair process worked for the .NET updates—but it failed miserably for Silverlight.

3. Silverlight Update Failed

The repair process that worked so nicely for .NET did not work at all for Silverlight largely because there was no "Repair" option available in the program list. The label said only "Uninstall" and not "Uninstall/Change." I was hesitant to completely uninstall Silverlight even if it was slightly outdated. I was fearful that if I could not re-install Silverlight, I would then be left without any functioning program at all.

But when I tried installing the new version over the old, I received the following error message:

"The feature you are trying to use is on a network resource that is unavailable. ...
[E]nter an alternate path to a folder containing the installation package 'silverlight.msi' in the box below."

It turns out that the procedure I finally used was even more radical. In Windows Explorer, I right-clicked on the file "C:\Windows\System32\regedit.exe" and selected the option "Run as administrator." I then navigated my way to the following registry key

"HKEY_CLASSES_ROOT\Installer\Products\
D7314F9862C648A4DB8BE2A5B47BE100"

—and then promptly deleted that entire key!

I had previously downloaded what I thought was the Silverlight installation file (Silverlight.exe) from Microsoft's web site http://www.microsoft.com/silverlight/. It was in fact the installation file, but not in the way that it first appeared.

I had read on Google that the Silverlight.exe file I downloaded was actually an archive file consisting of several different individual files. Sure enough, opening "Silverlight.exe" with WinZip, 7-Zip, IZArc, or any other archive program revealed four separate files within, one of which was named "silverlight.msi." Many of you will recognize the extension ".msi" as shorthand for "Microsoft installer." I then extracted the files to a folder on my hard drive and double-clicked on silverlight.msi.

Hallelujah! This installation process, coming as it did after deleting the registry key, successfully ran to completion. As with the .NET update, I had to install not only the update that highlighted the problem in the first place but another one as well.

Unresolved Questions

One small question that lingers in my mind: would double-clicking directly on the "Silverlight.exe" file I downloaded have worked just as well? That would have saved me the drill of extracting the four component files. If I am ever confronted with the same situation again, I will certainly give that a try first.

A second and more important question: could I have used the "Uninstall" option in the "Uninstall or change a program" window? I vaguely recollect that I tried and that the attempt failed. However, I neglected to write down any resulting error message, so I cannot be absolutely certain. At that point, I was juggling several balls in the air at the same time, and I guess I took my eye off one of them for a moment.

After the dust settled and Silverlight was finally working once again, I actually contemplated experimenting with the uninstall process—for a fleeting second. After all I had gone through to finally get Silverlight to work, I chickened out and chose to leave well enough alone.

However, you can bet that if this situation ever arises again, especially with Silverlight, I'll give "uninstall" a whirl first before I go mucking around in the registry again. If the "uninstall" works for you, then more power to you. If not, at least you now have another alternative that should work.

Final Thoughts

I have been a long-time critic of Microsoft and Windows, and these examples merely reinforce my inclinations. Why can Microsoft not even make functional updates to its own software (e.g., Silverlight and .NET) on its own latest-and-greatest operating system (i.e., Windows 7 Professional 64-bit)? I deeply resent having to squander so much of my own time and effort researching and resolving problems that just should not exist in the first place.

And if I were not already so angry, I might have laughed at some of the on-line forums where Microsoft's own technicians said several times: "Try this solution; if that doesn't work, try this second solution; and if they both fail, try third-party software."

Third party software? Microsoft unable to fix its own defective products? As Chatsworth Osborne Jr. so astutely observed on the old The Many Loves of Dobie Gillis TV show, "Surely you jest!"

---

And for all of you hardy souls who stuck with this narrative to the bitter end, I now ask you: do you begin to understand a little bit why I refer to it as Terrible Tuesday???