0x80073D0A: Firewall Service Not Running, Low Disk Space or Network Failure

Fix it now

These codes are the deployment engine refusing on environment grounds rather than on anything wrong with the package. 0x80073D0A is specific and often misread: it means the Windows Firewall service is not running. Read the exact code from the deployment log and fix the condition it names.

Get-AppxLog
Get-Service mpssvc
Start-Service mpssvc
Get-Volume
Get-AppxVolume

1. Take the code from Get-AppxLog or from AppXDeployment-Server, Operational, not from whatever generic failure your deployment tool displayed.
2. 0x80073D0A: start the Windows Firewall service and try again. Microsoft’s remedy is exactly that, and it is common on machines where a third-party firewall was installed and the inbox service was turned off.
3. 0x80073CF4: free space on the volume that holds the package repository, then retry. Staging needs room for the payload plus working space.
4. 0x80073CF5: copy the package to a local folder such as C:\temp and install from there rather than from a share, a mapped drive or a URL.
5. 0x80073D0D: the target volume is offline. Get-AppxVolume lists package volumes and Mount-AppxVolume -Volume <volume> brings one back.

0x80073D10 is the architecture refusal, not 0x80073D0A. If the log gives you 0x80073D10 you need a different build of the package, and nothing on this machine will change that.

If the condition it named is now satisfied and the package installs, stop here. Otherwise the next section takes the five codes apart.

Why it happens

Before a byte of payload is written, the engine confirms the operation can succeed in this environment. It picks the applicable package out of a bundle for the processor architecture, works out how much space staging needs on the target volume, confirms the source is readable, and confirms the services it depends on are available. Each of those failing produces its own code, and each has a different fix. They are not interchangeable.

0x80073D0A is the one people misfile. Microsoft publishes it as ERROR_INSTALL_FIREWALL_SERVICE_NOT_RUNNING, with the text “the package couldn’t be installed because the Windows Firewall service isn’t running. Enable the Windows Firewall service and try again.” It has nothing to do with the processor architecture. That is 0x80073D10, ERROR_INSTALL_WRONG_PROCESSOR_ARCHITECTURE, a separate code that means the package targets an architecture this device does not run.

The firewall dependency surprises people because disabling the inbox firewall service is a routine step when a third-party product takes over. Packaged apps declare firewall rules in their manifest, so the deployment path expects that service to be there to write them. Turn it off and every MSIX deployment on the machine stops, weeks after whoever disabled it has moved on.

Full reference

The five codes, side by side

Package volumes

Windows can be configured to install packaged applications somewhere other than the system drive. When it is, the deployment engine works against a package volume rather than a plain drive letter, and the volume has to be present and mounted for anything to happen. The cmdlets are small and worth knowing before you need them.

A removable drive that was set up as a package volume and then unplugged produces 0x80073D0D for packages that have nothing to do with it, because for an update the volume Microsoft refers to is the installed volume of every version of the package.

Working out which condition applies without guessing

1. Run Get-AppxLog immediately after the failure, or open AppXDeployment-Server, Operational in Event Viewer and read the most recent entry.
2. Match the code against the table above before doing anything on the machine.
3. For a service problem, check the service state rather than assuming – Get-Service mpssvc takes a second and rules it in or out.
4. For a space problem, check the volume the package repository is on, not whichever drive has least free space.
5. For an architecture problem, stop working on the device. The answer is a different package.

Architecture, and why emulation does not save you

A bundle contains separate packages for different processor architectures and the engine selects the applicable one. If nothing in the bundle applies, the deployment stops. Emulation does not change that: whether the device can run code of a given architecture is a separate question from whether the bundle declares a package the device will accept. Check the vendor’s supported platform list rather than assuming a bundle that installed elsewhere will install here.

When none of the five conditions is present

• Confirm the code you are working from came from the deployment log rather than from a wrapper. Deployment tools routinely collapse several of these into one generic message.
• Check the component store: DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow. Deployment depends on servicing.
• Look for a policy block instead. 0x80073CFF and 0x80073D01 are deployment policy refusals and read as environment failures until you see the code.
• Test the same package on a machine of the same build and architecture. If it installs there, you are looking at machine state, not the package.

Every code this article covers

Confirm the fix worked

1. Get-Service mpssvc reports Running, and its startup type is not Disabled.
2. Get-AppxVolume shows the package volume online.
3. The package installs from a local path with no code returned.
4. Get-AppxLog for the successful attempt records staging and registration completing.

Questions people ask about this