Tuesday, May 22, 2012

Icon Not See (Or: Cache Me If You Can)

Background. The other day, my daughter complained to me that her computer screen did not look right. In particular, the icons to Microsoft Office products in her start menu all had the same colorless generic appearance instead of showing distinctly colorful icons for Excel, PowerPoint, Word, and associated Office tools.

Now, my daughter is the perfectionist in our family: she insists that everything be just so. My son and I don't put much stock in fancy appearances as long as the software functions properly, which it apparently did. Just out of curiosity, though, I scoped out my son's machine and confronted the very same problem: his machine also displayed the same drab default icons for all Office menu items. To find the same problem on two different computers was suddenly cause for concern.

At this point, many analysts would immediately advocate re-installing Office to set things right again. To me, however, that is an extreme measure to be used only as a last resort. Instead, I much prefer to find the proximate cause of a problem in the hope that any new-found knowledge will translate into a simpler, more direct solution. The following narrative describes what I found.

1. Insure Icon Files Are In Their Proper Place

Some shortcuts created by Microsoft Windows installer programs have the Target field and the Find Target and Change Icon buttons grayed out when viewing the shortcut's Properties in the Shortcut tab. These shortcuts seem to rely on Class entries in the Registry to locate the icon file and icon number within the icon file. If that icon file is deleted, moved, or that registry entry is changed the shortcut will display the standard broken icon with no easy way to figure out where the problem is or fix it.

For Microsoft Office products, you can use Regedit to search for the files "wordicon.exe," "xlicons.exe," "pptico.exe," "outicon.exe," "accicons.exe," "misc.exe," etc. The purpose is to find the path or folder where Office expects to find these files so that you in turn can insure they are where the registry says they should be.

Searching the registry should lead you to one of the following folders:

Office 2003:
C:\WINDOWS\Installer\{91E30409-6000-11D3-8CFE-0150048383C9}
Office 2007:
C:\Windows\Installer\{90120000-0030-0000-0000-0000000FF1CE}
Office 2010:
C:\Windows\Installer\{90140000-003D-0000-0000-0000000FF1CE}

The folder you want to examine is by default hidden and protected. To reveal the folder so that you can then inspect its contents, you must
  • Open Windows Explorer as administrator
  • Select the "Tools | Folder Options..." menu
  • Select the "View" tab
  • Uncheck the "Hide protected operating system files (Recommended)" option
  • Click the "OK" button to save your selection
Once you have done so, navigate to the folder resulting from your registry search. If the required folder does not exist, then go ahead and manually create it.

My Office 2010 folder included 12 files with extension .exe and one with extension .ico; based on the file names (e.g., accicons, pptico, wordicon, xlicons, etc.) it is clear that the .exe files are indeed icon libraries. [There was also one other misfit file named ShellUI.MST which I ignored with no apparent ill consequences.]

I copied all 13 icon files (that is, everything except ShellUI.MST) to my newly-created folder and returned to the Start menu. Imagine my delight when I saw that all Office menu items now displayed a colorful, meaningful icon without even having to restart the computer. I thought I had solved the problem.

Almost, but not quite. On each or my two children's computers, I have established four separate accounts: one admin account for me and three general accounts: one for my son, one for my daughter, and another one for myself. With four accounts on each of two machines, that totals eight different accounts. Seven of those eight could now successfully view the icons in all Microsoft Office start menu shortcuts.

As luck would have it, it was my fussbudget daughter's account on her own computer that was the one account that still did not display properly. A graphic illustration of Murphy's Law at work.

All was not lost, however: my daughter's account was not a total failure. All of the programs listed in the "Microsoft Office 2010 Tools" sub-menu now displayed meaningful icons, as did OneNote in the main parent menu. Alas: the Big Three of Excel, PowerPoint, and Word all still displayed the dull, drab default icon, not their colorful trademark icon.

I briefly contemplated adding the ShellUI.MST file to the folder C:\Windows\Installer\{90140000-003D-0000-0000-0000000FF1CE} because that file was present in that folder on my own laptop. However, if seven of eight accounts on my children's two computers managed to work perfectly without that file, then its absence was clearly not causing the problem.

2. Chase a Wild Goose

If I were not fortunate enough to have access [pun intended] to the collection of icon files, I would have been compelled to try another alternative that I had read about. I now decided to give that method a try in the hopes that it would fix my one remaining problematic account.

This next measure was intended to be a repair process for broken shortcuts:
  • Open the Microsoft Office Picture Manager (file name: OIS.exe) as administrator
  • Click on the "Help | Detect and Repair..." menus
  • Check the "Restore my shortcuts while repairing" option
  • Click the "Start" button to begin the supposed repair process
When I did this, I waited what seemed like an eternity only to encounter the following error message:
"The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance."
In an attempt to overcome this new hurdle, I opened the Services window [select "Start orb | Control Panel | System and Security | Administrative Tools" and then double-click on "Service"]. Somewhat surprisingly, I found that the "Windows Installer" service was already active. I clicked the "Restart" link just to refresh that service. Still no luck: when I ran the Microsoft Office Picture Manager repair process again, I ran into the same error message as before. To quote the immortal Charlie Brown, "Rats!"

Even though this last tactic failed for me, I offer it to you readers as an option to consider because there were folks posting to on-line forums who reported that the method had worked for them. The more arrows in our quiver the more likely we are to eventually hit our target. And if I had not been fortunate enough to have all of the necessary icon files from a readily available computer with a functioning version of Office, this approach would have taken on greater importance to me.

3. Delete the Offending File

As it was, I now had reached the end of my rope. I had only one more alternative left to try. I felt that any remaining problem had to be related directly to my daughter's local account because all other accounts were now working correctly while only hers failed. After a little more research on Google, I took the following steps:
  • Logged on to my own admin account
  • Opened Windows Explorer
  • Navigated to my daughter's "C:\Users\[daughter's-user-name]\AppData\Local" folder
  • Promptly deleted her "IconCache.db" file
I then logged back on to my daughter's account to see what, if any, effect all my gyrations had produced.

Eureka! In her start menu, links to all Office elements, including the three troublesome programs (Excel, PowerPoint, and Word) now displayed their distinctive icons. Windows had re-generated a new "IconCache.db" file in my daughter's account. All was finally well, at least for the time being. Case closed - hopefully!

4. Prevent a Recurrence (?)

I include that qualification "hopefully" only because I have read numerous reports where this same problem continues to crop up over and over again. To prevent a recurrence, I offer the following recommended solution:
  • Open the registry editor (regedit.exe) as administrator
  • Navigate to the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
  • In the right-hand pane, create a new REG_SZ (string value) called "Max Cached Icons" (omit quotes but include the spaces)
  • Enter a value of 4096 or even 8192. These are values in megabytes (Mb) and should increase the size Windows allows for the icon file from the anemic default of only 500 Mb to whatever larger value you have entered.
I have been fortunate so far in that the problem has not reared its ugly head a second time—yet. While I therefore have not had occasion to personally verify these last few steps, I am fully prepared to give them a try if the need arises. I feel mildly optimistic that these steps should help because Microsoft's own web site http://support.microsoft.com/kb/2396571 prescribes them.

Postscript: Because only three shortcuts remained broken (Excel, PowerPoint, and Word), it would have been a simple enough matter to open Windows Explorer, copy each executable file (Excel.exe, PowerOnt.exe, and WinWord.exe), and paste them as shorcuts to my daughter's individual start menu (as opposed to the "all users" start menu).

However, that is not really solving the basic problem; it is merely sweeping it under the carpet and evading it altogether. What fun would that be???



Make no mistake: this is a cosmetic problem only. It does not seem to affect Office's ability to function properly. Even without the icons present, the software itself seems to work just fine. Both of my children use Office for school at some time or other during virtually every week, so far without incident. However, the missing icons were an irritant I can very well do without.

Allow me one final cautionary note: even though the issue involved is largely cosmetic, there were any number of postings on public forums to the effect that "it sound like your system is corrrupted and that you need to re-install Office or even Windows." Beware of alarmists who pose radical solutions to mundane problems. There almost always will be a solution whose complexity will be more proportional to the nature of the problem. No need to detonate a nuclear warhead just to kill a mosquito.

Having said that, I am still left with at least three nagging unanswered questions:

Lingering Mystery #1: What caused the icon file folder to disappear from my children's laptops while remaining intact on my own Windows 7 laptop? They all have the exact same operating system; were made by the same manufacturer, Toshiba (albeit a different model with a different processor); and more importantly, had the exact same version of Microsoft Office 2010 installed. Indeed, Office was installed on all three machines from the very same CD ROM disk because it was the student version with licenses that allow installation on up to three machines. It so happens that I installed Office first on my machine and then on the machines belonging to my son and daughter. Wild thought: could the footprint left for the second and third installations be not quite *exactly* the same as the installation on the first machine? Pure conjecture on my part, but nothing about Microsoft products would suprise me any more.

Whatever the case may be, you can bet that I have placed those icon files in a single archive (zip) file for storage in a safe place so that if that same folder ever disappears again, I am sure to have the necessary files readily available.

Lingering Mystery #2: Why did restoring the missing folder with icon archive files fix seven of eight account but only partially repair the eighth? Even within my daughter's computer, the shortcut links are posted to a folder path available to all users; why do three user accounts see the link properly while my daughter's account cannot properly view that same shared link? What caused her "IconCache.db" file to misbehave so badly?

Lingering Mystery #3: Why did the Microsoft Office Picture Manager repair process fail so miserably? I could not get that to work even after I repaired all of my daughter's icons.

There you have it: as is so often the case with Microsoft products, I began with one single problem, and even though I eventually resolved that issue, doing so spawned three more unanswered questions. About par for Microsoft's course.

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???