[Problem/Bug]: [Fixed Version][120] Render process crashes on startup on recent dev builds

[albahari]

What happened?

On recent dev builds (120.0.2172.1 and 120.0.2186.2), the render process crashes immediately when WebView2 is run from a folder other than %programfiles(x86)\Microsoft\Edge Dev\Application(version).

Is this a known issue?

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Prerelease (Edge Canary/Dev/Beta)

Runtime Version

120.0.2186.2

SDK Version

1.0.2088.41

Framework

Winforms

Operating System

Windows 11

OS Version

10.0.22621.0

Repro steps

Extract the WebView2 files from 120.0.2186.2 into c:\WebView\120.0.2186.2 and run the following:

string runtimeFolder = @"c:\WebView\120.0.2186.2";
string dataFolder = @"c:\WebView\Data";

if (!Directory.Exists (dataFolder))
    Directory.CreateDirectory (dataFolder);

var env = await CoreWebView2Environment.CreateAsync (runtimeFolder, dataFolder);

var webView2 = new WebView2 { Dock = DockStyle.Fill };
var form = new Form { Width = 1000, Height = 1000 };
form.Controls.Add (webView2);

form.Load += async (sender, args) =>
{
    await webView2.EnsureCoreWebView2Async (env);

    webView2.CoreWebView2.ProcessFailed += (sender, args) =>
        form.Text = "Error: " + args.ProcessFailedKind + ", " + args.Reason;

    webView2.Source = new Uri ("https://microsoft.com");
};

form.Show();

Instead of displaying a web page, the form title shows "Error: RenderProcessExited, Crashed".

Regression

Regression in newer Runtime

Last working version (if regression)

119.0.2151.44

AB#47503407

[vbryh-msft]

With what exit code it is crashing? Is it some packaged app? cc: @lflores-ms

[albahari]

The exit code is C0000022.

There is no issue with access to the folder in question - it occurs with any folder.

[lflores-ms]

Hi @albahari,

Thanks for reporting. We are aware of this issue and working on a solution before Stable release of 120.
In the meantime, you can ACL the uncompressed directory before WebView creation as a workaround:

icacls <runtime-path> /grant "ALL APPLICATION PACKAGES:(OI)(CI)(RX)"
icacls <runtime-path> /grant "*S-1-15-2-2:(OI)(CI)(RX)"

[albahari]

Thanks. The workaround is effective.

[YesTrustMe]

@albahari , what is the workaround?

[albahari]

@YesTrustMe The workaround is to modify the ACLs as described in #4132 (comment)

[vbryh-msft]

Hey @albahari @YesTrustMe - we have fixed the issue - the workaround should not be needed anymore. Let us know you still see it.

[fvanheeswijk]

@vbryh-msft Is this still needed for Microsoft.WebView2.FixedVersionRuntime.121.0.2277.128.x64.cab?

[vbryh-msft]

@fvanheeswijk the workaround is not needed - we have fixed the issue in 120 Stable.

[fvanheeswijk]

@vbryh-msft Oh that explains why implementing the fix didn't change anything... Maybe it is an idea to remove it from the https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#details-about-the-fixed-version-runtime-distribution-mode documentation? I spent almost a day trying to incorporate this into our WiX installer thinking it was necessary.

[lflores-ms]

Hi @fvanheeswijk,

The existing documentation is accurate. We recommend that you run ACL for Fixed Version runtimes 120 and up when used by unpackaged Win32 applications. The associated feature is currently reduced in some versions which is why you're not seeing a difference but will be fully re-enabled on newer updates.

The underlying feature has different implications for each of the scenarios described in the documentation (unpackaged Win32, packaged Win32, UWP). This ACL requirement is only applicable to unpackaged Win32 apps in Windows 10. Sorry for any confusion.

[fvanheeswijk]

@lflores-ms In that case, how do we test that implementing the fix works? The icacls command seems to have run successfully, however ALL APPLICATION PACKAGES and ALL RESTRICTED APPLICATION PACKAGES haven't gotten the rights shown in the screenshot in the documentation. Neither on Windows 10 nor on Windows 11. The only thing we can do right now is set aside the changes in our installer and test again once we move to a newer fixed version.

Also, does it matter that we have deployed the Fixed Version Runtime inside the program files folder of our application?

[lflores-ms]

The output from icacls should look something like below:

icacls <path> /grant "*S-1-15-2-2:(OI)(CI)(RX)"
processed file: <path>
Successfully processed 1 files; Failed processing 0 files

Make sure the properties of the deployed Fixed Version directory show "ALL APPLICATION PACKAGES" and "ALL RESTRICTED APPLICATION PACKAGES". PowerShell also lets you check programatically with Get-Acl. The output should include the following:

FileSystemRights  : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

The location of the Fixed Version runtime should not make a difference.