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

• 0x8A15000B, APPINSTALLER_CLI_ERROR_SOURCES_INVALID, "The configured source information is corrupt".
• 0x8A15000A, APPINSTALLER_CLI_ERROR_INDEX_INTEGRITY_COMPROMISED, "The index is corrupt".
• 0x8A15003F, APPINSTALLER_CLI_ERROR_SOURCE_DATA_INTEGRITY_FAILURE, "The source data is corrupted or tampered".

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.

Patch management docs: https://etducky.com/documentation/patch-management

Sources

Windows Package Manager Client repository, Return codes and Repair-WinGetPackageManager; Microsoft Learn, Debugging and troubleshooting issues with the WinGet tool, The WinGet source command, Troubleshooting packaging, deployment, and query of Windows apps, Add-AppxPackage, Get-AppxLog, and Get-WinEvent; PowerShell Gallery, Microsoft.WinGet.Client. All read 2026-10-28.

Event ID 20 from Microsoft-Windows-WindowsUpdateClient is the event Windows writes when an update fails to install. It is an Error in the System log, under the task category Windows Update Agent. The message reads "Installation Failure: Windows failed to install the following update with error" followed by the error code and the update's name with its KB number. Microsoft's own example of the event is "Installation Failure: Windows failed to install the following update with error 0x80070002: Security Update for Windows (KB4586793)."

The matching success event is event 19 from the same source, which reads "Installation Successful: Windows successfully installed the following update" followed by the update's name.

What it means

Windows Update downloaded the update and the install step failed. The event names the update and the error code, but not the component that failed. The detail is in the servicing log, CBS.log, which records every package install and the error that stopped it.

How to find the cause

List the recent install results on the affected machine from an elevated PowerShell prompt. Events 19 and 20 together show which updates succeeded, which failed, and whether the same update fails on every attempt.

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-WindowsUpdateClient'
    Id = 19, 20
} -MaxEvents 30 | Select-Object TimeCreated, Id, Message | Format-List

Note the error code and the KB number from the newest event 20, then look up the code in the table of common corruption errors in Microsoft's article Fix Windows Update corruptions and installation failures. Codes such as 0x800f0831 (CBS_E_STORE_CORRUPTION) and 0x80073712 (ERROR_SXS_COMPONENT_STORE_CORRUPT) point at the component store.

Search CBS.log for the same error code to find the component that failed. The log is at C:\Windows\Logs\CBS\CBS.log, and older entries roll over into CBSpersist files in the same folder. Replace the code below with the one from your event.

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern '0x80070002' -SimpleMatch | Select-Object -First 10

Read the first match by time. The lines around it point to the package or installer that failed.

For the Windows Update client's own trace, build the Windows Update log. Windows Update writes .etl trace files, and this command merges them into one readable WindowsUpdate.log on the current user's desktop.

Get-WindowsUpdateLog

When several machines fail the same update, run the event query on three or four of them. The same error code and KB number on every machine points at something those machines share more than at one damaged machine.

Fixes

When the error code is one of the component store errors in Microsoft's table, repair the component store, then check the system files, then retry the update.

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

When the machine can't reach Windows Update, or DISM reports 0x800F081F (CBS_E_SOURCE_MISSING), point the repair at a source running the same Windows version.

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:\\<servername>\c$\windows /LimitAccess

When the error code is 0x8024002E (WU_E_WU_DISABLED), turn the Windows Update client service back on, then retry the update.

When the update installs, asks for a restart, and then rolls back, find the failing component in CBS.log as above and fix that component. Microsoft's article on 0x80070002 includes a cumulative update on Windows Server that rolled back after a restart, where CBS.log pointed at a driver.

When the error code is 0x800f0922, follow the steps on its own reference page: https://etducky.com/blog/windows-update-error-0x800f0922-cbs-e-installers-failed

Related events and errors

• Event 19 from WindowsUpdateClient, the successful install of an update.
• 0x800F0922 CBS_E_INSTALLERS_FAILED, an update that fails while its installers run and then rolls back.
• 0x80070002, documented by Microsoft in Troubleshoot Windows Update error 0x80070002.

Where ET Ducky shows it

I build ET Ducky, and its patch management talks to the Windows Update Agent directly and installs updates by KB number. You'd tag a few machines as your first ring and schedule updates to that tag before the rest. A patch is marked successful only when the kernel events show services back up with no crash loops. The deployment moves to the next ring only after the machines in the current ring pass that check, and a regression in a ring pauses the deployment. You can also open a Live Session shell from the browser without the need for a VPN and run the commands above on each machine.

Patch management docs: https://etducky.com/documentation/patch-management

Sources

Microsoft Learn, Troubleshoot Windows Update error 0x80070002; Event ID 20, WUA Update Installation; Troubleshoot unexpected reboots using system event logs; Fix Windows Update corruptions and installation failures; Get-WinEvent; Select-String; Get-WindowsUpdateLog. All read 2026-10-21.

A service on an Ubuntu or Debian server shows as inactive the morning after a round of updates, and its own log has no error in it. Restarting it fixes the symptom, but the next update can stop it again. This post covers how to tell a crash from a stop request, how to find what asked systemd to stop the service, and how to check every service after an update so the next one is caught in minutes.

Find out whether it crashed or was stopped

I'd start with the unit's status. Replace haproxy.service with your own unit in every command below.

systemctl status haproxy.service --no-pager

A unit that shows inactive (dead) was stopped cleanly. A unit that crashed or failed to start shows failed with a result such as exit-code or signal. When the log lines under the status show "Stopping haproxy.service" and a process that exited with code 143, that process received SIGTERM (128 plus signal 15). systemd sends SIGTERM when something asks it to stop the unit.

Read the unit's own journal for the day to get the exact second of the stop.

journalctl -u haproxy.service --since today -o short-iso --no-pager | tail -n 20

A restart that fails leaves a different trail. The journal shows "Stopping", then "Starting", then an error from the service's own start command, such as a configuration test that failed. That points at the service's configuration or at something it depends on being unavailable at that second.

Check what apt ran at that minute

Every apt and unattended-upgrades run writes a block to /var/log/apt/history.log with a Start-Date, the command line, the packages it changed, and an End-Date. Older months are rotated into compressed files, so search them with zgrep.

zgrep -h -A4 "Start-Date: 2026-10-10" /var/log/apt/history.log*

When the Commandline line shows /usr/bin/unattended-upgrade, the automatic updates ran it. Compare its Start-Date and End-Date with the time of the stop. Then check whether the service's own package was in that run.

zgrep -h " upgrade haproxy" /var/log/dpkg.log*

A package upgrade usually restarts its own service from the package scripts. The unattended-upgrades runs also write the full dpkg output, including any service restarts, to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log. Search that file for the unit name.

sudo grep -n "haproxy" /var/log/unattended-upgrades/unattended-upgrades-dpkg.log

Run systemctl list-timers apt-daily-upgrade.timer to see when the automatic upgrade last ran and when it runs next. The timer runs at a set time with a random delay, so the stop time can move from day to day.

Check needrestart on Ubuntu 24.04 and later

A library upgrade can restart a service whose own package didn't change. On Ubuntu 24.04 needrestart restarts the affected services directly after apt finishes, in unattended-upgrades runs too. Ubuntu documented the change in needrestart changes in Ubuntu 24.04. A glibc update, for example, restarts most long-running services in one systemctl restart call. That call is in unattended-upgrades-dpkg.log with the full list of units it restarted.

A service that starts before something it needs at that second, such as name resolution, fails its start and stays down. When a service has to stay out of those restarts, add it to $nrconf{override_rc} in a file under /etc/needrestart/conf.d/ and restart it yourself in a maintenance window.

$nrconf{override_rc}{qr(^haproxy\.service$)} = 0;

Read everything logged in the minute before the stop

When apt didn't run at that time, read every unit's journal lines from the minute before the stop. The -o cat output leaves out the hostname, which is useful if you post it on a forum.

sudo journalctl --since "2026-10-10 10:04:30" --until "2026-10-10 10:05:38" -o cat

A stop that someone ran by hand with sudo shows up as a sudo line with the command it ran. Search for it directly.

sudo journalctl -t sudo --since "2026-10-10 10:00" --until "2026-10-10 10:10" -o cat | grep systemctl

Check the timers that fired in that minute with systemctl list-timers --all, and check crontab and /etc/cron.d for a script that stops services before a backup or a certificate renewal. A configuration management run from Ansible or Puppet also shows up as its own lines in the journal for that minute.

Prevent the next one

Adding Restart=on-failure to the unit doesn't help with this. systemd doesn't restart a service when its death is the result of a stop or restart that systemd performed. The fix depends on what asked for the stop.

When the stop came from unattended-upgrades, exclude that package with Unattended-Upgrade::Package-Blacklist in /etc/apt/apt.conf.d/50unattended-upgrades and upgrade it by hand. When it came from needrestart, use override_rc as above. When it came from a script or a person, fix the script or the runbook.

Also check every service after each update. Save the list of running services before the update and compare it after.

systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort > /tmp/running-before.txt
sudo apt upgrade
systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' | sort | comm -23 /tmp/running-before.txt -

Any unit the last command prints was running before the update and isn't running now. Run systemctl --failed as well to list units that failed to start.

Where ET Ducky shows it

I build ET Ducky, and its Linux agent reads process exec and exit events from eBPF tracepoints. The systemctl, needrestart, or package script process that ran in the minute before the stop is in that event record, along with the service's own processes exiting.

For patching, ET Ducky runs apt updates in rollout rings. You'd tag a few servers as your first ring and schedule updates to that tag before the rest. A patch is marked successful only when the kernel event stream shows services back up with no crash loops. If the first ring regresses, the deployment pauses before the next ring. You can also open a Live Session shell from the browser without the need for a VPN and run the journalctl and zgrep commands above on the host.

One Windows or Linux server on the Free query tier with your own AI key costs $5 a month. Pricing is at https://etducky.com/pricing.

Drafted with AI, reviewed by me.