Suddenly can't run bat files as administrator

I know this thread is old as crap, so I apologize for resurrecting it; but I was having the EXACT same issue, and found what was causing it. My batch file was running the following "cd "%~dp0"" to navigate to the directory that the batch file was running out of; but upon right-clicking, and selecting "Run as administrator", the path defaults to C:\Windows\System32\. The batch file that I was attempting to run lived on the E:\ drive, so I simply had to change the batch file to "cd /d "%~dp0"" (the /d switch tells cd to change drives as well as paths), and then it began working correctly. This effectively fixed my issue. Hopefully this might help SOMEONE save some time in the future! =)

jbrivers7 said:

I know this thread is old as crap, so I apologize for resurrecting it; but I was having the EXACT same issue, and found what was causing it. My batch file was running the following "cd "%~dp0"" to navigate to the directory that the batch file was running out of; but upon right-clicking, and selecting "Run as administrator", the path defaults to C:\Windows\System32\. The batch file that I was attempting to run lived on the E:\ drive, so I simply had to change the batch file to "cd /d "%~dp0"" (the /d switch tells cd to change drives as well as paths), and then it began working correctly. This effectively fixed my issue. Hopefully this might help SOMEONE save some time in the future! =)

Wonderful! Thank you.

Supported characters for a file name are letters, numbers, spaces, and ( ) _ - , .

*Please note file names should be limited to 100 characters.

Characters that are NOT supported include, but are not limited to:

@ $ % & \ / : * ? " ' < > | ~ ` # ^ + = { } [ ] ; !

I had the same problem today.
I had the following line in my batch file to elevate the script to Administrator if it's not:

Code:

@pushd %~dp0 & fltmc | find "." && (echo Opening CMD as admin... && powershell start '%~f0' ' %*' -verb runas 2>nul && exit /b)

This used to work fine, but apparently after one of Windows 10's updates caused a change to the way the fltmc.exe command runs. Now it's just stuck in a loop re-spawning a CMD window with the text UCPD.

The fix?
Replace the "." with "Access is denied", so the working command is:

Code:

@pushd %~dp0 & fltmc | find "Access is denied" && (echo Opening CMD as admin... && powershell start '%~f0' ' %*' -verb runas 2>nul && exit /b)

Well IDK and I am not going to play around with my system. Have you tried installing "sudo" ( nickname command that calls the security box ) and then running whatever after that?

I forget how to install via cmd ( I know there are an infinite number of ways to do so which I have played around with ).
but you should try doing so.

One thing I find funny based on how you startup CMD ( or powershell, Windows Terminal ) you may or may not have access to system-wide resources in comparison to local-resources ( which might force somebody to log into the true/hidden administrators account to performs certain tasks ).

This problem might be based off on how the users account ( local ) is configured as administrator ( when you elevate the status ).
Or even the installation of the OS you are using out of the box ( as there are many settings that can only be done within the Regedit, or your program of your choice.

..

The bigger question should be Do you need to be "sudo" in order to perform the specific task? Can you perform the task without being "sudo" ? Is the account you are using a local account and does it make any difference if it is administrator or not?
Can you perform the task by logging into the true / hidden administrators account.

MaloK said:

Supported characters for a file name are letters, numbers, spaces, and ( ) _ - , .

*Please note file names should be limited to 100 characters.

Characters that are NOT supported include, but are not limited to:

@ $ % & \ / : * ? " ' < > | ~ ` # ^ + = { } [ ] ; !

MaloK,
From my experience, you should NOT use parenthesis ( ) in a .BAT or .CMD filename.
Technically they are allowed, but they may cause the script to fail.

Try3 said:

There is no such thing as a "true" Admin account.
All Admin accounts are equal.
Any Admin user account created by a user has as much authority as the Built-in Admin account.


All the best,
Denis

The built in Administrators account is the true admin and can over-ride all accounts.
It is literally like using Windows 98 with no accounts and limited if not any security features.
It is advised to only use this account for emergencies, and to turn it off ( hide it ) afterwards.

The account you make when you first install windows is usually a local account and even if you give it administrator status,
it is still without all powers available to the true admin.

A great example for me was adding and removing things in the path. I made an installation and the path was not written. I tried to write in within my account ( a regular account with admin rights ) and it would not function or even it appear it was written or added, still did nothing. I went into the true admin account and perform the same move....BOOM!!! it works.

I can not delete something my account no matter how many times or ways I sudo the file. Without taking ownership I could log into the true admin and BOOM!! the file deletes with no requests and no warnings.

Even if your account is within the groups administrator it is never ( and never should be ) the true administrator by any means at all. Not repeating myself. You get the scenario.

......................

Now working in command-line is a different story all together. You can bypass and have those rights granted to you ( one way or another ). By using texts and commands to do so, or by installing something like sudo which is more or less the same ( but not silent ).

..........................

We make a bat and we want sudo ( admin ) rights, along with silence ( no pop-up or question ). Okay clap clap I applaud this move. That same move could be done without any sudo requests in the true administrators account.

.........................

If there is a way to have those powers-granted to all users system-wide. That is your cup of tea. However imagine the day when something or some-one abuses those admin rights and it is "silent" threat. This is why we avoid using the built in Administrator and give admin rights to #$@$$ users, or have guest accounts ( which is less then local users ).

The local user would be idea in terms of a workstation where you do not want some nutjob to go OB of the program or task at hand. We might be having fun with admin rights but it is never the true admin.