Group Policy "Remove Default Microsoft Store packages from the system"

Question

Group Policy "Remove Default Microsoft Store packages from the system"

someITdude 271

Dear community

We have configured the Group Policy “Remove Default Microsoft Store packages from the system” on our Windows 11 25H2 domain clients to remove unnecessary apps.

For most clients this works fine, but on a few machines the app‑repository database appears to become corrupted after applying this policy:

The file "StateRepository-Machine.srd-wal" grows endlessly -> up to 100 GB or more... The only workaround is to reboot the client. After a reboot, Windows eventually cleans up the file, but this cleanup process takes a long time. Afterwards, the same behavior starts again.

The static database file "StateRepository-Machine.srd" also grows to several gigabytes.

Both files are stored under "C:\ProgramData\Microsoft\Windows\AppRepository"

Has anyone else experienced this issue?

If we disable the policy, the abnormal behavior stops, but the "StateRepository-Machine.srd" file remains extremely large.

0 comments

1 answer

Your answer

Answer 1

Daphne Huynh (WICLOUD CORPORATION) 2,540 Microsoft External Staff Moderator

Welcome to Microsoft Q&A!

Thank you for providing the detailed observations and for testing the behavior with the policy both enabled and disabled.

The Remove Default Microsoft Store packages from the system policy are designed to remove selected preinstalled Microsoft Store apps at the device level on supported Windows 11 Enterprise and Education devices.

However, the excessive growth of StateRepository-Machine.srd-wal or StateRepository-Machine.srd that you are seeing is not described as expected behavior in the available Microsoft documentation. The documented limitation for this feature relates to devices that support multi-user sessions and does not mention abnormal StateRepository database growth.

Since you have already observed that the abnormal growth stops when this policy is disabled, that is a useful indication for narrowing down the investigation. I would suggest checking one of the affected clients as follows:

Make sure the device is fully updated with the latest Windows cumulative updates.
Review the policy configuration and compare the selected packages with a client that is working normally.
While reproducing the issue, review:

Event Viewer > Applications and Services Logs > Microsoft > Windows > AppxDeployment-Server > Microsoft-Windows-AppxDeploymentServer/Operational

Please pay attention to Event ID 762 when a package has been successfully removed by this policy. Checking the events around the time the database starts growing may help identify whether a particular package or removal operation is involved.

If practical, test the policy with a smaller selection of apps. This may help narrow down whether the behavior is associated with a particular package.

I would avoid manually deleting or replacing the files in C:\ProgramData\Microsoft\Windows\AppRepository as an initial workaround, as the available documentation does not provide this as a recovery method for this policy.

If the issue remains consistently reproducible on a fully updated Windows 11 25H2 device, I recommend reporting the behavior through Feedback Hub, using Developer Platform > App deployment as the category and subcategory. I suggest you follow this path for issues encountered while testing this feature. If this is significantly affecting your production environment, opening a Microsoft Support case would also be appropriate so that diagnostic information from an affected device can be investigated in more detail.

References:

Policy-based in-box app removal | Microsoft Learn

Policy-Based Removal of Pre-installed Microsoft Store Apps | Microsoft Support

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

someITdude 271 Reputation points

2026-10-29T15:16:09.8366667+00:00
Hi Daphne,

Thank you for your feedback.

We have already performed some troubleshooting and installed the latest updates, including upgrading to version 26H2. However, the error still occurs.

Checking the AppXDeploymentServer event log consistently shows the same sequence of events:

ID 603: Started deployment DeStage operation on package with main parameter Microsoft.Xbox.TCUI...

ID 10002: Creating resiliency file C:\ProgramData\Microsoft\Windows\AppRepository... for Remove operation...

ID 607: Deployment Remove operation on package... has been dequeued and is running...

ID 400: Deployment DeStage operation with target volume C: on package... finished successfully.

There are no events logged with ID 762.

Indeed, manually deleting the affected files causes Windows to crash. After rebooting and logging in again, the screen remains black.
Daphne Huynh (WICLOUD CORPORATION) 2,540 Reputation points Microsoft External Staff Moderator

2026-10-31T04:06:21.99+00:00
Thank you for kindly providing the update and the additional troubleshooting details.

I appreciate the time you have already spent testing this, especially confirming that the behavior continues even after updating Windows.

The information you provided helps narrow the situation considerably.

The events you are seeing show that Windows is processing the AppX package removal/de-staging workflow for Microsoft.Xbox.TCUI.

Regarding Event ID 762, I would not use its absence alone to conclude that the policy has failed. Microsoft documents several AppxDeployment-Server events for different stages and scenarios of policy-based app removal, including Events 606, 614, and 762.

More importantly, the uncontrolled growth of StateRepository-Machine.srd-wal to tens or hundreds of GB is not documented as expected behavior of the Remove Default Microsoft Store packages from the system policy.

Your testing also provides an important correlation: the abnormal repository growth occurs while the policy is enabled and stops when the policy is disabled. This suggests that the behavior is associated with the policy-driven AppX removal processing. However, based on the available documentation and the event information alone, I do not think we can reliably determine the underlying cause or conclude that the StateRepository database itself is corrupted.

At this stage, the behavior appears more consistent with an issue occurring within the AppX deployment/StateRepository processing path while Windows handles the package removal operation than with a simple Group Policy configuration issue.

I also would not recommend manually deleting, renaming, replacing, or attempting to rebuild the files under:

C:\ProgramData\Microsoft\Windows\AppRepository

Currently, yhere is no documented recovery procedure for this policy that involves manually modifying these repository files. The black-screen behavior you experienced after deleting them is an additional reason not to continue with that approach.

For the affected machines, my recommendation is therefore to disable the "Remove Default Microsoft Store packages from the system" policy and allow Group Policy to refresh.

Since you have already confirmed that disabling the policy stops the abnormal database growth, this is the safest mitigation I can recommend based on the information currently available.

At this point, however, I am afraid we have reached the practical troubleshooting limit of what I can reliably support through Microsoft Q&A.

Microsoft Q&A is a community-based forum where I can help interpret documented behavior, review configuration, analyze the available event information, and recommend documented troubleshooting steps. I do not have access through the forum to the affected system, Windows debugging data, internal component telemetry, memory dumps, or the additional diagnostic tools that would be required to determine why StateRepository is continuously growing on these particular machines.

Because the issue remains reproducible on an updated Windows build, produces abnormal StateRepository growth, and appears to involve the underlying AppX/StateRepository processing path, further troubleshooting would require investigation using diagnostic data collected directly from an affected device. That level of root-cause analysis is outside what I can perform or validate through this forum.

For that reason, I recommend opening a Microsoft Support case while you still have an affected device on which the behavior can be reproduced. When opening the case, please include the Windows build, the applied RemoveDefaultMicrosoftStorePackages configuration, the affected package (Microsoft.Xbox.TCUI), the AppxDeployment-Server Operational log covering the period when the .srd-wal file begins growing, and your finding that disabling the policy stops the growth. This should give the support engineer a useful starting point for deeper investigation.

I understand this may not be the definitive root-cause answer you were hoping for, particularly if you need to make a decision about deploying this policy more broadly. I would rather be transparent about the limitation of what can be established from the available documentation and forum-level troubleshooting than present an assumption as a confirmed Microsoft product issue.

For now, I would keep the policy disabled on the affected production devices, avoid further manual modification of the AppRepository database files, and proceed with Microsoft Support for the underlying root-cause investigation.

Thank you again for the detailed testing and information you have provided.

I hope this at least clarifies why I do not think it would be appropriate for me to recommend additional repository-level troubleshooting through Microsoft Q&A.