File Type Icons Missing inside a ThinApp, not in the Shell

Every now and then I get a little too aggressive when cleaning up files in a ThinApp package and all of my file type icons disappear within that package. They’re fine in the OS, but viewed from the ThinApp itself, you get nothing but default Windows icons. Microsoft Office is notorious for this – the actual ThinApp executables all have good icons and files within Explorer all look good… but the Open Dialogue box has no working icons! It took me a bit of poking around to figure out what was happening, so I figured that I’d write it down here so that I can easily look it up in the future (and maybe someone else will benefit from this too!).

The problem (with Office) comes from when you clean up files from %systemroot%\Installer. In my ThinApp Office 2010 Instructions you’ll notice that I do some work with Robocopy – that’s to work around this issue. Rather than just preserving the executables that Office uses (which was my goal there), I’ve decided to actually go into some detail here about how I figured out that those were the files that were in use. That way, if the problem shows up with other applications, it’ll be easy to figure out what needs be preserved to resolve the issue.

After an application is installed, it creates a bunch of file type associations under HKEY_CLASSES_ROOT (which is stored under both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER if you want to look at them in your build folder). In Regedit, you’ll notice that there are a bunch of keys under there for various file types – these keys and values contain the first steps that your computer uses when determining what to do with that file type. If you find the .docx key (for example), you’ll notice that it has a few values that give name to the file type as well as a few subkeys. Importantly (and frustratingly) there’s no subkey for “DefaultIcon”. Instead, with the .docx key selected, there is a “(Default)” value with Data that reads “Word.Document.12”. This bit of data is the key (if you’ll pardon the pun) to discovering where the system is looking for an icon for that file type. Other file types obviously have other data strings there, specific to that file type.

Your next step is to search the registry for Keys (I’d disable the “Values” and “Data” checkboxes, as they’ll probably return a lot of results that you aren’t interested in) named for whatever string you found. In this case, I searched for “Word.Document.12”. The first key that it found was actually under the .docx key – that’s not the one I wanted, so I hit F3 to find the next hit. That pulled me down to the HKEY_CLASSES_ROOT\Word.Document.12 Key (to which you could browse directly, if you’re getting a lot of useless hits on the search). Beneath that Key is a subkey called “DefaultIcon” with a “(Default)” Value that specifies the path that contains the icon for that file type. In this case, I can see that it’s looking for C:\Windows\Installer\{901200…FF1CE}\wordicon.exe,13.

My problem was that, in my eagerness to shrink my ThinApp package size, I was deleting all of the installer files from that directory (since the main executable pulled its icon from C:\Program Files\... and worked fine without those files). Deleting those files means that your main executable (and your Shell, since it uses the main EXE’s icon after you ThinReg your package) will have a working icon, but anything within the package (which is pulling those paths from the registry) is not going to have the files that it needs in order to populate icons. If you make sure that any files specified in a “DefaultIcon” Key’s “(Default)” Value remain present, everything will work (and you can still clean up a bunch of unused files).