Hidden gotcha: The command processor's AutoRun setting

Raymond Chen


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
    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

System Volume Information

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

C:\test>dir /ahd/b

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
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
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.


Comments are closed.