[clang-cl] Generates bad manifest XML for Visual Studio UAC settings

[d3x0r]

This is an example of where the settings get set.

Clang-CL generates XML that looks like this

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <ms_asmv1:trustInfo xmlns="urn:schemas-microsoft-com:asm.v3" xmlns:ms_asmv1="urn:schemas-microsoft-com:asm.v1">
    <ms_asmv1:security>
      <ms_asmv1:requestedPrivileges>
        <ms_asmv1:requestedExecutionLevel ms_asmv1:level="requireAdministrator" ms_asmv1:uiAccess="false"/>
      </ms_asmv1:requestedPrivileges>
    </ms_asmv1:security>
  </ms_asmv1:trustInfo>
</assembly>

Where a good manifest looks like

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel
                    level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
            </requestedPrivileges>
        </security>
    </trustInfo>
</assembly>

When the clang generated manifest is used in the program the porgram throws a 'side-by-side installation error' sort of error...

The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

when using the sxstrace tool gave me an error message when I did a profile and converted it to a log...

	ERROR: Line 6: The required attribute level is missing from element requestedExecutionLevel.

level is what it's looking for not ms_asmv1:level apparently. There's no automatic namespacing of tags in most path/node based xml parsers....

I could fall back and run a mt.exe ... command and embed a correct manifest while this is broken... but really respecting the options and building the file should work.

This causes a service or admin tool to not be able to run.

[ckearney-nitro]

I have also experience this issue on clang-cl (18.1.8), using ninja(1.12.0) as the cmake(3.31.0) generator.

INFO: Parsing Manifest File
INFO: Manifest Definition Identity is (null).
ERROR: Line 6: The required attribute level is missing from element requestedExecutionLevel.
ERROR: Activation Context generation failed.

[fredemmott]

This appears to be an error in a transformation/processing step, not just when generating - I get the same error when explicitly included a hand-written manifest file: https://github.com/fredemmott/FUI/blob/dc6501507745b10962a2bddab4696b30326104b3/src/app.exe.manifest

Like namazso, specifying -DCMAKE_MT=mt fixes this.

[fredemmott]

For CMake projects, if CMake uses the microsoft linker and /MANIFESTINPUT when using clang-cl, this is potentially actually:

• https://developercommunity.visualstudio.com/t/MANIFESTINPUT-linker-flag-breaks-manife/10936441?port=1025&fsid=eb444764-e9b1-4bc3-9cba-d47b79249beb
• https://gitlab.kitware.com/cmake/cmake/-/issues/27064

This seems likely given https://github.com/Kitware/CMake/blob/7fcc90c99c23e59d029e7b284284077f9c3eda90/Modules/Platform/Windows-Clang.cmake#L44

[nga888]

I'm pretty sure that a workaround for this specific issue is to specify the lld-link linker option /manifestuac:no when the input manifest file sets the trustInfo.

It appears that lld-link is creating an internal trustInfo in the "urn:schemas-microsoft-com:asm.v1" namespace that causes the use of the ms_asmv1 prefix when it is merged with the input manifest that also defines trustInfo. Specifying /manifestuac:no should prevent lld-link from creating the internal trustInfo.

Not entirely sure if this workaround is feasible within a VS project.