The Case of the Reverting Office Theme (resolved with a long-running Procmon trace)

Several times a day, all my Office apps kept reverting to the default “Colorful” theme, even though I had set it to the “White” theme. I prefer the “White” theme because I customize the Quick Access Toolbar in my Office apps with extra icons. Those icons have colors, and the oddly-misnamed “Colorful” theme renders them in monochrome, making it harder to tell what they are. I repeatedly set the theme back to “White,” but several hours later when I’d start an Office app I’d find that it had reverted. I didn’t know whether it was a bug in one or more Office apps, a setting pushed to my system through Group Policy Preferences, or something else.

“Colorful” (???) theme on the left; “White” theme on the right.

“When in doubt, run Process Monitor!” was David Solomon’s exhortation to anyone trying to troubleshoot on the Windows platform, and it’s still good advice. So is “Keep Calm and Run Procmon” (see below for more about that).

Because the theme setting changed only a few times a day, I knew I’d probably need to keep Procmon running for a long time to capture the instant when the setting changed. If you’ve ever left Procmon running for a long time by accident, you’ve probably seen it exhaust its own virtual memory, consume a lot of system commit, and start to bog down the entire computer. There are several different ways to perform long-running traces efficiently with Procmon, including using backing files instead of virtual memory, or using the “history depth” option to set the maximum number of events to retain. I chose to set a filter for just the items I wanted to monitor, and discard all other event data using the “Drop Filtered Events” option.

To identify which items to monitor, I started Procmon, dragged the crosshairs toolbar icon (“Include Process From Window”) over an Excel window, then opened the Filter dialog box and added a “Category is Write” criterion. Procmon now showed only “write” events from the Excel process. I opened File|Options and changed the theme, stopped the Procmon trace, and looked in the trace for events that seemed relevant. I quickly came across these two:

HKU\sid\Software\Microsoft\Office\16.0\Common\UI Theme
HKU\sid\Software\Microsoft\Office\16.0\Common\PendingUITheme

(…where sid is my domain account’s security identifier. If your account is a member of the Administrators group, you’d normally see HKCU instead of HKU\sid. Because I’ve been running as a non-admin again, I needed to run Procmon in a separate administrative account.)

I cleared the trace, reset the filter, and then added these two criteria to the filter:

Path is HKU\sid\Software\Microsoft\Office\16.0\Common\UI Theme
Path is HKU\sid\Software\Microsoft\Office\16.0\Common\PendingUITheme

I didn’t filter on “Category is Write” because I wanted to see what was reading the values, too. Instead I highlighted Category is Write so that write events would stand out. Most importantly, I enabled the “Drop Filtered Events” option on the Filter menu.

A little less than 6 hours later, I had my answer: it wasn’t Group Policy Preferences as I had hypothesized, but rather MsoSync.exe (“Microsoft Office Document Cache”), which had been started by GROOVE.EXE (OneDrive For Business). I don’t have access to Office symbols, so I couldn’t see the relevant function names when I inspected the call stacks. But I could deliver the Procmon trace to the Office team along with my bug report. They of course have Office symbols with which they can identify in which function and in which source file the bug lives.

Six hours of Procmon trace monitoring two registry values, highlighting the “write” events, and dropping all other events.

I submitted the Procmon trace along with my bug report to the Office team. A few days later, a new Office build had been installed on my computer, with the bug no longer present.

How badly did a 6-hour trace bog down my system? Not at all! Procmon captured and retained only 21 events during that entire period. In fact, I accidentally left the trace running for three days, during which I continued to run Office programs. Procmon captured a total of just 116 events. Process Explorer reported that even after running for three days, Procmon consumed only 146 MB of private bytes and 227 MB of working set, far less than many other programs I was also running. (And the reason that it was even as big as it was is that although Procmon captured a minimal number of events, it continues to capture information about all the processes that ran at any time during the trace.)

For complete documentation about the Sysinternals tools, along with tons of tips, tricks, and techniques, get a copy of Troubleshooting with the Windows Sysinternals Tools . (Makes a great gift!)

Also, cultural icon Chris Jackson has put the meme “Keep Calm and Run Procmon” on a t-shirt that you can purchase. (I bought a black one. It looks sharp.) Proceeds from these t-shirt sales go to the Seattle Humane Society.