Project Spartan 10009/10049 AppX reports "End of Life" on modern Windows

Đoàn Viết Khôi Nguyên 0 Reputation points
2026-08-19T09:57:37.0533333+00:00

Project Spartan 10009/10049 AppX reports "End of Life" on modern Windows

Hi Microsoft,

I'm an 11-year-old kid who really likes Windows modding, reverse engineering, and experimenting with old Windows software. Recently, I ran into a problem while working on a personal project to port the old Project Spartan browser to a newer version of Windows 10.

When I try to install the original Spartan AppX package through PowerShell, I get this error:

PS C:\Windows\system32> Add-AppxPackage "C:\Users\User\Downloads\Microsoft.Spartan_0.2.10009.16_x64__8wekyb3d8bbwe\Microsoft.Spartan_0.2.10009.16_x64__8wekyb3d8bbwe.appx"

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CFD,
A Prerequisite for an install could not be satisfied.

Package Microsoft.Spartan_0.2.10009.16_x64__8wekyb3d8bbwe is end of life and can no longer be installed.

NOTE: For additional information, look for [ActivityId]
2aee7b18-2f80-0004-6fe2-f12a802fdd01 in the Event Log or use
the command line
Get-AppPackageLog -ActivityID 2aee7b18-2f80-0004-6fe2-f12a802fdd01

I also tried modifying the AppxManifest.xml and rebuilding the package with WSAppBak (Windows Store app Backup tool), but the EOL error still occurs.

I found another interesting behavior while experimenting:

If I keep the original Microsoft Publisher information, the package gives the EOL error.

If I change the Publisher from Microsoft Corporation to Microsoft, the package installs successfully, but Spartan crashes when I launch it.

  • If I change the Microsoft.Spartan package identity/name, it also installs successfully, but the application crashes, apparently even earlier.
  • and the clue I know is when porting other Windows 10 10009/10049 apps when extract i need to remove AppxMetadata folder, AppxBlockMap.xml, and AppxSignature.p7x before compiles because this help remove EOL error in most apps, but when i tried that trick on Spartan it did not work as expected, and other app of Windows 10 10009/10049 also behave the same as Spartan, when change the publisher name it and compile, after install it crashs

I don't have the original Spartan source code, and I don't have enough experience with Windows debugging tools yet to determine exactly why it crashes.

I would really like to understand what is causing the EOL check. Is it related to the package identity, Publisher, AppX deployment system, package metadata, or another Windows compatibility mechanism?

If possible, could someone from the Microsoft team explain why this old Spartan package is considered end of life and whether there is a legitimate way to run it for Windows preservation/research purposes?

Thank you very much for reading this and for any information you can provide!

Developer technologies | Universal Windows Platform (UWP)

2 answers

Sort by: Most helpful
  1. Danny Nguyen (WICLOUD CORPORATION) 8,450 Reputation points Microsoft External Staff Moderator
    2026-08-21T06:39:39.1333333+00:00

    Hi @Đoàn Viết Khôi Nguyên ,

    I need to correct part of my earlier explanation. I could not verify that Windows uses a hardcoded blocklist in AppxDeploymentServer.dll, or that the following registry path is the source of this installation block:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\EndOfLife

    That registry path is used in AppX package lifecycle and removal scenarios, but I found no documentation showing that it is where Windows looks up packages that must be blocked from installation.

    What your deployment log confirms is:

    • Event 848 reports that the original Microsoft.Spartan package is considered end of life.
    • Event 605 shows that the operation reached Evaluated and failed before PrerequisitesChecked, returning 0x80073CFD.
    • Event 404 records the final AppX deployment failure and repeats the EOL message.

    These entries show that the EOL result comes from the Windows AppX deployment process. However, they do not show where Windows obtains that EOL status. I could not find public documentation confirming whether it comes from servicing metadata, an internal package database, a compatibility rule, or another source.

    Changing the package Name or Publisher creates a different package identity, which explains why Windows may process the modified package differently. However, that does not confirm the internal mechanism used for the original package.

    Microsoft documents how to review AppX deployment logs here:

    Those references explain how to retrieve deployment details, but they do not document Events 848 or 605 individually or identify the source of the EOL designation.

    Therefore, the most accurate conclusion is that current Windows versions reject the original Spartan package during AppX deployment, but the exact internal source of that EOL decision is not publicly documented. Project Spartan is also an obsolete preview component, so installing or running it on current Windows versions is not supported.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. Danny Nguyen (WICLOUD CORPORATION) 8,450 Reputation points Microsoft External Staff Moderator
    2026-08-19T10:50:43.8066667+00:00

    Hi @Đoàn Viết Khôi Nguyên ,

    Great write-up — you've already done most of the investigation yourself..

    Short answer: there's no supported way to install this package on modern Windows, and no official source for the APPX.

    Project Spartan was never released as a standalone package. It shipped in-box as part of Windows 10 Technical Preview build 10049, released to Insiders in the Fast ring on 30 March 2015. Preview builds are time-limited by design and are no longer distributed or serviced, so there's no Microsoft-provided download for this package.

    On the two behaviours you found

    1. The "end of life" block. Editing AppxManifest.xml and repacking won't get around it — that's expected, not a bug in your process. Worth knowing: this isn't specific to Spartan. The same message appears for other retired in-box packages (for example Microsoft.Wallet during a bulk re-register on Windows 11), so it's general deployment-stack behaviour for packages that have been retired.

    If you want to see exactly where it stops, run:

    Get-AppPackageLog -ActivityID <your ActivityId>
    

    You'll see the EOL message logged, followed by an entry saying the last successful state reached was Evaluated, and that the failure happened before reaching PrerequisitesChecked, with hr 0x80073CFD. So the check runs at the prerequisites stage, after the package has been evaluated.

    I haven't found a public documentation on this so I'd rather not guess at the mechanism.

    2. Why the rename installs but crashes. Package identity is tied to the signing certificate's subject, and Windows requires packages to be signed with a certificate that chains to a trusted root. When you removed AppxSignature.p7x and changed the Publisher, you created a different package that's no longer signed the way the system expects.

    For the crash itself: Spartan depends on early Windows 10 internals — the EdgeHTML and UWP components of that build — which have since changed or been removed. I can't confirm that from public docs, but it fits what you're seeing.

    Useful references if you want to keep digging into deployment errors generally

    For preservation/research purposes, the realistic route is running the original build in a VM rather than trying to port the app forward. Note that we can't help with sourcing old preview images here.

    Hope that clears up on why this happens. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

    Thank you.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.