7

When I start an elevated Command Prompt in Windows 7 or Windows Vista, the initial directory is the %SystemRoot%\system32 directory.

This is the default Windows behavior, and is not a problem specific to my system, so I'm not expecting some sort of "bug fix" here, but rather a tweak to "fix" the default behavior.

To repro:

  • Click Start
  • Type cmd.exe
  • Hit Ctrl+Shift+Enter
  • When the elevation prompt appears, select Yes

Expected:

  • The initial directory is my user profile directory, e.g. C:\Users\merlyn

Actual:

  • The initial directory is the system32 directory, C:\Windows\system32

I'd like this be easy to work with. I'd like it to apply to all cmd.exe prompts/shortcuts, regardless of where they're started from. E.g. I'd like it to automatically apply to my Visual Studio Command Prompt (2010) without having to modify that specific shortcut.

I'd like this to be safe so that batch files aren't broken by my fixes.

Is there an easy and safe way to get any elevated command prompt to start in the %UserProfile% directory by default?

Improve this question

2 Answers 2

Reset to default
12

Opening an elevated command-prompt always starts in %systemroot%\System32, the rationale being that if you are doing something requiring elevated privileges, you are likely to be working on system files as opposed to just the user’s own files which you can do without elevated privileges.

You can work around it:

  1. Open a registry editor (e.g., regedit)
  2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Command Processor
  3. Edit the Autorun value to read cd /d %userprofile%

Now whenever you open a command-prompt, it will either start in or switch to, as the case may be, the user profile directory. Also, instead of HKCU, you can set the value in the HKLM branch to do it for all users on the system.

Improve this answer
9
  • Thanks, I'll give this a shot! Just a comment: If this is true, seems like lame rationale to me :) The only file I routinely edit with elevated privileges is under system32 is the hosts file. The rest of them are almost always under %ProgramFiles%/%ProgramFiles(x86)%, a custom directory in the root, or a file for a different account under C:\Users.
    – Merlyn Morgan-Graham
    Commented Mar 13, 2012 at 2:46
  • There’s no way to know why you are opening an elevated command-prompt, so it just uses System32 as a reasonable default.
    – Synetech
    Commented Mar 13, 2012 at 2:48
  • I was going to reply to this with a rebuttal. But I realized it is both idle speculation, and quite OT, so I'll just drop it :) Again thanks for your help. I'll accept for now, and reply later if I find anything gets broken by this fix.
    – Merlyn Morgan-Graham
    Commented Mar 13, 2012 at 2:55
  • Well you said that you are opening the command-prompt via cmd. In that case, Windows has no idea what your intention is (maybe the PS9 can read your mind, but Windows cannot). If you want to open a command prompt to a specific location, you can use a shell-extension such as Kai Liu’s which allows you to open a regular or elevated command-prompt at that folder.
    – Synetech
    Commented Mar 13, 2012 at 3:43
  • Alright. Since you continued the thread... lol. Windows never has any idea of my intent when launching cmd.exe, and this doesn't change depending whether or not I have elevated. There was already a default, and there is no compelling reason to change it, as there is no new info provided. I speculate (since I didn't work on the team that implemented UAC or patched cmd.exe after UAC was added) that this is just a quirk of cmd.exe, and that this whole "change" in behavior wasn't intentional. It is probably just a by-product of the multiple-token thing, and the order in which system calls are made
    – Merlyn Morgan-Graham
    Commented Mar 13, 2012 at 4:15
0

Assuming your merlyn login has administrative rights, it doesn't actaully have those rights untill the UAC prompt has been processed. These rights come with requsting the elevated rights and recieving them when the prompt has been correctly passed. Under the elevated token it is running in a different security context than the standard level of your account pre UAC authorized. All this means that your expected outcome is false, and the actual outcome is actually the expected.

Understanding and Configuring User Account Control

Improve this answer
2
  • I understand that there are two sets of tokens involved, but how is the token related to the user profile? For example, the environment variable %UserProfile% is not changed under this elevated command prompt, and if you type CD %UserProfile% you'll end up in that directory. If you create files, the owner is still "you", etc. I know drag-and-drop is broken by elevated programs, but is anything else? Should the environment/path actually be different? "your expected outcome is false, and the actual outcome is expected" - yes I know this is how it works on a fresh install. I want to "fix" it.
    – Merlyn Morgan-Graham
    Commented Mar 13, 2012 at 2:39
  • I've tried to edit my question to try to show that what I'm expecting is different from what Windows does by default. Please let me know if what I'm asking has problems, maybe a) the wording isn't clear b) it doesn't make logical sense due to how permissions work, or can't be done c) something will be broken if this is worked around.
    – Merlyn Morgan-Graham
    Commented Mar 13, 2012 at 2:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .