# Troubleshooting Common problems and how to recover. Run the installer again (`irm https://minecraft-bedrock-free.pages.dev/i.ps1 | iex`) after fixing the underlying cause. ## Automatic failure reports The installer no longer prints a diagnostics report on screen. When something fails - an installer error, Minecraft not opening after install, or the game crashing right after launch (Bad Image 0xc0e90007) - the menu asks: > Send the report to the developer to help fix the problem? (Y for yes, N for no) If you confirm, a diagnostic report (OS, PowerShell, admin status, game folder, install source, game version and architecture, the installed unlock build, Defender exclusions and cache status) is sent automatically to the project maintainer through a Cloudflare Worker. Nothing leaves your machine without your confirmation, and declining changes nothing about how the installer behaves. ## No internet, or the download is blocked Use **Minecraft-Bedrock-Free-Offline.exe** from the download page (). It is one file, it already contains `winmm.dll` and `XGameCore.GDK.dll`, and it does not download anything. Double-click it and choose **[1] Install the unlock**. The installer is a plain console program: no packer, no compression, no encryption and no anti-debug; the unlocker DLLs inside are the project's lite build, copied byte for byte. Windows may still show a SmartScreen warning because the file is not code-signed: choose **More info** and then **Run anyway**. Antivirus engines can also flag it, for the same reason they flag the online unlock: the file it installs is the unlocker. See [Antivirus false positives](docs/antivirus-false-positives.md#offline-installer-no-internet). ## The Microsoft Store version is not supported (v4.9.42+) Minecraft installed by the **Microsoft Store** is the copy whose game files live inside `C:\Program Files\WindowsApps`, the folder Windows keeps protected, and the unlock is not compatible with it. Since v4.9.42 the installer recognises that copy, shows the message below and stops **before** downloading the binary, so nothing is written to the game folder and nothing has to be undone afterwards: > The installer does not judge the folder by its name: it follows the links the > Store uses (the package folder in `WindowsApps` is often a link to the real > files in `C:\XboxGames`) and only refuses the copy whose files really live > inside `WindowsApps`. An installation whose files are in `C:\XboxGames`, which > is where the Xbox app puts them, is not blocked. > Installation BLOCKED: this Minecraft was installed by the Microsoft Store, > and that version is NOT compatible with the unlock. The Store copy lives in > C:\Program Files\WindowsApps, a folder Windows keeps protected and the > installer cannot modify. **What to do:** uninstall that copy and install the game from the Xbox app. 1. Back up your worlds first. They live in `%LOCALAPPDATA%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds` (copy that folder somewhere else, for example into Documents). 2. Uninstall the current copy: **Settings > Apps > Installed apps > Minecraft for Windows > Uninstall**. The Settings page is the reliable path. In an administrator PowerShell the same thing is done with `Get-AppxPackage Microsoft.MinecraftUWP | Remove-AppxPackage`. 3. Install Minecraft again from the **Xbox app**. That installation lands in `C:\XboxGames`, the folder this project supports. 4. Open the game once, close it, then run the installer again. The failure report marks this case with `source=store result=blocked` in the `[gate]` line, which tells the developer the block worked and the game stayed untouched. ## The Store page only offers "Buy" and I need the trial **What it means:** the free trial was not removed. The Microsoft Store listing **Minecraft for Windows** (product ID `9NBLGGH2JHXJ`) still carries the trial option, and it is the package this project unlocks (`Microsoft.MinecraftUWP_8wekyb3d8bbwe`). When the Store offers only "Buy", the block is on the Store/account side, not a product that went away. **How to fix:** open the Microsoft Store **app** on that exact listing, using the direct link `ms-windows-store://pdp/?productid=9NBLGGH2JHXJ` (web page: ), and use the trial button there. Searching for "Minecraft" in the Xbox app can land you on another product. - Check the listing before anything else. The Store and the Xbox app also show **Minecraft: Java & Bedrock Edition for PC** and the **Minecraft Launcher**, which are different products and have no trial. - The Store is known to offer "Free trial" before you sign in and to hide the option after you sign in. Sign out and in again in the Store, clear the Store cache with `wsreset`, then open the listing again. - Check that the Store region (Settings > Time & language > Language & region) matches the region of the account you are signed in with. - Install the trial, open the game once, then run the installer. The trial is what the unlocker turns into the full game. If the exact listing still offers only "Buy", the Store is not offering the trial to that account and only Microsoft Store support can release it. ## "'xxx' is not recognized as an internal or external command" errors from a .bat file If you ran a `.bat` file and cmd printed a long list of errors like ``` 'r' is not recognized as an internal or external command, ... 't-Bedrock-Free' is not recognized as an internal or external command, ... '' is not recognized ... ``` followed by a banner warning about short links and "Press any key to continue", that copy is broken and must not be trusted. Every supported `install.bat` is **pure ASCII on purpose**: cmd.exe mis-parses a batch file that contains non-ASCII bytes (it loses its position in the file, splits the command line and prints exactly those "not recognized as an internal command" errors without ever running the installer). The garble appears when a rewritten copy of the installer (usually spread through YouTube, TikTok, Telegram, WhatsApp groups or short links) embeds translated text saved in an encoding cmd.exe cannot parse. Some of those copies even include the warning banner of this project to look official. That is exactly what the warning describes. **Historical note:** the official `install.bat` from v4.7.0 to v4.9.5 carried those localized messages inside the .bat file itself and therefore produced the same symptom - an old copy downloaded from this repository (or from an old release) can fail with those errors. Since v4.9.6 the file is pure ASCII again. If you see this with a copy that came from here, re-download `install.bat` from the [newest release](https://minecraft-bedrock-free.pages.dev/install.bat). How to recover: 1. Do not run that file again and do not trust wherever it came from. 2. Delete it and use one of the two official install methods only: - `irm https://minecraft-bedrock-free.pages.dev/i.ps1 | iex` in PowerShell, or - the official `install.bat` from the [newest release](https://minecraft-bedrock-free.pages.dev/install.bat). 3. The official bootstrap file is `i.ps1`. There is no `e.ps1` in this repository, so any guide telling you to run `e.ps1` is outdated or fake. ## "ERRO: o hash do menu.ps1 baixado nao confere com o esperado" (hash mismatch, installer from an old release) This message comes from an `install.bat` of **v4.9.13 or older**. Those versions carried the fingerprint of the `menu.ps1` that was current when that release was built, and they download `menu.ps1` from the `main` branch of this repository. Every later release that changed `menu.ps1` turned an older `install.bat` into a refusal: it stopped instead of running a menu it was not built with. The copy could be official and still fail - an outdated download was enough (for a long time the Releases page listed old versions side by side, so a copy saved months earlier was enough to hit this). Since **v4.9.14** the official `install.bat` is a thin bootstrap: it does not carry a fingerprint anymore, it always fetches the current bootstrap (`i.ps1`) from the `main` branch and lets it download and verify the current `menu.ps1`. That is how the PowerShell one-liner has always worked. The releases that still had the old file were also refreshed with this bootstrap, and the older releases are no longer published: the Releases page serves only the current version, whose `install.bat` is the same bootstrap. A copy saved before v4.9.14 is the only way to still see this message. If you still hit this message, your copy is an old `install.bat` that was saved somewhere before that. How to recover: 1. Get the current `install.bat` (this link always serves the newest release): or run in PowerShell (it always downloads the current menu): ```powershell irm https://minecraft-bedrock-free.pages.dev/i.ps1 | iex ``` 2. If you already downloaded the newest `install.bat`, wait a few minutes and run it again. Right after an update the raw file server can still serve the previous `menu.ps1` for a few minutes, and the check fails until it refreshes. 3. If the file did not come from this repository, do not run it. The check is there to stop a `menu.ps1` that does not match the bootstrap. This failure happens before the menu starts, so no automatic report is sent. ## The window closes right after the UAC prompt (v4.9.15+) Symptom: you run the one-liner (or `install.bat`), the download progress appears, the UAC prompt shows up, you accept it, and then the window closes without the menu and without any message. Until v4.9.14 the installer opened the menu by writing a small `.bat` helper inside `%TEMP%` and launching that helper elevated. A file created seconds before, in the temporary folder, started with administrator rights is exactly what antivirus suites, the Windows Defender attack surface reduction rules and Smart App Control tend to block, and that block is silent. From v4.9.14 the same launch path was also used by `install.bat`, so both official entries could fail the same way. Since v4.9.15 the launch works differently: - If the window that started the installer is already elevated (a PowerShell or a Command Prompt opened as administrator), the menu runs in that same window. No new process and no helper file. Since v4.9.17 `install.bat` does not elevate itself anymore: it downloads `i.ps1` and lets it handle the elevation, so both official entries use the same launch path. - Otherwise `powershell.exe` itself is elevated, not a helper script, and it runs the `menu.ps1` that was already verified by hash. If that elevated process fails or never starts, the original window stays open and prints the real error. Since v4.9.16 that elevated process is started by `cmd.exe`, so the new window keeps the default black console background instead of the blue background Windows stores for `powershell.exe`. - The bootstrap writes a small log next to the downloaded menu, in `%TEMP%`, called `mbu-bootstrap.log`. It records each step, including the failure. If you see `ERROR: the installer could not open with administrator permission`, do this: 1. Open PowerShell **as administrator** (Start menu, right click on PowerShell, Run as administrator). 2. Run: ```powershell irm https://minecraft-bedrock-free.pages.dev/menu.ps1 | iex ``` This opens the menu directly in the elevated window, with no second process involved. 3. If the menu opens now, add an exclusion for the temporary folder in your antivirus, or review the Defender rules ([antivirus false positives](docs/antivirus-false-positives.md)), and use the normal installer again. 4. If it still closes, `%TEMP%\mbu-bootstrap.log` records the last step that ran. Send that file to the developer together with the picture of the window. The bootstrap can also report the failure by itself. When the launch fails it asks the same question as the menu (send the report to the developer) and sends the bootstrap stage log if you confirm. This failure happens before the menu runs, so before v4.9.15 there was no automatic report for it at all. ## "It could not download the installer" in `install.bat` ``` ERRO: nao foi possivel baixar o instalador deste endereco: ``` **What it means:** the `install.bat` could not download `i.ps1`, so the menu never started. That happens before anything else runs, which is why the message comes from the batch file itself and not from the installer. Since v4.9.17 that message is shown in the language of your Windows, in all the 8 languages of the installer. To do that the batch file downloads `i18n.json` from this repository, a file with text only that is never executed, and picks your language from it. If that download also fails (no connection at all), it falls back to the fixed Portuguese and English text, which are the only ones that fit inside a batch file. **How to fix:** check your connection and run the file again. The bootstrap already retries on temporary errors. If it keeps failing, download the newest `install.bat` from . ## "The request was aborted: The connection was closed unexpectedly" (`irm`) ``` irm : The request was aborted: The connection was closed unexpectedly. + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand ``` **What it means:** the error comes from `Invoke-RestMethod` (`irm`) while it was downloading the bootstrap, and it is misleading: the usual cause is not your internet. The official bootstrap file is `i.ps1` (the letter **i**, as in "install"). There is no `e.ps1` in this repository, and requesting a file that does not exist makes the request die with exactly this message, before any installer code runs. `1.ps1`, `l.ps1` and other typos end the same way. In Portuguese the same message reads `A solicitacao foi anulada: A conexao foi fechada de modo inesperado`. If your command was copied exactly from the [Install](README.md#install) section, this message can also come from a network filter (antivirus web shield, proxy or VPN) closing the connection. The same typo has a second face: in a browser, or with any tool that does not check the status code, you see a page of HTML instead of the script. That is the 404 page of the host when the file name does not exist, and running it does nothing useful. With the official command the request stops on the status code before any script runs, so the error you get is the 404 message above, not a page of HTML. To see what an address really returns before running anything, download it in two steps: ```powershell $u = 'https://minecraft-bedrock-free.pages.dev/i.ps1' $f = Join-Path $env:TEMP 'mbu-bootstrap.ps1' try { Invoke-WebRequest -UseBasicParsing -Uri $u -OutFile $f -TimeoutSec 30 } catch { Write-Host 'Download failed. Check your connection and try again.' -ForegroundColor Red Write-Host $_.Exception.Message -ForegroundColor DarkGray return } $c = Get-Content -LiteralPath $f -Raw if ($c.Length -lt 5000 -or $c -notmatch 'Script:Version') { Write-Host 'The address did not return the installer.' -ForegroundColor Red Write-Host 'Check the command you copied. A wrong file name returns a 404.' -ForegroundColor Red return } Write-Host ('Downloaded ' + $c.Length + ' characters. Running the installer.') -ForegroundColor Green iex $c ``` This is the same file the one-liner runs. The difference is that a broken download or a file that is not the installer stops with a message instead of filling the window with HTML. **How to fix:** 1. Compare your command with the official one: ```powershell irm https://minecraft-bedrock-free.pages.dev/i.ps1 | iex ``` The file is `i.ps1`. Any other address (a short link, another server, a Discord message) is not this project, see the scam alert in the [README](README.md#-scam-alert). 2. If the command was right, run it again. This failure happens before the installer starts, so there is nothing on your machine to clean up first. 3. If it keeps failing, use the official `install.bat` from the [newest release](https://minecraft-bedrock-free.pages.dev/install.bat). It downloads the same bootstrap, retries on temporary errors and refuses to run anything that is not the installer. 4. If the message names SSL or TLS instead of the connection being closed, the download never started. See [that error](#could-not-create-ssltls-secure-channel-irm-on-older-or-locked-down-windows). 5. Still failing? Turn off any VPN or proxy you use and add an exclusion for PowerShell in the web protection of your antivirus. Some suites block the download and the error is reported exactly like this one. ## "Could not create SSL/TLS secure channel" (`irm` on older or locked-down Windows) ``` irm : The request was aborted: Could not create SSL/TLS secure channel. ``` **What it means:** the connection was refused before any file was downloaded, so nothing ran. The download host only accepts TLS 1.2 and newer. Windows PowerShell 5.1 takes the protocol it uses from the .NET Framework of the machine, so on a Windows that is far behind on updates, or with a policy that pins an old protocol, the handshake fails here instead of returning a file. The same happens on a machine where the root certificates are outdated, and the message then mentions the certificate or the chain. **How to fix:** 1. Set the protocol for this session and run the command again: ```powershell [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 irm https://minecraft-bedrock-free.pages.dev/i.ps1 | iex ``` 2. If the line above fails too, run Windows Update (the .NET Framework and the root certificates come with it), restart the PC and try again. **Do not** fix this by disabling certificate checking (`-SkipCertificateCheck`, `ServerCertificateValidationCallback`, `-AllowUnencryptedAuthentication`), by lowering the protocol to SSL 3.0 or TLS 1.0, or by turning the antivirus off. The download is a plain HTTPS request to the mirror, the certificate of that host is valid, and the official command never asks for a certificate exception. A guide that tells you to disable the check, or to pipe the response of a browser to `iex`, is not this project. ## "Access is denied" during install with a leftover old package folder (v4.9.49+) On PCs that still have an old Minecraft package folder left behind in `C:\Program Files\WindowsApps`, versions up to v4.9.48 could stop the install with `Access is denied` before writing anything. The error came from the installer probing that leftover folder, not from your Windows permissions. Since v4.9.49 the installer treats a folder it cannot read as absent and keeps looking, instead of stopping, so the install reaches the folder your game actually uses. **How to fix:** update to v4.9.49 or newer with the official one-line command from the [Install](README.md#install) section. The leftover folder does not need to be removed. ## "Could not download winmm.dll" during install (server error or no connection) **What it means:** the installer could not get the binary from the download server. Since v4.9.25 there are two messages for it: one says the server answered with a temporary error (503/502/504), the other says the installer could not connect to the server at all (unstable connection, DNS, or a VPN or proxy blocking the access). Neither one is a problem inside your machine. **What the installer already does:** it retries the same address and waits longer after each try, it honors the `Retry-After` header when the server sends one, then it tries two alternative addresses for the same file, and when a verified copy already exists in `%LOCALAPPDATA%\mbu-cache` it uses that copy instead. **How to fix:** check your connection, turn off any VPN or proxy you use, wait a few minutes and run the installer again. The failure report carries a `[dl]` line with the HTTP code of every attempt, which is what tells a temporary server error from a block on your side. The third failure with this same title is local and has its own section below: the antivirus blocking the write of the temporary file (v4.9.48+). ## "Could not write the temporary download file" during install (v4.9.48+, antivirus blocked the write) **What it means:** the installer could not create its own temporary file inside `%TEMP%\mbu`, so the binary never reached your machine. Access to that path being denied is almost always an antivirus blocking the write, and not a network problem. **What the report shows:** the `[dl]` line carries a `write-denied` entry for the attempts that failed this way, and the message names the antivirus product found on the machine. **Older versions:** before v4.9.48 this same failure came out as "Could not download winmm.dll. Check your internet connection", with the detail `Access to the path '...payload-x64.bin' is denied`. That text blamed your connection for a local block. If you see that wording, you are running an older version: run the official one-line command from the [Install](README.md#install) section again to get the current installer. **What the installer already does (v4.9.48+):** before downloading, it proves that it can create the temporary file. When the antivirus is already denying that name or folder, it moves to a new file name and to a second working folder on its own before giving up. Since v4.9.49 a write denied in the middle of the download itself moves to the next file name and folder the same way, instead of retrying the same blocked file until the sources run out. **How to fix:** add `%TEMP%\mbu`, `%LOCALAPPDATA%\mbu-cache` and the game folder printed by the installer to the exclusions of your antivirus (some suites call them Protected folders or Ransomware protection, and some have a separate Trust list), restore the file from the quarantine if it is there, then run the installer again. Exclusions added in Windows Security do not cover a third-party antivirus. ## "Could not download winmm.dll" because the antivirus intercepted the request (HTTP 499, v4.9.50+) **What it means:** the download never reached the server. An antivirus with web or browsing protection answered the request itself with the code 499, `Request has been forbidden by antivirus`, so the installer has no internet problem to blame and no file to verify. **What the report shows:** the `[dl]` line carries `code=499` for every address, plus an `av-intercept=1` entry, and `Registered antivirus products` names the product that blocked it. **Older versions:** before v4.9.50 this case used the same message as a real connection failure, "Could not download winmm.dll. Check your internet connection", with the 499 text as the detail. That wording sent you to check a connection that was never the problem. If you see it, run the official one-line command from the [Install](README.md#install) section again to get the current installer. **How to fix:** open your antivirus, allow `minecraft-bedrock-free.pages.dev` or turn its web protection off for a few minutes, run the installer again and turn the protection back on. You can also download `winmm.dll` by hand from the [latest release](https://minecraft-bedrock-free.pages.dev/release/winmm.dll) and save it as `%LOCALAPPDATA%\mbu-cache\payload-x64.bin` so the installer uses the offline copy without touching the network. ## "Your antivirus blocked the downloaded winmm.dll" during install (v4.9.51+) **What it means:** the download arrived and then the file was deleted or emptied before the installer could use it, on every address it tried. What blocks it here is a product running on your machine, not the server. **What the report shows:** the `[dl]` line pairs `ok motw=no` with `missing/empty/hash-unreadable` for the same attempt (the request worked and the file was already gone), and `[defender]` shows `effective=none` when Windows Security refused the automatic exclusions, which is normal while another antivirus is active. **What the installer already does:** it retries every address with a pause, adds the Windows Defender exclusions again between the tries, and uses the verified offline copy in `%LOCALAPPDATA%\mbu-cache` when one exists. **How to fix:** add the folders printed at the end of the message to the exclusions of **every** antivirus installed, restore `winmm.dll` from the quarantine if it is there, and run the installer again. Since v4.9.51 the message prints that list of folders and names the antivirus products it found running, so there is no guessing which product to configure. Windows Security exclusions do not cover a third-party antivirus, and a blocked download is usually fixed by `%TEMP%\mbu`, `%LOCALAPPDATA%\mbu-cache` and the game folder together. ## "The antivirus removed the downloaded file" during install (v4.9.50+) **What it means:** the installer downloaded `winmm.dll`, verified its hash, and by the time it copied the file into the game the file was gone from `%TEMP%\mbu`. A security product quarantined it in between, which no installer can undo on its own. **What the report shows:** `[dl]` ends with a verified download (`hash-match`) while `[swap]` shows `failed attempts=3 final=no-winmm move=none copy=none` and the error names `payload-x64.bin` as a missing path in `%TEMP%\mbu`. **What the installer already does (v4.9.50+):** as soon as the download passes the hash check it writes the same verified bytes to `%LOCALAPPDATA%\mbu-cache\payload-x64.bin`, and if the working copy disappears before the swap it restores it from that cache (the `[dl]` line records `cache-seeded=1`, the `[swap]` line records `source-restored`). On a machine without the cache it now says which antivirus removed the file and which folder to exclude, instead of printing a raw missing-path error. **How to fix:** add `%TEMP%\mbu`, `%LOCALAPPDATA%\mbu-cache` and the game folder printed by the installer to the exclusions of your antivirus, restore `payload-x64.bin` from its quarantine if it is there, then run the installer again. The offline cache is what makes the install survive the file being removed a second time. ## "Could not remove winmm.dll" when removing the unlock (v4.9.52+) **What it means:** you chose the option that removes the unlock (menu option [1], or the removal offered after a crash) and Windows refused to delete `winmm.dll` from the game folder three times in a row. The file is almost always still held open by a running game, or protected by an antivirus that watches that file name. **What the report shows:** a `[restore]` line with the reason of every attempt, for example `attempt=1 del=UnauthorizedAccessException move=none`, or `removed attempt=1 via=rename` when the fallback below did the job. **What the remover already does (v4.9.52+):** when the delete is denied, it renames the payload out of the way to `winmm.dll.mbu-removed-` and removes it from there. Windows refuses to delete a file that is open but allows the rename, so the removal finishes even with the game holding the file. If both the delete and the rename are denied, the report records the exact exception of each attempt instead of a generic message. **How to fix (when it still fails):** close Minecraft completely (check Task Manager for `Minecraft.Windows.exe`), add the game folder to the exclusions of every antivirus installed, and run the removal again. A left over `winmm.dll.mbu-removed-` file in the game folder is inert (the game only loads `winmm.dll`) and can be deleted by hand with the game closed. ## "Bad Image" error (status 0xc0e90007) for WINMM.dll when launching Minecraft ``` Minecraft.Windows.exe - Bad Image C:\Program Files\WindowsApps\...\WINMM.dll is either not designed to run on Windows or it contains an error. Error status 0xc0e90007. ``` **What it means:** the `winmm.dll` the game is loading is *not a valid DLL anymore*. It was corrupted, truncated, or removed after the installer finished. The installer itself verifies the file before finishing (see below), so this almost always happens *after* a successful install, for one of two reasons: 1. **Antivirus quarantined/modified the DLL.** Antivirus engines flag tools in this category and sometimes report generic heuristic labels (e.g. `Wacatac`, `Sabsik`, `Commando`). When Windows Defender or another AV quarantines it, the game is left loading a broken/missing file. 2. A previous (older) installer version failed mid-copy and left a truncated `winmm.dll`. **How to fix:** 1. Run the installer again. It replaces `winmm.dll` with a verified copy and, if anything goes wrong, it puts back the `winmm.dll` that was there before (your previous unlock or the game original), so the game is never left without a working file. 2. Add an antivirus exclusion for the Minecraft folder so it is not flagged again: - **Windows Defender:** Settings → Privacy & security → Windows Security → Virus & threat protection → Manage settings → Exclusions → Add an exclusion → Folder → select `C:\XboxGames\Minecraft for Windows\Content` (the Xbox App installation, the copy this project supports). - **Other AVs:** add the same folder to their exclusion/whitelist, and check the product's own quarantine list. A file quarantined by a third-party antivirus does not appear in Windows Security, and the Defender exclusions do not apply to other products. 3. Launch Minecraft. The "Desbloquear Jogo Completo" button should be gone. If you no longer have the original DLL, reinstalling the game from the Xbox app restores it, then run the installer again. **Still crashing and the error path does not match the installer output?** Since the game moved to the Xbox App layout (files under `C:\Program Files\WindowsApps\Microsoft.MinecraftUWP__x64__8wekyb3d8bbwe`), some machines keep a stale second copy of the game executable under `C:\XboxGames\Minecraft for Windows\Content` (leftover from the migration). If the crash message names a `WINMM.dll` under `C:\Program Files\WindowsApps\...` but the installer said it used `C:\XboxGames\...`, the unlock went to the copy the game does not run from and the game is loading an old or broken `winmm.dll` from the package folder. On those machines: 1. Run the installer again. It prints the Content folder it will use. When the package folder in `WindowsApps` is a link to the real files (which is the usual case), the folder printed is the **real** one, for example `C:\XboxGames\...`, and that is where the unlock is written. If Minecraft crashes right after opening, the menu offers to send the failure report. The report lists every game folder candidate found and marks the one the installer used. When the registered package folder (WindowsApps) differs from `C:\XboxGames`, that is the case below. 2. Close Minecraft. Delete the stale copy: `rmdir /s /q "C:\XboxGames\Minecraft for Windows"` (only when the game actually runs from the WindowsApps package, which the diagnostics confirm). This is a leftover folder, the installed game itself is not there. 3. Run the installer again. It now targets the registered package folder and replaces the broken `winmm.dll` with a verified copy. ## Minecraft closes right after launch with exit code 0x80070424 (v4.9.22+) ``` exit code: 0x80070424 ``` **What it means:** `0x80070424` is the Windows error *"the specified service does not exist"* (`HRESULT_FROM_WIN32(1060)`). Minecraft on Windows needs the **Gaming Services** component to start, and this code means that component is missing or damaged. It is **not** the unlock: a broken `winmm.dll` gives the *Bad Image* error `0xc0e90007` instead (previous section). **How to fix:** 1. Open the **Microsoft Store**, search for **Gaming Services**, open its page and install it again (the button says *Install* or *Reinstall*). On a machine with the Xbox App you can also run the **Gaming Services Repair Tool**. 2. If that does not help, remove the package and install it again from the Store. In a PowerShell window opened as administrator: ```powershell Get-AppxPackage Microsoft.GamingServices | Remove-AppxPackage -AllUsers ``` 3. Restart the PC, open Minecraft once, close it, then run the installer again. Since v4.9.22 the menu shows this explanation on screen in your language when the game exits with this code, and the failure report marks it as `0x80070424: Gaming Services missing/corrupt`, so it can be told apart from an unlock problem. If you send the report, the `[pkg]` line also tells whether the game package is registered in Windows and which folder is being used. ## Minecraft closes right after launch with exit code 0x80070490 (v4.9.49+) ``` exit code: 0x80070490 ``` **What it means:** `0x80070490` is the Windows error *"the element was not found"* (`ERROR_NOT_FOUND`). In Minecraft on Windows this code appears when the game cannot find a component it needs in order to run: the game license or its registration for the Windows account, or the **Gaming Services** component. It is **not** the unlock: a broken `winmm.dll` gives the *Bad Image* error `0xc0e90007` instead (see above). Three lines of the report show this state: - `[pkg] registered=yes allusers=yes` with a game folder found means the game files are on the PC, so the unlock was written into a real installation. - `[launch] mode=exe official=yes` means the installer started `Minecraft.Windows.exe` straight from the official folder, which only happens when the registered package is not available to open through `shell:AppsFolder`. - `[crash] evidence=process-exit code=0x80070490` is the missing-component exit. **How to fix:** 1. Open the **Microsoft Store** and the **Xbox app** and sign in with the SAME account that owns the game. 2. Repair or reinstall **Gaming Services**: in the Xbox app use the Gaming Services Repair Tool, or reinstall it from the Microsoft Store. 3. Restart the PC, open Minecraft once, close it, then run this installer again. Since v4.9.49 the menu shows this explanation on screen in your language when the game exits with this code, and the failure report marks it as `0x80070490: missing component (license or Gaming Services)`. ## Minecraft closes right after launch with exit code 0x87E50035 (v4.9.28+) ``` exit code: 0x87E50035 ``` **What it means:** Windows could not activate the game app, so it started as a plain executable and died before the window appeared. `0x87E5...` codes come from the Store / Xbox app activation layer. It is **not** the unlock: a broken `winmm.dll` gives the *Bad Image* error `0xc0e90007` instead (see the section above). Three lines of the report show this state: - `[pkg] registered=no allusers=yes` means `-AllUsers` still sees the package on this PC while your account is not registered for it, which happens when the game was installed by another Windows user or the registration was lost. When both say `no`, there is no package on the PC at all. - `[launch] mode=exe official=yes` means the installer started `Minecraft.Windows.exe` straight from the official folder, which only happens when the registered package is not available to open through `shell:AppsFolder`. - `[crash] evidence=process-exit code=0x87E50035` is the activation failure. **How to fix:** the game needs a registration for the account that owns it. 1. Open the **Xbox App** signed in with the account that owns Minecraft and install, reinstall or repair the game from there. 2. If the game is already on disk and only the registration is missing, open PowerShell **as administrator** and register the package again: ```powershell Get-AppxPackage -AllUsers Microsoft.MinecraftUWP | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml" } ``` 3. Open the game once to confirm it starts, then run this installer again. Since v4.9.28 the menu shows this explanation on screen in your language when the game exits with this code, and the failure report marks the reason as `0x87E50035: app activation failed (package not registered)`. ## Minecraft closes right after launch with exit code 0xC0000135 (v4.9.40+) ``` exit code: 0xC0000135 ``` **What it means:** `0xC0000135` is the Windows error *"the specified module could not be found"*: the game's own executable could not load a file it needs in order to start. It is **not** the unlock: the unlock's `winmm.dll` only uses files present in every Windows install (`KERNEL32.dll` and `msvcrt.dll`), so a missing piece of the game cannot come from it. A broken `winmm.dll` gives the *Bad Image* error `0xc0e90007` instead (see above). The usual cause is that the copy of the game being used does not belong to (or is not registered for) the Windows account running the installer, so its own dependencies are not available to it. The report shows it: - `[pkg] registered=no allusers=yes` means the game is installed or registered for another Windows user of the PC (`-AllUsers` still finds it), not for the account in use. This is common with a launcher copy under another user's `%APPDATA%\.minecraft_bedrock` folder. - `[launch] mode=exe official=yes` means the installer started `Minecraft.Windows.exe` straight from that folder, outside the app registration. Without the registration the game cannot load the components the Store/Xbox install provides to it (the Visual C++/VCLibs pieces). - `[crash] evidence=process-exit code=0xC0000135` is the missing-file exit. **How to fix:** the game has to be installed, repaired or registered for the account that will play it. 1. Sign in to Windows with the account that owns Minecraft (or install the game for your account). Open the **Xbox App** signed in with that account and install, reinstall or repair Minecraft from there. 2. If the game was installed by the official Minecraft launcher, open that launcher and start the game once so it repairs its own files, then close it. 3. Open the game once to confirm it starts, then run this installer again. Since v4.9.40 the menu shows this explanation on screen in your language when the game exits with this code, and the failure report marks the reason as `0xC0000135: required game file missing (copy not usable for this account)`. ## Minecraft does not open and the installation itself looks incomplete (v4.9.37+) ``` [launch] mode=failed official=yes exe=present exe-size=0B exe-pe=0x0000 exe-read=ok exe-attrs=none pkg=no uri=no-process start-err=This command cannot be run due to the error: ... content=C:\XboxGames\... ``` **What it means:** the installer wrote `winmm.dll` and then tried to open the game, and Windows could not run the game's own executable. The `[launch]` line now describes the state of the installation itself: - `exe-size=` is the size Windows reports for `Minecraft.Windows.exe` in the folder being used. `exe-size=0B` means an empty file, the usual leftover of a paused download, an interrupted update or a partial uninstall. - `exe-pe=` is the machine type read from the file's own PE header. A healthy x64 build reports `exe-pe=0x8664`, the only value that proves the file really is an executable. `exe-pe=0x0000` means the header could not be read, and on its own it does not tell apart an empty file, a truncated one and a file Windows refuses to open. That is why the two fields below exist. - `exe-read=` (v4.9.39+) is the result of opening the file just to read it: `ok`, `denied` when Windows refused the access, `error` for any other failure, or `unknown` when the file could not even be inspected. `exe-read=denied` with a full `exe-size` is the signature of game files that are on disk but cannot be read, which is not a size problem and not a truncated download. - `exe-attrs=` (v4.9.39+) lists the file attributes that matter here: `reparse`, `sparse`, `offline`, `encrypted`, several of them joined by `+`, or `none`. `reparse`, `sparse` and `offline` mean a placeholder whose real content lives somewhere else, which is how the Xbox app and the Microsoft Store store game files on some installs, and they stay unreadable without the package that owns them. `encrypted` means the file is encrypted for another Windows account. `none` together with `exe-read=denied` points at permissions or at security software instead. - `pkg=` says whether Windows still has a Minecraft package registered for your account. `pkg=no` together with an official folder means the game cannot be activated either, so the installer tells you to repair the game instead of blaming itself. - `apps=` (v4.9.50) records the second start attempt, the one that opens the game through its registered package (the same activation the Store copy uses): `skipped` when there was no package to activate or the activation was already the main path, `no-process` when the activation command ran but no game process appeared, or `error=...` when the activation itself failed. It exists so a report can tell "the installer only tried the executable" from "it also tried the registered package and that failed too". The report can also carry a `[content] used= now=...` line. It records the game folder used during the run and how that same folder looks when the report is written: `now=missing` when it is gone, `now=no-exe` when it exists without the game executable, or another folder when the game moved. It exists so that a folder changing mid-run cannot make two lines of the same report look contradictory. `pkg=no` combined with `exe-read=denied` on a full size executable is the signature of game files left behind by a game that is no longer registered: the folder is still there, the size is still reported, and nothing in it can be read or run. Repair does not apply in that state because there is nothing to repair. `pkg=registered` with `exe-read=denied` is a different state: the files are on disk and the game is registered, but Windows refuses to open the executable for this session. That usually points at security software or at file permissions, not at a download that went wrong. Since v4.9.50 the installer also tries to start the game through its registered package before falling back to the `minecraft:` protocol: when an attempt through the package starts the game, the report shows `[launch] mode=apps official=yes pkg=registered content=...` instead of `mode=exe`. **How to fix:** 1. If the report shows `pkg=no` with `exe-read=denied`, open the **Xbox App**, select Minecraft and choose **Uninstall** to clear the leftover, then install the game again from there. Do not delete the game folder by hand: a missing folder is a different failure the installer also has to explain. 2. If the report shows `pkg=registered` with `exe-read=denied`, open the game once from the **Xbox App** or from the Start menu. If the game opens, the unlock is already installed and there is nothing else to do. If it does not open, continue to the next step. 3. Otherwise open the **Xbox App**, use **Repair**, or reinstall Minecraft. Do not run the installer against a folder the Xbox app still shows as *installing*, *paused* or *needs attention*. 4. Confirm the game opens on its own once, close it, then run this installer again. In this state the menu shows a message in your language instead of the generic "could not start Minecraft automatically": it names the incomplete or unregistered installation when no package is registered, and since v4.9.50 it tells you that Windows refused to read or run the executable when the game is registered but the read was denied. Since v4.9.43 the installer detects this state at the start and stops **before downloading or writing anything**, with `Installation BLOCKED: Minecraft is not ready on this PC` (the report records the block on the `[gate]` line). The fix is the same as above. ## "Access to the path '...winmm.dll.new' is denied" during install (antivirus blocked the write) ``` Access to the path 'C:\Program Files\WindowsApps\...\winmm.dll.new' is denied. ``` (Depending on the installer version the denied file may be `winmm.dll`, `winmm.dll.new` or `winmm.dll.new-`. All of them are the same problem.) **What it means:** the installer could not create its file inside the game folder. `C:\Program Files\WindowsApps` is protected by TrustedInstaller, so the installer first takes ownership of the package folder and grants write access to the current user, SYSTEM and the Administrators group, then verifies the permission by actually creating a test file. When Windows still refuses the write, the cause is almost always one of these: - Minecraft or another process is holding the folder (close the game first). - An antivirus with ransomware protection (Windows "Controlled folder access" or a third-party equivalent) is blocking writes to the folder even for an administrator. - A security policy or a second antivirus product is denying the change to the folder permissions. **How to fix:** 1. Close Minecraft completely (the game keeps the DLL mapped while running). 2. Make sure the installer runs **as administrator**. The official bootstrap (`irm ... | iex`) and `install.bat` request elevation automatically. If you are on an account without admin rights, ask the machine's administrator to run it. 3. Run the installer again. Recent versions retry the write step up to three times and re-apply the folder permissions between attempts, so a temporary block often clears on the second try. If it still fails, your antivirus is the likely blocker: 1. Open Windows Security and check **Virus and threat protection > Ransomware protection**. If Controlled folder access is on, allow the installer (or add the Minecraft folder under the previous section) and retry. 2. If you use a third-party antivirus, add the Minecraft folder and `%TEMP%\mbu` to its exclusions, or temporarily disable its real-time protection, and retry. 3. Some third-party antivirus products ship their own "protected folders" or anti-ransomware feature (even when Windows Security shows Defender as passive). If the installer still fails with **Administrator: yes** in the report, that feature is the blocker: allow the Minecraft Content folder in it, then retry. 4. **360 Total Security** is the product most often seen blocking this write. Adding the folder to its exclusions is not always enough, because its file guard also refuses the DLL rename inside a folder it watches. Open its **Trust List** (Settings > Antivirus > Trusted Files, or the trusted zone of the version you have) and add the Minecraft folder printed by the installer, or turn its real-time protection off for the duration of the install. Since v4.9.44 the error message itself prints that folder, so you do not have to guess which one to add. The failure report you can send from the menu includes an `[acl]` line with the result of every permission step (takeown, grants and the write probe). Steps that fail also include the tool's own output (for example `grantAdm=1, grantAdmErr=Access is denied. | ...`), which tells whether the permission change itself was rejected. Since v4.9.33 that line also reports `denySeen` and `denyRemoved` (deny entries present on the folder, including inherited ones, and whether they were removed) and adds a read-back of the folder state taken after the last attempt (`aclOwner`, `aclDenyLeft`, `aclAdmWrite`). Since v4.9.36 that read-back also ends with `aclVerdict`: `deny-present` when a deny entry for an administrator is still there, `adm-no-write` when Administrators does not hold the Modify right, and `acl-clean-still-denied` when the permissions are already correct and the write is denied anyway. The report also lists the file system filters loaded in the system in the `[filters]` line. Since v4.9.35 the `Err=` suffix only appears when the tool really failed: a localized *success* summary (for example the Spanish `Se procesaron correctamente 1 archivos; error al procesar 0 archivos`, which contains the word `error`) no longer marks a successful step as an error, and a failure is recognized by the access-denied wording or by a non-zero count in the summary (`Failed processing 1 files`). Steps that succeed are printed as `name=0`. Since v4.9.37 the installer calls those tools by their full path inside `%SystemRoot%\System32` instead of relying on `PATH`: on a machine where `PATH` is trimmed (debloated or hardened Windows images) the old code could not even find `takeown.exe` and `icacls.exe`, so the permission step silently did nothing and the report showed the shell's own "command not recognized" text. When neither `System32` nor `Sysnative` has the tool, the step is now reported as `takeown=missing-tool` (or `grantAdm=missing-tool`) instead of an error that looks like a permission denial. When the read-back shows the permissions are correct (owner changed, no deny entry left, `aclAdmWrite=yes`) and the write is still denied, no permission change will help: a product with a filter in the disk stack (antivirus, endpoint security or a system hardening tool) is blocking the write to the game folder, and the filter names in the report usually identify it. If the game is the Microsoft Store (UWP) installation (the game folder is inside `C:\Program Files\WindowsApps`), the installer no longer tries to unlock it: since v4.9.42 it recognises that copy at the start of the installation, explains that the Store version is not supported and stops before downloading anything. See [The Microsoft Store version is not supported](#the-microsoft-store-version-is-not-supported-v4942). Releases up to v4.9.41 tried anyway and ended with a message that named the Store (UWP) installation as the cause, said that an antivirus exclusion does not help and pointed to the Xbox app version, which is the same advice. The current Minecraft version, installed through the Xbox app (GDK), uses a folder the installer can write to (`C:\XboxGames`). A Store install of the current GDK era keeps its files in `:\XboxGames\7792D9CE-355A-493C-AFBD-768F4A77C3B0\Content` (Preview: `98BD2335-9B01-4E4C-BD05-CCC01614078B`), which is not inside `WindowsApps`, so those folders are treated like any other `XboxGames` folder and the report names them `Microsoft Store (GDK)` in the install source line. Back up your worlds before switching: they live in `%LOCALAPPDATA%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\minecraftWorlds`. If you are still stuck after the steps above, sending that report tells the developer exactly which step is being denied. Since v4.9.8 the installer is explicit about this case: - When a third-party antivirus with real-time protection is registered, the menu warns **before** installing and names it (the automatic exclusions only cover Windows Defender, so they do nothing for it). - When the write is denied even though the folder was released and the write probe passed, the error message names the detected antivirus instead of showing the raw `Access to the path ... is denied` from .NET. - The staging file uses a unique name per attempt, so a `winmm.dll.new` left locked by an antivirus from a previous run no longer blocks the next try. - The failure report carries an `[error]` line with the cmdlet and the script line of the operation that actually failed (`cmd=Copy-Item line=...`), instead of pointing at the installer's internal rethrow. Since v4.9.10 a denied write no longer destroys the unlock you already had: - Before touching `winmm.dll`, the installer moves it aside to a `winmm.dll.mbu-prev-*` file. If publishing the new DLL fails (exactly the antivirus case above), that file goes back to its place and the machine ends up exactly as it started, with the previous unlock or the game original still working. A `winmm.dll.mbu-prev-*` left behind by a run that was killed mid-swap is recovered on the next run. - If the antivirus quarantines the new DLL right after it was copied, the installer puts the previous one back. Before, it only restored `winmm.dll.orig`, which does not exist when a known unlock was installed - in that case the game was left with a broken `winmm.dll`. - The failure report now carries `[swap]` (hash prefix of the DLL that was there, whether the swap published and whether a rollback was needed) and `[defender]` (whether the installer tried to add the automatic Defender exclusions and whether Windows accepted them, which is what Tamper Protection blocks - until now the report could not tell "tried and failed" from "never tried"). - Since v4.9.35 the `[swap]` line also tells why a copy was rejected: `verify=fail got= want=` means the copied file did not match the expected hash (the antivirus changed or quarantined it), while `got=unreadable` means the copy could not even be read back, which is what a file held open by a scanner looks like. The installer now re-reads that copy up to 3 times before giving up, so a short lock during the scan no longer fails the install and shows up as `verify=retry-ok`. - `[threat]` and `[cfa]` now say when a third-party antivirus is active: those two lines read the Windows Defender log only, so `[threat] none` with another antivirus running means "not covered here", not "nothing blocked it". Since v4.9.44 the installer also tries a second way to publish the DLL and reports the folder it is really writing to: - The game folder shown on screen and in the report is the folder the files really live in. When the registered package folder in `WindowsApps` is a link to `C:\XboxGames\...`, the installer works with the real folder instead of the link, so the folder named in the error message is the same one an antivirus exclusion has to cover. - If moving the staged copy into place is denied but the folder still accepts a new file (which is what a filter in the disk stack usually allows), the installer publishes the DLL by **copying** it under the final name instead of renaming it, then reads the hash of the result back. Either way the previous `winmm.dll` goes back to its place if the install does not complete. - The `[swap]` line records which way it worked (`published=1 via=move` or `via=copy`) and, when both fail, what denied each one: `failed attempts=3 final=no-winmm move= copy=`. `UnauthorizedAccessException` in both means the write itself is being denied, not a file held open by a scanner. - The access denied message names the folder to add to the antivirus exclusions (or protected folders), in all 8 menu languages. ## Installer blocks an old game version (v4.9.5+, version floor since v4.9.23) Since v4.9.23 the installer checks a **minimum supported version** (the `min_supported` field of `tested-versions.json`) instead of an exact list: any Minecraft for Windows build from **1.21 on** is accepted, including a build **newer** than the one this release was verified against. That is on purpose - the unlock hooks the GDK license APIs (`XStore*`), which is not tied to the game build. **What it means when you are blocked:** your game build is **older** than the floor (for example 1.17.x or 1.20.x). The installer stops before downloading anything, with the message "Installation BLOCKED: game version ... is older than the minimum supported version (...)". **How to fix:** update Minecraft from the Xbox app, then run the installer again. **If your game is NEWER than the `tested` list:** nothing to do, it is not a block. Since v4.9.23 a build newer than the verified one installs normally. Since v4.9.33 a build between the minimum supported and the verified build is reported as `older than the verified build`, which is not a block either. Older releases (v4.9.5 up to v4.9.22) refused it with the same message, so if you saw this on a game that was already up to date, update the installer (re-run the one-liner) and try again. The `tested` list in [`tested-versions.json`](https://minecraft-bedrock-free.pages.dev/tested-versions.json) is only a record of the builds verified by hand; the `min_supported` field is what decides if the installer proceeds. ## Installer fails while downloading with "contains a virus or potentially unwanted software" (#49) During the download step the installer verifies the binary it just wrote to `%TEMP%\mbu\winmm.dll`. If your antivirus removes or blocks that file right after it is written you may see errors like: ``` Get-FileHash : The file '...\Temp\mbu\winmm.dll' cannot be read: Operation did not complete successfully because the file contains a virus or potentially unwanted software. ``` followed by "You cannot call a method on a null-valued expression." (on versions before v4.4.1 the second message replaced the real cause). **What it means:** Microsoft Defender (or a third-party antivirus) flagged the unlock binary during the write. The installer adds Defender exclusions before downloading, but some setups still block the file anyway (cloud-delivered protection acting at first sight, the engine applying new exclusions asynchronously, managed policy ignoring local exclusions, or another antivirus product running alongside Defender). **How to fix:** 1. Open **Windows Security -> Virus & threat protection -> Protection history** and look for the blocked `winmm.dll`. Choose **Allow** or **Restore**. 2. Add the exclusions manually (both folders): - `%TEMP%\mbu` (the download folder) - the Minecraft `Content` folder from the first section above 3. If you use another antivirus in addition to Defender, add the same exclusions there too. 4. Run the installer again. Since v4.4.1 it retries automatically and shows a clear message naming the folders when this happens. ### If it still fails (v4.9.9) Two things changed, so read this before touching anything: 1. **The installer now uses its own offline copy first.** After any successful install it keeps the verified binary in `%LOCALAPPDATA%\mbu-cache`. When a download is removed or left unreadable (no network error involved - the file simply is not there or cannot be hashed), the installer copies that cached copy instead of failing. Same bytes, already accepted on your machine: in the 2026-09-12 report the cached copy and the file inside the game folder were both intact while every fresh download was eaten in `%TEMP%`. 2. **"Controlled folder access" (ransomware protection) is handled.** Path exclusions do **not** cover it: it has its own allowed-applications list. If it is on, the error message now says so instead of sending you to Protection history, where there is no **Allow** button for this kind of block. To fix it: **Windows Security -> Virus & threat protection -> Ransomware protection -> Manage ransomware protection -> Controlled folder access**, then allow the installer/PowerShell and `Minecraft.Windows.exe` (or turn it off temporarily and run the installer again). When you send the failure report, it now carries the objective evidence of the block instead of only saying "your antivirus blocked it": - `[dl]` - every download attempt with the address, the attempt number, the HTTP code and the error text, plus what happened to the file (missing, empty, unreadable hash, whether MotW was present, whether the offline cache worked, and whether the installer moved to an alternative address). Since v4.9.36 the hash step is labelled for what it is: `hash-match` when the downloaded file is the expected one and `hash-mismatch=` when it is not. Until v4.9.35 the label was `hash-ok` and it only meant "file downloaded and readable", so it is NOT evidence that the contents were the expected payload. On a mismatch the installer now tries the next address (the address pinned to the installer's own version serves the exact file for that version, so it always matches) instead of stopping at the first mirror, - `[threat]` - the last entries Defender recorded as a threat (name, time, resource), which is what tells a real detection from a folder-protection block, - `[cfa]` - recent controlled folder access events (1123 blocked / 1124 audited) from the Windows Defender operational log. See [docs/antivirus-false-positives.md](docs/antivirus-false-positives.md) for why these detections happen. ## Verifying the installed file The installer verifies the SHA-256 of `winmm.dll` both before and after copying it. You can do the same manually: ```powershell Get-FileHash "$env:ProgramFiles\WindowsApps\Microsoft.MinecraftUWP_*\winmm.dll" -Algorithm SHA256 # or, for the Xbox App install: Get-FileHash "C:\XboxGames\Minecraft for Windows\Content\winmm.dll" -Algorithm SHA256 ``` Compare against the hash published in [`SHA256SUMS.txt`](https://minecraft-bedrock-free.pages.dev/SHA256SUMS.txt). If it does not match, the file was modified. Reinstall. ## "Minecraft Launcher package found, but the game files are missing" (v4.9.20+) On some machines the game is registered by the official Minecraft Launcher while the game files are not there yet. The package points to `%APPDATA%\.minecraft_bedrock\versions\` and that folder has no `Minecraft.Windows.exe`. The installer finds the package, sees that the game executable is missing and stops with this message. Right above it the installer lists the folders it checked, so you can compare that list with where your game really is installed. **How to fix:** open the launcher you installed the game with, let it finish the installation (or use its verify/repair option), start the game once and close it, then run the installer again. If your copy comes from the Xbox app, install it from there instead. Until v4.9.37 the missing-executable case showed only "Minecraft package found but the game executable is missing", which sent users to a full reinstall that was usually not necessary. Since v4.9.38 that message names the Xbox app repair path instead. Since v4.9.30 that list also covers the folder the registered package really points to and every `XboxGames` folder on the fixed drives of the PC. So a game whose content sits in `C:\XboxGames\Minecraft for Windows_1\Content`, or on a drive other than `C:`, is found and installed without a reinstall. Since v4.9.41 it also covers the package store of every drive (`:\WindowsApps` and the store path Windows reports for app packages), which is where a Microsoft Store installation lands when Windows is set to install apps on another drive. The failure report shows the same locations plus a `[scan]` line with the drives it looked at, their type, and how many `XboxGames` and package store folders it found: the `[pkg]` line adds `target=` and `target-exists=` when the package folder is a link, and each `[candidate]` line marks it as `(junction -> ...)` followed by where it points, or as `link target is missing` when the link points to a folder that is gone. ## "Only the Minecraft Launcher was found, not the game" (v4.9.49+) On PCs where only the official **Minecraft Launcher** (the app that opens the games) is installed, the game files are not on the PC yet. The launcher lives in `:\XboxGames\Minecraft Launcher\Content` and that folder does not contain `Minecraft.Windows.exe`. Before v4.9.49 the installer listed that folder as checked and stopped with "Minecraft Content folder not found", which reads as if nothing Minecraft related was installed. Since v4.9.49 the installer names this case: it says the Minecraft Launcher was found but the game itself (Minecraft for Windows) was not found, and it tells you to install the game. **How to fix:** open the Minecraft Launcher and install **Minecraft for Windows** (the Bedrock game) there, or install it from the Xbox app, open the game once and run this installer again. The launcher alone is not the game. **How to tell this apart in a report:** the checked folders list contains a path under `XboxGames\Minecraft Launcher` and no folder was used, because none of the candidates has `Minecraft.Windows.exe`. ## "Minecraft is registered, but the folder the package points to does not exist" (v4.9.38+) The current Microsoft Store package of Minecraft (package version `1.26.4501.0` on the machines seen so far) keeps a folder inside `C:\Program Files\WindowsApps` that is a link to `C:\XboxGames\Minecraft for Windows\Content`, the same folder the Xbox app installation uses. The game files, `Minecraft.Windows.exe` included, live in that linked folder, not inside `WindowsApps`. When that folder is gone (deleted by a disk cleanup tool, moved to another drive, an interrupted uninstall or a failed repair), the package stays registered and the link keeps pointing to a path that no longer exists. Windows still reports the `WindowsApps` entry as existing, so the old failure report said only `exists, no Minecraft.Windows.exe`, which reads like a problem inside the protected package folder. The installer stops because there is no game folder to write the unlock into. Since v4.9.42 the installer refuses a Microsoft Store installation, so the supported way out is to install the game from the Xbox app (or repair that Xbox app installation) instead of repairing the Store copy. **How to fix:** in the Xbox app select Minecraft and use Repair, or reinstall it, start the game once and then run this installer again. A cleanup tool that deletes the `XboxGames` folder can cause this, so keep that folder out of automatic cleaners. **How to tell this apart in a report:** the `[pkg]` line carries `target-exists=no`, and the linked `[candidate]` line says `link target is missing` instead of `exists, no Minecraft.Windows.exe`. ## "Windows refused administrator permission for this account" (v4.9.21+) This message appears when Windows itself refuses the elevation request, before the UAC window is even shown. The installer needs administrator rights to write the game files, so it cannot continue without them. Until v4.9.20 this case printed only the raw Windows error text (`This command cannot be run due to the error: Access is denied`), which told the user nothing. Two causes are common: 1. The account you are using is not an administrator on this PC, so the request would need the user name and password of an administrator account. 2. The elevation prompt is blocked by a Windows policy, or by the family and parental controls of a child account, so the request is denied without asking anything. **How to fix:** sign in with an administrator account and run the installer again, or ask the administrator of the PC to run the command below in a PowerShell window opened as administrator: ```powershell irm https://minecraft-bedrock-free.pages.dev/menu.ps1 | iex ``` You can check your account type in Windows Settings, Accounts, Your info, where it says "Standard user" or "Administrator". If the message says that you cancelled the administrator request, the request reached the UAC window and was declined: run the installer again and accept that window. ## FAQ ### How do I remove the unlock without the menu? Download `uninstall.ps1` from , open PowerShell **as administrator**, and run it. It closes the game, restores `winmm.dll` (or removes it when there was no original), cleans the Defender exclusions the installer added (including the game folder exclusion when it lives under an `XboxGames\` folder, since v4.9.50) and deletes the local binary cache. Since v4.9.52, when `winmm.dll` cannot be deleted because the game or an antivirus is holding the file, the script moves it aside under `winmm.dll.mbu-removed-` and finishes the removal anyway. ### Does it work with a third-party launcher / version switcher? No. The unlock only works with the official **Xbox App** build (the Microsoft Store copy is not supported and the installer refuses it). It does nothing in other launchers - and can break them. Do not copy it into another launcher. Since v4.9.26 the installer checks the folder it is about to use. When that folder is not the official installation it explains the risk and asks for confirmation before touching anything. When the game does not start after the install, the failure message tells you to open the game through your launcher, and the report records why the automatic start failed (executable missing, start error, no process after the fallback). ### Does it work on an older Minecraft version? The unlock targets the official build and is only tested on the **current** version. Microsoft doesn't let you install an older version, so there's no supported way to run an older version with this unlocker. ### I downloaded the file by hand and left it in Downloads / next to another game Delete that extra copy and run the installer again, nothing else is needed. The file must live only in the Minecraft game folder, which is where the installer puts it. Any other program that starts from the same folder as the file picks it up, which can stop that program from working (32-bit programs there may not open at all) and online games with anticheat can flag the session. ### Where is the offline copy the installer keeps? (v4.9.31+) It is `%LOCALAPPDATA%\mbu-cache\payload-x64.bin`. Do not move or rename it. It is not the file the game reads, and only the installer places the file where the game reads it. Installs up to v4.9.30 kept that same copy as `winmm.dll` in that folder, and the installer now renames a valid copy to the new name on the first run, so the offline install keeps working after the update.