KB4052623: MdOdrMcpFilterPackage stuck on stale ExternalLocation (0x80073D0B), slow first boot and false Defender warning

I am reporting what appears to be a Microsoft Defender platform-servicing defect involving the non-removable SYSTEM package MdOdrMcpFilterPackage_1.0.0.0_neutral__cw5n1h2txyewy.

Environment

• Windows 11 25H2, OS build 26200.9168
• Microsoft Defender platform 4.18.26080.3
• Microsoft Defender engine 1.1.26080.3
• Defender update: KB4052623, Current Channel (Staged)
• Default gradual rollout configuration; no Beta/Insider Defender channel or custom platform ring
• Affected package display name: Microsoft Defender On-device Registry Filter
• Package is registered for SYSTEM (S-1-5-18) and is marked NonRemovable

User-visible symptoms

1. The first startup after the computer has been off overnight is consistently slower than later restarts on the same day.
2. After startup, Windows sometimes displays a notification saying that Windows virus protection must be activated.
3. Defender is actually active: AMServiceEnabled, AntivirusEnabled, RealTimeProtectionEnabled, and AntispywareEnabled all report True.
4. The SecurityCenter application log contains only SECURITY_PRODUCT_STATE_ON (Event 15) for the retained period and no corresponding OFF state.

Confirmed package-registration inconsistency

Read-only inspection of the AppX StateRepository shows that this package still references the external location and source MSIX of Defender platform 4.18.26040.7-0:

ExternalLocation:
C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.26040.7-0

PackageSourceUri:
C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.26040.7-0\MdOdrMcpFilter.msix

That old platform directory no longer exists. The current, correctly signed MSIX is present under:

C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.26080.3-1\MdOdrMcpFilter.msix

The current MSIX and executable have valid Microsoft Windows Authenticode signatures. The MSIX contains AppxManifest.xml, AppxBlockMap.xml, and AppxSignature.p7x; therefore, a workaround based on a missing AppX signature does not apply here.

The package manifest identity remains version 1.0.0.0 in both Defender platform 4.18.26070.9 and 4.18.26080.3. Its relevant manifest data is:

Identity Name: MdOdrMcpFilterPackage
Publisher: Microsoft Windows
Version: 1.0.0.0
Architecture: neutral
Executable: MdOdrMcpFilter.exe
Extension: com.microsoft.windows.ai.mcpFilter
COM server CLSID: 8E8BC9EC-86D1-4B1F-912E-6F3F2F33645A

Reproducible servicing failure

The supported Defender command MpCmdRun.exe -ResetPlatform was run once. It returned exit code 0 but did not repair the package registration.

During that operation, AppXDeploymentServer logged:

Event 603: RemoveForAllUsers started
Event 400: DeStage completed successfully
Event 603: Stage started by MsMpEng.exe as SYSTEM
             ForceUpdateFromAnyVersion
             ExternalLocation = ...\4.18.26080.3-1

Events 867 / 401 / 404: 0x80073D0B
Windows cannot install the package because it is already installed
with a different external location.

At the same time, Windows Update logged Event 19 stating that KB4052623 platform 4.18.26080.3 was installed successfully. This appears to be a partial-success condition: the main Defender platform updates and reports healthy, while its auxiliary AppX package remains registered against an obsolete external location.

Timing evidence

The same AppX failure is logged repeatedly, including at morning startup. First attempts after overnight shutdown commonly take approximately 3.1 to 5.5 seconds in AppX staging; later attempts on the same day are often below one second.

One representative first-start attempt reported:

AppX stage overall time: 4641 ms
Active time:             4500 ms
Enqueue time:            3828 ms
Indexing time:            359 ms
Result:                  0x80073D0B

StateRepository Event 284 also shows a full reindex lasting roughly 10 to 18.6 seconds on affected first starts. The package-stage error is therefore a confirmed contributor to the delay, although the available evidence does not prove it is the sole cause of the complete StateRepository reindex.

Probable origin

The StateRepository reference is pinned to platform 4.18.26040.7. Defender Event 2014 records a successful platform update to 4.18.26050.15 on 3 June 2026, followed by normal health events. The retained AppX log no longer reaches that date, so I cannot prove the first failing transaction. The most likely consistency break is the 4.18.26040.7 to 4.18.26050.15 transition, becoming visible after the old platform directory was cleaned up.

Later platform updates (4.18.26060.3008, 4.18.26070.9, and 4.18.26080.3) have not corrected the stale package registration because the AppX package identity continues to be version 1.0.0.0.

Related report

Another user reports the same package, caller, security context, external-location mismatch, and AppX events 401/404/867 here:

https://learn.microsoft.com/answers/questions/5944598/appxdeploymentserver-loopar-p-f-r-ldral-st-defende

The suggestion in that thread concerning a missing AppxSignature.p7x is not applicable to this machine because the current Microsoft-signed MSIX contains the signature file and validates successfully.

Questions for Microsoft

1. Is this a known Defender platform-servicing defect in KB4052623?
2. Is there a supported repair for a stale external-location registration of this NonRemovable SYSTEM package, without manually editing the StateRepository database?
3. Can a future Defender platform update either repair the stale external location or advance the AppX identity version so the package can be staged cleanly?
4. Can the Defender platform updater surface this auxiliary package failure instead of reporting the entire platform update as successful?
5. Could this transient package/StateRepository inconsistency explain the false Windows Security notification even though all Defender protection states remain enabled?

I can provide additional sanitized event XML if Microsoft engineering needs it. I have deliberately not modified the StateRepository, removed the package, disabled Defender, or changed system security settings.