MEmu Instance Settings Not Saving: A Safe Step-by-Step Fix

If MEmu Play keeps discarding changes to CPU, RAM, resolution, render mode, or storage paths, do not delete the affected virtual machine or reinstall the emulator immediately. The problem is often caused by a running VM, insufficient permissions, a locked configuration file, invalid values, security software, or a stale Multi-MEmu display. Follow the checks below in order, changing one setting at a time and protecting your VM images before attempting any destructive repair.

1. Confirm Which MEmu Setting Is Not Saving

Start by identifying exactly what fails. This prevents an unrelated restart requirement or display problem from being mistaken for configuration corruption.

1. Open Multi-MEmu and note the name or number of the affected instance.
2. Make sure the instance is completely stopped.
3. Open its settings and change one harmless option, such as the resolution preset.
4. Apply or save the change.
5. Close the settings window, reopen it, and check the value.
6. If the value remains, launch the VM and verify that Android uses it.

Some settings are written immediately but do not take effect until the Android VM restarts. CPU allocation, memory allocation, resolution, Android image options, render mode, OpenGL, and DirectX settings commonly require a full VM shutdown and launch. Closing only the MEmu window may not be enough if the emulator is minimized to the notification area or if a background process remains active.

1.1 Distinguish a save failure from an apply failure

A save failure means the old value returns as soon as you reopen the settings panel. An apply failure means the new value remains visible in settings, but the running VM behaves as though it still uses the old value. Apply failures can involve graphics drivers, unsupported presets, virtualization configuration, or a restart that has not occurred.

Resolution can also be deceptive. Android applications may use their own orientation, density, or full-screen behavior. Check the actual MEmu settings again rather than judging only from one application.

1.2 Check whether every setting or only one setting fails

If CPU and RAM save but a path does not, the path may be invalid, unavailable, protected, or unsupported for an existing VM. If only render mode fails, the problem may involve OpenGL, DirectX, the display driver, or a mode chosen automatically at launch. If no setting saves, focus first on VM state, permissions, configuration locks, and security software.

2. Shut Down the VM and MEmu Processes Completely

MEmu should not rewrite the configuration of a running instance. Multi-MEmu can also show a VM as stopped while a related process is still shutting down or holding a file open.

1. Save work inside Android and close any running games or applications.
2. Shut down the instance through MEmu or Multi-MEmu rather than forcing Windows to terminate it.
3. Close MEmu Play, Multi-MEmu, the operation recorder, and the synchronizer.
4. Stop any scripts using MEMUC or ADB to control the instance.
5. Open Windows Task Manager and wait for MEmu-related VM processes to exit.
6. Reopen Multi-MEmu and change one setting.

If a process does not close, restart Windows instead of repeatedly ending VM processes. Forced termination can leave a virtual disk in an inconsistent state, particularly while Android is writing application data.

Automation deserves special attention. A MEMUC script, ADB workflow, synchronizer session, or operation recorder task may relaunch the instance after you stop it. Temporarily pause that automation while testing settings.

3. Test Windows Permissions Safely

MEmu needs write access to its configuration and VM storage locations. A Windows account may be able to launch an existing VM while lacking permission to update a configuration file or create data in a selected folder.

1. Close all MEmu components.
2. Right-click the MEmu or Multi-MEmu shortcut.
3. Select the option to run it as administrator.
4. Change one setting on a stopped VM and save it.
5. Close and reopen Multi-MEmu to see whether the change remains.

If running as administrator fixes the issue, treat that as a diagnostic result rather than the ideal permanent solution. Check the permissions of the MEmu installation, configuration, and VM storage folders. Your Windows account should have appropriate modify access to the folders MEmu is expected to update.

Avoid granting broad permissions to an entire drive. Do not take ownership of Windows system folders or weaken security for unrelated applications. Correct only the relevant MEmu folder permissions.

3.1 Validate custom paths

A custom VM, backup, import, export, or shared-folder path should exist and remain available. Test with a short local path in a folder your account owns. Avoid these locations while diagnosing the problem:

• Read-only folders and protected Windows directories
• Disconnected network drives
• Removable drives that may change drive letters
• Cloud folders that are offline or still synchronizing
• Folders controlled by another Windows account
• Paths with restrictive enterprise security policies

Changing a path in a settings panel does not necessarily relocate an existing VM image. Depending on the MEmu build and the specific option, the path may affect future imports, exports, downloads, shared folders, or newly created instances only. Do not manually drag an active virtual disk to another folder and assume Multi-MEmu will find it.

4. Use Valid CPU, Memory, Resolution, and Graphics Values

MEmu may reject, normalize, or replace values that are outside its supported range. Begin with a built-in CPU and memory preset rather than a custom value. Do not assign all host processor threads or nearly all physical RAM to one instance. Windows and the emulator need spare resources.

For resolution, select a standard preset first. If that saves, test the desired custom width, height, and DPI individually. A malformed or extreme value can be rejected even if the settings window initially accepts it.

For graphics, test one render mode at a time. Switch between the available OpenGL and DirectX options only while the VM is stopped, save, and then launch the instance. Update the Windows graphics driver through the computer or GPU manufacturer if a selected mode will not apply.

4.1 Do not mix graphics and virtualization troubleshooting

Render mode and hardware virtualization solve different problems. OpenGL and DirectX concern graphics rendering. VT, Hyper-V mode, and MEmuHyperv concern how the virtual machine uses host virtualization. A graphics setting that will not save is not, by itself, proof that VT or Hyper-V must be changed.

Do not disable Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform, Memory Integrity, or related Windows features as an early fix. These features may be required by WSL2, Docker Desktop, Windows Sandbox, enterprise security tools, or other virtual machines. Record the original state and understand the effect on other software before changing any virtualization or security feature.

5. Refresh Multi-MEmu and Check for a Stale Display

Multi-MEmu can occasionally display information that does not yet reflect the instance configuration. After saving a setting, close the settings panel and refresh or reopen Multi-MEmu. If there is no refresh command in your installed interface, exit Multi-MEmu completely and start it again.

Confirm the instance identity before editing. Cloned VMs can have similar names, and it is easy to change one instance while launching another. Rename instances with clear labels such as test, work, game, Android 7.1, or 64-bit so the target remains obvious.

If you use command-line automation, temporarily stop MEMUC or ADB scripts and test through Multi-MEmu alone. A management script may be applying a saved template or changing launch parameters after your manual edit.

6. Determine Whether Only One VM Is Affected

A fresh test instance is one of the safest ways to separate an application-wide problem from damage limited to one VM. It also avoids experimenting on valuable Android data.

1. Open Multi-MEmu.
2. Create a fresh instance using an image already available in your installation.
3. Choose an Android 5.1 or 7.1 image, or a 32-bit or 64-bit image, according to the options MEmu actually provides.
4. Do not sign in to Google or install applications yet.
5. Stop the new VM.
6. Change one CPU, memory, or resolution setting.
7. Reopen the settings and launch the VM to verify the result.

If the fresh VM saves settings normally, the original instance probably has an instance-specific configuration problem. If the fresh VM also fails, investigate permissions, antivirus interference, installation damage, or an application-wide configuration lock.

Do not assume an Android 5.1 image can be converted safely into Android 7.1, or that a 32-bit image can be changed into a 64-bit image by editing a setting. These are different VM images. Create the required image and migrate data through supported application backups, account synchronization, shared folders, or MEmu export and import features where available.

7. Check for Configuration Locks and Security Software

A configuration file can remain locked after a crash, forced shutdown, backup scan, cloud synchronization, or security scan. Restart Windows first. Then open Multi-MEmu before launching unrelated backup or synchronization tools and test one setting.

Windows Security or third-party antivirus software may block changes to protected folders. Review protection history, quarantine records, and Controlled Folder Access notifications for entries involving MEmu. If a legitimate MEmu executable was blocked, allow it using the security product's documented application-control process.

Do not disable antivirus protection globally as a routine fix. If a short diagnostic test is unavoidable, disconnect from untrusted networks, limit the test to the minimum time, restore protection immediately, and prefer a narrow exception for a verified MEmu executable or folder. On a managed computer, contact the administrator instead of bypassing policy.

7.1 Avoid manual configuration editing unless recovery is available

Do not delete lock files, edit VM definitions, or replace configuration files based on instructions written for another MEmu release. File names and storage layouts can change. Removing the wrong file may make Multi-MEmu lose track of the instance even though its virtual disk still exists.

If advanced inspection is necessary, close MEmu, back up the complete instance through a supported export method, and copy relevant configuration files before editing anything. Keep the original copy unchanged.

8. Protect VM Images and Android Data Before Repair

Before importing, compacting, replacing, or deleting a VM image, create a recoverable backup. A VM may contain local application data that is not synchronized to Google Play Services or any cloud account.

• Use Multi-MEmu's available export or backup function for the stopped instance.
• Store the backup on a different physical disk when possible.
• Record the Android version and whether the image is 32-bit or 64-bit.
• Copy important files through shared folders or another verified transfer method.
• Confirm that games and applications have completed their own account or cloud synchronization.
• Preserve authentication information and recovery codes outside the emulator.

An exported VM is useful only if it can be located and read. Check that the backup file exists and has a plausible size. For critical data, test an import on another instance or system before deleting the source VM.

8.1 Destructive actions that require extra caution

Deleting an instance normally removes access to its local Android data. Compacting a virtual disk rewrites storage and should not be attempted during instability, while the VM is running, or without a backup. Importing over an existing instance can also cause confusion about which disk contains the current data.

Clearing Google Play Services or Google Play Store data can sign applications out, reset local service state, or require account verification. Removing a Google account can affect synchronized information. Neither action is a logical first fix for CPU, RAM, resolution, render mode, or path settings that do not save.

9. Repair or Reinstall MEmu Only After Backups

If all instances reject valid settings after a Windows restart, an administrator test, a local-path test, and a security review, the MEmu installation may need repair. Use an official installer obtained from MEmu's website and preserve instance exports before changing the installation.

1. Export every important stopped VM.
2. Copy essential Android files through shared folders.
3. Record instance names, Android images, CPU and memory presets, resolution, render mode, and custom paths.
4. Close automation using MEMUC, ADB, the synchronizer, or the operation recorder.
5. Use an available repair or update option before uninstalling.
6. After repair, test settings with a new empty VM before importing valuable images.

Uninstalling may remove configurations or VM data depending on the selected options and installed build. Never continue through prompts that mention deleting user data or virtual machines unless verified backups exist. Do not manually erase leftover folders until all required instances have been restored successfully.

10. Final Resolution Checklist

Use this checklist to confirm the issue is actually fixed rather than temporarily hidden:

• The correct VM is fully stopped before settings are edited.
• CPU and memory use supported presets or reasonable custom values.
• Resolution and DPI remain saved after reopening Multi-MEmu.
• The selected OpenGL or DirectX render mode remains after a full VM restart.
• Custom paths point to existing, writable, local folders during testing.
• No MEMUC, ADB, synchronizer, or operation recorder task overwrites the configuration.
• Windows Security or third-party antivirus is not blocking configuration writes.
• A fresh VM can save settings, or the repaired original VM now behaves normally.
• The Android image type, such as Android 5.1, Android 7.1, 32-bit, or 64-bit, has not been changed through unsafe file replacement.
• Important VM images and local Android data have verified backups.
• Virtualization and Windows security features were not changed unnecessarily.

If settings save in a fresh VM but not in the original, keep the original as a recovery source and migrate carefully to the working instance. Import or restore only from a verified backup, and retain the source VM until applications, accounts, shared files, and Google Play Services work correctly in the replacement. This approach is slower than deleting the broken instance, but it provides the best chance of preserving data while resolving the settings problem.