Fix Windows 11 Search Not Working After 25H2 Update

Most Windows 11 search complaints have the same three suspects: a stuck process, a corrupted index, or a broken service. That's still true after 25H2, but there's a fourth cause specific to this version that most generic troubleshooting guides don't mention, because it didn't exist before this release. If your search worked fine before you updated and started spinning endlessly, freezing, or refusing input right after, check that one first — it saves you from rebuilding an index that was never actually the problem.

Windows 11, version 25H2 replaced the older SearchApp component with SearchHost, and the new SearchHost renders its results using msedgewebview2 — the Microsoft Edge WebView2 runtime — rather than the older native UI. That's a real architectural change, not a rename, and it means search now has a dependency it didn't have before: a working, up-to-date WebView2 runtime. If you'd previously disabled or removed WebView2 (some privacy or de-bloat guides recommend this), or if it's simply out of date on your machine, search can hang or fail to render results after upgrading to 25H2 even though nothing else about your system changed.

Confirm this is your problem before touching the index or the service

Open Task Manager, go to the Details tab, and check whether msedgewebview2.exe processes exist and whether they're running normally rather than stuck in a suspended or not-responding state. If you don't see any WebView2 processes at all when search is open and spinning, that's consistent with this cause — the rendering dependency isn't loading. It's also worth checking, separately, whether SearchHost.exe itself shows as suspended in Task Manager; that's a related but distinct symptom (the host process itself stalling, rather than its rendering dependency failing), and the fix for that one is simpler and comes first below.

The quick fix that clears a genuine stuck process

Before assuming this is the WebView2 issue, rule out a simple hung process — it's the least invasive check and it's often all that's needed:

  1. Open Task Manager (Ctrl+Shift+Esc), go to Details, find SearchHost.exe, right-click, and End Task.
  2. Click the search box again. Windows relaunches the process automatically.

If that fixes it, you're done, and you never needed to touch WebView2, the index, or anything else. This resolves a genuinely stuck process; it does nothing for a rendering dependency that's actually missing or broken, which is why it's worth trying first but not stopping there if the freeze comes right back.

If it comes right back: force the WebView2 runtime to update

WebView2 updates itself in the background through a scheduled task, but that task can be disabled, blocked by policy, or simply hasn't run recently on a machine that was previously configured to avoid it. Forcing it manually is the fix here:

  1. Open Task Scheduler (taskschd.msc).
  2. Navigate to Task Scheduler Library > Microsoft > EdgeUpdate.
  3. Find MicrosoftEdgeUpdateTaskMachineUA, right-click it, and select Run.
  4. Let it complete, then restart the search process (End Task on SearchHost.exe, or just reboot) and test again.

If that task doesn't exist at all, WebView2 may have been removed entirely rather than just left outdated — in which case reinstalling the WebView2 Runtime directly resolves it, and Windows will then keep it current through the same scheduled task going forward.

If WebView2 checks out fine and search still misbehaves

At this point you're back in more familiar territory, and the standard search-repair sequence is worth running in order:

  • Restart Windows Explorer (Task Manager > Details > explorer.exe > Restart) before anything more invasive. This alone clears a surprising number of taskbar-level UI glitches that look like a search failure but are actually a shell rendering issue.
  • Confirm search is actually enabled in the taskbar, under Settings > Personalization > Taskbar > Taskbar items. It sounds obvious, but a settings sync or update can occasionally reset this, and it's a thirty-second check before you go looking for a deeper cause.
  • Run the Search and Indexing troubleshooter if it's still available on your build — Microsoft has been shifting some of these away from the legacy MSDT-based troubleshooters toward the Get Help app, so don't be surprised if the path to it has moved since you last looked.
  • Rebuild the search index via Settings > Privacy & Security > Searching Windows > Advanced Indexing Options > Advanced > Rebuild, if results are missing rather than the box itself failing to open. This doesn't touch your files, only the search database, so it's low-risk — just expect heavy disk activity while it runs.
  • Test in a new local administrator account. If search works fine there and fails in your regular profile, the problem is profile-specific — often a corrupted search-related registry key or a damaged AppX registration tied to that one account — rather than a system-wide fault, which changes what you troubleshoot next.

What I would not do

Uninstalling a specific KB in the hope it reverts whatever broke search is genuinely popular advice in forum threads on this exact symptom, and I understand the appeal — it's worked for some people. But it's inconsistent enough to be a poor first move: some users report it does nothing, and at least one report I've seen describes it rolling the device back toward 24H2 behavior entirely, which trades one set of problems for another rather than fixing anything. If you're going to try it, know exactly which KB you're removing and be prepared for the possibility that it changes more than just search.

I also wouldn't jump to deleting the search index database folder by hand as an early step. It's a legitimate advanced fix in genuinely stubborn cases, but it forces a full reindex with heavy CPU and disk load, and it's overkill if your actual problem is an outdated WebView2 runtime that a background task update fixes in under a minute.

And I wouldn't disable Copilot or search highlights in the taskbar as a "fix" unless you've confirmed through the steps above that nothing else resolves it. Some people have reported this working, and it might be masking the same WebView2 dependency by reducing what search tries to render — but treat it as a workaround you're choosing to live with, not a root-cause fix, since you're losing a feature rather than repairing what broke it.

Checklist

  • Check whether msedgewebview2.exe processes are present and running when search is open.
  • End Task on SearchHost.exe first — it's free and often enough on its own.
  • Manually run the MicrosoftEdgeUpdateTaskMachineUA scheduled task to force a WebView2 update.
  • Restart Explorer before assuming the problem is the index rather than the shell.
  • Test in a new local admin profile before concluding the issue is system-wide.
  • Rebuild the index only if results are missing, not if the box itself won't open — a rebuild doesn't fix a rendering dependency.
← Newer Posts Older Posts →