Back to Blog

0x8A15000F Data Required by the Source Is Missing in winget

Christopher 4 min read
referencewindows

0x8A15000F is the winget return code APPINSTALLER_CLI_ERROR_SOURCE_DATA_MISSING, with the description "Data required by the source is missing". It shows as the error of a failed winget command, and a script or deployment tool that runs winget reads it as the exit code -1978335217, the decimal form of the same value.

What it means

Data that a winget source needs is missing. The default winget source is stored as the package Microsoft.Winget.Source_8wekyb3d8bbwe. WinGet ships in App Installer as a packaged app, and packaged apps depend on being registered for the user who runs them. When the error appears for some users and not for others, it's likely that the source package isn't registered for those profiles. Packages can't be registered for NT AUTHORITY\SYSTEM, so the winget command line isn't supported in the system context at all.

How to find the cause

Check which account the failing command runs as. A script set to run as SYSTEM, such as a scheduled task or a deployment script in the system context, can't use winget.exe.

As an affected user, list the sources, then update them with verbose logging.

winget source list
winget source update --verbose-logs --open-logs

The log files are in %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir, and winget --info prints the same folder.

Then find the app deployment error for the source package in that user's session.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppXDeploymentServer/Operational'
    StartTime = (Get-Date).AddMinutes(-15)
} | Where-Object { $_.Message -like '*Winget.Source*' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

In Event Viewer the same log is under Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational. Get-AppxLog shows the logs of the most recent deployment operation. Run both checks as a working user too and compare the two results.

Fixes

When the source package isn't registered for the user, register it by its family name as that user, then update the sources.

Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.Winget.Source_8wekyb3d8bbwe
winget source update

When the source configuration is damaged, reset the sources from an elevated prompt. The reset removes every source except the defaults msstore, winget, and winget-font, so add any custom sources again afterward.

winget source reset --force
winget source update

When the winget client itself is broken, install the Microsoft.WinGet.Client module from the PowerShell Gallery and repair the client. Run the repair with -AllUsers from an elevated prompt to repair it for every user account on the machine.

Install-Module -Name Microsoft.WinGet.Client
Repair-WinGetPackageManager -AllUsers

When the command has to run as SYSTEM, use the Microsoft.WinGet.Client cmdlets such as Update-WinGetPackage in place of winget.exe. The module works in the system context for applications installed machine wide.

Related errors

Where ET Ducky shows it

I build ET Ducky, and its patch management updates Windows apps through winget and Windows Update and Linux packages through apt, dnf, zypper, snap, and flatpak. You'd tag a few machines as your first ring and schedule app updates to that tag before the rest. A patch is marked successful only when services come back up with no crash loops, and a regression in a ring pauses the deployment.

Sources

App updates through winget in patch rings

Read how ET Ducky updates Windows apps through winget and Windows Update in rings, and pauses the deployment when a ring regresses.

Read the patch management docs