Interactive Troubleshooter

Published: Oct 24, 2026

How to Fix Microsoft Store Downloads Stuck at Pending

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Comprehensive diagnostic flowchart and repair manual for resolving Microsoft Store app downloads stuck indefinitely in the Pending or Downloading state. Details underlying cause vectors including Windows Update service deadlocks, corrupt AppX package vaults, network stack throttling, and token cache invalidation.

Full Diagnostic Tree & Step-by-Step Overview

What specific symptom or error behavior are you experiencing with Microsoft Store downloads?

All downloads immediately sit at 'Pending' without starting or throwing an error code
Downloads start, progress to a specific percentage, and then freeze or throw error 0x80070005, 0x80248014, or 0x80073D0A
Store fails to download only when connected to specific networks, VPNs, or proxy environments
Microsoft Store application fails to sign in, crashes upon initiating a download, or shows corrupt account state

Which condition best describes your system's background service or cache state?

Windows Update service is stuck, paused, or pending system updates in the background
Background Intelligent Transfer Service (BITS) or Cryptographic Service is unresponsive
Local AppX / WinStore package cache directory corrupted or permission locked
Storage location is set to a non-system drive or secondary NVMe/HDD partition

Remediation: Resolving Windows Update Pipeline Deadlocks

Solution:

Root Cause: Windows Update Service Queue Deadlock

The Microsoft Store infrastructure heavily relies on the Windows Update (wuauserv) pipeline, background installation agent (InstallService), and System Event Notification Service. When a background Windows Update becomes hung or locked during transaction commit, wuauserv holds an exclusive file lock on %SystemRoot%\SoftwareDistribution\DataStore. This prevents Microsoft Store from allocating local installation tokens, forcing all new download requests into an indefinite 'Pending' queue state.

Diagnostic Verification:

Open Event Viewer (eventvwr.msc) and navigate to Applications and Services Logs -> Microsoft -> Windows -> WindowsUpdateClient -> Operational.

Inspect for Event ID 20 or Event ID 101 showing failed transaction initialization or time-outs (0x8024001E).

Open PowerShell as Administrator and run:

Get-Service -Name wuauserv, bits, InstallService | Select-Object Name, Status, StartType
Confirm if wuauserv is stuck in Stopping or Running state without consuming CPU cycles.

Step-by-Step Fix:

1Stop Dependent Services:

Open Command Prompt as Administrator.

Run the following commands sequentially to halt the update engine and transfer agents:

net stop wuauserv
net stop bits
net stop appidsvc
net stop cryptsvc

2Purge SoftwareDistribution and Catroot2 Caches:

Delete or rename the cache directories where locked update state files reside:

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

3Restart Core Store Services:

Re-enable and restart the services to generate clean state repositories:

net start wuauserv
net start bits
net start appidsvc
net start cryptsvc

4Trigger Windows Store Queue Sync:

Open Run (Win + R), type wsreset.exe, and press Enter. Wait for the blank console window to close automatically.

Prevention & Long-Term Monitoring:

Ensure Storage Sense or automated disk cleanup scripts do not purge active Windows Update temporary folders during system runtime.

Monitor Windows Update health using official vendor guidelines found on the Microsoft Official Support Guide.

Remediation: BITS Queue Repair and Job Clearing

Solution:

Root Cause: Corrupted Background Intelligent Transfer Service (BITS) Job Buffer

Microsoft Store relies on BITS to fetch UWP .appxbundle and .msixbundle packages asynchronously using idle network bandwidth. If a previous background transfer job was interrupted by an abrupt shutdown or driver crash, an orphaned transfer job descriptor remains locked in the BITS queue database (%ALLUSERSPROFILE%\Microsoft\Network\Downloader\qmgr*.dat). Subsequent store download tasks are appended behind the corrupted job, blocking execution indefinitely.

Diagnostic Verification:

Open PowerShell as Administrator and query active BITS jobs:

Get-BitsTransfer -AllUsers | Select-Object JobId, DisplayName, JobState, OwnerAccount

Identify any jobs stuck in TransientError, Connecting, or Queued state that belong to NT AUTHORITY\SYSTEM or your local account.

Step-by-Step Fix:

1Clear All Active BITS Transfer Queues:

Run the following PowerShell command to forcefully remove all pending background transfer tasks across all user profiles:

Get-BitsTransfer -AllUsers | Remove-BitsTransfer

2Re-register Core BITS DLL Assemblies:

Stop the BITS service and re-register its system DLL references in Windows Registry:

net stop bits
regsvr32.exe /s qmgr.dll
regsvr32.exe /s qmgrprxy.dll

3Re-initialize BITS Service State:

Reset BITS configuration back to standard automatic start mode:

sc.exe config bits start= auto
net start bits

4Validate Download Operations:

Launch Microsoft Store and attempt to download a small utility app to verify job processing.

Prevention & Long-Term Monitoring:

Avoid force-killing network interfaces while large store games or updates are actively transferring.

Audit BITS health periodically via PowerShell script checks in enterprise environments.

Remediation: AppX LocalState Directory Reset & ACL Repair

Solution:

Root Cause: WinStore Package LocalState Corruption & Access Control List (ACL) Misconfiguration

The Microsoft Store core application (Microsoft.WindowsStore_8wekyb3d8bbwe) stores local runtime state, temporary downloads, and token caches under %LOCALAPPDATA%\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe\LocalCache. If Windows updates, profile migrations, or security tools alter permissions or corrupt this directory structure, the Store app loses write access to create temporary staging folders (AC\INetCache), resulting in perpetual 'Pending' state.

Diagnostic Verification:

Inspect process tree or check Event Viewer under Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Operational.

Look for Error Code 0x80070005 (Access Denied) or 0x80073CF6 (Package could not be registered).

Step-by-Step Fix:

1Terminate Store Application Processes:

Open PowerShell as Administrator and kill running Store binaries:

Stop-Process -Name "WinStore.App" -Force -ErrorAction SilentlyContinue

2Rename Corrupt LocalCache Folder:

Execute the following command to purge local cache staging folders:

Remove-Item -Path "$env:LOCALAPPDATA\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe\LocalCache\*" -Recurse -Force

3Restore Default Security Descriptor Permissions:

Reset permissions on the user Packages directory to ensure ALL APPLICATION PACKAGES group has full control:

icacls "%LOCALAPPDATA%\Packages" /reset /t /c /q

4Re-register Microsoft Store UWP Package:

Run the explicit AppX re-registration cmdlet in PowerShell:

Get-AppxPackage -allusers Microsoft.WindowsStore | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Prevention & Long-Term Monitoring:

Do not manually edit security ACLs or restrict permissions on the %LOCALAPPDATA%\Packages root path.

Exclude the AppX staging paths from aggressive third-party file cleaning software.

Remediation: Secondary Storage Drive & WindowsApps ACL Re-indexing

Solution:

Root Cause: Target Volume File System Mismatch or WindowsApps Lock

When Microsoft Store is configured to install applications onto a secondary drive (e.g., D:\ or E:\), it initializes a protected WpSystemFolder and WindowsApps folder on that target volume. If the secondary drive uses an unsupported file system (such as exFAT or FAT32 instead of NTFS), or if previous OS installations left orphaned Security Identifiers (SIDs) on those folders, the Store cannot construct the Virtual Hard Disk (VHD) mounting point required for application deployment.

Diagnostic Verification:

Open Windows Settings (Win + I) -> System -> Storage -> Advanced storage settings -> Where new content is saved.

Note if 'New apps will save to' points to a non-system partition.

Run fsutil fsinfo volumeinfo D: (replace D: with your secondary drive) and verify the File System Name is NTFS.

Step-by-Step Fix:

1Temporarily Redirect App Save Location:

Open Settings -> System -> Storage -> Change where new content is saved.

Switch 'New apps will save to:' back to C: (System Drive) and click Apply.

2Take Ownership and Repair Secondary Storage Folders:

Open Command Prompt as Administrator.

Grant administrators permissions to repair target volume app containers on the secondary drive (e.g., D:):

takeown /F "D:\WindowsApps" /r /d y
icacls "D:\WindowsApps" /grant administrators:F /t

3Delete Orphaned App System Folders:

Rename or delete D:\WpSystemFolder and D:\WUDownloadCache to allow clean volume initialization:

ren "D:\WpSystemFolder" "WpSystemFolder.old"
ren "D:\WUDownloadCache" "WUDownloadCache.old"

4Re-enable Target Drive:

Navigate back to Storage settings and switch target location back to D: drive.

Prevention & Long-Term Monitoring:

Store applications must always be installed on internal drives formatted strictly with NTFS or ReFS.

Do not disconnect external USB storage drives while application downloads are actively processing.

Select the error code or specific freeze behavior observed during the download attempt:

Error 0x80070005 (Access Denied / File Lock Failure)
Error 0x80248014 or 0x80070422 (Windows Update / Service Disabled)
Error 0x80073D0A or 0x80073D05 (Windows Firewall / Store Package Failure)
Progress bar reaches 99% or 'Installing' phase and hangs continuously

Remediation: Resolving 0x80070005 Permission Denied Errors

Solution:

Root Cause: Security Descriptor Corruptions in ProgramData AppRepository

Error 0x80070005 translates directly to ERROR_ACCESS_DENIED. In the context of Microsoft Store, this occurs when the AppXSvc (AppX Deployment Service) is blocked from writing to C:\ProgramData\Microsoft\Windows\AppRepository or C:\Program Files\WindowsApps. This is frequently caused by overly aggressive third-party antivirus utilities, registry cleaning scripts, or corrupted NT AUTHORITY\SYSTEM access rights.

Diagnostic Verification:

Open Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Operational.

Filter for Event ID 404 or 465 indicating file system access denied on AppRepository\StateRepository-Machine.sdb.

Step-by-Step Fix:

1Boot System into Safe Mode or Elevate PowerShell:

Open PowerShell as Administrator.

2Repair AppRepository Container Permissions:

Grant core system accounts explicit permissions over the AppRepository path:

$path = "C:\ProgramData\Microsoft\Windows\AppRepository"
icacls $path /grant "NT AUTHORITY\SYSTEM:(OI)(CI)(F)" /T /C
icacls $path /grant "NT Service\AppXSvc:(OI)(CI)(F)" /T /C

3Reset Security Inheritance on WindowsApps:

Re-establish access rights for UWP execution containers:

icacls "C:\Program Files\WindowsApps" /reset /t /c /q

4Re-enable AppX Deployment Engine:

Restart the AppX deployment service via Command Prompt:

net stop AppXSvc
net start AppXSvc

Prevention & Long-Term Monitoring:

Exclude C:\Program Files\WindowsApps and C:\ProgramData\Microsoft\Windows\AppRepository from active third-party AV real-time scanning engines.

Remediation: Repairing Disabled Service Infrastructure (0x80248014 / 0x80070422)

Solution:

Root Cause: Dependency Service Disabling or Registry Corruption

Errors 0x80248014 and 0x80070422 indicate ERROR_SERVICE_DISABLED. The Microsoft Store framework relies on a chain of system services: wuauserv (Windows Update), PushToInstall (Windows Push Notification System), LicenseManager (Client License Service), and clipsvc (Client License Service). If telemetry strippers or debloating scripts disable any of these services or corrupt their HKLM registry start values, downloads freeze at pending.

Diagnostic Verification:

Execute the following script in PowerShell to inspect dependency states:

Get-Service -Name wuauserv, InstallService, LicenseManager, clipsvc | Select-Object Name, Status, StartType

Verify if any of the above report Disabled under StartType.

Step-by-Step Fix:

1Re-enable Core Service Startup Configurations:

Open PowerShell as Administrator and run:

Set-Service -Name wuauserv -StartupType Automatic
Set-Service -Name InstallService -StartupType Manual
Set-Service -Name LicenseManager -StartupType Manual
Set-Service -Name clipsvc -StartupType Manual

2Repair Registry Service Start Values:

Ensure registry entries reflect operational start values (Automatic = 2, Manual = 3):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\wuauserv" /v Start /t REG_DWORD /d 2 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\ClipSvc" /v Start /t REG_DWORD /d 3 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LicenseManager" /v Start /t REG_DWORD /d 3 /f

3Start Mandatory Services:

net start wuauserv
net start ClipSvc
net start LicenseManager

4Re-attempt Store Application Installation:

Open Microsoft Store, cancel the pending download, and click 'Get' to re-initialize transfer.

Prevention & Long-Term Monitoring:

Avoid executing untrusted third-party 'Windows Debloater' or privacy scripts that disable core OS services globally.

Remediation: Resolving Windows Firewall & Container Isolation Failures (0x80073D0A)

Solution:

Root Cause: Windows Defender Firewall Service Disablement or Rule Filtering

Error 0x80073D0A occurs when the Windows Defender Firewall service (mpssvc) is stopped or disabled. Universal Windows Platform (UWP) applications run inside isolated AppContainer sandboxes. The AppX deployment manager requires the local Windows Firewall engine to build temporary loopback boundary rules for sandbox network authorization. If third-party firewalls disable mpssvc, Store installation tasks abort.

Diagnostic Verification:

Check the state of the native firewall service using Command Prompt:

sc query mpssvc

If the state returns STOPPED or DISABLED, the UWP AppContainer deployment engine will fail consistently.

Step-by-Step Fix:

1Enable and Start Windows Defender Firewall Service:

Run the following commands in Administrator Command Prompt:

sc config mpssvc start= auto
net start mpssvc

2Reset Windows Firewall Rules to Default:

Re-establish stock network isolation rules for AppContainers:

netsh advfirewall reset

3Enable UWP Loopback Exemption (If using local proxy/VPN):

Grant Store client local loopback processing capabilities using CheckNetIsolation:

CheckNetIsolation.exe LoopbackExempt -a -p=S-1-15-2-1609470199-2079831979-1603528116-3029323136-1282928507-2207908862-2826880287

4Restart Microsoft Store Service Container.

Prevention & Long-Term Monitoring:

Keep the native Windows Defender Firewall service enabled even if secondary third-party antivirus firewalls are installed.

Remediation: Resolving Package Staging & Cryptographic Signature Deadlocks

Solution:

Root Cause: Cryptographic Verification Hang During Package Staging

When a download completes (reaching ~99%), the Store transitions the AppX bundle to the staging phase via AppXSvc. During staging, cryptsvc validates the digital signatures of all payload files against Microsoft root certificates. If cryptographic catalog databases in %SystemRoot%\System32\catroot2 are damaged or trust store CRL checks time out, the staging process freezes at the transition barrier.

Diagnostic Verification:

Open Event Viewer -> Windows Logs -> Application.

Look for CAPI2 warnings or errors (Event ID 11, 256, or 512) citing signature verification timeouts.

Step-by-Step Fix:

1Reset Cryptographic Database Cache:

Run Command Prompt as Administrator:

net stop cryptsvc
ren C:\Windows\System32\catroot2 catroot2.old
net start cryptsvc

2Re-register Cryptography and Softpub DLL Systems:

Execute the following registration commands:

regsvr32.exe /s softpub.dll
regsvr32.exe /s wintrust.dll
regsvr32.exe /s dssenh.dll
regsvr32.exe /s rsaenh.dll
regsvr32.exe /s cryptdlg.dll

3Clear Pending AppX Staging Queue:

Open PowerShell as Administrator and execute:

Get-AppxPackage -AllUsers -PackageTypeFilter Bundle | Where-Object {$_.IsPartiallyInstalled -eq $true} | Remove-AppxPackage -AllUsers

4Reboot System and Retry Download.

Prevention & Long-Term Monitoring:

Maintain updated root certificate stores via standard Windows Security patches.

Which network or transport configuration describes your system connection?

Active Corporate VPN, Custom Proxy, or Secure Web Gateway
Metered Connection settings enabled on Wi-Fi or Cellular network
Custom/Third-party DNS Servers or Corrupted WinSock Network Stack
Delivery Optimization (DO) P2P distribution network bottleneck

Remediation: Bypassing VPN, WinHTTP Proxy, and SSL Inspection Barriers

Solution:

Root Cause: WinHTTP System Proxy Misconfiguration & SSL Interception

Microsoft Store relies on two distinct network stacks: standard user-level WinINet (used for app browsing) and system-level WinHTTP (used by BITS and wuauserv for background downloading). Standard commercial or corporate VPNs frequently set proxy rules in WinINet but fail to update WinHTTP. When BITS attempts to pull payload chunks from Akamai/Azure CDNs, WinHTTP routes requests to non-existent local proxies or gets blocked by SSL/TLS decryption inspection.

Diagnostic Verification:

Open Command Prompt as Administrator and inspect WinHTTP proxy settings:

netsh winhttp show proxy

If a proxy server is configured that does not match your active gateway, BITS downloads will hang indefinitely.

Step-by-Step Fix:

1Reset WinHTTP System Proxy Settings:

Clear stale system proxy configurations:

netsh winhttp reset proxy

2Flush System DNS Resolver Cache:

Clear cached CDN records in Windows DNS resolver:

ipconfig /flushdns

3Configure AppContainer Loopback Exemptions for Corporate Proxies:

If operating on a required proxy network, exempt Microsoft Store from loopback isolation:

CheckNetIsolation.exe LoopbackExempt -a -n="microsoft.windowsstore_8wekyb3d8bbwe"

4Temporarily Disable SSL Inspection:

Ensure security gateways allow untampered access to *.do.dsp.mp.microsoft.com and *.delivery.mp.microsoft.com.

Prevention & Long-Term Monitoring:

Configure split-tunneling on enterprise VPN profiles to bypass Microsoft Store CDN traffic.

Remediation: Overriding Metered Connection Download Constraints

Solution:

Root Cause: Network Cost Policy Throttling in Windows Network List Manager

Windows implements a Network Cost Policy subsystem governed by the Network List Manager (netprofm) service. When an active Wi-Fi, Ethernet, or cellular connection is marked as 'Metered', Windows restricts background data usage. The Microsoft Store automatically pauses and queues all pending downloads to prevent data overages, showing a persistent 'Pending' status without displaying an explicit error modal.

Diagnostic Verification:

Open PowerShell as Administrator and query metered status across active network interfaces:

Get-NetConnectionProfile | Select-Object InterfaceAlias, IPv4Connectivity, NetworkCategory, Name

Open Settings -> Network & internet -> Select Active Network -> Check if 'Metered connection' toggle is enabled.

Step-by-Step Fix:

1Disable Metered Connection Toggle:

Open Settings (Win + I) -> Network & internet -> Wi-Fi / Ethernet.

Select your connected network properties and switch Metered connection to Off.

2Configure Microsoft Store Metered Download Policy:

Open Microsoft Store application.

Click on your Profile icon -> App settings.

Toggle App updates and Download over metered connections to On.

3Restart Network List Service:

Re-synchronize network policy profiles via Command Prompt:

net stop netprofm
net start netprofm

4Resume Pending Downloads inside Store Queue.

Prevention & Long-Term Monitoring:

Verify network interface properties after major Windows feature updates to ensure cost flags are not reset.

Remediation: Winsock Socket Reset and Public DNS Alignment

Solution:

Root Cause: Winsock Catalog Corruption and Akamai CDN DNS Mismatch

Microsoft Store relies heavily on geo-located CDN networks (Akamai, Azure Front Door) to deliver multi-gigabyte application binaries. If the local TCP/IP Winsock catalog contains corrupt LSP (Layered Service Provider) entries, or if your configured DNS provider fails to resolve Anycast CDN endpoints (tlu.dl.delivery.mp.microsoft.com), socket connections to the content server silently drop, leaving downloads at 0 KB/s pending status.

Diagnostic Verification:

Open Command Prompt and test domain resolution against Microsoft's delivery infrastructure:

nslookup tlu.dl.delivery.mp.microsoft.com

If the request times out or fails to return valid CNAME / IP mappings, DNS resolution is broken.

Step-by-Step Fix:

1Reset TCP/IP Stack and Winsock Catalog:

Open Command Prompt as Administrator and run:

netsh winsock reset
netsh int ip reset

2Reconfigure DNS Adapters to Trusted Public Resolver (Cloudflare / Google):

Execute the following PowerShell commands to update active network adapters:

$Adapter = Get-NetAdapter | Where-Object Status -eq 'Up'
Set-DnsClientServerAddress -InterfaceIndex $Adapter.ifIndex -ServerAddresses ("1.1.1.1", "8.8.8.8")

3Flush and Register System DNS:

ipconfig /flushdns
ipconfig /registerdns

4Restart Computer to complete stack rebuild.

Prevention & Long-Term Monitoring:

Maintain clean network stack configurations and avoid manual socket filtering tools unless required.

Remediation: Rebuilding Delivery Optimization (DoSvc) Caches

Solution:

Root Cause: Delivery Optimization (DoSvc) Cache Locking and P2P Stall

Delivery Optimization (DoSvc) is the peer-to-peer and HTTP hybrid distribution service used by Windows Store and Windows Update. It breaks files into smaller pieces cached in C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache. If the local transaction log database (dosvc.edb) becomes corrupt, DoSvc fails to stitch downloaded chunks together, causing downloads to hang indefinitely in a pending state.

Diagnostic Verification:

Open PowerShell as Administrator and check DoSvc status:

Get-DeliveryOptimizationStatus

Inspect if active transfers report Stalled or show zero throughput across peer and HTTP sources.

Step-by-Step Fix:

1Stop Delivery Optimization Service:

Open Command Prompt as Administrator:

net stop dosvc

2Purge Corrupt Delivery Optimization Cache:

Forcefully delete temporary DO storage directories:

Remove-Item -Path "C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Cache\*" -Recurse -Force

3Switch Delivery Optimization Download Mode to HTTP Only (Bypass P2P):

Update Group Policy / Registry to fetch files directly from HTTP origin servers rather than local peers:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization" /v DODownloadMode /t REG_DWORD /d 1 /f

4Restart Delivery Optimization Service:

net start dosvc

Prevention & Long-Term Monitoring:

Monitor network optimization settings under Settings -> Windows Update -> Advanced options -> Delivery Optimization.

Select the account authentication or application stability failure symptom:

Store crashes instantly upon clicking 'Get' or 'Install' button
Microsoft Account sign-in fails or prompts endlessly for credentials
System Clock, Time Zone, or Hardware Secure Token Out of Sync
Entire UWP App Framework Corrupted Across System Profiles

Remediation: Full Microsoft Store Package Re-deployment

Solution:

Root Cause: Corrupt AppX Assembly Manifest or Missing Binary Dependencies

When the Microsoft Store executable (WinStore.App.exe) crashes immediately upon initiating a download transaction, the underlying cause is typically damaged binaries within the system installation directory or mismatched framework dependencies (such as Microsoft.VCLibs or Microsoft.UI.Xaml).

Diagnostic Verification:

Open Event Viewer -> Windows Logs -> Application.

Look for Error Event ID 1000 (Application Error) citing WinStore.App.exe as the faulting application name and Faulting module name: KERNELBASE.dll or twinapi.appcore.dll.

Step-by-Step Fix:

1Terminate Active Store Assemblies:

Open PowerShell as Administrator:

Get-Process -Name "WinStore.App" -ErrorAction SilentlyContinue | Stop-Process -Force

2Unregister Corrupt AppX Package Manifest:

Remove current package registrations for the active user:

Get-AppxPackage *WindowsStore* | Remove-AppxPackage

3Re-install Store and Core UWP Runtime Dependencies:

Re-deploy the Microsoft Store system manifest from the protected system staging directory:

Get-AppxPackage -allusers *WindowsStore* | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

4Re-register System Framework Dependencies:

Ensure required C++ and XAML UI packages are restored:

Get-AppxPackage -allusers *VCLibs* | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

5Reboot system and verify UI stability.

Prevention & Long-Term Monitoring:

Run System File Checker periodically to maintain package repository integrity.

Remediation: Clearing Account Token Broker & Web Account Manager (WAM) Cache

Solution:

Root Cause: Invalid Web Account Manager (WAM) Token Vault State

Microsoft Store relies on the Web Account Manager (TokenBroker) service and Microsoft Account identity providers to grant license acquisition tokens (XSTS tokens) for downloads. If account tokens stored in %LOCALAPPDATA%\Microsoft\TokenBroker\Cache become invalid due to password changes or session timeouts, the Store cannot acquire an acquisition license, leaving downloads stalled waiting for token authentication.

Diagnostic Verification:

Open Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> AAD -> Operational or Microsoft-Windows-User Control Management/Operational.

Look for Event ID 1098 errors indicating token broker acquire token failed with 0x80070520.

Step-by-Step Fix:

1Sign Out of Microsoft Store Account:

Open Microsoft Store -> Click Profile Icon -> Select Sign Out.

2Clear Token Broker Vault Cache:

Open PowerShell as Administrator and execute:

Stop-Service -Name TokenBroker -Force -ErrorAction SilentlyContinue
Remove-Item -Path "$env:LOCALAPPDATA\Microsoft\TokenBroker\Cache\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item -Path "$env:LOCALAPPDATA\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\*" -Recurse -Force -ErrorAction SilentlyContinue

3Re-register Account Broker Plugins:

Get-AppxPackage -AllUsers Microsoft.AAD.BrokerPlugin | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

4Restart System, Open Microsoft Store, and Sign back in.

Prevention & Long-Term Monitoring:

Ensure two-factor authentication prompts are fully completed during sign-in sessions.

Remediation: Resynchronizing Windows Time Service (w32time) & TLS Certificates

Solution:

Root Cause: Secure Channel Certificate Validation Clock Skew

HTTPS connections and OAuth authentication tokens exchanged between Microsoft Store and Azure servers require strict cryptographic time synchronization. If system time drifts by more than 5 minutes from Universal Coordinated Time (UTC), SSL/TLS certificate validation fails. The Store client drops HTTPS requests silently, blocking download token issuance.

Diagnostic Verification:

Check system clock against atomic time via Command Prompt:

w32tm /query /status

Verify if system time offset indicates a discrepancy greater than a few seconds.

Step-by-Step Fix:

1Re-enable Windows Time Service:

Run Command Prompt as Administrator:

sc config w32time start= auto
net start w32time

2Resynchronize System Time against Windows NTP Server:

Force an immediate time sync update:

w32tm /resync /force

3Verify Time Zone and Automatic Time Settings via PowerShell:

Ensure automatic time zone setting is enabled:

Set-TimeZone -Id "W. Central Africa Standard Time" -ErrorAction SilentlyContinue
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\tzautoupdate' -Name 'Start' -Value 3

4Relaunch Microsoft Store and check download progress.

Prevention & Long-Term Monitoring:

Replace motherboard CMOS battery if hardware system clock repeatedly drifts after shutdowns.

Remediation: Performing System Image (DISM & SFC) & Store Rebuild

Solution:

Root Cause: Global Windows Component Store (WinSxS) Corruption

When multiple troubleshooting steps fail to resolve pending downloads, the underlying cause is system-wide corruption of the Windows Component Store (WinSxS) or corrupted system binaries in C:\Windows\System32. This invalidates core deployment APIs relied upon by UWP apps across all user accounts.

Diagnostic Verification:

Open Command Prompt as Administrator and run SFC scan check:

sfc /verifyonly

If output states 'Windows Resource Protection found integrity violations', component store repair is mandatory.

Step-by-Step Fix:

1Repair Component Store Payload via DISM:

Open Command Prompt as Administrator and execute the following commands in order:

DISM.exe /Online /Cleanup-Image /CheckHealth
DISM.exe /Online /Cleanup-Image /ScanHealth
DISM.exe /Online /Cleanup-Image /RestoreHealth

2Run System File Checker Repair:

Repair damaged system files using the clean DISM image:

sfc /scannow

3Provision Microsoft Store for All User Profiles:

Execute the global AppX provisioning command in PowerShell:

Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -like "*WindowsStore*"} | ForEach-Object {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallPath)\AppXManifest.xml"}

4Restart the Computer to finalize integrity repairs.

Prevention & Long-Term Monitoring:

Maintenance regular system restore points prior to major OS upgrades or modifications.

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