WebView2 dependency in MSIX fails to install on Azure Windows 11 22H2 Pro Gen2

[AliveDevil]

WebView2 dependency in MSIX fails to install on Azure Windows 11 22H2 Pro Gen2

[AliveDevil]

WindowsPackageManagerServer memory dump, link valid until the end of the week: https://1drv.ms/u/s!AqDF3R6HxnoJjLk_MNE2l2MtonKX0Q?e=ZWmESH

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Unable to install MSIX package (#3724), similarity score: 0.78
• Package dependency is not available mid-installation (#3668), similarity score: 0.77

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[stephengillie]

It sounds like Microsoft.EdgeWebView2Runtime might have an issue. Installing it in a WIndows 11 VM ended with:

2024-05-13 07:43:52.016 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/--accept-package-agreements?Market=US
2024-05-13 07:43:52.079 [REPO] Response status: 200
2024-05-13 07:43:52.086 [REPO] Opening database for ReadWrite at 'C:\Users\User\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2024-05-13 07:43:52.087 [REPO] Opened SQLite Index with version [1.6], last write [2024-05-13 07:42:19.000]
2024-05-13 07:43:52.108 [CLI ] No app found matching input criteria
2024-05-13 07:43:52.115 [CLI ] Terminating context: 0x8a150014 at C:__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\WorkflowBase.cpp:3c8

This should probably be moved to the winget-pkgs repo, because it's only impacting 1 package.

[Trenly]

It sounds like Microsoft.EdgeWebView2Runtime might have an issue. Installing it in a WIndows 11 VM ended with:

2024-05-13 07:43:52.016 [REPO] Sending http GET request to: storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/--accept-package-agreements?Market=US
2024-05-13 07:43:52.079 [REPO] Response status: 200
2024-05-13 07:43:52.086 [REPO] Opening database for ReadWrite at 'C:\Users\User\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2024-05-13 07:43:52.087 [REPO] Opened SQLite Index with version [1.6], last write [2024-05-13 07:42:19.000]
2024-05-13 07:43:52.108 [CLI ] No app found matching input criteria
2024-05-13 07:43:52.115 [CLI ] Terminating context: 0x8a150014 at C:__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\WorkflowBase.cpp:3c8

This should probably be moved to the winget-pkgs repo, because it's only impacting 1 package.

@stephengillie - on your VM can you try with --source winget ? It seems to work on my VM

@AliveDevil - I see you have listed Microsoft.WebView2 as the dependency, have you tried Microsoft.EdgeWebView2Runtime? I don't see Microsoft.WebView2 as a valid package in WinGet at all

[AliveDevil]

@Trenly yes, I did try that and AppInstaller refuses to install the package. Can get you the exact error tomorrow morning (CEST).
The Microsoft.WebView2 dependency is supposed to be set like that and the only valid external dependency allowed.

[stephengillie]

@stephengillie - on your VM can you try with --source winget ? It seems to work on my VM

Edit: I thought it proceeded normally, but was mistaken. My Windows 11 VM is somewhat behind on updates. Correction to above - I had a bug in my testing setup. Tested again before adding --source winget - and got this before and after:

2024-05-13 11:21:20.877 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/Microsoft.EdgeWebView2Runtime?Market=US
2024-05-13 11:21:20.938 [REPO] Response status: 200
2024-05-13 11:21:20.943 [REPO] Opening database for ReadWrite at 'C:\Users\User\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2024-05-13 11:21:20.945 [REPO] Opened SQLite Index with version [1.6], last write [2024-03-19 10:48:19.000]
2024-05-13 11:21:20.967 [REPO] Finding installed package from available package using system reference search: Query:[none] Include:ProductCode='microsoft edgewebview'[Exact] Include:NormalizedNameAndPublisher='microsoftedgewebview2runtime'+'microsoft'[Exact]
2024-05-13 11:21:20.969 [CLI ] Found one app. App id: Microsoft.EdgeWebView2Runtime App name: Microsoft Edge WebView2 Runtime
2024-05-13 11:21:20.969 [CLI ] Found installed package, converting to upgrade flow
2024-05-13 11:21:20.978 [REPO] Attempting to open pinning database: C:\Users\User\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db
2024-05-13 11:21:20.978 [REPO] ... opening existing pinning database
2024-05-13 11:21:20.978 [REPO] Opening database for Read at 'C:\Users\User\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\pinning.db'
2024-05-13 11:21:20.979 [REPO] Opened Pinning Index with version [1.0], last write [2024-01-04 12:47:12.000]
2024-05-13 11:21:20.980 [CLI ] Terminating context: 0x8a15002b at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:bc

[AliveDevil]

This is the log output with <win32dependencies:ExternalDependency name="Microsoft.EdgeWebView2Runtime" …:
AppInstaller-2024-05-14-09-42-47.739.log
AppInstaller-2024-05-14-09-42-48.163.log
WinGetCOM-2024-05-14-09-42-50.156.log

[stephengillie]

TImeline:

48 seconds - Unable to read Group Policy

[Tue May 14 09:42:48 2024]{12036} GroupPoliciesAppServiceClient -> Unable to read Group Policy from registry (0x00000002)

AppInstaller-2024-05-14-09-42-48.163.log

51 seconds - Failed to find dependency

[Tue May 14 09:42:51 2024]{2068} Failed when attempting to find the external dependency: Microsoft.EdgeWebView2Runtime
[Tue May 14 09:42:51 2024]{2068} PackageDependencyInstaller -> Reporting error from Windows Package Manager package search for Microsoft.EdgeWebView2Runtime - 0xa0040002

AppInstaller-2024-05-14-09-42-47.739.log

51.047 seconds - File write error:

2024-05-14 09:42:50.802 [REPO] Reading MSI UpgradeCodes
2024-05-14 09:42:50.989 [REPO] Reading MSI UpgradeCodes
2024-05-14 09:42:51.047 [FAIL] C:__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFEB87174CC: (caller: 00007FFEB871E129) Exception(1) tid(20ec) 800700B7 Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist. A file cannot be created if it already exists.

WinGetCOM-2024-05-14-09-42-50.156.log

[JohnMcPMS]

Could you try the following on the VM:

> winget source add test https://cdn.winget.microsoft.com/platform
> winget install Microsoft.WebView2 -s test

This is a manual version of what is happening in the background and will hopefully give us better error details.

[stephengillie]

This was successful in my VM. I'm interested to hear if it was in @AliveDevil's environment also.

[AliveDevil]

The winget installation of WebView2 works, log¹ attached.

AppInstaller still refuses to install the MSIX with the external dependency:
AppInstaller-2024-05-15-08-44-28.432.log
AppInstaller-2024-05-15-08-44-29.298.log

Footnotes

1. WinGet-2024-05-15-08-42-34.279.log ↩

[JohnMcPMS]

Does this system have UAC disabled and the user is a member of the Administrator group?

[AliveDevil]

Confirmed: UAC is enabled (and on the default state).
User is member of the local Administrators group.

System Screenshot

[JohnMcPMS]

Everything is pointing at some problem connecting to the COM server (although launching it just fine), and the only known issue would have been the UAC disabled. It could be the same issue though, just manifesting some other way.

COM traces are likely the best way forward, but they will probably have information similar to what you have been redacting in your responses. I can tell you how to collect them and you can take a shot at analyzing them, or send them along in a more secure fashion if you are comfortable.

You will need this file:
tools/COMTrace/ComTrace.wprp

Then:

[Get AppInstaller ready to Install, but don't Install yet]
> wpr.exe -start <local path to the .wprp file> -filemode
[Click the Install button, wait for it to fail]
> wpr.exe -stop com_trace.etl

You can inspect the resulting .etl file with: https://learn.microsoft.com/en-us/windows-hardware/test/wpt/windows-performance-analyzer

This should contain the reason for the failure, probably on the first (chronologically) trace line with the 0x80070005 error (although it is possible that the root cause has some other HRESULT).

[AliveDevil]

Attached com_trace.etl (unfiltered) for:

• Open AppInstaller of MSIX
• wpr.exe -start
• Click Install
• wpr.exe -stop

com_trace.zip

[JohnMcPMS]

Yes, it does indeed look like another instance of the same issue, based on:

Call security blocked activation call: CLSID:{C53A4F16-787E-42A4-B304-29EFFB4BF597}, Client PID (image):1360 (C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.11261.0_x64__8wekyb3d8bbwe\AppInstaller.exe), Server PID (image): 0x254c (C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.22.11261.0_x64__8wekyb3d8bbwe\WindowsPackageManagerServer.exe)

@yao-msft was going to be looking at fixing this soon, although it isn't clear what exactly is the ACL mismatch in this case. I don't think there is a short-term mitigation that you can do beyond simply avoiding the feature.

[AliveDevil]

Interesting that I ever encountered this now on the Azure image.

My own test VMs - created using Convert-WindowsImage - don't exhibit this issue (neither 22621, nor 22631).

[JohnMcPMS]

Indeed, I'm contacting experts internally to see if they can help understand the issue better.

[JohnMcPMS]

Experts suggest a dump of the server process (WindowsPackageManagerServer.exe) if you can get it after the install attempt fails. Also the contents of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, but that is only helpful if the information in the process dump doesn't make sense.

[JohnMcPMS]

They also suggest killing the server process just before attempting as a test (if it isn't running, then that answers the question as well).

[AliveDevil]

So, I created the memory dump of WindowsPackageManagerServer, but even compressed this file exceeds the maximum allowed file size (25 MiB) with 33 MiB. Any preferred way of sharing that file?

Steps were:

• Close WindowsPackageManagerServer
• Open MSIX, install
• On error created process memory dump with Task Manager

[JohnMcPMS]

Sorry about the delay, some other things came up. I think we understand what we have to do to fix this (thank you for the process dump), but now we are curious as to why it is happening. If you are able and willing, could you confirm whether the WindowsPackageManagerServer process is elevated or not from Task Manager > Details and enabling the Elevated column.

[AliveDevil]

No worries for the delay.

The WindowsPackageManagerServer is indeed elevated.