What is msedgewebview2.exe, and why is the GPU process busy?
Each copy of msedgewebview2.exe is one process in an app's WebView2 group, and the GPU process is the one that draws that app's pages. High CPU or memory usually comes from the page that app is showing, so quit the app, or restart it so a newer WebView2 Runtime can load. Uninstalling the Runtime breaks the apps that need it, and it usually comes back, since Windows 11 includes it and many apps reinstall it.
The same file, several jobs
Microsoft's end-user FAQ is written for the msedgewebview2.exe rows in Task Manager. The file is the WebView2 Runtime, and it updates on its own. What WebView2 is covers the install and how it differs from the Edge browser.
WebView2 uses Edge's process model. The process model page defines a group as one browser process, one or more renderer processes, and helpers such as the GPU process and the audio service. The FAQ calls the browser process the manager, and adds utility processes such as network or audio. Every role shows up in the Details tab as msedgewebview2.exe, so the file name does not tell you the job.
A group belongs to one user data folder, so two folders make two groups, and the FAQ's usual picture is one set for each app. What is WebView2 Manager in Task Manager? covers the manager row and how a group forms around it.
Renderers are the rows that multiply, typically one for each WebView2 control, and more with Site Isolation. The process model page leaves those rules to Chromium. The browser architecture article it cites says Site Isolation runs a separate renderer for each cross-site iframe, and that each process has its own private memory space.
What the GPU process is doing
The Chrome article's process table says the GPU process handles GPU tasks apart from the other processes, because the GPU draws requests from more than one app on the same surface. WebView2 keeps that split. Microsoft's performance guidance says rendering uses the GPU by default, and that the drivers and extra buffers cost memory. It treats the disable-gpu flag as a troubleshooting switch.
Inside one user data folder the GPU process is shared. A reply on the WebView2 feedback thread says a host's instances share the browser process, the network process, and the GPU process, with a separate renderer per WebView2 by default, for sandboxing. One busy view can raise a GPU row that also serves the folder's other views.
COREWEBVIEW2_PROCESS_KIND names browser, renderer, utility, and GPU, and an unexpected GPU exit is reported to the host app as COREWEBVIEW2_PROCESS_FAILED_KIND_GPU_PROCESS_EXITED.
Which app owns each copy
The Manager article walks through the Processes and Details tabs. Two details matter for a busy GPU row. On Processes, sort by Name first, because the FAQ says another sort can break the grouping under the parent app. On Details, every copy is msedgewebview2.exe; Microsoft's Task Manager article says you change columns by right-clicking a column heading and choosing Select columns. Add the command line. The feedback reply says the Type and Subtype arguments show the kind of process: manager, renderer, GPU, or a utility such as network. Type says what that copy is doing. The parent on Processes says which app.
Microsoft's Microsoft 365 note shows the pattern with Outlook: several WebView2 instances listed under Microsoft Outlook. Process Explorer (procexp.exe), which the FAQ also names, lists each process in its top window with the account that owns it.
Why the CPU or the memory is high
The FAQ says extra memory or CPU usually comes from how WebView2 is being used. A heavy page costs more, in the renderer that holds it and in the shared GPU row that draws the folder.
A page left open can grow past the first paint. The performance guidance says long-running pages can retain resources, that refreshing the WebView returns to a clean baseline, and that newer Runtime builds have fixed many leaks and high-CPU cases. It also says to try the same case in Edge as well as in WebView2 to isolate the issue, since both use the same engine. A page as heavy in Edge is the cost itself, and a spike only in the app points at that app.
An app that never quits can keep an old Runtime. The distribution page says a new Evergreen Runtime downloads in the background and is used when the app restarts, and an app that keeps running stays on the previous version. Microsoft 365's note puts those updates at a few times a month, usually 5 MB to 30 MB.
Quit the app, then let the Runtime update
- On Processes, sort by Name and read the parent above the busy rows. Use
TypeandSubtypeon Details when you need the role of onemsedgewebview2.exeline. - Quit that app. The group should leave with its browser process. Rows that remain belong to another group. If rows stay under that same app, it is still running.
- Open the app again so a Runtime downloaded in the background becomes the running build.
- If the CPU returns with the same page, open that page in Edge. The FAQ says to contact the app's support when one app is consistently heavy.
Ending the GPU row from Task Manager is an exit the runtime reports to the host, and the host decides what you see next. The Manager article covers End task. Apps themselves shut a group down with Close on the controller, per the process model page.
Leave the Runtime installed on Windows 11
Removing the shared Runtime does not make a heavy page cheaper. One copy serves every Evergreen app, so deleting it stops them together, and the page costs the same once the Runtime is back. The FAQ says a removed copy often returns, because Windows 11 includes it as part of the operating system and many apps reinstall it when they install or launch.
For admins, the Microsoft 365 note adds that clearing the setting that allows automatic installs does not remove a copy already on the PC, and that Outlook's Room Finder and Meeting Insights are unavailable without the Runtime. A Fixed Version inside another app stays in that app's folder. Why to keep it and how to check the install are in What WebView2 is, and these pages offer no per-app off switch.
A Pake window is one of these hosts
A Pake app on Windows runs on this Runtime. The install requirements say Windows 11 already includes it. When it is missing, Pake shows Apps made with Pake need the Microsoft Edge WebView2 Runtime and a Get WebView2 link to Microsoft's download page. A running Pake app is one more group of msedgewebview2.exe. How Pake works describes that window.
Each Pake app keeps its own WebView2 profile, and the CLI options note it is not shared with Chrome or Edge. Two Pake apps with different names or identifiers use two folders, so two groups when both are open. A desktop-app build names its folder by identifier, so a rename keeps the sign-in.
On Windows, Hide on close keeps the app running in the tray and is off by default. While it is on, the group stays until you quit from the tray. If such an app will not close when you remove it, Pake offers End App, which drops unsaved work, and Manage your apps covers removal. A GNU build loads WebView2Loader.dll at runtime, and the MSI includes it. That DLL loads the Runtime. It is a different file from the msedgewebview2.exe rows.
FAQ
Does each page get its own GPU process?
Views in one user data folder share one GPU process. Another folder adds another GPU process. The row that multiplies inside a folder is usually a renderer.
If I end the GPU process, who restarts it?
The runtime reports the exit to the host app, and what you see next depends on that app. The Runtime stays installed either way.
Will a restart help when Edge is heavy on the same page?
It loads a Runtime already downloaded, and it drops use a long-running view has retained. The cost you can also see in Edge comes back with the page.
Does removing the Runtime delete every copy of the file?
It removes the shared Evergreen install, which Windows 11 and many apps put back. A Fixed Version inside another app is left in that app's folder.