The case of the slow font drop-down in Microsoft Word
A couple of staff recently reported that they were experiencing an odd problem in Microsoft Word 2010. Whenever they tried to open the font drop-down to pick a new font, there was a frustrating delay of about 5-10 seconds between clicking on the drop-down and the drop-down opening, during which time Word would not respond to any user input.
During this time, the drop-down itself would either be invisible apart from the Aero shadow effect, or appear as a filled black rectangle:
It seemed like Word was having a really hard time enumerating all the fonts on the system and creating the previews that are shown in the dropdown.
(This is a technical article, so try to keep up.)
Initially only a single user reported the problem. Having recently dealt with a case involving a corrupt copy of Helvetica, I checked the machine for rogue or corrupt font files in the %WinDir%\Fonts directory. When that turned up nothing, I tried a reinstall of Office. No joy there, so I chalked it up to either sunspot activity or voodoo. Since the user was not overly troubled by the problem (and has one of the few workstations in the school with applications that are tricky to reinstall), I resolved to rebuild the machine when I had time.
Before that happened, I got another report. This time, I discovered that the problem followed the user around to different machines, something I hadn’t checked with the first user since they always used the same machine.
It was time to break out the big guns. Specifically, Process Monitor.
After logging the incident a couple of times, something immediately leapt out at me.
Of course, the server path wasn’t actually called old-serv, but it was the name of a server I’d retired over the summer that used to hold user data such as their redirected AppData directory. What’s more, Word was suspiciously trying to open this file over and over while I was waiting for the font drop-down to open:
I quickly spotted it was picking up this spurious file name from HKEY_CURRENT_USER\Software\Microsoft\Office\Common\FontBmpCache in the user’s registry.
There’s not much in the way of documentation about this online, so I’m not sure if this is new in Office 2010 or was also in earlier versions, but from the name, I would say it’s a cache of the font preview bitmaps that appear in the font drop-down. Because my users had been migrated to a new server over the summer break, the file could no longer be found, and this was causing Word to choke as it repeatedly tried to resolve the non-existent pathname.
Deleting the value from the registry immediately resolved the problem.
There are a couple of things that still bother me, however.
- Why did only 2 users report this problem, when all users had been migrated away from this server? Partly this can be put down to the fact that most of our users were only using Windows XP before the migration, and started using Windows 7 immediately after, when they received new .V2 format user profiles. For those users who had been using Windows 7 before the migration, all of them will have had the same problem. Most did not report it.
- Why is Word so dumb that it stores the absolute path to a file in AppData, rather than using the %APPDATA% environment variable? All it would take is changing the REG_SZ value to a REG_SZ_EXPAND, and the job’s done. Only the Office developers could explain why they didn’t do it. They could also answer this:
- Why is Word so dumb that it can’t work out the old path is unavailable and create a new file in the correct AppData folder? Without tracking this down, only recreating the user’s profile would have fixed the problem. I regard that as quite a drastic step. It shouldn’t ever be necessary.
In my view, this also strengthens the case for using DFS paths whenever possible for folder redirection. If I need to move the files to a new server in future, I can simply update the DFS target with the new server name. Of course, using DFS for everything in Windows 7 would be a lot more practical if they worked properly with Libraries, which they don’t. Hint to the Windows team: get on that, you idiots.