Forum Discussion
Minecraft UWP save failure on Windows 11 Insider due to sandbox regression
I am experiencing an issue where Minecraft for Windows (Bedrock) does not save data correctly on Windows 11 Insider builds (Canary, Dev, and Beta). After extensive troubleshooting, the problem appears to be caused by a UWP sandbox initialization regression in these Insider channels.
Summary of the issue:
- Minecraft creates a fallback folder at: C:\Users\<user>\AppData\Roaming\Minecraft Bedrock This folder should never exist for the UWP version of Minecraft.
- The correct UWP save locations remain unused: LocalState SystemAppData\wgs SystemAppData\Helium
- The Helium folder stays empty and the wgs folder is never created.
- Marketplace and cloud save features fail or behave inconsistently.
What has been ruled out:
- File system permissions (ACLs verified and correct)
- Incorrect launcher (Start Menu points to the correct UWP AppX entry)
- Corrupted Minecraft installation (package re-registered successfully)
- Microsoft Store or Gaming Services issues
- User profile corruption
- Missing or incorrect folder structure
- AppX registration issues
- System file corruption (DISM and SFC clean)
- Reinstalling Minecraft or Gaming Services
- Reinstalling Windows using Insider ISOs (Dev, Beta, Canary)
Key findings:
- The Minecraft UWP package installs correctly.
- The launcher is correct.
- All ACLs are correct.
- AppX re-registration succeeds.
- Despite this, the UWP sandbox never initializes, so Minecraft cannot access its restricted storage.
- As a result, Windows forces Minecraft into a Win32-style fallback mode, creating the Roaming folder.
Microsoft Support Response:
Microsoft Support confirmed that this behavior matches a known limitation or regression affecting UWP sandbox initialization on Windows 11 Insider builds (Canary, Dev, and Beta). They stated that there is currently no supported workaround on affected builds and recommended either filing a report here or installing the Windows 11 Stable build.
Conclusion:
This appears to be a UWP runtime regression in current Windows 11 Insider builds that prevents Minecraft (and potentially other UWP apps) from initializing their sandbox correctly. The issue persists across clean installs and multiple Insider channels. A fix would require changes to the UWP/AppModel runtime in Insider builds.
(I am about to reset my entire PC for a 3rd time, this time with the Windows 11 Stable build. Fingers crossed it fixes this issue.)
UPDATE as of 4/21/2026
Final Summary of All Repairs, Findings, and the 2024 Minecraft Save‑Location Change
After extensive troubleshooting, we (CoPilot and myself) identified several independent issues that combined to create the appearance that Minecraft Bedrock was not saving worlds correctly. Below is the complete chronological record of what was repaired, why it was necessary, and the final discovery that resolved the confusion.
• The Windows installation was severely corrupted. Photos LocalState never populated, Calculator LocalState appeared empty (later confirmed Calculator no longer uses LocalState), Minecraft worlds did not appear in the expected LocalState path, several UWP apps were missing SystemAppData folders, and Microsoft Store apps behaved inconsistently. Sticky Notes LocalState worked normally, which proved the profile itself was fine and only the UWP subsystem was broken.
• WinRE and DISM were repaired. WinRE was damaged and had to be fixed before the system could be rebuilt cleanly.
• A full SSD wipe and partition reset was performed. All partitions on Drive 0 were deleted and the drive was left unallocated so Windows Setup could rebuild a clean GPT layout. SMART data and controller health were checked, and an NVMe sanitize attempt confirmed the SN770 firmware behaves normally. This ruled out SSD‑level corruption.
• The installer kept forcing Windows 25H2 (build 26200). Even when selecting Windows 11 23H2, the download redirected to 25H2. This Insider build has known issues with UWP provisioning, LocalState creation, SystemAppData, and Xbox Game Runtime, which explained the broken UWP behavior.
• Windows 23H2 was installed. This is the last stable build with fully working UWP provisioning, AppContainer inheritance, LocalState templates, Store behavior, and Xbox Game Runtime integration. After installing 23H2, UWP behavior returned to normal.
• AppContainer and UWP permissions were rebuilt using system‑level commands. The following commands were used to repair ACL inheritance and AppContainer capability permissions:
icacls “C:\Users<User>\AppData\Local\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe” /reset /t /c
icacls “C:\Users<User>\AppData\Local\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe” /grant “*S-1-15-2-…”:(OI)(CI)(F)
icacls “C:\Users” /reset /t /c
These commands restored LocalState template permissions, AppContainer SIDs, and Store package inheritance.
• A reboot regenerated AppContainer identities. After rebooting, UWP apps began saving normally again.
• Online information about Minecraft’s save location is outdated. Most guides still point to the old LocalState path, which has not been used since 2024.
• Minecraft’s real save location (2024 and newer) is under the Xbox Game Runtime system. Worlds are stored here:
C:\Users<User>\AppData\Roaming\Minecraft Bedrock\Users<XboxUserID>\games\com.mojang\minecraftWorlds
My worlds were saving correctly the entire time, just in the new location that most documentation does not mention.
• Final verification confirmed everything was working. Photos LocalState saved correctly, Sticky Notes worked normally, Calculator still did not use LocalState (expected), and Minecraft worlds saved perfectly in the new 2024 path. No corruption or permission issues remained.
Final Conclusion: Minecraft Bedrock was never broken. Windows 25H2 caused the UWP failures. Windows 23H2 is the last stable build with fully working UWP and Store frameworks. Minecraft’s save system changed in 2024 and now uses the Roaming Xbox Game Runtime path. Online documentation is outdated, which caused the confusion. My worlds were saving correctly the entire time under the new system.
3 Replies
UPDATE as of 4/21/2026
Final Summary of All Repairs, Findings, and the 2024 Minecraft Save‑Location Change
After extensive troubleshooting, we (CoPilot and myself) identified several independent issues that combined to create the appearance that Minecraft Bedrock was not saving worlds correctly. Below is the complete chronological record of what was repaired, why it was necessary, and the final discovery that resolved the confusion.
• The Windows installation was severely corrupted. Photos LocalState never populated, Calculator LocalState appeared empty (later confirmed Calculator no longer uses LocalState), Minecraft worlds did not appear in the expected LocalState path, several UWP apps were missing SystemAppData folders, and Microsoft Store apps behaved inconsistently. Sticky Notes LocalState worked normally, which proved the profile itself was fine and only the UWP subsystem was broken.
• WinRE and DISM were repaired. WinRE was damaged and had to be fixed before the system could be rebuilt cleanly.
• A full SSD wipe and partition reset was performed. All partitions on Drive 0 were deleted and the drive was left unallocated so Windows Setup could rebuild a clean GPT layout. SMART data and controller health were checked, and an NVMe sanitize attempt confirmed the SN770 firmware behaves normally. This ruled out SSD‑level corruption.
• The installer kept forcing Windows 25H2 (build 26200). Even when selecting Windows 11 23H2, the download redirected to 25H2. This Insider build has known issues with UWP provisioning, LocalState creation, SystemAppData, and Xbox Game Runtime, which explained the broken UWP behavior.
• Windows 23H2 was installed. This is the last stable build with fully working UWP provisioning, AppContainer inheritance, LocalState templates, Store behavior, and Xbox Game Runtime integration. After installing 23H2, UWP behavior returned to normal.
• AppContainer and UWP permissions were rebuilt using system‑level commands. The following commands were used to repair ACL inheritance and AppContainer capability permissions:
icacls “C:\Users<User>\AppData\Local\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe” /reset /t /c
icacls “C:\Users<User>\AppData\Local\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe” /grant “*S-1-15-2-…”:(OI)(CI)(F)
icacls “C:\Users” /reset /t /c
These commands restored LocalState template permissions, AppContainer SIDs, and Store package inheritance.
• A reboot regenerated AppContainer identities. After rebooting, UWP apps began saving normally again.
• Online information about Minecraft’s save location is outdated. Most guides still point to the old LocalState path, which has not been used since 2024.
• Minecraft’s real save location (2024 and newer) is under the Xbox Game Runtime system. Worlds are stored here:
C:\Users<User>\AppData\Roaming\Minecraft Bedrock\Users<XboxUserID>\games\com.mojang\minecraftWorlds
My worlds were saving correctly the entire time, just in the new location that most documentation does not mention.
• Final verification confirmed everything was working. Photos LocalState saved correctly, Sticky Notes worked normally, Calculator still did not use LocalState (expected), and Minecraft worlds saved perfectly in the new 2024 path. No corruption or permission issues remained.
Final Conclusion: Minecraft Bedrock was never broken. Windows 25H2 caused the UWP failures. Windows 23H2 is the last stable build with fully working UWP and Store frameworks. Minecraft’s save system changed in 2024 and now uses the Roaming Xbox Game Runtime path. Online documentation is outdated, which caused the confusion. My worlds were saving correctly the entire time under the new system.
Minecraft creates a fallback folder (C:\Users\<user>\AppData\Roaming\Minecraft Bedrock) but cannot access its proper sandbox locations (LocalState, SystemAppData\wgs, Helium).
You've done an incredible job documenting this—seriously, this is one of the most thorough bug reports I've seen. You've basically done Microsoft's QA work for them.
