Hidden gotcha: The command processor's AutoRun setting

Raymond Chen

If you type cmd /? at a command prompt, the commandprocessor will spit out pages upon pages of strange geeky text.I’m not sure why the command processor folks decided to writedocumentation this way rather than the more traditional mannerof putting it into MSDN or the online help.Maybe because that way they don’t have to deal with annoyingpeople like “editors” telling themthat their documentation contains grammatical errors oris 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
    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 itcaused them massive grief.

I must be losing my mind, but I can’t even write a stupid forcommand 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

System Volume Information

Yet when I type the command manually, I get completely differentoutput!

C:\test>dir /ahd/b

Have I gone completely bonkers?

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

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

C:\test>reg query "HKCU\Software\Microsoft\Command Processor" /v AutoRun
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 commandas 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/bproduced a listing of the hidden subdirectories of the root directoryrather than the hidden subdirectories of the C:\test directory.

In the original formulation of the problem, the command the customerwas trying to run looked for its configuration files in the currentdirectory, and the cd\ in the AutoRunmeant that the program looked for its configuration files in theroot directory instead of the C:\testdirectory.Thus came the error message (“Configuration file not found”)and the plea for help thatwas titled, “Why can’t the XYZ command find a configuration filethat’s right there in front of it?”

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