MicrosoftEdge / WebView2Feedback

Feedback and discussions about Microsoft Edge WebView2
https://aka.ms/webview2
423 stars 51 forks source link

[Problem/Bug]: WebView2 deadlocks and crashes when sending large messages on ARM64 Windows with x64 target #4589

Open andrewmd5 opened 1 month ago

andrewmd5 commented 1 month ago

What happened?

Description: When running a WebView2-based application built with C# targeting x64 on an ARM64 Windows machine, attempting to send large messages to the WebView2 control leads to deadlocks and eventual crashes of the entire application. This issue occurs in the following scenarios:

  1. Returning large data from a [ComVisible] method on a bridge between C# and JavaScript.
  2. Posting large JSON payloads to the WebView2 control using CoreWebView2.PostWebMessageAsJson.
  3. Sending large strings to the WebView2 control using CoreWebView2.PostWebMessageAsString.

The application becomes unresponsive and eventually crashes, indicating a fundamental issue with the translation layer for WebView2 when running x64 applications on ARM64 Windows.

Expected behavior: The application should be able to send and receive large messages without any deadlocks or crashes, regardless of the target platform (x64) and the underlying architecture (ARM64).

Actual behavior: The application deadlocks when attempting to send large messages to the WebView2 control and eventually crashes, making it impossible to use WebView2 reliably in x64 applications running on ARM64 Windows.

Additional context: This issue is critical for developers targeting x64 applications that use WebView2 and need to support ARM64 Windows devices, especially since Steam only supports the x64 platform. The deadlocks and crashes make it impossible to use WebView2 reliably in such scenarios, severely limiting the usability of the control on ARM64 Windows machines.

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime), Prerelease (Edge Canary/Dev/Beta)

Runtime Version

1.0.2526-prerelease

SDK Version

1.0.2526-prerelease

Framework

Win32 (.NET 9) (I am manually creating and managing my window without winforms or WPF, but the official example apps crash too.)

Operating System

Windows 11

OS Version

No response

Repro steps

  1. Set up a Windows 11 ARM64 virtual machine running on macOS with an M1 processor.
  2. Create a C# application that uses WebView2 and targets the x64 platform (as it is the only platform supported by Steam).
  3. Implement a scenario where large messages are sent to the WebView2 control, such as:
    • Returning large data from a [ComVisible] method on a bridge between C# and JavaScript.
    • Posting large JSON payloads using CoreWebView2.PostWebMessageAsJson.
    • Sending large strings using CoreWebView2.PostWebMessageAsString.
  4. Run the application on the ARM64 Windows virtual machine.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

andrewmd5 commented 1 month ago

Some crash info:

Fault bucket 1639157105078463052, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: compressorx.exe
P2: 1.0.0.11
P3: 6646f262
P4: ntdll.dll
P5: 10.0.22621.3593
P6: 812b397d
P7: c0000005
P8: 00000000001d6f98
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.d00e9227-7fe9-454e-b8f0-e701b29cb342.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.38670882-5f29-4dba-acde-68877782290b.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.ccfda5c3-fe80-4039-90e0-358097037657.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.0671375e-8927-4f06-a5a7-96b8e1012cef.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.07b33bf9-887a-496e-b0a3-6acadc0ca8d9.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_compressorx.exe_a7f95b6fcd2a72ac12e2c82357ba29a1e281da9e_87b9f108_c7019dee-4a66-4ef1-8c1e-f7b0de9b6299

Analysis symbol: 
Rechecking for solution: 0
Report Id: 8531dd0b-9038-47e9-b9cd-cb3a64776407
Report Status: 268435456
Hashed bucket: 5618e262cccf96e526bf74b3d3426a4c
Cab Guid: 0
Faulting application name: compressorx.exe, version: 1.0.0.11, time stamp: 0x6646f262
Faulting module name: ntdll.dll, version: 10.0.22621.3593, time stamp: 0x812b397d
Exception code: 0xc0000005
Fault offset: 0x00000000001d6f98
Faulting process id: 0x0x424C
Faulting application start time: 0x0x1DAB5B17BF5FF8A
Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\CompressorX\compressorx.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 8531dd0b-9038-47e9-b9cd-cb3a64776407
Faulting package full name: 
Faulting package-relative application ID: 

Report.wer.zip

Faulting application name: compressorx.exe, version: 1.0.0.11, time stamp: 0x6646f262
Faulting module name: xtajit64.dll, version: 10.0.22621.3527, time stamp: 0x4ddf3cc7
Exception code: 0xc0000005
Fault offset: 0x000000000003c348
Faulting process id: 0x0x2728
Faulting application start time: 0x0x1DAB5B1F0EE0D74
Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\CompressorX\compressorx.exe
Faulting module path: C:\Windows\System32\xtajit64.dll
Report Id: 63822674-7870-45d1-b30e-6a41b677f145
Faulting package full name: 
Faulting package-relative application ID: 
Fault bucket 1728986764558992126, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: compressorx.exe
P2: 1.0.0.11
P3: 6646f262
P4: xtajit64.dll
P5: 10.0.22621.3527
P6: 4ddf3cc7
P7: c0000005
P8: 000000000003c348
P9: 
P10: 

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.d64c0ab0-feaf-42c9-bd35-ed74cd8b50b9.tmp.dmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.41e9a5d7-2b59-4d6d-bf06-b7581336bce1.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.5c778894-a8c8-460b-b5f7-2677b2611c08.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.841ba235-250c-44d9-a217-8c407a081368.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.b9c2faa5-3b18-4950-aa3f-1766314d107c.tmp.xml

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_compressorx.exe_eeb18023cd9dd7529dd5d1d050687f12d0e13466_87b9f108_9c81fd0c-133b-40a2-8ccb-9760f303134b

Analysis symbol: 
Rechecking for solution: 0
Report Id: 63822674-7870-45d1-b30e-6a41b677f145
Report Status: 268435456
Hashed bucket: bbedcc1ddb0951f357fe984d42e402fe
Cab Guid: 0

Report2.wer.zip

andrewmd5 commented 1 month ago

FYI @david-risney while looking into this I noticed there is a misconfiguration in the Common.targets that causes ARM64 builds to use the x86 WebView2Loader

Here is the fix:

<PropertyGroup>
  <EffectivePlatform>$(Platform)</EffectivePlatform>
  <EffectivePlatform Condition="'$(EffectivePlatform)' == 'Win32'">x86</EffectivePlatform>
  <EffectivePlatform Condition="'$(EffectivePlatform)' == 'Any CPU'">x86</EffectivePlatform>
  <EffectivePlatform Condition="'$(EffectivePlatform)' == 'AnyCPU'">x86</EffectivePlatform>
  <EffectivePlatform Condition="'$(NETCoreSdkRuntimeIdentifier)' == 'win-x86'">x86</EffectivePlatform>
  <EffectivePlatform Condition="'$(NETCoreSdkRuntimeIdentifier)' == 'win-x64'">x64</EffectivePlatform>
+ <EffectivePlatform Condition="'$(NETCoreSdkRuntimeIdentifier)' == 'win-arm64'">arm64</EffectivePlatform>
  <EffectivePlatform Condition="'$(PlatformTarget)' == 'x64'">x64</EffectivePlatform>
  <EffectivePlatform Condition="'$(PlatformTarget)' == 'x86'">x86</EffectivePlatform>
+ <EffectivePlatform Condition="'$(PlatformTarget)' == 'arm64'">arm64</EffectivePlatform>
  <EffectivePlatform Condition="'$(PlatformTarget)' == 'Any CPU' And '$(WebView2ProjectKind)' == 'managed'">anycpu</EffectivePlatform>
  <EffectivePlatform Condition="'$(PlatformTarget)' == 'AnyCPU' And '$(WebView2ProjectKind)' == 'managed'">anycpu</EffectivePlatform>
  <EffectivePlatform Condition="'$(PlatformTarget)' == '' And '$(WebView2ProjectKind)' == 'managed'">anycpu</EffectivePlatform>
</PropertyGroup>

This doesn’t fix the original issue, however.