Starting with v1.1.4, bootstrapper fails for unpacked apps with 'access is denied'

[fredemmott]

Describe the bug

Once the runtime is upgraded from v1.1.3 to v1.1.4, unpackaged apps (built with either v1.1.3 or v1.1.4 SDK) fail with:

D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(373)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFD265B8AE7: (caller: 00007FFD265B779A) Exception(1) tid(2780) 80070005 Access is denied.
    Msg:[Error in LoadLibrary: 5 (0x5) loading C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe\Microsoft.WindowsAppRuntime.dll] CallContext:[\Initialize] 

This happens regardless of if the runtime was installed via the MS store, or from the redistributable.

Steps to reproduce the bug

Download and build https://github.com/OpenKneeboard/OpenKneeboard at f25d16439d6f5f5a967846de3608f31853785aba

Try to run the exe

Expected behavior

Bootstrapper loads the runtime libraries

Screenshots

No response

NuGet package version

1.1.4

Packaging type

Unpackaged

Windows version

Windows 10 version 21H2 (19044, November 2021 Update)

IDE

Other

Additional context

The same app works fine with the v1.1.3 runtime, or when packaged.

I'm able to open the DLL in other programs, e.g. DependenciesGui

Downgrading to v1.1.3 fixes the issue.

IDE: VSCode

[btueffers]

https://task.ms/41120526

[fredemmott]

As a workaround, is there any way I can get Windows/the store to stop automatically updating me from 1.1.3 to the broken version? I have no packages installed that depend on the windows app runtime.

[DrusTheAxe]

Does this happen when you install WinAppSDK runtime 1.1.4 as the 1st/only WinAppSDK packages on the machine? When 1.1.3 is installed and you update to 1.1.4?

There's an odd ACL issue that might be the culprit here. Please run

icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe\Microsoft.WindowsAppRuntime.dll"

and share the result. And if you also have 1.1.3 installed please do that same for that too.

[fredemmott]

Okie, so starting with get-appxpackage -name '*AppRuntime*' | remove-appxpackage:

1. installing 1.1.3 from installer at https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads
2. all is good
3. windows automatically upgrades to 1.1.4 - 1.1.3 is still partially installed: https://gist.github.com/fredemmott/f00b0e2cb401cbc99adf9424c60bc371
4. MSIX package still launches
5. unpackaged exe fails with 'access is denied'

• can open in dependenciesgui
• acls: https://gist.github.com/fredemmott/a2c1eec04f4b77be69ef7f5155149ab7

6. get-appxpackage -name '*AppRuntime*' | remove-appxpackage
7. install 1.1.4 from installer at https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads; 1.1.3 is not installed at all
8. MSIX package still launches
9. unpackaged exe fails with 'access is denied'

• ACLs: https://gist.github.com/fredemmott/76c8e42023f1a93b93e5333a30d8588d

10. get-appxpackage -name '*AppRuntime*' | remove-appxpackage
11. install 1.1.3 again
12. all good, msix and standalone
13. acls: https://gist.github.com/fredemmott/f31b3421972b75f023c0131d330bd249

[fredemmott]

Not used to reading this, but sounds likely related:

• v1.1.3: BUILTIN\Users:(I)(RX)
• v1.1.4: BUILTIN\Users:(R)

[m2jean]

Having the same issue with my unpackaged app and 1.1.4. It works after I grant RX permission to the DLLs but they get randomly reset

[DFX-Coding]

I have the same problem with unpackaged apps and SDK v1.1.4. Debugging in Visual Studio 2022 does not work anymore either, then the error code appears: The program "[15828] TestProg.exe" was terminated with code 2147942405 (0x80070005).

[DrusTheAxe]

• v1.1.3: BUILTIN\Users:(I)(RX)
• v1.1.4: BUILTIN\Users:(R)

That is extremely interesting. Do you know the repro to produce this? Would this be in the above 13 steps as steps 3.5 run ICACLS on 1.1.3 and 7.5 run ICACLS on 1.1.4 ?

[fredemmott]

Yep, it's the above steps for me; BUILTIN\Users:(R) (1.1.4) on steps 5 and 9, BUILTIN\Users:(I)(RX) (1.1.3) on step BUILTIN\Users:(I)(RX) , both within the full ACLs in the linked gists

[fredemmott]

Checking just the ACLs:

1.1.3

1. Download the 1.1.3 x64 exe installer from https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads
2. Run once downloaded
3. Check ACLs (icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1003.565.600.0_x86__8wekyb3d8bbwe\Microsoft.WindowsAppRuntime.dll"), see BUILTIN\Users:(I)(RX)

1.1.3 -> 1.1.4

1. Download the 1.1.4 x64 exe installer from the same location
2. run once downloaded
3. Check ACLs (icacls "C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe\Microsoft.WindowsAppRuntime.dll")
   • on a clean hyper-v VM running 19044.1288), see BUILTIN\Users:(I)(RX)
   • on my day to day machine (version 19044.1889, installed january, developer mode enabled, Visual Studio 2019 and 2022 installed), see BUILTIN\Users:(I)(R)

[fredemmott]

Left side: my day to day machine Right side: VM

Differences on right side:

• has 'integrity level' below 'owner'
• has 'Inherited from' -> "parent Object' instead of 'None'
• only has one 'Users' entry, not 4

[DrusTheAxe]

1.1.3

... 3. Check ACLs (icacls "...x86..."), see BUILTIN\Users:(I)(RX)

x86 but the 1.1.4 ICACLs is for x64. Wrong path? (but same result?)

[DrusTheAxe]

only has one 'Users' entry, not 4

And notice the last 2 Users have Conditional ACEs(?) for Microsoft.WindowsAppRuntime and YourPhone?

YourPhone is a packaged app using WinAppSDK but I wouldn't expect YourPhone (or any other package) in the ACL for a framework package. Tapping some other Windows folks about this

[fredemmott]

Sorry, yep, wrong path and same results. Interestingly, if I install all mandatory and recommended windows updates in my hyper-v VM (taking me from 19044.1288 to 19044.1889) I can reproduce the R vs RX ACL difference in my VM (RX on 1288, R on 1889), just by installing the v1.1.4 exe

[fredemmott]

Ditto (R + conditional ACLs, not RX), on .1889 and also if I install the optional '2022-08 Cumulative Update Preview for Windows 10 Version 21H2 for x64-based Systems (KB5016688)' to get me to .1949 before installing the windows app runtime

[fredemmott]

On a tangent, self-contained isn't a viable workaround due to https://github.com/microsoft/microsoft-ui-xaml/issues/7281

[DrusTheAxe]

if I install all mandatory and recommended windows updates in my hyper-v VM (taking me from 19044.1228 to 19044.1889) I can reproduce the R vs RX ACL difference in my VM (RX on 1228, R on 1889), just by installing the v1.1.4 exe

If you don't apply any windows updates but otherwise same order of operations does 1.1.4 wind up with RX or R?

[fredemmott]

No updates, v1.1.4 exe on 19044.1288, I get RX

Edit: corrected '1228' to '1288'

[DFX-Coding]

With the Windows App SDK 1.2 Preview 1 the problem does not occur and all unpackaged apps work as they should.

[brent-schmidtbauer]

I have this issue using the 1.2.x variants of the SDK. It only seems to happen on Windows 10 (and upgrade to 11 and the problem goes away). The Windows 10 machines were fully up to date. Downgrading the Win10 machines to v1.1.3 of the SDK allowed them to work as well but any newer version caused the issue.