Hidden gotcha: The command processor’s AutoRun setting

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

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

Comments (37)
  1. IanA says:

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

    I guess it was done to help ‘legacy’ Users, used to MSDOS (those most likely to use the command prompt?) where this was a typical practice. Of course, in old MSDOS days ‘online help’ and ‘MSDN’ were not around.

    Although you are ‘not sure’ I think you may guess the same, but I enjoyed the swipe at "Editors" that your uncertainty allowed…

  2. Thanks for the tip.

    I’m using this (just implemented after I read your article) to correct a problem I was having.  My cmd.exe always started in the H: drive.  I could not figure out why.  But by using the autorun I made it always change to the directory I want it to be, namely %HOME%.

  3. Nugae says:

    /? documentation is available wherever the cmd.exe program is available. It doesn’t require an Internet connection, it doesn’t require CDs full of documentation and massive programs to interpret and present that documentation. It never gets out of step with the program it is documenting.

    Definitely it should be eliminated.

  4. John says:

    What happens if you set Autorun to cmd.exe?

  5. John says:

    LOL.  It does exactly what I hoped it wouldn’t do.

  6. John says:

    It keeps launching cmd.exe until you run out of resources.  Fortunately, it doesn’t open a new window for each instance.  However, setting AutoRun to "start" results in the (un)desired effect.  Nice!

  7. Barry Kelly says:

    It looks to me that what’s missing is the distinction between interactive, login and nested shells.

    Having commands for the startup of an interactive shells and login shells is usually quite useful. Interactive shell startup can add aliases, or do the chdir being demonstrated here. Login shells might run a program like fortune, for a qotd effect.

    Finally, non-interactive nested shells such as those used in backquoting don’t have nearly as much use for such initialization.

    It seems to me to add up to a deficiency in cmd.

    [And people complain about feature creep. Name any program that distinguishes among those three scenarios. Remember the days when command line tools just did what they were told and didn’t try to second-guess you? -Raymond]
  8. Ben says:

    The documentation is available both in the on-line help for Windows and on TechNet (once in general for cmd.exe, and once specifically describing the Autorun key), as per your suggestions. The TechNet links are the following:



    While it seems that the primary reason that you didn’t already find these is for lack of looking, if we require a justification for the command processor being able to list its own help text, then I think doing so is just as valid a tradition (in keeping with the expectations of those familiar with DOS or UNIX/Linux) as the newer tradition of putting documentation elsewhere. In addition, it’s my experience that I usually want information on command-line parameters when I am, in fact, already at the command line; incidentally, help for PowerShell is provided in the same format.

    As regards the use of the Autorun entry: I personally use it to set Administrator’s command prompt to use red text rather than the standard grey, so as to distinguish an elevated prompt from a standard one at a glance.

  9. Hajo says:

    "Like I said, I’m sure there must be some valid reason for the AutoRun setting, but I haven’t yet found one."

    The AutoRun setting on my machines point to a batch file that contains, among other things, a line like

    doskey /macrofile="%HOMEDRIVE%%HOMEPATH%doskey.mac"

    Very handy to have some shortcuts to frequently used commands with cryptic options.

    Another tip what to do with it comes from Aaron Margosis: On <http://blogs.msdn.com/aaron_margosis/archive/2007/06/25/follow-up-on-setting-color-for-all-cmd-shells-based-on-admin-elevation-status.aspx&gt; he describes how to highlight CMD windows running with elevated user rights.

  10. ERock says:

    I had a soundcard that didn’t natively support work in a command window. I liked the features it had under Win95 but I wanted to run DOS things also.

    It seemed to use this trick to run a TSR or some kind of initialization thingie to enable Soundblaster emulation while in a window. And it was much appreciated by me at least at tht time.

  11. Kip says:

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

    I prefer it this way.  Maybe because I only actually have to look up stuff on MSDN once in a blue moon, but I can never seem to find what I’m looking for.  In fact, I typically use Wikipedia now.

    At the very least, it’d be nice if all of the commands, when run with /?, would give you the URL to the MSDN page on that command…

  12. Somedude says:

    Kip: for effective Microsoft searching, use google’s site search.

    for example, to find the cmd documentation:

    cmd.exe help site:microsoft.com

    First result!  I can’t believe how often Microsoft’s own search function completely messes me around.

  13. John says:

    It’s not only that it’s hard to find what you’re looking for in MSDN; it’s that often you don’t know what to look for in the first place.

    One trick I’ve figured out is to search for your topic, then when you find something that could be relevant, sync the page with the table of contents.  Usually there will be something in or nearby the current page in the TOC that is useful (and of course this information will not show up in your searches).  Otherwise, the search functionality in MSDN is COMPLETELY USELESS.  Microsoft should just strip out the search functionality completely and save people countless hours of frustration.

  14. Thomas says:

    It’s very nice for loading doskey macros (I have shortcuts for navigating round, plus "mcd"="md … cd …", "ls"="dir", your "whereis", etc.). I don’t set any environment variables in there – they’re all configured via Control Panel. I found that trying to do more complicated stuff in AutoRun made things break in various unexpected ways.

  15. pdw says:

    “Name any program that distinguishes among those three scenarios.”

    Unix shells :)

    [They only distinguish two (login vs non-login; interactive and non-interactive are treated the same) and even then only because they are told whether they are the login shell or not. Windows doesn’t have a character mode login shell. -Raymond]
  16. sandman says:

    <i> Name any program that distinguishes among those three scenarios.</I>

    Bourne shell, csh, and ksh all do I believe. Generally via the -i and -l switches and also by using isatty() on stdin and stdout.

    Of course since VC++2005 deprecates isatty() , I guess that wouldn’t be wise to use.

  17. andy says:

    Sounds similar to how its done in various UNIX shells, such as BASH’s .bashrc where you can put stuff to be run. Also Powershell has something similar.

    Thanks for mentioning this, as I’ve sometimes wanted to do what ‘ak’ above describes :) (thanks to ak as well!)

  18. I use AutoRun to ensure that vcvarsall.bat is always run for every command prompt that I open, whether it be from Start -> Run -> cmd.exe (a hard habit to break) or right clicking a folder and running command prompt here. While I could dissect the batch file and load it all into the environment, I’d rather just use the one that comes with Visual Studio.

    This way i know I can always run csc.exe, wsdl.exe, or whatever no matter how I got to the command prompt.

  19. Peter says:

    Raymond asked if there were any command line utilities that "know" what mode they’re in.  Well, I know of one: devenv.exe (a.k.a., Visual Studio).  It will decide whether to load environment customizations based on whether you’re command-line or not.

    So if your build depends on the customizations, it will work in interactive mode, but not when you try to automate it.

    And as Raymond says: this is horrid.  It took us a day or so to figure out because it’s so counter-intuitive.

  20. pdw says:

    AIUI, Unix shells traditionally have three cases:

    • Interactive login shell: read /etc/profile and ~/.profile
    • Any interactive shell: read the script specified by the ENV environment variable

    • Read nothing for non-interactive shells.

    The more featureful shells (bash, zsh) allow you to specify a script for the last case as well. Most shells also maintain a SHLVL variable to see how deep a shell is nested.

    Now, I’m not saying all of this is necessarily useful (changing the behavior of non-interactive shells is actively evil, as you’ve pointed out). And the way it’s all configured in Unix is utterly chaotic.

    And I don’t think you even can reliably distinguish interactive and non-interactive CMDs in Windows?

  21. Legitimate use: preventing German spies from using your computer if you leave it unlocked by mistake.

    HKCUSoftwareMicrosoftCommand ProcessorAutoRun = checkforgermanspies.bat


    @echo off


    if "%ANSWER%"=="" goto INTERROGATE

    if "%ANSWER%"=="Minnie Mouse" goto RIGHTANSWER



    echo Who is Mickey Mouse’s girlfriend?

    set /p ANSWER=

    goto BEGIN


    echo Sound the alarm!



    echo Sorry for all the trouble, citizen.


  22. mh says:

    I actually worked on something once where correctly identifying (and behaving differently based on the type of) logon session was important, but can’t remember for the life of me what it was now.

    One valid reason for cmd.exe spewing it’s help text: if your internet access goes down.  I can see this being redirected to a text file for easier browsing, though.

    That autorun key is definitely a bomb waiting to explode.  Once upon a time it could have been useful for an admin to put something helpful (or unhelpful, depending on who the admin is…) to the user in there, but these are not innocent times any more.

    I just put "exit" in mine – oh joy!

  23. Miral says:

    First, I use the /? help all the time.  Is there documentation elsewhere?  I’ve certainly never seen it.

    Second, the AutoRun function is very useful.  The problem is that it doesn’t go far enough — there should be another key or two to specify additional commands, and an extra command line parameter (that’s automatically included when backquote recursing) to avoid running those extra commands.  That way you can set up some commands that run all the time (eg. to set up basic environment variables) and some that only run for interactive command prompts.  Easy.

  24. Xepol says:

    I suppose it makes up for the functionality lost when autoexec.bat and config.sys went the way of the dodo – no nice convenient way to get your cool command line prompt utilities into memory (like doskey).

    I don’t know how useful this in currently, but I imagine it’s like other less useful reverse compatibly parts of windows – someone still needs them to do something stupid and MS hasn’t had the nerve to say "hard cheese, buddy, time to update past windows 3.1!"

  25. ak says:

    I used to have a really long line of gunk in there, now its "just":

    title Console [%username%@%userdomain%] &"%ALLUSERSPROFILE%..CommonCmdInit.cmd" "%cd%" &cd "..%username%desktop">nul 2>&1 &echo r0>nul

    CmdInit.cmd does a whole lot of stuff, figures out if the user is admin, if so, it changes the color to red. It also sets up a bunch of aliases and adds some stuff to %path% etc. here are some random snippets form it (are we getting off topic now?):

    if exist "%systemroot%system32cacls.exe" "%systemroot%system32cacls.exe" "%systemroot%system32configsystem">nul 2>nul&&color 0c

    doskey alias=IF "[$1]"=="[]" (doskey/macros:ALL) ELSE (doskey $*)

    doskey vcd=pushd %%$*%%

    doskey ie=start iexplore.exe $*

    doskey e=IF "$1"=="" (explorer /e,.) ELSE (explorer /e,$*)

    doskey where=cmd/c (setlocal^^^&set "pe=.;%%path%%"^^^&@for %%a in ($1) DO @for %%b in (%%PATHEXT%%) DO @for %%c in (%%~na%%b) DO @if NOT "%%~$pe:c"=="" echo.%%~$pe:c)

    set PROMPT=$M$+$P$G


    set LS_OPTIONS=-bhAC –color=auto –recent –streams

    set GREP_OPTIONS=–binary-files=text -d skip –color=auto

    it also checks for recursion and some env vars (%_MSDEV_BLD_ENV_% etc) so it knows when not to do its magic

  26. Worf says:

    Hmm… if one were truly evil, they’d set autorun  to something like echo "C:>"; pause; exit

    Or just have it contain merely… "exit"

    Would definitely confuse a bunch of people at work, where Windows CE and Windows Mobile require dropping to the command prompt at one point or another. Hmm… an idea to prank people with…

  27. Centaur says:

    I imagine this key might well be abused by malware.

    Speaking of online help, it annoys me to no end that, since Windows XP, it does not document exit codes (aka errorlevels). I happen to know from DOS and Windows 2000 times that find.exe returns 0 when it finds the text, 1 when it doesn’t; but if I were a new Windows XP user, I would have no way to discover it. I am still at a loss on whether ping.exe returns anything useful.

  28. I’m not sure why the command processor folks decided to write documentation this way

    I think it shows the dedication, love and respect to the product – having help embedded and making the product self contained.

    It’s saying this to me: ‘We know this will be a part of a bigger system but let the user who lives and breathes in the command processor window survive without any external dependencies. There will be such users, – we are such users’…

  29. Peter says:

    @centaur: "I am still at a loss on whether ping.exe returns anything useful."

    Are you looking for official documentation or multiple exit codes? Otherwise, isn’t this enough:

    ping msdn.com

    … (success)

    echo %ERRORLEVEL%


    ping doesnotexist

    … (errormsg)

    echo %ERRORLEVEL%


  30. Dan says:

    I have something similar to ak’s script in my Vista autorun entry… I make the color white on red if the command prompt is running elevated (instead of using cacls, my version tried to create a file in system32… I just changed it to use cacls instead, thanks ak!)

    Here it is if anyone else wants to use it:

    @echo off

    cacls "%systemroot%system32configsystem" > nul 2> nul && goto admin



    title User: Command Prompt

    color 07

    goto end


    title Command Prompt

    color 4F

    goto end


    Remember there is no need for an "Administrator" prefix since Windows will automatically add one to consoles.  The color just helps me remember not to use the console to relaunch explorer or other apps.

    My old script was something like:

    echo. > "%systemroot%system32delete.me" 2> nul

    if exist "%systemroot%system32delete.me" goto admin



    del "%systemroot%system32delete.me"

  31. Dave says:

    >Otherwise, the search functionality in MSDN is COMPLETELY USELESS.  

    >Microsoft should just strip out the search functionality completely and

    >save people countless hours of frustration.

    At the risk of appearing to jump on the MS-bashing bandwagon here, MSDN’s search really is pretty awful.  At work we have a Google alias set up (despite having a full corporate MSDN subscription available locally) and use that to search MSDN, because the native search is so bad.  Could someone please, please make this… well, at least less awful?

    [Wow, if only there were a Feedback link on the MSDN search page. (Remember, feedback needs to be actionable. “This sucks” is not actionable. “I searched for X but got Y instead” is actionable.) -Raymond]
  32. Ulric says:

    Getting the online help for command-line tools in Windows doesn’t require internet access.

    On XP, it’s in the Start menu, in "Help And Support"

    type "CMD", it’s all there.

    Raymond is right in questioning why the online help is in the .exe.  It’s not right to do this: help needs to be handled by the documentation team and be TRANSLATED in multiple language.

    Personally, I used JPSoft’s 4NT.

    when you do /? for any commant, it launches WinHelp with the proper page.

  33. Ulric says:

    Note that man pages and "/?" are not the same thing.

    /? is suposed to be only for short reminder of parameters, while all the explanatory stuff is suposed to be in a separate doc.  On Windows, it’s not man pages, it’s HTML help.  In any case, my point is man pages are not embedded in the executable.

  34. David Walker says:

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

    Raymond:  Sorry to harp on your first paragraph, but … surely you know that if you type "anycommand /?" at a command prompt, like "dir /?" or "time /?", you’ll get some documentation on what that command is supposed to do.  (For most commands, anyway.)

    Maybe it’s a *standard* for command-prompt commands?  Left over from the standard for DOS commands, perhaps?

    The "cmd" command does lots of things, and its built-in help is more complete and thorough than the built-in help for most commands.  Don’t complain because it’s thorough!  Seeing that complaint is very strange.  Do you think terse documentation is preferable to good documentation?  Should the subject be treated only in outline?

    Type "for /?" to get a similarly long and very useful explanation of what the "for" command does.

    There’s no reason to kill these "man pages" (in *nix terminology), and no reason there can’t be MSDN documentation also.  The more documentation the better, as long as the different sources don’t contradict each other!

    The creators of the command have the most control over the text displayed from using /?, and maybe they wanted the documentation to be complete and correct.  Don’t fault them for that.

  35. Name, Title And Comment Required says:

    "Unix shells :)"

    "Bourne shell, csh, and ksh all do I believe."

    And so on…

    I find it amusing how a bunch of commenters felt the urge to tell a blogger whose name appears in the Linux kernel credits about these crazy "Unix" shells, especially when they’re wrong about how these shells behave.

    Is the assumption that anyone who works at Microsoft must never have used Unix?

  36. Dave says:

    >Could someone please, please make this… well, at least less awful?

    Actually it looks like it’s

    <a href=”http://www.codinghorror.com/blog/archives/000428.html“>already been fixed</a>.  Apologies for the premature grumbling.

    >Wow, if only there were a Feedback link on the MSDN search page.

    I’m aware of that, but I think submitting a link to Google with the text “Learn, guys” probably wouldn’t go down too well :-).

    [You forgot to read the other half of my comment. The part that talks about actionable feedback. “You suck” isn’t actionable. “I searched for X using the search keyword Y and couldn’t find it” is actionable. -Raymond]
  37. The cause for this nasty to diagnose behavior was that in customer’s machine, when you ran &quot;cmd.exe

Comments are closed.

Skip to main content