The Case of the Unexplained Installation Failure (and an ill-advised registry hack)
Since Mark Russinovich hasn’t trademarked his “Case of the Unexplained…” series, I’m appropriating the title to describe the results of some troubleshooting I did for a customer. The root cause turned out to be a widely-adopted but ill-advised registry hack that many organizations have built into their standard desktop images. If you’re not interested in the troubleshooting steps, skip ahead past the nerd content here and just read the Analysis. [Spoiler: it’s about the Autorun.inf “SYS:DoesNotExist” registry hack.]
The Case
The customer has Kodak scanners that come with CDs containing the required software. When the admin inserted the CD, Autorun didn’t quite work correctly – the Autorun dialog appeared but did not show the Autoplay option to install the software. So the admin opened the folder in Explorer and started autorun.exe to start the installation. Shortly after approving the User Account Control elevation request, the admin saw an error message with a strange title that looked like the installer was performing an incorrect OS version check:
App install error message
The Troubleshooting
I figured that the author of the installation program had assumed that since Windows XP was so perfect that Microsoft would never need to release another version of Windows, there was no reason to check for newer versions. I applied the WinXP compatibility mode (which among other things lies to the program about what the OS version actually is) and tried again. It failed in exactly the same way. What’s more, the installation worked perfectly well on freshly installed copies of Windows Vista that didn’t have the organization’s policies applied to it. Ah – so it’s not a Vista issue, there’s something in the policies!
I started Process Monitor, and ran the installation program again to the point of the error message and then stopped the Procmon trace. I dragged the Procmon crosshairs toolbar icon over the error message to apply a filter to show only events involving the window owner’s process (setup.exe).
Because of the “0” in the title in the error message, I thought the problem might be due to the program searching for something and not finding it, so I right-clicked on items in the Result column and excluded events with result codes I figured wouldn’t be interesting: SUCCESS, FAST IO DISALLOWED, FILE LOCKED WITH ONLY READERS, REPARSE, BUFFER OVERFLOW, and END OF FILE. (I usually exclude results that I want to filter out rather than include results that might be interesting because it’s easy to miss some when setting “include” rules.)
When I looked at the remaining entries, one thing that quickly stood out was the name “DoesNotExist” appearing in path names near the end of the results. I used Procmon’s highlighting feature to make them stand out in the context of surrounding events.
Because the surrounding context didn’t give me an idea of what had happened immediately prior to these failed searches, I took advantage of Procmon’s non-destructive filtering and removed the filter rule that excluded SUCCESS results. As you can see in the screenshot, there had been a bunch of file accesses to D:\setup.ini and then a few to D:\autorun.inf before the attempted registry access to HKLM\Software\DoesNotExist\Info.
I opened the event properties for the first RegOpenKey event and looked at the call stack to get an idea of how and why setup.exe was trying to open that key. Line 12 of the stack showed that the randomly-named component of the setup program was calling into GetPrivateProfileStringA, which led (in line 7) to an attempt to open a registry key.
GetPrivateProfileString is one of the APIs that Windows programmers can use to read from files that are formatted like the old .ini files from 16-bit Windows. And as its documentation points out, those accesses can be redirected to the registry with an IniFileMapping. I located the IniFileMapping that redirected autorun.inf to “DoesNotExist”, deleted it, rebooted, and the installation then worked correctly.
IniFileMapping entry redirecting Autorun.inf to a non-existent registry key
The Analysis
What is IniFileMapping?
IniFileMapping has been part of Windows since NT 3.1. When programs use the ini-file APIs to access files, an IniFileMapping entry can redirect the access to the machine or user registry (HKLM or HKCU). IniFileMapping was designed to help older apps that used .ini files to use the registry instead, to take advantage of the scalability benefits and to enable multiple users to have their own copies of settings instead of sharing a single ini file.
What is Autorun.inf?
When a removable disk, such as a CD or a USB drive, is inserted and Windows detects the new disk, Windows Explorer checks for an Autorun.inf file in the root folder of the drive. The Autorun.inf is a text file formatted as an .ini file (that is, section names in square brackets, name=value pairs within each section). It can include entries which tell Explorer what icon to display for the drive and a default Autoplay action to offer to the user, or in some cases, the program can just begin running. This is the mechanism that allows a program installation to automatically start just by inserting a CD. There are registry settings and group policies that can control whether and how Autorun and Autoplay work. (That link also describes the distinction between Autorun and Autoplay.)
A problem with Autoplay is that by default it has also been applied to writable drives such as thumbdrives. Worms like Conficker were able to propagate through such devices by writing an Autorun.inf and a copy of itself to the drive. The malware could then infect other computers simply by inserting the drive. That was compounded by a bug in the implementation of the settings that were supposed to disable Autoplay. That bug has since been fixed. Furthermore, updated Windows systems now have Autoplay disabled by default for writable drives. Autorun and Autoplay still work for CDs and DVDs, as the threat of worm propagation through that avenue is much smaller and (at this time) does not outweigh the benefits.
Why does this computer have an IniFileMapping for Autorun.inf?
A couple of years ago, a blog post described a clever trick to disable Autoplay for all drives. The trick leveraged the fact that Autorun.inf is formatted as an ini file and that Explorer uses the ini file APIs to read it. By creating an IniFileMapping for Autorun.inf that redirects access to a non-existent registry key, Autoplay entries cannot be read. The author asserted that the only negative effect is that users must browse for the file to execute. As more malware began using writable removable drives as a propagation mechanism, CERT and other security-conscious organizations began recommending this trick, adding the assertion that “This setting appears to disable Autorun behaviors without causing other negative side effects.” Since then, the setting has been mandated as part of the standard image for many organizations.
Why did this application install fail?
It turns out that the Autorun.inf on Kodak’s installation CD contained much more than just Autoplay entries:
[autorun]
open=autorun.exe[Info]
Dialog=Kodak i610/i620/i640/i660 Scanner
Model=600
ModelDir=kds_i600
ProgramGroup=i610,i620,i640,i660[Versions]
CD=04040000
FIRMWARE=04000300
ISISDRIVER=2.0.10711.12001
ISISTOOLKIT=57.0.260.2124
KDSMM=01090000
PKG=02010000
SVT=06100000
TWAIN=09250500[Install]
[SUPPORTEDOSES]
WIN=WINVISTA WINXP WIN2K[REQUIREDSPS]
WINXP=1
WIN2K=3
Kodak uses the Autorun.inf not only for Autoplay but as a general-purpose ini file containing configuration settings for the installation program. The installation program of course uses standard APIs to read the file, but the IniFileMapping redirects to a non-existent registry location, causing the installer to fail. It needs to be said here that what Kodak is doing is perfectly legitimate. There are no guidelines that say that the Autorun.inf cannot contain other application specific settings.
Could the customer have worked around the problem by copying the CD content to the hard drive and running it from there? No. The IniFileMapping setting applies to any file called Autorun.inf no matter where it is.
The bottom line is that the installation failed because the assurances of no “negative side effects” were not backed with extensive compatibility testing, and denies legitimate usage scenarios.
Recommendation
Customers who want to block Autoplay should use supported mechanisms rather than relatively untested hacks that can end up causing unintended side effects. I’ve seen plenty of cases where a non-standard setting that seems to many to be perfectly safe turns out to have serious repercussions that aren’t discovered for years. (That sort of thing led to the publishing of KB article 885409.)