Persistent Office 2019 Installation Failures Across Multiple Tools & MS Store (ODT Exited Abnormally & Various Error Codes)"

Capture one time-correlated Office Click-to-Run trace and one Microsoft Store/AppX trace before attempting another repair; the resulting error codes will distinguish an Office deployment failure from Windows servicing or AppX corruption.

1. Capture the Office 2019 installation failure

Office 2019 clients use Click-to-Run rather than MSI, so Windows Installer logs are unlikely to identify the primary failure.^1^

1. Open Command Prompt as administrator.
2. Enable verbose Click-to-Run logging:

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide ^
 /v LogLevel /t REG_DWORD /d 3 /f

3. Record the current time, then reproduce the failure once with Microsoft’s current ODT—not Office Tool Plus:

cd /d C:\Path\To\ODT
setup.exe /configure configuration.xml
echo Exit code: %ERRORLEVEL%

ODT officially writes troubleshooting logs under %TEMP%; successful configuration ends with Products configured successfully.^2^

4. After the failure, inspect both locations, sort by Date modified, and retain files created during that reproduction:
   • %TEMP%
   • %WINDIR%\Temp
   Click-to-Run verbose logs normally use a {Machine Name}-{TimeStamp}.log naming pattern.^3^
5. Disable verbose logging:

reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide ^
 /v LogLevel /f

6. Search the captured files for error, failed, HRESULT, and the final return code. Preserve the complete log rather than extracting only the matching line because the preceding operation often identifies the failed prerequisite.

Also check Event Viewer → Windows Logs → Application for errors at exactly the same time. Do not use the VSTO logging procedure: that records installation/startup errors for Office add-ins and document customizations, not the Office suite installer.

2. Capture the separate Microsoft Store/AppX failure

Immediately reproduce one Store installation failure, then open:

Event Viewer → Applications and Services Logs → Microsoft → Windows

Check these logs in order:

1. AppXDeployment-Server → Microsoft-Windows-AppXDeploymentServer/Operational
2. AppxPackagingOM → Microsoft-Windows-AppxPackaging/Operational

The first contains deployment errors; the second is particularly relevant when the package cannot be opened. Microsoft also documents Get-AppxLog for retrieving events from the latest deployment.^4^

Run this directly after the failed Store operation:

$stamp = Get-Date -Format "yyyyMMdd-HHmmss"
Get-AppxLog |
    Format-List * |
    Out-File "$env:USERPROFILE\Desktop\Appx-$stamp.txt"

Export the relevant Event Viewer logs with Save All Events As and retain the exact hexadecimal code. Useful discriminators include:

• 0x80073CFE: package repository corruption.
• 0x80073D07: a system binary requires remediation.
• 0x80073D0A: Windows Firewall service is not running.
• 0x80073D01: deployment is blocked by policy.
• 0x80073CF3: dependency, conflict, or architecture validation failed.^4^

These codes justify different repairs; do not delete WindowsApps, manually alter AppX registry keys, or repeatedly re-register every built-in package before identifying the code.

3. Repair Windows only if the evidence points there

Because unrelated Store deployments also fail, an operating-system repair is a reasonable next branch—but it is not yet proof that Click-to-Run, Windows Installer, or specific registry keys are damaged.

If DISM reports component-store corruption

Review:

• C:\Windows\Logs\CBS\CBS.log
• C:\Windows\Logs\CBS\CbsPersist_*.log or .cab
• C:\Windows\Logs\DISM\dism.log

If online DISM /RestoreHealth already failed because repair content could not be obtained, rerun it with installation media matching the installed Windows version, edition, architecture, and language:

DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth ^
 /Source:WIM:D:\sources\install.wim:<index> /LimitAccess

The source must match the installed operating system; otherwise, collect the DISM and CBS logs instead of manually replacing component files.^5^

If Store and Office still fail but servicing repair is inconclusive

On Windows 11, use Settings → System → Recovery → Fix problems using Windows Update → Reinstall now. This reinstalls the current Windows version, repairs system files/components, and preserves apps, files, and settings.^6^

If that option is unavailable, perform an in-place repair from matching Windows installation media: run setup.exe from within Windows and select Keep personal files and apps. Back up important data first.^7^

Escalation package

If repair does not resolve the failures, provide Microsoft Support with:

• Windows version/build (winver) and architecture.
• Exact Office 2019 edition and license type.
• ODT version, XML with sensitive paths removed, command, exit code, and verbose logs.
• Exported Application, AppXDeployment-Server, and AppxPackagingOM logs.
• Exact Store HRESULT/error code.
• CBS.log, archived CBS logs, and dism.log.
• A timeline containing one Office and one Store reproduction.

For fuller Store collection, Microsoft’s public TSS tool supports the PRF_Store scenario specifically for Store installation and infrastructure failures.^8^

Finally, Office 2019 reached end of support on October 14, 2025, so it no longer receives security fixes, bug fixes, or Microsoft technical support; plan migration to a supported Office release even if installation is restored.^9^

References

1. Office 2019 on-premises release details
2. Overview of the Office Deployment Tool
3. Add Microsoft 365 Apps to Windows Devices Using Microsoft Intune
4. Troubleshooting packaging, deployment, and query of Windows apps
5. Fix Windows Update corruptions and installation failures
6. Fix issues by reinstalling the current version of Windows | Microsoft Support
7. Reinstall Windows with the installation media | Microsoft Support
8. Collect data to analyze and troubleshoot application management scenarios
9. Products reaching end of support on October 14, 2025