Interactive Troubleshooter

Published: Sep 8, 2026

Windows 11 Widgets Using 30% CPU: Disable Services

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This interactive diagnostic guide addresses high CPU consumption and background thread loops caused by Windows 11 Widgets (Widgets.exe) and Microsoft News feeds. Follow this workflow to isolate WebView2 runtime crashes, purge Web Experience Pack instances, configure Group Policy overrides, and disable underlying background services.

Full Diagnostic Tree & Step-by-Step Overview

Which process or subsystem in Task Manager is responsible for the elevated 30%+ CPU usage?

Widgets.exe (Windows Widgets host process) continuously using 25-40% CPU continuously
Microsoft Edge WebView2 (msedgewebview2.exe) child processes spawning repeatedly under Widgets
Windows Web Experience Pack background updates and feed refresh sync looping in background
CPU spikes occur specifically when hovering over or opening the Taskbar Widget icon

How does Widgets.exe behave when attempting standard process termination?

Widgets.exe restarts automatically within seconds after ending task in Task Manager
Widgets.exe stays terminated, but taskbar integration remains broken with high background DWM usage
Widgets.exe consumes high CPU only while connected to a specific corporate proxy or VPN

Windows Web Experience Pack Auto-Respawn Loop

Solution:

Root Cause: Windows Web Experience Pack Auto-Respawn Mechanism

In Windows 11, Widgets.exe is managed by the MicrosoftWindows.Client.WebExperience AppX package. When Widgets.exe crashes or is manually killed in Task Manager, the System Event Notification Service and Windows Shell infrastructure automatically trigger its restart. If the underlying feed cache or user token is corrupted, Widgets.exe enters an infinite crash-and-respawn loop, pinning 25-40% of CPU capacity on a single core cluster.

Diagnostic Verification:

1Open Task Manager (Ctrl + Shift + Esc) -> Details tab.

2Locate Widgets.exe and observe if the PID (Process ID) changes every few seconds.

3Open Event Viewer (eventvwr.msc) -> Windows Logs -> Application.

4Search for Event ID 1000 (Application Error) listing Widgets.exe or WebExperienceHost.exe as the failing module.

Step-by-Step Fix:

1Completely Remove Windows Web Experience Pack via PowerShell:

Right-click the Start Menu and select Terminal (Admin) or PowerShell (Admin).

Run the following command to remove the Web Experience AppX package for all users:

Get-AppxPackage -AllUsers *WebExperience* | Remove-AppxPackage -AllUsers

2Block Reinstallation via Group Policy (Windows 11 Pro/Enterprise):

Press Win + R, type gpedit.msc, and press Enter.

Navigate to: Computer Configuration -> Administrative Templates -> Windows Components -> Widgets.

Double-click Allow widgets and set it to Disabled.

Click Apply and OK.

3Enforce via Windows Registry (Windows 11 Home):

Press Win + R, type regedit, and press Enter.

Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft

Create a new Key named Dsh under Microsoft if it does not exist.

Inside Dsh, create a new DWORD (32-bit) Value named AllowNewsAndInterests and set its Value data to 0.

Prevention & Long-Term Monitoring:

Re-check Group Policy after major Windows 11 feature updates (e.g., 24H2) to ensure system provisioning does not reinstall the Web Experience package.

DWM Render Queue Saturation from Orphaned Widget Handles

Solution:

Root Cause: Desktop Window Manager (DWM) Frame Buffer Lockup

When Widgets.exe is killed while rendering an active web canvas layer, the DirectX surface allocated by Desktop Window Manager (dwm.exe) fails to release its memory handle. DWM continues polling the non-existent process window frame at 60Hz/120Hz, leading to sustained high CPU and GPU usage in dwm.exe even after Widgets appears closed.

Diagnostic Verification:

1Open Task Manager -> Processes tab.

2Check if Desktop Window Manager displays >15% CPU usage after terminating Widgets.

3Verify if screen stuttering occurs during taskbar interaction.

Step-by-Step Fix:

1Restart Desktop Window Manager Service:

Open Terminal (Admin).

Execute command: taskkill /F /IM dwm.exe

*Note:* The screen will flicker black briefly as DWM automatically restarts with clean render handles.

2Turn Off Taskbar Widgets Toggle:

Open Windows Settings (Win + I) -> Personalization -> Taskbar.

Under Taskbar items, toggle Widgets to Off.

3Clear DWM DirectX Shader Cache:

Open Disk Cleanup (cleanmgr.exe).

Select System Drive (C:), check DirectX Shader Cache, and click OK to purge corrupt cached surfaces.

Prevention & Long-Term Monitoring:

Disable taskbar widget entry points before forcibly terminating background shell hosts.

Proxy Authentication Loop in Windows Feed Infrastructure

Solution:

Root Cause: Network Proxy TLS Interception Failure in WebExperience Host

Enterprise environments utilizing SSL/TLS inspection proxies or authenticated PAC scripts often block background connections made by Widgets.exe to assets.msn.com. When the Web Experience Host encounters recurring 407 Proxy Authentication Required or 403 Forbidden errors, it executes an unthrottled reconnect retry loop, generating severe CPU usage.

Diagnostic Verification:

1Open Resource Monitor (resmon.exe) -> Network tab.

2Expand Network Activity and filter by Widgets.exe or msedgewebview2.exe.

3Check if thousands of outbound send/receive cycles occur toward MSN edge CDN endpoints without completing data transfers.

Step-by-Step Fix:

1Configure WinHTTP Proxy Settings to Match System Proxy:

Open Command Prompt (Admin).

Run: netsh winhttp import proxy source=ie

2Bypass MSN Feed Endpoints in Corporate Proxy:

Add wildcards *.msn.com, *.bing.com, and *.assets.msn.com to your proxy bypass list in Settings -> Network & internet -> Proxy.

3Disable Feeds Completely via Registry:

Open PowerShell (Admin) and run:

New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Dsh" -Name "AllowNewsAndInterests" -Value 0 -PropertyType DWORD -Force

Prevention & Long-Term Monitoring:

Ensure enterprise edge firewalls do not drop silent background keep-alive packets from Windows native web components.

What is the primary condition under which Microsoft Edge WebView2 instances crash or spike CPU?

Multiple msedgewebview2.exe processes running with corrupted user profile cache files
WebView2 GPU acceleration failing and falling back to software rasterization
Third-party antivirus/EDR injecting hooks into WebView2 render processes

Corrupted WebView2 User Data Cache and IPC Lockup

Solution:

Root Cause: Edge WebView2 Cache Corruption and Inter-Process Communication (IPC) Deadlock

Windows 11 Widgets renders its cards using embedded Microsoft Edge WebView2 instances. These instances store cookies, DOM storage, and IndexedDB cache in %LOCALAPPDATA%\Microsoft\Windows\Widgets. If a system crash or power outage interrupts a cache write, WebView2's rendering engine locks up while attempting to parse corrupted SQLite databases, resulting in continuous 30%+ CPU thread spinning across msedgewebview2.exe instances.

Diagnostic Verification:

1Open Task Manager -> Expand Widgets.

2Observe multiple Microsoft Edge WebView2 child processes consuming high CPU.

3Check for the existence of corrupted log files in %LOCALAPPDATA%\Microsoft\Windows\Widgets\EBWebView.

Step-by-Step Fix:

1Force Terminate All WebView2 and Widget Processes:

Open Command Prompt (Admin) and execute:

taskkill /F /IM Widgets.exe
taskkill /F /IM msedgewebview2.exe

2Delete Corrupted WebView2 User Data Cache:

Open File Explorer and navigate to %LOCALAPPDATA%\Microsoft\Windows\Widgets.

Select the EBWebView folder and press Shift + Delete to permanently remove it.

*Why this works:* Windows will regenerate clean cache databases upon next launch.

3Repair Microsoft Edge WebView2 Runtime:

Open Settings (Win + I) -> Apps -> Installed apps.

Search for Microsoft Edge WebView2 Runtime.

Click the three dots (...), select Modify, and click Repair.

Prevention & Long-Term Monitoring:

For detailed runtime documentation, refer to the official Microsoft Edge WebView2 Documentation.

Software Rasterization Fallback in Embedded WebView2

Solution:

Root Cause: GPU Acceleration Blacklist Fallback to CPU Software Rendering

When graphics drivers crash or become out of date, Microsoft Edge WebView2 automatically blacklists GPU hardware acceleration and falls back to SwiftShader software rasterization. Rendering complex CSS animations, news video feeds, and live weather overlays via CPU software emulation causes immediate multi-thread CPU spikes.

Diagnostic Verification:

1Open Command Prompt and launch Edge GPU diagnostic tool by targeting the WebView2 executable:

"C:\Program Files (x86)\Microsoft\EdgeWebView\Application\msedgewebview2.exe" --gpu-testing

2Check if Compositing or WebGL lists *Software only, hardware acceleration disabled*.

Step-by-Step Fix:

1Update Graphics Driver:

Update GPU drivers to the latest WHQL release via official vendor utilities (NVIDIA GeForce Experience/App, AMD Software, or Intel Driver & Support Assistant).

2Reset GPU Acceleration Flags in Windows:

Open Settings -> System -> Display -> Graphics.

Ensure Hardware-accelerated GPU scheduling (HAGS) is set to On.

3Force Hardware Acceleration via Registry:

Open PowerShell (Admin) and run:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Avalon.Graphics" -Name "DisableHWAcceleration" -Value 0

Prevention & Long-Term Monitoring:

Maintain current WHQL graphics drivers to avoid browser framework acceleration blacklisting.

Security Software API Injection Conflict with WebView2

Solution:

Root Cause: Antivirus Endpoint Hooking Conflict in Sandbox Processes

Certain Endpoint Detection and Response (EDR) agents or third-party antivirus suites inject Dynamic Link Libraries (DLLs) into every running process to inspect memory. When these hooks collide with chromium security sandboxes inside msedgewebview2.exe, worker threads enter an endless exception-handling loop, consuming CPU capacity.

Diagnostic Verification:

1Open Event Viewer -> Application logs.

2Look for Event ID 1000 faults pointing to ntdll.dll or third-party security DLLs (e.g., epmparh.dll, klhk.dll) loaded inside msedgewebview2.exe.

Step-by-Step Fix:

1Add Antivirus Exclusion Rules:

Configure your security software to exclude the following process paths from active memory hooking:

C:\Windows\SystemApps\MicrosoftWindows.Client.WebExperience_*\Widgets.exe
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\*\msedgewebview2.exe

2Test via Clean Boot State:

Press Win + R, type msconfig, go to Services tab, check Hide all Microsoft services, and click Disable all.

Restart PC to confirm CPU usage drops when security hooks are unmounted.

Prevention & Long-Term Monitoring:

Keep security software signatures updated to ensure compatibility with modern Chromium sandbox revisions.

What type of background syncing behavior or system load is present?

Continuous background network sync updating news cards even when the Widget panel is closed
Windows Web Experience Pack stuck during a pending Microsoft Store background update
High CPU paired with massive disk read/write activity in the User Data directory

Background MSN Feed Syncing with Closed Panel

Solution:

Root Cause: Unrestricted Background Refresh in Web Experience Service

Even when the Widgets dashboard is hidden, the Windows Web Experience Pack maintains active background threads to update live taskbar badges (such as stock updates, sports scores, and ticker alerts). On systems with corrupt notification subscriptions, these threads poll remote MSN endpoints every few milliseconds without backoff intervals.

Diagnostic Verification:

1Open Settings -> Apps -> Installed apps.

2Search for Windows Web Experience Pack and verify if background permissions are set to Always.

Step-by-Step Fix:

1Turn Off Unnecessary Widget Feed Cards:

Click the Taskbar Widget icon to open the board.

Click your Profile icon (top right) to open Widget Settings.

Under Widget customization and Show or hide feeds, toggle off Microsoft Start / Discover feed.

2Turn Off Taskbar Badging and Announce Features:

In Widget Settings, toggle Off both *Show announcements on taskbar* and *Show badges on taskbar*.

3Disable Background App Activity via PowerShell:

Open PowerShell (Admin) and run:

Get-AppxPackage *WebExperience* | Set-AppxPackage -Default

Prevention & Long-Term Monitoring:

Minimalize feed cards to essential offline utilities (e.g., local clock, calendar) to reduce API polling background overhead.

Microsoft Store AppX Package Stalls and Installer Locks

Solution:

Root Cause: Windows AppX Deployment Service (AppXSVC) Lockup

When the Microsoft Store attempts to auto-update the MicrosoftWindows.Client.WebExperience package while Widgets.exe is running, wsreset and AppXSVC fail to gain an exclusive file lock on active DLLs. The installer retries continuously in the background, spiking CPU usage across wsappx, AppXSVC, and Widgets.exe.

Diagnostic Verification:

1Open Task Manager and check for high CPU in wsappx or AppX Deployment Service (AppXSVC).

2Open Microsoft Store -> Library and check if *Windows Web Experience Pack* shows *Error* or *Updating...* indefinitely.

Step-by-Step Fix:

1Reset Microsoft Store Infrastructure:

Press Win + R, type wsreset.exe, and press Enter. Wait for the command window to close automatically.

2Terminate AppXSVC and Purge Download Cache:

Open Services (services.msc), locate Background Intelligent Transfer Service (BITS) and click Stop.

Navigate to C:\Windows\SoftwareDistribution\Download and delete all contents.

3Force-Update Web Experience Pack Manually:

Open PowerShell (Admin) and run:

Get-AppxPackage -AllUsers *WebExperience* | Reset-AppxPackage

Prevention & Long-Term Monitoring:

Pause Microsoft Store updates during heavy system workloads to prevent installation lockups.

High I/O Storage Churn from SQLite Database Logging

Solution:

Root Cause: Unbounded SQLite Write-Ahead Logging (WAL)

The Windows Web Experience Pack utilizes embedded SQLite databases to maintain cached news articles and user interaction metrics. When database Write-Ahead Logging (WAL) files grow beyond safety limits without undergoing a checkpoint operation, file I/O operations stall, forcing CPU cores into high I/O wait states (iowait).

Diagnostic Verification:

1Open Resource Monitor -> Disk tab.

2Check Disk Activity for Widgets.exe and identify high write volumes to files ending in .db-wal or .db-journal in %LOCALAPPDATA%\Packages\MicrosoftWindows.Client.WebExperience_cw5n1h2txyewy.

Step-by-Step Fix:

1Delete Local AppX Storage State:

Open PowerShell (Admin) and execute:

Stop-Process -Name "Widgets" -Force -ErrorAction SilentlyContinue

Remove-Item -Path "$env:LOCALAPPDATA\Packages\MicrosoftWindows.Client.WebExperience_cw5n1h2txyewy\LocalState\*" -Recurse -Force

2Re-register AppX Deployment Package:

In PowerShell (Admin), execute:

Get-AppxPackage -AllUsers *WebExperience* | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Prevention & Long-Term Monitoring:

Regularly clean temporary user data using built-in Windows Storage Sense rules.

What specific interaction triggers the performance drop when accessing the Taskbar Widget icon?

Hovering cursor over the taskbar icon triggers immediate 30%+ CPU spike before board opens
Opening the widget board causes desktop frame drops and slow card loading
Widget icon displays wrong weather location or continuously flashes error icons

Taskbar Open-on-Hover Thread Pre-Warming Overhead

Solution:

Root Cause: Aggressive Taskbar Peek Pre-Warming Execution

Windows 11 includes an 'Open on hover' feature for Taskbar Widgets. Moving the mouse cursor over the widget icon triggers the shell to instantly wake up background WebView2 render threads and pre-render all news feeds in memory before the user even clicks the icon. This aggressive pre-warming results in noticeable CPU spikes upon accidental cursor hovers.

Diagnostic Verification:

1Hover over the Widget weather icon on the left or center of your taskbar without clicking.

2Observe Task Manager for immediate CPU spikes in Widgets.exe.

Step-by-Step Fix:

1Disable 'Open on Hover' Behavior:

Click the Widgets icon on the taskbar to open the board.

Click your Profile / Settings icon in the top-right corner.

Toggle Off the switch for Open Widgets board on hover.

2Hide Widget Icon from Taskbar Altogether:

Open Settings (Win + I) -> Personalization -> Taskbar.

Under Taskbar items, switch Widgets to Off.

*Why this helps:* This removes the shell taskbar hook entirely while leaving underlying core Windows features unaffected.

Prevention & Long-Term Monitoring:

Keep taskbar hover triggers disabled on laptops or battery-constrained hardware to preserve CPU cycles.

XAML Islands Shell Compositor Stutter

Solution:

Root Cause: Windows App SDK XAML Islands Render Delay

The Windows 11 Widget board interface uses XAML Islands to host Web content within desktop shell windows. Mismatches in system scale factors (e.g., 125% or 150% DPI scaling) force the UI thread to perform real-time bitmap scaling across web elements, driving high CPU usage during layout calculation.

Diagnostic Verification:

1Open Settings -> System -> Display.

2Check if custom or non-standard Scale settings (e.g., 115%) are configured.

Step-by-Step Fix:

1Reset DPI Display Scaling to Standard Values:

Open Settings -> System -> Display.

Set Scale to a standard recommended preset (100% or 200%).

2Disable Visual Transparency Effects:

Open Settings -> Accessibility -> Visual effects.

Toggle Transparency effects to Off.

*Why this works:* Disabling acrylic/mica transparency reduces GPU/CPU composition passes for the Widget canvas overlay.

Prevention & Long-Term Monitoring:

Use standard DPI scaling factors to ensure XAML layout engines operate without real-time scaling re-calculations.

Windows Location Service Polling Loop

Solution:

Root Cause: Windows Location API Lockout and Polling Loops

The default Weather widget relies on lfsvc (Geolocation Service) to display local weather conditions. If location access is disabled globally, but allowed for Widgets, the geolocation provider gets stuck in an infinite polling loop attempting to resolve IP-based coordinates.

Diagnostic Verification:

1Check Task Manager for high CPU in Widgets.exe alongside Geolocation Service (lfsvc).

2Open Event Viewer -> System and check for repeated Location Provider timeout warnings.

Step-by-Step Fix:

1Set Explicit Location for Weather Widget:

Open the Widgets board.

Click the three dots (...) on the Weather card and select Edit location.

Manually search and set your fixed City/Zip Code instead of relying on *Always detect my location*.

2Reset Windows Geolocation Service:

Press Win + R, type services.msc, and press Enter.

Locate Geolocation Service, right-click and select Restart.

3Adjust Location Privacy Permissions:

Open Settings -> Privacy & security -> Location.

Ensure Let apps access your location is explicitly toggled On or manually set Weather to a fixed location as configured in step 1.

Prevention & Long-Term Monitoring:

Setting fixed location parameters on desktop systems avoids continuous network-based geo-lookup loops.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website