If you type cmd /? at a command prompt, the command processor will spit out pages upon pages of strange geeky text. I’m not sure why the command processor folks decided to write documentation this way rather than the more traditional manner of putting it into MSDN or the online help. Maybe because that way they don’t have to deal with annoying people like “editors” telling them that their documentation contains grammatical errors or is hard to understand.

Anyway, buried deep in the text is this little gem:

If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.
    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun
        and/or
    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

I sure hope there is some legitimate use for this setting, because the only time I see anybody mention it is when it caused them massive grief.

I must be losing my mind, but I can’t even write a stupid for command to parse the output of a command.

C:\test>for /f "usebackq delims=" %i in (`dir /ahd/b`) do @echo %i

When I run this command, I get

RECYCLER
System Volume Information
WUTemp

Yet when I type the command manually, I get completely different output!

C:\test>dir /ahd/b
test_hidden

Have I gone completely bonkers?

The original problem was actually much more bizarro because the command whose output the customer was trying to parse merely printed a strange error message, yet running the command manually generated the expected output.

After an hour and a half of head-scratching, somebody suggested taking a look at the command processor’s AutoRun setting, and lo and behold, it was set!

C:\test>reg query "HKCU\Software\Microsoft\Command Processor" /v AutoRun
! REG.EXE VERSION 3.0
HKEY_CURRENT_USER\Software\Microsoft\Command Processor
    AutoRun     REG_SZ  cd\

The customer had no idea how that setting got there, but it explained everything. When the command processor ran the dir /ahd/b command as a child process (in order to parse its output), it first ran the AutoRun command, which changed the current directory to the drive’s root. As a result, the dir /ahd/b produced a listing of the hidden subdirectories of the root directory rather than the hidden subdirectories of the C:\test directory.

In the original formulation of the problem, the command the customer was trying to run looked for its configuration files in the current directory, and the cd\ in the AutoRun meant that the program looked for its configuration files in the root directory instead of the C:\test directory. Thus came the error message (“Configuration file not found”) and the plea for help that was titled, “Why can’t the XYZ command find a configuration file that’s right there in front of it?”

Like I said, I’m sure there must be some valid reason for the AutoRun setting, but I haven’t yet found one. All I’ve seen is the havoc it plays.