Geoff Chappell - Software Analyst
Some paid work last month had me making what might have been routine use of Image File Execution Options for getting a particular process to run automatically under a debugger. Slightly less routine is that this was wanted before any user was yet logged on, so that the user-mode debugger had to be operated through the kernel-mode debugger from a second computer. What changed the work from routine to initially impossible was interference from software that injects its DLLs into arbitrary other software. Too much of this is done without a full understanding of what Windows functionality they disturb. As far as I’ve ever been able to tell, it’s hardly ever done with much sense of responsibiilty for the costs they impose on by-standers. I’d happily see these guys drummed out of business, along with most makers of anti-virus software, meaningful difference between their products and malware being sometimes hard to discern.
Anyway, the spill-over to my unpaid work is that it got me looking again at the exported functions for querying Image File Execution Options. Somehow, I wrote about one of them one day more than a decade ago without ever returning to it or its companions. There have, of course, been developments. And I have in the meantime got more interested in the early history. Image File Execution Options actually are ancient.
One of the quirks of the API for Image File Execution Options is that an option can be in the registry as a string but can be queried as a dword. Indeed, it wasn’t until Windows 2000 that an option could be anything other than a string. It’s well past time, then, to document the low-level helper that parses a dword from a string. You’d think such a function is straightforward. It always has been documented. But look at the documentation and ask why it goes to the trouble of presenting examples. Then ask whether Microsoft would have added these without experience of this simple function causing real-world problems.