85°F Knoxville
Mon–Fri 9–5 ETAnswered by a human
Book a call →
Software · RESOLVED

WebView2 Runtime Won't Install? The Admin MSI Fix That Actually Works

A user's app wouldn't launch because WebView2 Runtime silently failed to install. The fix was to grab the MSI directly from Microsoft and install it elevated.

Corey Watson · Managing Member, Limehawk•Updated Apr 2026•4 min
~2 hours (ticket open to resolution, most of it waiting)
Time to fix

Incident

Ticket came in: a client's application was blocked from launching because the WebView2 Runtime wouldn't install. He'd hit the error, tried the normal install path, and gotten nowhere. The app had a hard dependency on WebView2 being present machine-wide and wouldn't even start its initial window without it. Classic "nothing happens" symptom from the user's side — the installer would run, appear to do something, and then the app would still say WebView2 was missing.

This is a small ticket with a mundane fix, but the pattern is worth writing up because WebView2 install failures are a steady trickle. Enough apps depend on WebView2 now that when it misbehaves, it breaks multiple things on the same machine — in this case our own remote-support client plus Lenovo Vantage, both of which quietly rely on WebView2 under the hood.

What webview2 actually is

WebView2 is Microsoft's embedded Chromium runtime. When a desktop app wants to render web content inside itself — a settings pane, an onboarding screen, a log-in window — it uses WebView2 instead of shipping its own browser engine. The runtime installs once per machine and gets shared across every app that depends on it. When WebView2 is missing or broken, every app that depends on it breaks simultaneously — users don't connect the dots but from the engineer's side it's a strong tell.

What goes wrong with the default installer

The standard WebView2 install path is the bootstrapper — a small Evergreen installer that phones home, downloads the real payload, and installs it. That bootstrapper can fail quietly in a few ways we see in the field:

  • the user doesn't have admin rights and the installer elevates inconsistently
  • the bootstrapper can't reach Microsoft's download endpoint (proxy, filtering, flaky wifi mid-download)
  • a prior partial install left registry or file-system artifacts that the bootstrapper refuses to step on
  • AV or endpoint controls flag the bootstrapper and kill it without a clear error
  • the bootstrapper returns a success code but the actual runtime didn't register

In any of these cases, the user sees "it finished" or "it errored" without useful signal, and the dependent app still won't launch. Running the bootstrapper a second time usually doesn't change anything.

The fix

Skip the bootstrapper. Grab the standalone WebView2 MSI directly from Microsoft's evergreen download page and install it elevated. The standalone installer is self-contained, doesn't need network access at install time, and goes in cleanly as long as it runs with admin rights.

Steps:

  1. On Microsoft's WebView2 download page, grab the Evergreen Standalone Installer — not the Bootstrapper
  2. Pick x64 for modern machines (x86 only if you're on a legacy 32-bit install, which is rare)
  3. Right-click → Run as administrator (or push it via RMM with elevated context)
  4. Let it complete — it's silent and fast
  5. Restart the dependent app

That's it. In this ticket we downloaded the standalone installer, ran it elevated on the user's machine, and the app came up. Because WebView2 registers machine-wide, everything else on the system that depended on it (Lenovo Vantage in this case) also started working without any additional work.

Why elevated install matters

The WebView2 runtime installs into Program Files and writes to HKLM. A non-elevated process can't do either. If the bootstrapper fails to elevate cleanly — which happens under some UAC and Group Policy configurations — it silently falls back to behavior that looks like an install but doesn't actually put the runtime in the right place. Forcing the install elevated eliminates that whole class of failure.

Outcome

Ticket opened at about 3pm, resolved by about 5pm. Most of that was coordination time and the remote session itself — the install was a couple minutes once we were on the machine. User replied: "Thank you." Then got the close notification and replied with "What am I supposed to do with this Email?" — which, honestly, is peak end-user.

App launched. Vantage launched. Nothing else had to be touched. The entire fix was replacing the bootstrapper with the standalone MSI and running it elevated.

time to fix: ~2 hours end-to-end, install itself was under 5 minutes apps restored: 2 (the requesting app + Lenovo Vantage, as a bonus) complexity: low

Key takeaways