ExplorerPatcher
ExplorerPatcher copied to clipboard
valinet
WebView2 CPU Usage Issue from Weather Widget
When using the Weather Widget on the taskbar, Microsoft's Edge WebView2 service will glitch/hang and use like 15% CPU consistently which leaves my laptop's processor running at 95 degrees.
There are several processes under COM Surrogate in the task manager that support the widget (Several WebView2 services).
Ending or restarting the widget fixes the issue, however I'm not sure what causes it as it takes several hours for the issue to come up again.
I have changed the update frequency to every minute to see if I can catch something sooner that might be triggering the constant CPU usage.
So it appears sometimes after resuming from sleep, the program hangs when trying to reconnect? Although you can't see it in the screen shot, the contents of the box flickers like crazy which likely is causing the CPU to hang.
Could also be something to do with the DPI scaling as the box content is oversized and is trying to use the laptop screen scaling instead of transitioning to the external monitor.
I've experienced something similar, tried to debug it, and eventually just gave up and disabled the weather widget. Basic details are as follows:
After resuming from sleep overnight, the laptop started to heat up. Task manager showed that the widget was running 30% CPU (on a 12-core system; so 100% on 3+ cores) and had around 4GB of private bytes in memory. Most likely whatever was going wrong was mired in javascript.
Reproducing the effect on demand is practically impossible; sleeping the device and resuming after a minute or two won't do it. My guess is that there's an interaction between the outdated state of the application host and some update on the remote website that happens during sleep.
One possible solution might be to completely drop and reload the weather host after resuming from sleep. The fact that it had managed to run up 4GB of memory usage suggests that periodically starting over is a warranted feature anyway.
Obviously the "correct" solution would be fetching the weather data from an API and displaying it locally so you actually get to control your runtime (and don't incur a 400MB memory penalty under even the best of circumstances). But heaven knows I don't feel like writing it. So I totally get why showing someone else's webpage is where this goes.
If this is happening to you and you have a laptop, check if it has modern stand by. It might be related to this. Is your battery low in power when this also happens?
same thing happening for me, weather widget keep consuming 15~30% cpu usage forever, so I had to disable the weather widget.
Process name WebView2: weather - Google Search under COM Surrogate showing 15~30% CPU usage forever.
Killing the process works for few hours, but it starts again after few hours.
If this is happening to you and you have a laptop, check if it has modern stand by. It might be related to this. Is your battery low in power when this also happens?
It's indeed related. It only happens for me in a laptop which only has a S3 standby. With a Modern Standby laptop it works normally. It doesn't matter if you are on a battery or plugged in.
Since you're running a preview update, please install the latest pre-release version of EP.
Similar effect here, using latest version of EP. Low CPU usage after weather widget loaded. But when clicking the mouse inside a certain widget area, CPU load rises dramatically. CPU load won't go down until restarting EP or disable and then again enable weather option in EP. Clicking anywhere outside the marked area does no harm. See attached screenshots.
If this is happening to you, please include the following:
- windows version and build number. You can find this by running winver.
- EP version. Open up the EP properties application and go to about to find it.
Sorry, I should have included it in my comment. Here is the information requested:
I have the same issue with EP when resuming from sleep or hibernation on my laptop, except that COM Surrogate & child processes use about 30-35% of CPU.
Restarting File Explorer (using the link in bottom left of EP options menu) solves the CPU usage issue until the laptop goes to sleep / resumes, then the issue manifests itself again.
I am running W11 23H2, build 22631.3085 with EP 226212.2861.62.2.
I'm having the same issue on my DESKTOP. I do not use sleep mode and leave my PC on 24/7. The only thing that turns off is my monitor.
EP 22621.2428.59.1 W11 Pro 22H2 22621.3007
I'm having the same issue on my DESKTOP. I do not use sleep mode and leave my PC on 24/7. The only thing that turns off is my monitor.
EP 22621.2428.59.1 W11 Pro 22H2 22621.3007
Please update EP: https://github.com/valinet/ExplorerPatcher/releases/tag/22621.2861.62.2_9b68cc0
I'm having the same issue on my DESKTOP. I do not use sleep mode and leave my PC on 24/7. The only thing that turns off is my monitor. EP 22621.2428.59.1 W11 Pro 22H2 22621.3007
Please update EP: https://github.com/valinet/ExplorerPatcher/releases/tag/22621.2861.62.2_9b68cc0
After updating the issue still persists.
I don't see anyone here claiming this is happening on Windows 10, so I'd like to say that this is indeed happening to me on Windows 10:
Even after upgrading everything, the issue still persists. I notice it because occasionally I will hear my PC fans raging, even while I am not even at my computer. So I go check it out and see the weather widget is the problem.
I ended up completely disabling the weather widget.
Even after upgrading everything, the issue still persists. I notice it because occasionally I will hear my PC fans raging, even while I am not even at my computer. So I go check it out and see the weather widget is the problem.
I ended up completely disabling the weather widget.
If I had to guess, this is probably happening due to a callback leak.
Just now I (again) got a very similar problem. Instead of soon after hibernation it happend "randomly" about ~20 minutes after returning from hibernation. I walked away from my machine and when I came back I could here the fans spinning fast so I immediatly knew what was happening. It was still COM Surrogate but this time it was not the weather but the "gpu process". Not only did it cause a high cpu utilisation but also "ate" my RAM away.
Command line arguments of two most hungry processes:
"C:\Program Files (x86)\Microsoft\EdgeWebView\Application\121.0.2277.112\msedgewebview2.exe" --type=gpu-process --noerrdialogs --user-data-dir="C:\Users\user\AppData\Roaming\ExplorerPatcher\ep_weather_host\EBWebView" --webview-exe-name=DllHost.exe --webview-exe-version=10.0.22621.1 --embedded-browser-webview=1 --embedded-browser-webview-dpi-awareness=2 --no-appcompat-clear --gpu-preferences=WAAAAAAAAADgAAAMAAAAAAAAAAAAAAAAAABgAAAAAAA4AAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAAAAYAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAA== --mojo-platform-channel-handle=2092 --field-trial-handle=2080,i,8537857491189957101,15380455410726052139,262144 --enable-features=MojoIpcz,msSingleSignOnOSForPrimaryAccountIsShared --variations-seed-version /prefetch:2 /pfhostedapp:1e9f6608ee9db5c89957a60288a87d7536191c35
"C:\Program Files (x86)\Microsoft\EdgeWebView\Application\121.0.2277.112\msedgewebview2.exe" --type=renderer --noerrdialogs --user-data-dir="C:\Users\user\AppData\Roaming\ExplorerPatcher\ep_weather_host\EBWebView" --webview-exe-name=DllHost.exe --webview-exe-version=10.0.22621.1 --embedded-browser-webview=1 --embedded-browser-webview-dpi-awareness=2 --allow-insecure-localhost --no-appcompat-clear --lang=en-US --device-scale-factor=1.25 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=11 --js-flags="--harmony-weak-refs-with-cleanup-some --expose-gc --ms-user-locale=" --time-ticks-at-unix-epoch=-1707948004568474 --launch-time-ticks=134328812311 --mojo-platform-channel-handle=4968 --field-trial-handle=2080,i,8537857491189957101,15380455410726052139,262144 --enable-features=MojoIpcz,msSingleSignOnOSForPrimaryAccountIsShared --variations-seed-version /pfhostedapp:1e9f6608ee9db5c89957a60288a87d7536191c35 /prefetch:1
This is a picture that shows the COM surrogate utilisation of CPU and RAM.
I also created a dump of the two processes (each about >3GB). I could upload them but my network connection is very slow so it would take ages. Maybe I will try to analyse them myself.
Similar effect here, using latest version of EP. Low CPU usage after weather widget loaded. But when clicking the mouse inside a certain widget area, CPU load rises dramatically. CPU load won't go down until restarting EP or disable and then again enable weather option in EP. Clicking anywhere outside the marked area does no harm. See attached screenshots.
EP Version 22621.3296.64.1 still does this. Clicking anywhere inside the weather display area will consume 10+% of the CPU until the weather COM process is End Task(ed).
USING: Windows 11 ver 22H2 (0S Build 22621.3296)
I don't see anyone here claiming this is happening on Windows 10, so I'd like to say that this is indeed happening to me on Windows 10:
This also happens to me on windows 10. If I click on any graphic in the popup weather window, the cpu usage goes up. So I don't enable the weather feature in the taskbar.
Hey, EP 22621.3296.64.1, Win 11 Pro (ver 23H2 build 22631.3296) here, memory use goes to space even when widget is unclicked on the taskbar (up to 1.2gb ram out of 8gb), regardless if the widget is loaded or not (sometimes news is not switched to weather, dunno if it happens after standby or at other times as well).
I updated to ExplorerPatcher version 22621.3296.64.1 and now CPU usage is absolutely normal, even when clicking into that certain areas. When the window is not opened, then there is no noticeable CPU usage at all.
This issue seems to be fixed, at least for my configuration and at this point in time.
This is my current Windows version: Windows 11 23H2 Build 22631.3296
Bad news: After waking the PC from sleep mode today, the CPU load was at roughly 75% soaked up by webview2. The weather widget flickered and displays something like "Connection lost afer sleep" (or similar).
After restarting Explorer Patcher, it works ok, but I guess it will throw the same issue tomorrow morning.