Why does AppInstance.GetActivatedEventArgs return E_ACCESSDENIED when running as Admin?

[stevenbrix]

We have a packaged MSIX application which has a custom CMake based build system. We use AppInstance to handle single instancing, and when we get the activation event args through AppInstance.GetActivatedEventArgs while running as admin, it fails with E_ACCESSDENIED.

I'm not able to reproduce with a C++ or C# project created through Visual Studio, so it seems somehow related to something our build is/isn't doing. Any tips on why this API would fail this way would be super helpful, thanks! 🙏

[DarranRowe]

The two big questions are:

1. Are you properly initialising the apartment. The winrt::init_apartment call that happens in the generated wWinMain initialises the apartment to STA. It does the equivalent of calling RoInitialize with the parameter of RO_INIT_SINGLETHREADED.
2. Have you tried attaching a debugger to the application? While Visual Studio will not attach to installed .msix packages, Add-AppxPackage with the -Register option will install loose files in development mode. WinDbg is capable of attaching to an application running in a package too. I ask this because there could be a more substantial message being reported via RoOriginateError or OutputDebugString to the debugger.

[stevenbrix]

First off, thank you so much for the quick response!!

1. I'm assuming so since the app runs fine in non-admin?
2. Yeah I have, this is the output:

C:\__w\1\s\dev\WindowsAppRuntime_Insights\WindowsAppRuntimeInsights.h(44)\Microsoft.WindowsAppRuntime.dll!00007FFC2CCA8FBC: (caller: 00007FFC2CCA8EEC) LogHr(1) tid(8170) 8007029C An assertion failure has occurred.
C:\__w\1\s\dev\WindowsAppRuntime_Insights\WindowsAppRuntimeInsights.h(44)\Microsoft.WindowsAppRuntime.dll!00007FFC2CCA8FBC: (caller: 00007FFC2CCA8EEC) LogHr(2) tid(8170) 8007029C An assertion failure has occurred.
    Msg:[Failed to load resource string. id: 10001] 
ModLoad: 00007ffc`2e560000 00007ffc`2e680000   C:\Windows\System32\execmodelclient.dll
ModLoad: 00007ffc`4bea0000 00007ffc`4bedf000   C:\Windows\System32\Windows.Shell.ServiceHostBuilder.dll
ModLoad: 00007ffc`2db80000 00007ffc`2dba7000   C:\Windows\system32\execmodelproxy.dll
onecoreuap\base\appmodel\execmodel\client\applicationinstance\applicationinstance.cpp(58)\execmodelclient.dll!00007FFC2E5A3E7C: (caller: 00007FFC2CCC5D7C) ReturnHr(1) tid(8170) 80070005 Access is denied.
    CallContext:[\GetActivatedEventArgsClient] 
C:\__w\1\s\obj\Release\ARM64\WindowsAppRuntime_DLL\Generated Files\winrt\Windows.ApplicationModel.h(219)\Microsoft.WindowsAppRuntime.dll!00007FFC2CCC5DB4: LogHr(3) tid(8170) 80070005 Access is denied.
    [auto __cdecl winrt::impl::consume_Windows_ApplicationModel_IAppInstanceStatics<struct winrt::Windows::ApplicationModel::IAppInstanceStatics>::GetActivatedEventArgs(void) const]
(6ee4.8170): C++ EH exception - code e06d7363 (first chance)
(6ee4.8170): C++ EH exception - code e06d7363 (first chance)
Microsoft.WindowsAppRuntime.dll!00007FFC2CD6D768: ReturnHr(1) tid(8170) 80070005 Access is denied.
    Msg:[winrt::hresult_error: Access is denied.] 

[DarranRowe]

I had the time to test this out today.
I could not get this to fail, even when building the entire package by hand. I also tested this out on my ARM64 Surface since I saw the platform there. This wasn't a WinUI based project, it was a Windows API project. It had a reference to the Windows App SDK since I was using the custom title bar functionality. Using the Windows App SDK is easier to do this.
I added the instancing functionality to my main function, and I tried using both Windows.AppModel.AppInstance.GetActivatedEventArgs and Microsoft.Windows.AppLifecycle.AppInstance.GetActivatedEventArgs.
The general build process that I used was:

1. Generate the projection using C++/WinRT. This is done in two/three steps. The first generates the projection for Windows. If targetting the Windows App SDK 1.6, the second is to generate the WebView2 projection, referencing the Windows metadata. The second if targetting 1.5 or older, or the third for 1.6 is to generate the Windows App SDK projection referencing the Windows metadata and, if targetting the Windows App SDK 1.6, referencing the WebView2 metadata.
2. Compile all of the source files.
3. Generate the application manifest.
4. Compile my main application resources.
5. Compile the resource file to include the application manifest.
6. Link the executable, linking against all .obj files generated in step 1, and both .res files generated in steps 3 and 4.
7. Copy the executable file to my application packaging directory.
8. Make the .msix file.

The application manifest stuff there basically sidesteps using the linker. For this example, the two source manifest files that I used were:

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

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:ws="http://schemas.microsoft.com/SMI/2005/WindowsSettings" xmlns:ws4="http://schemas.microsoft.com/SMI/2016/WindowsSettings" xmlns:ws6="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
  <assemblyIdentity version="1.0.0.0" name="CompositionUITest.App"/>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows 10-->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <ws:dpiAware>true/PM</ws:dpiAware>
      <ws4:dpiAwareness>PerMonitorV2, PerMonitor</ws4:dpiAwareness>
      <ws6:activeCodePage>UTF-8</ws6:activeCodePage>
    </windowsSettings>
  </application>
</assembly>

I generated the output manifest with mt.exe and then compiled that into a resource using a simple .rc file:

#include "winres.h"

LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST CompositionUITest.exe.manifest

The package manifest that I used was:

<?xml version="1.0" encoding="utf-8"?>
<Package
	xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
	xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
	xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"
	xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
	xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
	IgnorableNamespaces="mp uap uap10 rescap">
	<Identity Name="CompositionUITest" Publisher="CN=Darran" Version="1.0.0.0" ProcessorArchitecture="x64" />
	<mp:PhoneIdentity PhoneProductId="93d91935-e381-43fa-95a6-ea8b0986c04a" PhonePublisherId="00000000-0000-0000-0000-000000000000" />
	
	<Properties>
		<DisplayName>CompositionUITest</DisplayName>
		<PublisherDisplayName>Darran</PublisherDisplayName>
		<Description>CompositionUITest test application.</Description>
		<Logo>Images\PackageLogo.png</Logo>
	</Properties>
	<Dependencies>
		<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
		<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
		<PackageDependency Name="Microsoft.WindowsAppRuntime.1.6" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" MinVersion="6000.242.101.0" />
		<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" MinVersion="14.0.33728.0" />
	</Dependencies>
	<Applications>
		<Application Id="App" Executable="CompositionUITest.exe" uap10:RuntimeBehavior="packagedClassicApp" uap10:TrustLevel="mediumIL">
			<uap:VisualElements
				DisplayName="CompositionUITest"
				Description="Composition Test Application"
				BackgroundColor="transparent"
				Square150x150Logo="Images\Logo150x150.png" Square44x44Logo="Images\Logo44x44.png">
		</uap:VisualElements>
		</Application>
	</Applications>
	<Capabilities>
		<rescap:Capability Name="runFullTrust" />
		<rescap:Capability Name="allowElevation" />
	</Capabilities>
</Package>

I didn't generate the .pri file for this since I wasn't using it in the application, and I didn't need it for the package due to this being a test.
Right now, you need to provide more information on what you are building and how you are building it. You don't need to really provide source code. It would also be useful to know if the application is intended to be self contained and using WinUI. If you are using WinUI, how are you running the Xaml compiler?
Also, when precicely are you using AppInstance? The documentation for Windows.ApplicationModel.AppInstance states "The AppInstance class is intended to be used in the Main method of the app. If this class is used later, the property values may be null, and the methods may fail." This is more .NET centric, but it applies to main/wmain/WinMain/wWinMain for C++. This does apply to the Windows App Runtime version, since it calls through to Windows.AppModel.AppInstance when running in a package.

[stevenbrix]

Thank you so much for trying all of this out! I've indeed also tried everything to recreate our environment and have not had any luck. Your manifest has different attributes to mark it as a Win32 app, so maybe there is something there (we use EntryPoint="Windows.FullTrustApplication") but this isn't a problem in my testing.

We don't run the xaml compiler, and we build using Swift. Due to the nature of our application, the .exe that is built is a C++ application built using GN which loads a swift DLL inside winMain and calls an export on the Swift DLL. A few things are done before loading the swift dll, but we don't use any WinRT (WinAppSDK or UWP).

The first thing we do when this swift DLL is loaded is get the event args from the AppInstance. The swift dll is built like a normal WinUI application at that point (although the issue occurs before anything WinUI happens).

This works fine when running in non-admin, so I don't really think it's anything we're doing in Swift, but probably something in the C++ executable. I even tested with a swift executable loading a swift dll and that's fine.

<security>
  <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="false" />
  </requestedPrivileges>
</security>

we don't currently have this in our side-by-side manifest, is this required? i wouldn't think so since it's not in my C++/C#/Swift repro apps which work fine

[DarranRowe]

Your manifest has different attributes to mark it as a Win32 app, so maybe there is something there (we use EntryPoint="Windows.FullTrustApplication") but this isn't a problem in my testing.

As documented, uap10:RuntimeBehaviour set as packagedClassicApp and uap10:TrustLevel set as mediumIL is equivalent to windows.fullTrustApplication.

we don't currently have this in our side-by-side manifest, is this required?

The documentation recommends it, although it shouldn't make much of a difference. I just provided the full instructions on how I generated and embedded the manifest so it was complete.

The first thing we do when this swift DLL is loaded is get the event args from the AppInstance. The swift dll is built like a normal WinUI application at that point (although the issue occurs before anything WinUI happens).

Since you leave the main function, this could do it. Since you seem to be in the undocumented behaviour territory here, success in some situations is a valid outcome. It could very well be that the Swift DLL does something extra when running as administrator, or it just takes some more time for the library to do its work. Just as a test, and since it is reference counted, try obtaining the event args before loading the Swift DLL.

[stevenbrix]

Since you leave the main function, this could do it.

Perhaps, although seems unlikely, the cxx main method looks like this :

wWinMain() {
  // do stuff
  return swift_main(); // this synchronously calls AppInstance.GetActivatedEventArgs
}

Just as a test, and since it is reference counted, try obtaining the event args before loading the Swift DLL.

Either way, I have some good news! There was something we are doing inside our main method which causes this to happen (I don't quite know what yet). But if I load our swift DLL earlier in the main method then it works as expected. It could be something we're doing in main or perhaps since we're returning from main like i showed above. Either way this gives me something to go on.