- Close every instance before changing CPU, RAM, graphics, or multi-open settings.
- Test a fresh instance to separate configuration damage from installation-wide problems.
- Protect accounts, files, scripts, and clones before repair or reinstallation.
- Confirm Which LDPlayer Settings Are Not Saving
- Close Every Instance Before Changing Its Configuration
- Run LDMultiplayer With The Required Permissions
- Check Windows Security And Third-Party Antivirus Activity
- Reject Invalid Or Unsustainable Settings
- Refresh LDMultiplayer And Rebuild Its View
- Test With A Fresh Instance Without Deleting Anything
- Protect Existing Instances Before Repair Or Reinstallation
- Check Related Network And Shared-Folder Problems
- Pause Automation And Synchronization During Testing
- Repair Or Reinstall Only After Safe Tests Fail
- Final Resolution Checklist
When LDPlayer multi-instance settings do not save, the cause is usually an open instance, a locked configuration file, insufficient Windows permissions, security software interference, or a value that LDPlayer cannot apply. Start with the least disruptive checks below, change one setting at a time, and protect your existing instances before attempting repairs.

Start with free Canva bundles
Browse the freebies page to claim ready-to-use Canva bundles, then get 25% off your first premium bundle after you sign up.
Free to claim. Canva-ready. Instant access.
1. Confirm Which LDPlayer Settings Are Not Saving
First, identify the exact symptom. This prevents an instance-specific problem from turning into an unnecessary reinstall.
- Open LDMultiplayer without starting any instances.
- Choose one affected instance and note its current CPU, RAM, resolution, DPI, graphics, FPS, network, or optimization setting.
- Change only one value.
- Use the available Save or confirmation button.
- Close LDMultiplayer normally, reopen it, and inspect that instance again.
- If the value remains, start the instance and confirm that the applied configuration matches the saved value.
A setting that remains visible but does not take effect is different from one that immediately reverts. The first case may require a full instance restart. The second more strongly suggests a permissions problem, file lock, invalid value, or security block.
1.1 Test Whether Only One Instance Is Affected
Repeat the same test on another existing instance, preferably with a harmless change such as a small CPU or RAM adjustment that remains within your computer's available resources.
- If every instance reverts, investigate LDMultiplayer, Windows permissions, file access, and antivirus controls.
- If one instance reverts, its individual configuration or virtual disk may be damaged or locked.
- If only clones are affected, test the original source instance and a fresh instance separately.
- If global multi-open optimization settings revert, focus on LDMultiplayer rather than Android settings inside one instance.
Keep LDPlayer 9 and LDPlayer 5 instances separate during testing. Different LDPlayer generations can use different components and instance formats, so a result from one installation does not automatically diagnose the other.
2. Close Every Instance Before Changing Its Configuration
The safest first fix is to close all running instances. CPU, RAM, resolution, DPI, OpenGL-related options, and some multi-open settings may not save correctly while an emulator process is using the relevant configuration.
- Exit the game or app running inside each instance.
- Stop the Synchronizer and Operation Recorder if either tool is active.
- Close every LDPlayer window.
- Wait for LDMultiplayer to show that no instance is running.
- Exit LDMultiplayer as well.
- Open Task Manager and look for remaining LDPlayer or LDMultiplayer processes.
- If a related process remains after the windows have closed, select it and choose End task.
- Reopen LDMultiplayer, make one change, save it, and reopen the manager to verify the result.
Do not force-end processes while an instance is installing an app, updating a game, copying files, or writing account data. An abrupt stop during disk activity can damage the instance.
2.1 Restart Windows If A Configuration Lock Remains
A background process, updater, backup program, or security scanner may keep a configuration file open even after LDPlayer disappears from the desktop. Restart Windows, open LDMultiplayer before launching any other instance, and test one setting immediately.
A restart is especially useful after changing graphics mode, virtualization components, Hyper-V-related settings, or security exclusions. It also clears stale processes without requiring you to find or edit LDPlayer's configuration files manually.
3. Run LDMultiplayer With The Required Permissions
If LDMultiplayer can read an instance's settings but cannot write new values, Windows permissions may be blocking the change.
- Close LDPlayer and LDMultiplayer completely.
- Right-click the LDMultiplayer shortcut.
- Select Run as administrator.
- Approve the User Account Control prompt.
- Change one setting on one stopped instance and save it.
- Close and reopen LDMultiplayer normally to see whether the value persists.
If running as administrator fixes the issue, do not immediately grant broad access to the entire drive. Check whether LDPlayer was installed under another Windows account, copied from another disk, restored from a backup, or moved manually. Those situations can leave instance files owned by a different account.
You can inspect the LDPlayer installation folder through Properties, Security. Your Windows account should be able to modify the application's writable data. Avoid changing ownership or granting Everyone full control unless you understand the security implications.
3.1 Avoid Manual Configuration Editing
Do not guess which configuration file controls an instance, remove files at random, or edit values while LDPlayer is running. LDPlayer installations and releases can organize data differently. An incorrect edit can affect instance registration, clones, shared folders, keymapping profiles, gamepad controls, scripts, or virtual disks.
If you already changed a file manually, restore your known-good copy before continuing. Otherwise, use LDMultiplayer's interface for all tests.
4. Check Windows Security And Third-Party Antivirus Activity
Microsoft Defender Controlled Folder Access and third-party security tools can prevent an application from modifying protected files. Antivirus scanning can also temporarily lock a file at the moment LDMultiplayer tries to save it.
- Open Windows Security.
- Review Virus and threat protection, Protection history for recent LDPlayer-related blocks.
- Check Ransomware protection if Controlled Folder Access is enabled.
- If a verified LDPlayer executable was blocked, allow only the required executable or installation location.
- Restart the allowed application and test one setting again.
Use targeted allow rules rather than disabling antivirus protection. Verify that LDPlayer came from its official source before adding an exclusion. A folder-wide exclusion reduces scanning for every file placed in that folder and should be used only when necessary.
If you use third-party antivirus, inspect its quarantine, behavior monitoring, ransomware protection, and application control logs. Add the narrowest possible exception, test the save operation, and keep real-time protection enabled.
4.1 Do Not Disable Windows Security Or Virtualization Indiscriminately
Do not permanently disable Microsoft Defender, firewall protection, Memory Integrity, Hyper-V, or other Windows security features merely to test whether a setting saves. Virtualization changes can affect WSL2, Docker Desktop, Windows Sandbox, Google Play Games, virtual machines, and other software.
VT, meaning Intel VT-x or AMD-V, is normally important for emulator performance. Hyper-V compatibility depends on the LDPlayer edition and Windows environment. Treat virtualization as a separate compatibility question unless settings began reverting immediately after a virtualization change.
5. Reject Invalid Or Unsustainable Settings
LDPlayer may refuse, normalize, or fail to apply settings that exceed available resources or conflict with an instance's configuration. Test conservative values before assuming file corruption.
- Do not allocate more CPU cores than Windows can reasonably provide while other instances are running.
- Leave enough physical RAM for Windows, security software, and foreground applications.
- Use the same resolution and DPI across instances that will be controlled by the Synchronizer.
- Test the default frame rate before applying aggressive high-FPS or multi-open optimization values.
- Use a supported graphics mode rather than forcing an OpenGL option that the current graphics driver cannot handle reliably.
After changing CPU, RAM, resolution, DPI, graphics mode, or multi-open optimization, restart the affected instance. Some values can be stored successfully but cannot be applied to an already running virtual machine.
5.1 Change One Value At A Time
Do not simultaneously change CPU allocation, RAM, resolution, graphics mode, FPS, and virtual disk options. Save and verify each change separately. This makes it possible to identify the exact value that causes the configuration to revert.
If the setting saves until you select a particular value, return to the last working value. Also check free disk space. Instance configuration changes, snapshots, clones, and virtual disk expansion may fail when the LDPlayer drive is nearly full.
6. Refresh LDMultiplayer And Rebuild Its View
LDMultiplayer may display stale information even when an instance has saved correctly. Refresh the manager before performing repairs.
- Close all instances.
- Use the refresh control in LDMultiplayer if it is available in your installed version.
- Close and reopen LDMultiplayer.
- Sort or reselect the affected instance.
- Open its settings and confirm the saved value.
- Start only that instance and check the setting from within LDPlayer where applicable.
If LDMultiplayer is unresponsive or its instance controls do not work, close it and try running it as administrator once. Do not repeatedly click Clone, New Player, Start, or Delete while the manager is frozen, because delayed commands may execute after it recovers.
6.1 Separate Global And Instance Settings
LDMultiplayer contains settings that can affect multi-open behavior globally, while each instance also has its own CPU, RAM, resolution, graphics, and application state. Confirm which layer you are changing.
Synchronizer behavior, window arrangement, and multi-open FPS limits are not necessarily stored in the same place as one instance's Android settings. Likewise, Google Play Services, a Google account, in-game options, and Android app data exist inside the instance and will not normally repair a Windows-side LDMultiplayer save failure.
7. Test With A Fresh Instance Without Deleting Anything
A fresh instance is the safest way to determine whether the problem belongs to one virtual machine or the whole LDPlayer installation.
- Close all existing instances.
- Open LDMultiplayer.
- Select New or New/Clone, depending on the interface shown.
- Create a new player rather than cloning the affected instance.
- Give it a recognizable test name.
- Change one CPU, RAM, resolution, or graphics setting.
- Save, close LDMultiplayer, reopen it, and check the value.
If the fresh instance saves settings, the original instance is probably the problem. If the fresh instance also reverts, focus on permissions, antivirus, disk access, or the LDPlayer installation.
Creating a fresh instance does not transfer the original instance's apps, guest accounts, local saves, keymaps, or Android data. Do not delete the original after a successful test.
7.1 Compare The Original, A Clone, And A Fresh Instance
If disk space permits, compare three controlled cases:
- The original affected instance
- A clone of that instance
- A completely fresh instance
If the original and clone fail but the fresh instance works, the clone may have copied the original configuration problem. If only the original fails, cloning may provide a temporary path, but verify the clone thoroughly before relying on it.
Check app launches, Google Play Services, network access, shared folders, Synchronizer behavior, Operation Recorder scripts, gamepad mappings, and keyboard controls. A clone that starts is not automatically a complete or safe replacement.

8. Protect Existing Instances Before Repair Or Reinstallation
Before any repair, update, move, or reinstall operation, protect data that cannot easily be recreated. This is especially important for guest game accounts stored only inside one instance.
- Bind important game progress to the game's supported account system where possible.
- Record which Google account belongs to each instance without removing the account.
- Use LDMultiplayer's backup or export capability if it is available in your installed version.
- Copy irreplaceable screenshots, downloads, and documents through the shared-folder feature.
- Export or copy important Operation Recorder scripts using the tool's file-location option.
- Document custom keymapping and gamepad layouts.
- Record each instance's CPU, RAM, resolution, DPI, graphics, and network settings.
Store backups on a different drive when possible. A backup inside the same installation folder may be lost during an uninstall, disk failure, or manual cleanup.
Do not delete an instance until its replacement has launched repeatedly and its important apps, accounts, files, controls, and network connection have been verified. Do not assume that uninstalling LDPlayer will preserve local instance data.
9. Check Related Network And Shared-Folder Problems
A save failure can appear alongside connectivity or file-transfer problems when security software, permissions, or a damaged instance affects several LDPlayer components.
9.1 Network Connectivity
Test the affected instance separately. Open a browser inside Android, load a simple website, and then test Google Play Services or the relevant game. If every instance lacks connectivity, check the Windows connection, VPN, proxy, firewall, DNS filtering, and security software. If only one instance is offline, compare it with a fresh instance before changing Windows networking.
Do not remove a Google account or clear Google Play Services data as an early network fix. Those actions can create authentication problems and do not repair LDMultiplayer's Windows-side configuration permissions.
9.2 Shared Folders And File Transfer
LDPlayer's shared-folder feature provides a path between Windows and Android. If file transfer fails, test both directions with a small, non-sensitive file.
- Open the shared-folder tool from the affected instance.
- Open the PC shared folder.
- Place a small test file there.
- Open the Android shared folder and confirm that the file appears.
- Create or copy another test file from Android and confirm that Windows can see it.
If one instance cannot access the shared folder but another can, treat it as an instance-specific fault. If no instance can access it, review Windows folder permissions, Controlled Folder Access, antivirus activity, and whether the destination folder still exists.
10. Pause Automation And Synchronization During Testing
Disable the Synchronizer, Operation Recorder, macros, gamepad automation, and keymapping scripts while diagnosing settings. Automation can start apps, close screens, change focus, or make several instances appear to behave identically even when only one is faulty.
The Synchronizer works best when participating instances use matching resolution and DPI. A resolution change that fails to save on one instance can produce inaccurate clicks or inconsistent typing. Fix the underlying setting before resuming synchronized control.
After the problem is resolved, test tools in this order:
- Start one instance without automation.
- Verify its settings and network connection.
- Test shared-folder transfers.
- Confirm keyboard and gamepad mappings.
- Run a short Operation Recorder script.
- Start a second instance.
- Enable the Synchronizer for a brief controlled test.
11. Repair Or Reinstall Only After Safe Tests Fail
Consider repair or reinstallation only if settings fail in every instance, including a fresh one, after closing processes, restarting Windows, testing administrator permissions, reviewing security blocks, and using conservative values.
Before proceeding, back up all accessible instances and files. Confirm that important game accounts are bound. Save scripts, screenshots, downloads, and control layouts outside the LDPlayer installation directory.
Do not manually delete LDPlayer folders unless the official uninstall or support procedure specifically requires it and your backups have been verified. Deleting folders can remove virtual disks containing complete instances.
If LDPlayer 9 and LDPlayer 5 are both installed, confirm which installation you are repairing. Avoid deleting data from one version while troubleshooting the other. After reinstalling, create a fresh test instance and confirm that settings persist before importing, restoring, or recreating production instances.
12. Final Resolution Checklist
Use this checklist before returning to normal multi-instance use:
- All instances were fully closed before settings were changed.
- No abandoned LDPlayer process remained in Task Manager.
- LDMultiplayer could save a single conservative test value.
- The value remained after closing and reopening LDMultiplayer.
- The setting took effect after restarting the instance.
- A second existing instance was tested.
- A fresh instance was tested without deleting the original.
- Windows Security and antivirus logs showed no unresolved blocks.
- CPU and RAM allocations leave adequate resources for Windows.
- Graphics and OpenGL settings work with the installed graphics driver.
- Matching resolution and DPI were restored before using Synchronizer.
- Network access works in the affected instance.
- Shared-folder transfers work in both directions.
- Operation Recorder, keymapping, and gamepad tools work after settings are stable.
- Important instances and guest account data are backed up.
The issue is resolved when a setting survives an LDMultiplayer restart, takes effect after the instance restarts, and remains stable during a second Windows session. If only one old instance still fails while fresh instances save normally, preserve the old instance, recover its important data, and replace it only after the new environment has been fully verified.