Command prompt - initial current-directory setting
This behavior indicates that the cmd.exe
process is inheriting an environment block containing an =M:
environment variable with the value M:\neo
. Such hidden environment variables are used internally by the command processor to keep track of the current directory for each drive. If Explorer is passing them on to the new cmd.exe
, that suggests that Explorer was (perhaps indirectly) launched from a command prompt whose last current directory on the M drive was M:\neo
. I can reproduce this behavior with these steps:
- Open a command prompt to
M:\neo
. - Terminate Explorer, e.g. with
taskkill /im explorer.exe /f
. - Restart
explorer
from the open command prompt. This instance of Explorer inherits all the command processor's environment variables. - Launch a new command prompt from Explorer, e.g. with a shortcut or the Run dialog. This prompt's current directory on the M drive will also be
M:\neo
.
If UAC is disabled, it is conceivable that a Task Manager instance launched from the command line could also be part of "the chain of custody of your environment block," having been used to restart Explorer at some point. (Note: Not tested, since I have UAC on.)
You can verify that Explorer is passing on the per-drive current directory variable by launching PowerShell instead and evaluating ${env:=M:}
, since PowerShell itself will not set these variables. But if the variable is absent/empty, it is possible that the current directory is being affected by a script invoked by command processor AutoRun commands. It would be possible to see those in the Registry or disable them temporarily by launching cmd /d
from the Run dialog.
I understand that the problem has gone away for you, but in case it comes back (and for others' benefit), you can try to investigate environment inheritance by looking at the process tree in Process Explorer. If the process that launched Explorer is still running, it will show as Explorer's parent in the tree on the left and you will be able to see many details about it. But in the likely event that the parent process has ended, you would need to enable process auditing, reboot, and trace through instances of event 4688 to figure out what chain of processes (probably involving a batch script) created the instance of Explorer that is currently running.