Why does 'Run as administrator' change (sometimes) batch file's current directory?

I have a batch file that is in the same directory as the file I want to xcopy. But for some reason the file is not being found.

I thought that current directory was always where the batch file was located.

I run batch file as administrator. This occurs on a Windows 7 64-bit desktop computer.

Batch file:

@ECHO OFF
XCOPY /y "File1.txt" "File2.txt"
PAUSE

Error:

File not found - File1.txt
0 File(s) copied

Solution 1:

Which directory is current working directory on starting a batch file with context menu item Run as administrator depends on User Account Control (UAC) setting for the current user.

This can be demonstrated with following small batch file C:\Temp\Test.bat:

@echo Current directory is: %CD%
@pause

With having selected in User Account Control Settings

Default - Notify me only when programs try to make changes to my computer

• Don't notify me when I make changes to Windows settings

and using Run as administrator, Windows uses registry key

HKEY_CLASSES_ROOT\batfile\shell\runasuser\command

This registry key does not contain a default string for executing the batch file. Instead there is the string value DelegateExecute with the CLSID {ea72d00e-4960-42fa-ba92-7792a7944c1d}.

The result is opening a dialog window with title User Account Control and text:

Do you want to allow the following program to make changes to this computer?

Program name: Windows Command Processor
Verified publisher: Microsoft Windows

After confirmation by the user, Windows opens temporarily a new user session like when using on command line RunAs.

In this new user session the current working directory is %SystemRoot%\System32 on executing now the command defined in Windows registry with default string of key

HKEY_CLASSES_ROOT\batfile\shell\runas\command

which is:

%SystemRoot%\System32\cmd.exe /C "%1" %*

Therefore a console window is opened with title C:\Windows\System32\cmd.exe and the 2 lines:

Current directory is: C:\Windows\System32
Press any key to continue . . .

After hitting any key, batch execution finishes which results in closing cmd.exe which results in closing the user session.

But with having selected in User Account Control Settings

Never notify me when

• Programs try to install software or make changes to my computer

• I make changes to Windows settings

the behavior is different as the user has already elevated privileges.

Now Windows uses directly the command

%SystemRoot%\System32\cmd.exe /C "%1" %*

according to default string of key

HKEY_CLASSES_ROOT\batfile\shell\runas\command

in current user session.

The result is opening a console window also with title C:\Windows\System32\cmd.exe, but displayed in window is:

Current directory is: C:\Temp
Press any key to continue . . .

The current working directory of the parent process (Windows Explorer as desktop) is used for executing of the batch file because no switch to a different user session was necessary in this case.

PA has posted already 2 possible solutions in his answer which I replicate here with a small improvement (pushd with directory in double quotes) and with adding a third one.

1. Change current directory to directory of batch file using pushd and popd:

   pushd "%~dp0"
   %SystemRoot%\System32\xcopy.exe "File1.txt" "File2.txt" /Y
   popd
   

   This works also for UNC paths. Run in a command prompt window pushd /? for an explanation why this also works for UNC paths.

2. Use directory of batch file in source and destination specifications:

   %SystemRoot%\System32\xcopy.exe "%~dp0File1.txt" "%~dp0File2.txt" /Y
   

3. Change working directory to directory of batch file using cd:

   cd /D "%~dp0"
   %SystemRoot%\System32\xcopy.exe "File1.txt" "File2.txt" /Y
   

   This does not work for UNC paths because command interpreter cmd does not support a UNC path as current directory by default, see for example CMD does not support UNC paths as current directories for details.

Solution 2:

The error message is very self explanatory. The file file1.txt is not found.

Because the file name does not include an absolute path, the system tries to find it on the current directory. Your current directory does not contain this file.

Your misconception is that the current directory is not the directory that contains the bat file. Those are two unrelated concepts.

You can easily check by adding this two commands in your bat file

echo BAT directory is %~dp0
echo Current directory  is %CD%

you can notice they are different, and that there is a subtle difference in the way the last backslash is appended or not.

So, there are esentially two ways to cope with this problem

1. either change the current directory to match the expected one

   pushd %~dp0
   XCOPY /y "File1.txt" "File2.txt"
   popd
   

2. or specify the full path in the command

   XCOPY /y "%~dp0File1.txt" "%~dp0File2.txt"
   

Solution 3:

For the sake of completeness and obscurity, I add another workaround, confirmed as working under Windows 8.1 and expected to work elsewhere, as it relies on documented functionality:

You can change the runas command definition keys
HKEY_CLASSES_ROOT\batfile\shell\runas\command and
HKEY_CLASSES_ROOT\cmdfile\shell\runas\command into

%SystemRoot%\System32\cmd.exe /S /C "(for %%G in (%1) do cd /D "%%~dpG") & "%1"" %*

Which results in the bat or cmd file starting in its containing directory when started using the runas verb, respectively the "Run as Administrator" menu entry.

What the additions to the original command exactly do:

• cmd /S strips away first and last (double) quote in command string after /C
• for %%G in (%1) do enumerates its single entry, the %1 argument, making it available for expansion as %%G in the loop body; the letter is arbitrary but some may be "reserved"
• %%~dpG expands to the drive and path of %%G, the ~ tilde stripping away quotes if present, which is why we add them back explicitly
• cd /D changes both the drive and directory to its argument, and finally
• & runs the second command "%1" %* regardless of success of the first one.

You can use pushd which will even support UNC paths, but a stray popd would land any script in the system32 directory, not a behavior I would be fond of.

It should be possible to do this for the exefile entry as well, but frankly, I'd rather live with the inconsistency than to attempt this on my system, as any error there could break a lot.

Enjoy defeating the security mechanics of your operating system :)