SOLVED: Error 0x87DD0005

Question

SOLVED: Error 0x87DD0005

Mohammad Hassan 10

TROUBLESHOOTING CASE REPORT

eFootball Launch Failure

Denuvo Anti-Tamper License Error 0x87DD0005 - Case Report


Environment	Windows 10 Pro 22H2 - Build 19045 (x64)
--------	--------
Environment	Windows 10 Pro 22H2 - Build 19045 (x64)
Affected App	eFootball - Microsoft Store / Xbox app version
Primary Symptom	Denuvo error page and code 0x87DD0005 at launch
Outcome	RESOLVED - full functionality restored

Personal Technical Reference - October 2026

Executive Summary — 1
Problem Onset and Symptoms — 1
- 2.1 What the Failure Looked Like — 2
  - 2.2 Context and Unusual Factors — 2
    - 2.3 Environment Snapshot — 2
    1. Phase 1 - Diagnosis and Evidence Gathering — 3
      - 3.1 The Fastest Evidence Source: Event Viewer AAD Log — 3
        
        3.2 dsregcmd /status - Discovery of a Ghost Enterprise Account — 4
        
        3.3 Interpretation - Why This Breaks the Game — 4
        
        Phase 2 - Ghost Workplace Account Removal — 4
        
        Phase 3 - Windows Update Investigation — 5
        
        Phase 4 - System Component Repair — 6
        
        6.1 A Failed Removal That Revealed Deeper Damage — 6
        
        6.2 Gaming Services Repair and Reset — 6
        
        6.3 System File Repair - DISM and SFC — 7
        
        6.4 Re-registering the Identity and Store Components — 7
        
        Phase 5 - Identity and Token Cleanup — 8
        
        7.1 Purging Stale Credentials from Credential Manager — 8
        
        7.2 Emptying the TokenBroker Caches — 9
        
        7.3 Reboot as a Checkpoint — 9
        
        Successful Launch Sequence and Root Cause Analysis — 10
        
        8.1 The Exact Sequence That Worked — 10
        
        8.2 Root Cause Assessment — 11
        
        Lessons Learned and Recommendations — 11

Appendix A - Command Reference (Copy-Ready) — 12
- A.1 Diagnosis Commands — 12
  - A.2 Identity Cleanup Commands — 13
    - A.3 System Repair and Re-registration Commands — 13
      - A.4 Update State Queries — 14
        
        A.5 Final Launch Checklist — 14
        
        Appendix B - Files, Paths and Logs Register — 15

Note: This Table of Contents is generated via field codes. To ensure page number accuracy after editing, please right-click the TOC and choose Update Field.

1. Executive Summary

This document records a complete, real troubleshooting case from the moment the fault appeared to the moment it was resolved, so that it can serve as a reliable personal reference if the same failure ever recurs. The affected product was eFootball, the Microsoft Store (Xbox app) edition, running on Windows 10 Pro 22H2, build 19045.7725. The game had been working normally the day before the incident, and no deliberate configuration changes had been made in the intervening period.

At launch, the game displayed the Denuvo Anti-Tamper error page (support.codefusion.technology/anti-tamper/?e=88500000&l=english&p=m&a=eFootball) together with the code 0x87DD0005, and then closed itself. This code belongs to the Microsoft Store licensing and identity chain rather than to the game engine itself, which immediately suggested that the failure was happening during the license validation step that Denuvo performs before the game is allowed to run.

Diagnosis through Event Viewer revealed a broken token-renewal chain inside the Windows identity stack (AAD BrokerPlugin / Web Account Manager), along with a leftover ghost enterprise account of the Workplace Join type. Remediation proceeded in five chronological phases: evidence gathering, ghost account removal, Windows update verification, system component repair (DISM, SFC, and Appx re-registration), and finally identity and token cleanup (Credential Manager and TokenBroker caches). The game returned to full working order after the complete cleanup combined with one specific launch habit: after a reboot, the Xbox app is opened and signed in first, and only then is eFootball started.

2. Problem Onset and Symptoms

2.1 What the Failure Looked Like

On the morning of the incident, launching eFootball from the Start menu produced a browser-style error page instead of the game window. The page was served by Denuvo Anti-Tamper at the address support.codefusion.technology/anti-tamper/ with the parameters e=88500000, l=english, p=m (indicating the Microsoft Store platform), and a=eFootball. Beneath the page header, the error code 0x87DD0005 was displayed, after which the game process terminated automatically without reaching the main menu.

The code 0x87DD0005 is not a graphics or crash-code error; it is a licensing error returned when the Windows Store licensing stack cannot establish a valid entitlement for the requesting application. In practical terms, Denuvo Anti-Tamper asked Windows to prove that the signed-in user owns the game, Windows failed to produce a valid proof, and the anti-tamper layer aborted the launch on purpose. This distinction matters because it directs all troubleshooting toward accounts, tokens, and certificates rather than toward drivers or game files.

2.2 Context and Unusual Factors

Three contextual facts made this incident unusual and worth documenting. First, the game ran perfectly on the previous day, so any explanation had to involve something that changed on the machine or on the service side within roughly twenty-four hours. Second, on that same morning, other users in community forums reported the identical error with the same code, which briefly made a server-side outage look plausible. Third, Windows had installed a batch of six updates that same day, including the October 2026 cumulative update (KB5126657, build 19045.7807) listed in the update history, and the monthly Malicious Software Removal Tool run (KB890830).

The combination of a sudden failure, matching reports from strangers, and a same-day update wave naturally produced two competing hypotheses. The first was that the Xbox Live or Store licensing services were partially down. The second was that the newly arrived cumulative update had broken the Store identity components. Both hypotheses were actively investigated, and both were eventually demoted from primary cause, for reasons explained in the later phases of this report.

2.3 Environment Snapshot

The table below fixes the exact environment in which the failure occurred and in which every command in this document was executed. Recording the build number precisely proved important later, because the update history page and the actually installed package store told two different stories.

Table 1: Environment snapshot at the time of failure

Item	Value
Operating system	Windows 10 Pro 22H2, 64-bit
--------	--------
Operating system	Windows 10 Pro 22H2, 64-bit
OS build (at incident)	19045.7725 (September cumulative KB5122878)
Update history showed	KB5126657 (October cumulative, build 19045.7807)
Affected application	eFootball - Microsoft Store / Xbox app edition
Primary error code	0x87DD0005 (Denuvo Anti-Tamper license failure)
Date of incident	October 2026

3. Phase 1 - Diagnosis and Evidence Gathering

3.1 The Fastest Evidence Source: Event Viewer AAD Log

For Microsoft Store applications, license and sign-in problems almost always leave traces in the operational log of the Azure Active Directory (AAD) provider, because Store apps authenticate through Web Account Manager (WAM) and the Microsoft.AAD.BrokerPlugin system component. Opening Event Viewer and navigating to Applications and Services Logs, then Microsoft, then Windows, then AAD, then Operational, produced immediately actionable evidence - far faster than any generic advice about reinstalling the game.

The log contained a repeating sequence of failures covering token renewal, certificate retrieval, and an outright protocol rejection from a Microsoft resource. The table below lists each event, its essential message, and the interpretation that guided the next steps.

Table 2: Event Viewer evidence (Microsoft-Windows-AAD/Operational)

Event ID	Message Summary	Interpretation
1097	Token renewal failed with 0xCAA90056	The periodic refresh of the account token could not complete, so the cached identity was aging toward expiry
--------	--------	--------
1097	Token renewal failed with 0xCAA90056	The periodic refresh of the account token could not complete, so the cached identity was aging toward expiry
1098	0xCAA20003 (invalid_grant) with AADSTS9002313 - Request is malformed; resource https://arc.msn.com/v4\|The broker presented a stale or corrupted grant to an Xbox/Microsoft service, and the service rejected the request as malformed rather than merely expired
1025	HTTP 400 response from the cacerts endpoint	The certificate provisioning endpoint refused the request, indicating the local certificate material no longer matched what the service expected
1256	P2P certificate event	Routine peer-to-peer certificate chatter; recorded as benign noise and deliberately ignored

3.2 dsregcmd /status - Discovery of a Ghost Enterprise Account

The single most revealing diagnostic of the whole case was dsregcmd /status, a built-in command that prints the device registration and workplace join state of the machine. Its output showed two things that did not belong: the field WorkplaceJoined was set to YES, and the WorkplaceTenantId pointed to tenant 7a828af0-5008-44c1-8bbe-4b232493defe - a university tenant associated with an academic email used in 2023.

This was a leftover Workplace Join registration: a lightweight, headless enterprise account that certain organizations attach to a device without full Azure AD join. The device certificate attached to this registration was also aged, and its validity window added further suspicion. In other words, the machine was carrying two identities at once - the personal Microsoft account that actually owned the game, and a stale enterprise shadow identity that the token broker kept trying to satisfy.

3.3 Interpretation - Why This Breaks the Game

Putting the evidence together produced a coherent picture. Denuvo Anti-Tamper asks the Store licensing stack for proof of ownership. The licensing stack asks Web Account Manager for a valid token. WAM delegates to the AAD BrokerPlugin, which consults its TokenBroker caches and device certificates - and those caches contained grants for the wrong identity, certificates that failed renewal, and a ghost workplace tenant competing for attention. The service rejected the malformed request with AADSTS9002313, the broker returned failure, and the launch was aborted with 0x87DD0005.

This interpretation also explained why the failure was sudden rather than gradual: token chains survive on refresh cycles, and the cycle had finally failed after the cached material aged past the point where the service would still accept it. The same-day update wave may have accelerated or triggered the final refresh failure, but the corrupted identity state itself was local, which matched the fact that a clean reinstall of the game alone would never fix it.

4. Phase 2 - Ghost Workplace Account Removal

With the ghost tenant identified, the next chronological step was to remove it completely. The removal touched three places: the certificate store, the registry, and the Task Scheduler. Each location is listed below in the order it was actually performed, and every step was verified afterwards with a fresh dsregcmd /status run.

Certificate store: opened certmgr.msc, expanded Personal, then Certificates, located the stale workplace certificate (issued 3-8-2023, tied to the university tenant), and deleted it.
Registry traces: removed the key HKCU\Software\Microsoft\Workplace, which holds the Workplace Join account metadata that keeps a ghost identity alive.
Scheduled task: in Task Scheduler, removed the Workplace Join task that periodically re-attempts the headless enterprise join.
Verification: ran dsregcmd /status again and confirmed WorkplaceJoined now reads NO and the university tenant no longer appears.

The removal itself succeeded on the first attempt. However, launching the game at this point still produced the same Denuvo page and the same 0x87DD0005 code. This was an important intermediate result: the ghost account was a genuine contaminant worth removing, but it was a contributor rather than the sole cause, and additional repair phases were required.

5. Phase 3 - Windows Update Investigation

Because the update history page listed the October cumulative (KB5126657, build 19045.7807) as installed that day, the plausible next hypothesis was an update regression. The authoritative way to check which packages are truly present is the Deployment Image Servicing and Management tool, not the history page. The commands used were:

Commands: verifying the actually installed update state

net stop wuauserv

DISM /Online /Get-Packages | findstr /i "RollupFix"

wmic qfe list brief | findstr /i "5126657"

wmic qfe list brief | findstr /i "5122878"

The DISM query returned exactly one rollup package: Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.7725.1.26 - the September cumulative KB5122878. The October package was not present in the servicing store at all, and the quick query confirmed it. The October entry visible in the Settings update history page was a historical record of an offered or partially staged update, not proof of an installed component. The system had remained on build 19045.7725, which the Command Prompt banner and winver also confirmed.

Key lesson. The Settings page titled Update history is a log of update attempts and offers, not a statement of installed state. Only DISM /Online /Get-Packages or wmic qfe can be trusted to answer the question - and confusing the two can lead to uninstalling a package that is not actually installed.

As a final hygiene check, the Malicious Software Removal Tool log was inspected at C:\Windows\debug\mrt.log. It recorded the routine October run (KB890830) with no detections and no removal actions, which closed the malware hypothesis as well. With the update and malware angles ruled out, attention moved to repairing the identity and Appx servicing components themselves.

6. Phase 4 - System Component Repair

6.1 A Failed Removal That Revealed Deeper Damage

The planned deep fix for the Store stack was to remove and let Windows regenerate the Gaming Services component, which underpins all Store-delivered games. The PowerShell removal command failed with error 0x8007007E (The specified module could not be found), reported as a failure to load an extension DLL. A component that cannot even be removed cleanly is a component whose servicing metadata is damaged, and this shifted the plan from surgical removal to generic integrity repair.

6.2 Gaming Services Repair and Reset

Following the standard route, Gaming Services was repaired and then reset through Settings, under Apps, then Installed apps, then Gaming Services, then Advanced options. The Repair action completed normally, and the Reset action was executed afterwards to rebuild the component state. This is the recommended order when the PowerShell route is blocked by servicing errors, because Repair preserves data while Reset rebuilds the app registration.

6.3 System File Repair - DISM and SFC

To heal the servicing damage that the 0x8007007E error exposed, the component store was repaired first and the system files were verified second, in that specific order:

Commands: component store repair, then system file verification

DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow

DISM RestoreHealth completed successfully after downloading healthy copies of damaged components, and the subsequent System File Checker run completed without finding integrity violations, which is the expected outcome when DISM has already replaced the damaged material. The servicing stack was now healthy enough to accept package re-registration.

6.4 Re-registering the Identity and Store Components

The final repair step re-registered three Appx packages whose registration the incident had damaged. The first and most important was the AAD BrokerPlugin, the very component whose token failures were logged in Phase 1. An initial attempt failed with a parameter error because the switch -ForCurrentUser is not supported in this cmdlet usage on Windows PowerShell 5.1; removing that parameter produced a clean, silent success:

Commands: re-registering AAD BrokerPlugin, Microsoft Store, and Xbox app

Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode

Get-AppxPackage Microsoft.WindowsStore | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Get-AppxPackage Microsoft.GamingApp | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Practical note. Re-registration commands must be run from the affected user account, from an elevated PowerShell window. The -DisableDevelopmentMode switch combined with -Register re-reads the manifest and rebuilds the package registration without touching the app data - exactly what a damaged broker needs.

7. Phase 5 - Identity and Token Cleanup

7.1 Purging Stale Credentials from Credential Manager

With the components repaired, the remaining work was to erase every cached identity artifact that could still feed the broker a bad grant. The first stop was Credential Manager. The inventory command lists the stored credentials whose names begin with the relevant prefixes, and each listed entry was then deleted by its exact name:

Commands: listing and deleting stale Microsoft account credentials

cmdkey /list | findstr /i "MicrosoftAccount SSO_POP"

cmdkey /delete:"MicrosoftAccount:target=SSO_POP_Device"

cmdkey /delete:SSO_POP_Device

cmdkey /delete:SSO_POP_User

The entries worth targeting were the SSO_POP_Device and SSO_POP_User credentials and every MicrosoftAccount: entry whose target matched the Microsoft account in use. These records hold the single sign-on tokens that the token broker hands to Store apps; when they go stale, every Store-dependent application inherits the failure. The delete commands must copy the names exactly as the list command prints them.

7.2 Emptying the TokenBroker Caches

The second stop was the two TokenBroker cache locations. The cache folders themselves must remain in place - only their contents are removed. This cleanup was performed twice during the case: once midway through the process, and once again after the component re-registration of Phase 4, because re-registration can itself write fresh entries that are better discarded before the final sign-in.

Commands: emptying both TokenBroker cache folders (contents only)

Remove-Item "$env:LOCALAPPDATA\Microsoft\TokenBroker\Cache\*" -Force -ErrorAction SilentlyContinue

Remove-Item "$env:LOCALAPPDATA\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\*" -Force -ErrorAction SilentlyContinue

Warning. Delete the contents of the TokenBroker folders, never the folders themselves. Removing the folders can confuse the broker and the Appx model, and the folders are regenerated empty anyway. If a file refuses to be deleted, an application is still holding it - close all Store apps or reboot first.

7.3 Reboot as a Checkpoint

A full reboot followed the cleanup, not a sign-out. A reboot forces every broker process, scheduled identity task, and cached handle to start from zero against the freshly cleaned state, and it also applies anything the servicing operations of Phase 4 had left pending. This reboot is the formal checkpoint that separates the repair phase from the final launch sequence.

8. Successful Launch Sequence and Root Cause Analysis

8.1 The Exact Sequence That Worked

After the reboot, the game did not simply work the moment it was clicked - the order of the first sign-in mattered. The sequence below is recorded exactly as performed, because it is the repeatable recipe if the failure ever returns:

Reboot the machine and wait for full startup.
Open the Xbox app first and sign in freshly with the Microsoft account that owns the game; wait until the library loads completely.
Only then launch eFootball.
The Denuvo Anti-Tamper check completed silently this time - no error page, no 0x87DD0005 - and the game reached the main menu.
Confirm from the game settings that cloud and online features operate normally.

The reason this order matters is that the Xbox app performs the interactive sign-in that mints brand-new tokens and repopulates the emptied TokenBroker caches with valid material. Launching the game first would have forced Denuvo to request a license against still-empty caches. Opening the Xbox app first guarantees that by the time the game asks for proof of ownership, fresh and valid tokens are already in place.

8.2 Root Cause Assessment

The most probable root cause is a composite one: the machine was carrying a stale ghost enterprise identity (Workplace Join to a university tenant from 2023) alongside aged device certificates and corrupted token grants, and the token-renewal chain of the AAD BrokerPlugin finally broke past the point of self-repair. The Event Viewer sequence (0xCAA90056, then 0xCAA20003 with AADSTS9002313, then HTTP 400 on certificate retrieval) is the signature of exactly such a collapse.

It is honest to state that the single decisive step cannot be isolated, because the repair was cumulative: removing the ghost account, repairing servicing, re-registering the broker, and purging credentials and tokens were all completed before the one successful attempt. What can be stated confidently is the negative result - neither a server-side outage nor the October cumulative update was the cause. The update was proven not installed via DISM, the MSRT log was clean, and the Xbox Live status page showed no major disruption matching the incident window.

The practical conclusion for future incidents is that Store-game license failures of this family respond to identity-stack repair, not to reinstalling the game. The game binary was never the problem at any point in this case.

9. Lessons Learned and Recommendations

Start from the AAD operational log. For any Microsoft Store app that fails licensing or sign-in, Event Viewer at Applications and Services Logs, Microsoft, Windows, AAD, Operational produces concrete event codes in minutes - far faster than generic fixes.
Trust DISM, not the history page. The Settings update history records attempts; only DISM /Online /Get-Packages and wmic qfe reveal what is genuinely installed. Verify before uninstalling anything.
Check dsregcmd after any identity change. The WorkplaceJoined, AzureAdPrt, and certificate fields turn a vague suspicion of a broken identity into a confirmed, specific diagnosis.
Document ghost tenants at discovery time. Recording the tenant ID and the origin (a 2023 university email) immediately explained the certificate ages and prevented misattributing the tenant to malware.
Keep the Xbox-app-first habit. After any identity operation, reboot, sign in through the Xbox app first, and only then start Store games. This guarantees fresh tokens exist before any license check.
Re-run token cleanup after re-registration. Component re-registration can write fresh cache entries; emptying the TokenBroker caches a second time after Phase 4 removed that risk before the final sign-in.

If this failure ever recurs, the fastest route is Appendix A: execute the diagnosis commands first, confirm the identity symptoms, then walk the cleanup and repair sequence in order. The full command set is deliberately kept copy-ready in that appendix.

Appendix A - Command Reference (Copy-Ready)

All commands below were executed exactly as written during this case. Commands are grouped by the phase in which they were used, so the appendix doubles as a recovery playbook when paired with the chapter order of this report.

A.1 Diagnosis Commands

A.1 - Registration state, Event Viewer, credential inventory

dsregcmd /status

eventvwr.msc

cmdkey /list | findstr /i "MicrosoftAccount SSO_POP"

A.2 Identity Cleanup Commands

A.2 - Credential deletion and TokenBroker cache cleanup

cmdkey /delete:"MicrosoftAccount:target=SSO_POP_Device"

cmdkey /delete:SSO_POP_Device

cmdkey /delete:SSO_POP_User

Remove-Item "$env:LOCALAPPDATA\Microsoft\TokenBroker\Cache\*" -Force -ErrorAction SilentlyContinue

Remove-Item "$env:LOCALAPPDATA\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\*" -Force -ErrorAction SilentlyContinue

A.3 System Repair and Re-registration Commands

A.3 - Component store repair, SFC, Appx re-registration

DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow

Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode

Get-AppxPackage Microsoft.WindowsStore | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Get-AppxPackage Microsoft.GamingApp | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

A.4 Update State Queries

A.4 - Installed rollup packages and quick-fix verification

DISM /Online /Get-Packages | findstr /i "RollupFix"

wmic qfe list brief | findstr /i "5126657"

wmic qfe list brief | findstr /i "5122878"

A.5 Final Launch Checklist

Reboot.
Open the Xbox app first and sign in freshly; wait for the library to load.
Launch eFootball.
If the Denuvo page returns, re-check Event Viewer AAD logs for new event codes before repeating any cleanup.

Appendix B - Files, Paths and Logs Register

The register below lists every location that was read, modified, or monitored during this case, with the purpose of each location and the action actually taken. It exists so that a future recurrence can be handled without re-discovering where the state lives.

Table 3: Register of locations touched during remediation

Location / Path	Type	Purpose	Action Taken
Applications and Services Logs > Microsoft > Windows > AAD > Operational	Event log	Token, grant, and certificate failure evidence (events 1097, 1098, 1025, 1256)	Reviewed in Phase 1; re-checked before final launch
--------	--------	--------	--------
Applications and Services Logs > Microsoft > Windows > AAD > Operational	Event log	Token, grant, and certificate failure evidence (events 1097, 1098, 1025, 1256)	Reviewed in Phase 1; re-checked before final launch
dsregcmd /status output	Command output	Device registration, Workplace Join state, AzureAdPrt, certificate validity	Confirmed ghost tenant, then confirmed clean state
certmgr.msc > Personal > Certificates	Certificate store	Held the stale 2023 workplace certificate of the ghost tenant	Certificate deleted
HKCU\Software\Microsoft\Workplace	Registry key	Metadata that keeps the Workplace Join account alive	Key removed
Task Scheduler > Workplace Join task	Scheduled task	Periodically re-attempts the headless enterprise join	Task removed
%localappdata%\Microsoft\TokenBroker\Cache	Token cache	Microsoft account token broker cache	Emptied (contents only), twice
%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker	Token cache	AAD BrokerPlugin token cache	Emptied (contents only), twice
C:\Windows\debug\mrt.log	Log file	Malicious Software Removal Tool (KB890830) scan log	Inspected - no detections
Settings > Apps > Gaming Services > Advanced options	Settings page	Repair and Reset entry point for Gaming Services	Repair, then Reset executed

Locked Question. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments