Why WhatsApp Desktop Kept Hanging: A WebView2 GPU Failure on Windows 11

Some days ago I was trying to use the WhatsApp desktop app. I don't use my phone during working hours — it makes me more productive, and I avoid social media on it at all costs because I believe it degrades my concentration a lot. So the desktop app is my only window to WhatsApp during the day, and the fact that I couldn't use it properly pissed me off enough that I tweeted about it:

The rant was premature, though. What came after the tweet turned into a clean example of how I debug: isolate one variable at a time, follow the evidence instead of the loudest suspect, and don't stop at the first fix that only reduces the symptoms.

So, to start: I'm on Windows 11, using WhatsApp Desktop version 2.2631.102.0 from the Microsoft Store. The issue was that every time I opened WhatsApp, it hung on startup. The app opened but stopped responding right away, and I had to close it forcefully.

I went to OpenCode and fired up an agent running Kimi K3, and explained the problem I was facing. The first suggestion was to clean the WebView2 cache. I've faced similar issues before, so I knew the suggestion wasn't far off from the usual suspects. We tried that — it didn't work. After that, it suggested the whole embedded-browser profile was corrupted. Since my session was already gone after the cleanup, it was worth trying. That didn't sort out the failure either. So we went for the nuclear option: a clean reinstall. That seemed to work, but after a while of using the app it started behaving the same way, intermittently.

In the end, the agent found the cause. It suggested deactivating GPU acceleration, which I agreed with immediately — I've had issues in Chrome before because of that feature. It's crazy how unstable RTX 3080s are on Windows nowadays; it seems to be the cause of a lot of apps just hanging. That was the last option on the list, and it was the right one: changing a single user-scope variable, WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--disable-gpu, ended the issues.

What follows is the detailed setup and evidence from the investigation the agent ran: the event-log evidence, the hypotheses we discarded one at a time — which matches how I like to work, changing one variable per test — the crashes, the search, and the final workaround. Hope you enjoy it. Or your agent does, if it's the one reading this ;)

The setup

• App: WhatsApp Desktop from the Microsoft Store, package 5319275A.WhatsAppDesktop, version 2.2631.102.0, x64.
• Runtime: the app is a WinUI 3 shell (WhatsApp.Root.exe) hosting an embedded WebView2 (Edge Chromium) browser. Its browser profile lives under %LOCALAPPDATA%\Packages\5319275A.WhatsAppDesktop_cv1g1gvanyjgm\LocalCache\EBWebView.
• OS: Windows 11 Pro N, build 26200.
• GPU: NVIDIA GeForce RTX 3080, driver 32.0.16.1088 (2026-07-21). No nvlddmkm or display-driver errors in the System log.
• WebView2 Runtime: 151.0.4129.78, current.

Failure: Application Hang 1002

The Application event log showed the same event at every failed launch:

ProviderName: Application Hang
Id: 1002
The program WhatsApp.Root.exe version 1.0.0.0 stopped interacting with
Windows and was closed.

Three hangs in one evening, and more on earlier dates. The app was not crashing — it was freezing during startup and Windows was closing it. That distinction matters: a crash leaves a faulting module; a hang leaves nothing but the event.

First suspect: the WebView2 cache

The app's LocalCache\EBWebView directory held 287 MB. The agent cleared only the disposable caches — Cache, Code Cache, GPUCache, Service Worker\CacheStorage, shader and Dawn caches, about 150 MB — while preserving the session data (Cookies, Local Storage, IndexedDB, and LocalState). The app still hung on the next launch. Cache corruption was real but not sufficient.

Second suspect: the browser profile

Next it renamed the entire EBWebView directory to EBWebView.bak, forcing the app to build a fresh profile while keeping a rollback copy. The next launch was immediately responsive — Responding: True in the process list, no new hang event. The profile was part of the problem.

About forty minutes later the app died with a real crash:

ProviderName: Application Error
Id: 1000
Faulting application name: WhatsApp.Root.exe
Faulting module name: Microsoft.ui.xaml.dll, version: 3.2.3.0
Exception code: 0xc0000005

Microsoft.ui.xaml.dll is the WinUI 3 framework bundled inside the WhatsApp package, and 0xc0000005 is an access violation. The failure had moved out of the browser profile and into the app's UI layer.

Ruled out along the way

Each of these was checked on its own before moving on:

• Damaged package files. Every DLL in the package passed an Authenticode signature check, the package reported Status: Ok, and winget upgrade confirmed no newer build existed. A repair re-registration (Add-AppxPackage -Register) changed nothing.
• The Windows N edition. Windows N editions ship without Media Foundation, and missing media components are a documented cause of WhatsApp Desktop instability. The relevant DLLs (mfplat.dll, mf.dll, mfreadwrite.dll, EVR.dll) were all present in System32. Ruled out.
• Overlay and injection software. MSI Afterburner was installed, but neither it nor RivaTuner Statistics Server was running or registered for autostart. Discord's overlay was not enabled. Ruled out.
• Driver errors. The System log showed no nvlddmkm or display-driver errors in the days around the hangs.

The nuclear option: a clean reinstall

A full uninstall and reinstall from the Store (winget install 9NKSQGP7F2NH) replaced everything: package, profile, and state. The app linked again and worked — but the hangs did not stop completely. The rate dropped from three hangs in one evening to one in sixteen hours, and shorter freezes remained while scrolling and opening media.

That pattern — surviving a complete reinstall with fresh data — points below the app, to the rendering stack it shares with nothing else on the machine except other WebView2 hosts.

The actual cause: WebView2 GPU acceleration

WebView2 honors an environment variable that appends Chromium command-line switches to every embedded browser it hosts:

[Environment]::SetEnvironmentVariable(
  'WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS',
  '--disable-gpu',
  'User'
)

User scope, no elevation required, no app files touched. After setting it and restarting the app, the remaining hiccups stopped. Rendering falls back to software, which is unnoticeable for a chat client.

Reverting is one command and a restart:

[Environment]::SetEnvironmentVariable(
  'WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS',
  $null,
  'User'
)

Validation

• Before the variable: three Application Hang events in one evening; after the reinstall, one hang plus visible stutter within sixteen hours.
• After the variable: a responsive process across launches, no new hang or crash events, and smooth scrolling and media through normal daily use.

The attribution is empirical, not microscopic: we did not identify which GPU operation inside WebView2 faults against this driver build. The evidence is that every layer above the GPU — app data, app package, OS media components, injected overlays — was tested and cleared, and the hangs stopped exactly when the GPU path was disabled and nothing else changed.

What I would check first next time

1. Read the Application log before touching the app. Event 1002 (hang) versus 1000 (crash with a faulting module) selects completely different investigation paths.
2. Test the GPU path early on any WebView2 or Electron app. WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--disable-gpu is a one-line, reversible experiment that would have short-circuited most of this note.
3. Change one variable per test. Clearing the cache and the profile together would have left ambiguity; doing them separately showed the profile mattered and the cache did not.
4. A reinstall that only reduces failure frequency is a clue, not a fix. Whatever survives a fresh install is not in the app's data.
5. Keep rollback copies. Renaming EBWebView to EBWebView.bak instead of deleting it meant every step was reversible until the fix was proven.

Caveats

• The variable affects every WebView2 host for the user account, not only WhatsApp. On this machine that trade was acceptable; on a machine with GPU-heavy WebView2 apps, test each one.
• The right long-term fix belongs to WhatsApp's build or the NVIDIA driver. After either updates, remove the variable and retest — the workaround should not outlive the bug.
• WhatsApp Web in a browser was the zero-install fallback throughout; it shares the account and none of the failure.

Credits

• OpenCode agent (Kimi K3) — ran the event-log queries, the staged cache, profile, and reinstall tests, and found the final GPU workaround on this machine.