Signed and RequireAdministrator executable being run from temp folder?

Question

i manifested my executable as require administrator:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 

    <!-- Disable Windows Vista UAC compatability heuristics -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo> 
</assembly>

And then i digitally signed it.

But then when i run the executable i noticed something odd: the name of the executable on the Consent dialog changed from PingWarning.exe to pinxxxx.tmp; as though a temp copy was made, and that is being run:

i dug out Process Montior, to see if anyone is creating a *.tmp file when i launch my executable, and there is:

The Application Information service inside this particular svchost container is intentionally copying my executable to the Windows temp folder, and asking for user "Consent" from there; giving an invalid filename.

Once consent has been granted, the executable is run from its original location:

The file is not copied to the temp folder if i do not digitally sign it:

---

So my problem is the invalid filename appearing on the consent dialog when i digitally sign my executable which has been manifested as requireAdministrator.

What do?

---

Update:

The closest thing to an explanation i can find comes from Uninformed.org ^🕗:

Breaking the Broker

In the case of a launch request for a program requesting uiaccess, appinfo!RAiLaunchAdminProcess is called to service the request. The process is then verified to be within the (hardcoded) set of allowed directories by appinfo!AiCheckSecureApplicationDirectory. After validating that the program is being launched from within an allowed directory, control is eventually passed to appinfo!AiLaunchProcess which performs the remaining work necessary to service the launch request. At this point, due to the "secure" application directory requirement, it is not possible for a limited user (or a user running with low integrity, for that matter) to place a custom executable in any of the "secure" application directories.

The hint being that are some (undocumented, unspecified) hardcoded paths that an application is "allowed" to be located in.

The other is is for a program requesting uiaccess. In my case i did not have uiAccess="false" in my original manifest. But changing the manifest to include the no ui access:

But that did not fix the original problem.

---

Update Two:

From MSDN:

SendSAS function

Important Applications with the uiAccess flag set to true must be Authenticode signed to start properly. In addition, the application must reside in a protected location in the file system. Currently, there are the two allowable protected locations:

• **\Program Files**
• **\windows\system32**

This seems to backup the notion that an executable requesting uiAccess must be in an allowed location; except i'm not asking for uiAccess.

Answer 1

I have seen the same problem with unsigned applications, specifically with NSIS and InnoSetup installers (A bit of a problem when 1gb+ installers are copied to %windir%\temp and then scanned by consent.exe)

The NSIS bug tracker has a entry about it. Back when I was investigating this, I was in contact with someone @ MS and they were supposed to contact someone that worked on UAC but nothing really came of it. The only applicable information I got from that conversation was this quote:

One friend in Windows had a vague recollection that this may have been a mitigation for a concern about file tampering while the trust dialog was being displayed