You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My application uses WebResourceRequest interception to provide data from a local file to WebView2. We still build an x86 variant and we experience OutOfMemory-Crashes in EmbeddedBrowserWebView.dll when writing a larger response (~120MB). In the x64 build we don't run into that problem.
The API suggests that the response data is streamed to the WebView2 process but it seems that the data is collected before sending which leads to huge memory allocations and then finally to the OutOfMemory situation.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
120.0.2210.61
SDK Version
1.0.2194.0
Framework
Win32
Operating System
Windows 10
OS Version
19045.3803
Repro steps
I used the WebView2Samples repo to reproduce the bug:
Clone WebView2Samples repo
Modify the file SampleApps\WebView2APISample\assets\ScenarioCustomScheme.html so that it's size is larger than 200MB (e. g. by adding a comment which is 200MB in size)
Switch to x86 and build the WebView2APISample app in Release-Mode
Run the app
Select "Scenario / Navigate to custom scheme via WebResourceRequested"
@monica-ch While this mitigates the problem (it crashes then with a ~400MB file with ~2.6GB of memory allocated) I think this can't be regarded as a solution. I think there is an issue with the way the data is forwarded via IPC from the host process to the WV2 process.
I would have expected that the data (~400MB) is at most copied once and then handled within the host process without further memory allocations (that would mean ~800MB memory allocation maximum). But with the x64 build the max. allocated memory is ~3.1GB which is ca. 8 times the size of the original file (400MB). This looks inefficient for me as there are too many memory allocations, probably including duplication of data.
While this results in a crash in this scenario I would assume that this affects every WebResourceRequested usage as data is copied multiple times during processing the request. This looks like an opportunity to optimize the handling of WebResourceRequests.
What happened?
My application uses
WebResourceRequest
interception to provide data from a local file to WebView2. We still build anx86
variant and we experience OutOfMemory-Crashes in EmbeddedBrowserWebView.dll when writing a larger response (~120MB). In thex64
build we don't run into that problem.The API suggests that the response data is streamed to the WebView2 process but it seems that the data is collected before sending which leads to huge memory allocations and then finally to the OutOfMemory situation.
Importance
Important. My app's user experience is significantly compromised.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
120.0.2210.61
SDK Version
1.0.2194.0
Framework
Win32
Operating System
Windows 10
OS Version
19045.3803
Repro steps
I used the WebView2Samples repo to reproduce the bug:
WebView2Samples
repoSampleApps\WebView2APISample\assets\ScenarioCustomScheme.html
so that it's size is larger than 200MB (e. g. by adding a comment which is 200MB in size)x86
and build theWebView2APISample
app in Release-ModeWhen running that with the VS-Memory-Profiler I can see that the private bytes peak at 1.1GB before crashing.
What I would derive from that:
x64
variant the memory peaks at 1.6GB (!) before dropping down. That's ~8 times the size of the response dataRepros in Edge Browser
No
Regression
No, this never worked
Last working version (if regression)
No response
AB#48468066
The text was updated successfully, but these errors were encountered: