UAC - Batch Files just Blink (Do Nothing) when Run-as-Administrator

If the following is true:
1. A batch file resides in a path that is unprotected by windows like C:\Temp or D:\Anything, and,
2. any of the folders in the path, or the name of the batch file, contain the "(" opening parenthesis, and,
3. the batch file is run by clicking/selecting Run-as-Administrator.

The batch file will blink and process no commands, no matter what commands are in the batch file.

Also Note:
1. If a batch file resides in any path that is protected by windows like C:\Program Files (X86).

The batch file will always operate correctly however it's run, even if the batch file is named Test(.bat.
Notice here that the path "C:\Program Files (X86)" as well as the batch file name "Test(.bat" both contain the "(" opening parenthesis character, yet all works fine so long as it's in a windows protected path.

Does anyone know why this behavior is so?
The answer could provide crucial information needed to solve a much more difficult UAC elevation issue that I am having.

Also, for all those folks on forums that have wondered why their elevated batch files just blink at them. Here is an answer.
Check for those oddball path/file names with characters other than the hyphen, underscore, numbers and letters.

I know the "(" opening parenthesis character does its dirty work but I have not tried any other characters.
In researching this issue I did see another post sighting the same issue when the path contained an @ character and a space character anywhere in the path.

A .Bat files is old MS-DOS file designed to run under command.com we now use . CMD to run modern files

From Wikipedia:
New Quote from Wikipedia

The only known difference between .cmd and .bat file execution is that in a .cmd file the ERRORLEVEL variable changes even on a successful command that is affected by Command Extensions (when Command Extensions are enabled), whereas in .bat files the ERRORLEVEL variable changes only upon errors.

The source for the Wikipedia quote above is actually based on this news group posting.

The differences between .CMD and .BAT as far as CMD.EXE is concerned are: With extensions enabled, PATH/APPEND/PROMPT/SET/ASSOC in .CMD files will set ERRORLEVEL regardless of error. .BAT sets ERRORLEVEL only on errors.

Therefor I can rename AnyBatchFile.bat to AnyBatchFile.cmd and it will operate correctly as long as it does not depend on the aforementioned ERRORLEVEL differences.

So to be clear, using AnyThing.cmd produces the same error described above.
Using the .cmd extension is just as broken as using the .bat extension.

Unfortunately this incorrect behaviour is the default. The problem relates to the fact that the path has a space in it, not because the folder is “protected”.

You can fix this behaviour by merging the attached registry file, you should just try to avoid it though.

I tested every win 8.1 and win 7 box I have and, they all have the "default" setting which I will consider to be an error. No out-of-the-box win 7 or win 8.1 setup will operate a batch file with a "(", and who knows what else, in the filename or path.

After examining Pyprohly's fix.reg file, I realized that the fix is to surround the cmd.exe parameters in the registry key with double quotes.

This is the standard practice for creating shortcuts of the type:
C:\Windows\System32\cmd.exe /C or /K "parameters".
The parameters are always outside quoted unless one wishes to invite random disasters due to, but not limited to, spaces that may appear in the parameters sometime in the future.

I sure would like to know why MS made such a decision if this is planned or if this is just an error.
And, it is quite curious why a batch file that resides in "C:\Program Files (x86)\Test(.bat", which has a "(" in the path and filename works without the additional fix of surrounding the parameters with double quotes.

I wonder.
Did MS decide against the outer quotes for a reason? Is there some hidden thing in windows that causes cmd.exe to interpret unquoted parameters with characters like @, (, etc... in the path or filename with a different response versus plain vanilla paths and filenames?

eewiz said:

And, it is quite curious why a batch file that resides in "C:\Program Files (x86)\Test(.bat", which has a "(" in the path and filename works without the additional fix of surrounding the parameters with double quotes.

It relates back to the finicky way Cmd parses it’s arguments.

Consider the following.

Code:

[1] C:\Users\Pyprohly>type "C:\foo\file(.bat"
@echo Hello World! %*
[2] C:\Users\Pyprohly>type "C:\foo\file.bat"
@echo Hello World! %*
[3] C:\Users\Pyprohly>type "C:\f oo\file(.bat"
@echo Hello World! %*
[4] C:\Users\Pyprohly>
[5] C:\Users\Pyprohly>cmd /c "C:\foo\file(.bat" 1 2 3
Hello World! (.bat 1 2 3

[6] C:\Users\Pyprohly>cmd /c ""C:\foo\file(.bat" 1 2 3"
Hello World! 1 2 3

[7] C:\Users\Pyprohly>cmd /c "C:\f oo\file(.bat" 1 2 3
Hello World! 1 2 3

[8] C:\Users\Pyprohly>cmd /c ""C:\f oo\file(.bat" 1 2 3"
Hello World! 1 2 3

In line 5, the bracket delimits the command, so it’s as if you’re running the program “C:\foo\file” with “(.bat” as the first argument. If “C:\foo\file.bat” didn’t exist, “C:\foo\file” would have not been found and the command would have failed.

In line 7, the path contains a space. The bracket is no longer treated as a delimiter. It works just because it works. Why? Don’t even ask Microsoft; they won’t know the answer.

This exemplifies the importance of always wrapping all of the arguments of ‘cmd /c’ and ‘cmd /k’ in double quotes as a precaution that should be extrapolated from the Cmd’s help document. Not even Microsoft could get this right.

I agree with Pyprohly, Microsoft should have done better when creating all those hidden methods to run stuff on cmd.exe from shortcuts, schedules, elevations, etc... I would surmise that it was Tim Paterson that created this mess and Bill Gates never changed it thereafter when he used QDOS from SCP to create PC-DOS v1. In the 8.3 world of DOS, the features provided by these special characters might have been valuable. But now, I guess it's buyer beware.

This is the only hint of special characters I have found. It comes from the cmd.exe help obtained from running CMD /?.
The special characters that require quotes are:
<space>
&()[]{}^=;!'+,`~

There is no other mention of any use of these characters other than the requirement to be quoted.
At first I was reluctant to change the registry. There is always that thought that Microsoft might have had a good reason. But, even if so, that reasoning works against me, so I added quotes to all of the pertinent registry entries on all of my boxes. I have always been able to get out of the batch language, what I need to maintain my boxes, without ever having to use any of those special characters. So, I figure that I will not miss them.

Thank you for your explanation of the issue.