- Site Admin
- Posts: 41868
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
You could send "%P" as one of the parameters, and then use that to change to the correct directory, e.g. with
According to this answer on StackOverflow it's a security feature:
If you think about it, it makes sense as a security feature. It could help prevent some DLL dropping attacks where a user places some DLL with the same name as known Windows DLLs (like kernel32.dll or shell32.dll or similar) in the same directory as an executable file. Now instead of loading the malicious DLL, the system loads the one from a directory that is known to be safe: the Windows (or system32) directory when the executable is launched elevated (via runas verb).Microsoft added this as a security feature starting in Windows 8. Whenever cmd.exe detects it's running elevated, it ignores its launch parameters and always starts in %SystemRoot%\System32. You cannot override this behavior.
But there are indications that it started in Vista:
SS64.com also mentions it:A particularly vexing problem — which the prologue solves — is that in Vista with UAC, if a .BAT file is launched "as Administrator," it doesn't start up in the folder where INSTALL.BAT resides — instead it's usually running in Windows\System32. So one of the steps in the prologue is to get back to the right startup folder.
(Though I don't agree with the "disconnected" part.)When a script is run with elevated permissions several aspects of the user environment may change: The current directory, the current TEMP folder and any mapped drives will be disconnected.
Anyway, I don't think it's a bug. If it was, MS would have fixed it within the last 14 years, wouldn't they? Yeah sure, there are other long-standing bugs in Windows like the one in wevtutil...
- Power Member
- Posts: 10996
- Joined: 2003-02-05, 20:24 UTC
- Location: Valsted, Denmark
Code: Select all
[em_ext_cmdelevated] cmd=*%COMSPEC% /C param=Start /D"%P" menu=Command Prompt as Administrator button=cmd.exe