mksSandbox.exe memory bloat

5. RE: mksSandbox.exe memory bloat

Recommend

Yevgeni Shirukin

Posted Mar 01, 2025 03:57 AM

These issues might occur with *3D acceleration disabled*. I am *reenabling
3D acceleration* and reversing the changes I made to optimize performance
without it.

When *3D acceleration is off*, the *memory leak does not happen*.
*More Details About My Case:*

I run a *game that has a built-in autoclicker*, which *presses a few
buttons and moves the mouse in a circular pattern*.

- *If I keep the game open (not minimized to the tray), there is no
memory leak.*
- *If I minimize the game to the tray, the RAM usage instantly starts
increasing (Host system mksSandbox.exe )*, until my *host system runs
out of RAM and crashes the VM*.
- *After the crash, all RAM is released.*

*Important Observations:*

- *While the memory leak happens, the guest system remains stable.*
- The guest OS *only shows 50% memory usage*, and it *does not increase.*
- The *leak is directly caused by minimizing the game to the tray.*
- I *cannot keep the game open in full mode* because I *run six
instances* of it.
- *If I disable 3D acceleration, the experience becomes very
laggy*, but *there
is no memory leak*.

Original Message

Original Message:
Sent: 2/28/2025 2:30:00 PM
From: Michael Banack
Subject: RE: mksSandbox.exe memory bloat

It's possible switching to DX11 might help, but otherwise the ChatGPT analysis there is pretty much completely wrong or nonsensical to me.

If you can post your logs here, our development team can take a look and see if we can offer any suggestions.

Original Message:
Sent: Feb 28, 2025 12:42 PM
From: Yevgeni Shirukin
Subject: mksSandbox.exe memory bloat

Did some chat gpt analysis on logs got his will try to to forse Directx 11

Funny part that everything worked fine for weeks but i managed to reset BIOS by clicking back of pc i did bios update again did same setup clean os reinstal clean vm reinstal and this thing started to happen and keeps happening after multiple vm os reisntals :)

🛑 Major Issues Identified

1️⃣ VMware is Attempting to Use Vulkan but Failing

From mksSandbox-2.log:

pgsql
2025-02-28T06:42:47.319Z In(05) mks  Vulkan Renderer: No supported Vulkan device/driver found (See mks.vk.allowUnsupportedDevices or mks.vk.forceDevice configuration options).

VMware tries to initialize Vulkan but fails, likely causing mksSandbox.exe to fall back to DirectX 12.
When fallback happens, memory leaks can occur due to inefficient memory cleanup.

2️⃣ DirectX 12 is Being Used, but VRAM Management is Unstable

From mksSandbox-2.log:

yaml
2025-02-28T06:42:47.568Z In(05) mks  DX12Module: Selected adapter:2025-02-28T06:42:47.568Z In(05) mks  DX12Module:  NVIDIA GeForce RTX 4090

DirectX 12 is being selected for rendering, but VMware isn't properly managing VRAM allocations.
This can cause mksSandbox.exe to keep allocating VRAM without freeing it, leading to memory leaks.

3️⃣ mksSandbox.exe is Attempting to Handle a Minimized Window Incorrectly

The fact that mksSandbox.exe doesn't leak RAM when the window is not minimized suggests a rendering bug when handling hidden windows.
VMware might be trying to render frames even when the window is minimized, leading to VRAM not being released properly.

✅ Fixes to Stop mksSandbox.exe From Leaking RAM

🟢 Fix 1: Force DirectX 11 Instead of DirectX 12

Since Vulkan fails and DirectX 12 has memory management issues, forcing DirectX 11 can stabilize memory usage.

Steps:

Open the VMX file (YourVM.vmx) in a text editor.

Add the following lines:

ini
mks.enableDX12Renderer = "FALSE"mks.enableDX11Renderer = "TRUE"

Save the file and restart VMware Workstation.

✅ Effect: Forces DirectX 11, which has better memory management than DX12 in VMware.

🟢 Fix 2: Disable Vulkan to Prevent Unnecessary Fallback

Since VMware fails to use Vulkan, prevent it from attempting Vulkan rendering.

Steps:

Add this line to the VMX file:

ini
mks.vk.allowUnsupportedDevices = "FALSE"

Save and restart the VM.

✅ Effect: Prevents VMware from attempting Vulkan, reducing rendering errors.

🟢 Fix 3: Disable Background Rendering for Minimized Windows

Since mksSandbox.exe leaks RAM when the window is minimized, force it to stop rendering hidden windows.

Steps:

Add these lines to the VMX file:

ini
svga.noScreenBuffering = "TRUE"mks.noScreenBuffering = "TRUE"

Save and restart VMware Workstation.

✅ Effect: Stops unnecessary rendering when the VM is minimized.

🟢 Fix 4: Reduce VRAM Allocation to Prevent Memory Overflows

Currently, VMware is allocating too much VRAM but not managing it properly.

Steps:

Modify the VRAM allocation in the VMX file:

ini
svga.vramSize = "2097152"  # 2GB VRAM instead of 4GB

Save the file and restart VMware Workstation.

✅ Effect: Prevents excessive VRAM allocation that leads to memory leaks.

🟢 Fix 5: Use Remote Desktop Instead of VMware Console (Alternative)

If Fixes 1-4 don't work, try running the VM via Remote Desktop (mstsc.exe), which bypasses mksSandbox.exe completely.

Steps:

Enable Remote Desktop inside the VM:
- Open Settings → System → Remote Desktop.
- Enable "Allow Remote Desktop connections".
On your host machine, open mstsc.exe and connect to the VM.

✅ Effect: Completely eliminates mksSandbox.exe from consuming RAM.

Original Message:
Sent: Feb 28, 2025 11:06 AM
From: Michael Banack
Subject: mksSandbox.exe memory bloat

It sounds like you have a memory leak in the graphics stack somewhere, either in VMware code, or in the host graphics drivers.

Can you post a vmware.log and mksSandbox.log from one of the affected VMs when 3D is turned on?

Otherwise, most of the Workstation memory settings you're adjusting only affect Guest main memory, not the graphics memory usage.

There should be a setting in the Workstation UI under VM Settings => Display => Graphics Memory that you can adjust while the VM is fully powered off. That will control the maximum amount of graphics resources that each VM is allowed to use on your Host (although it's measured in Guest resources, which don't strictly map byte-for-byte onto Host resources). Lowering that setting should reduce the maximum amount of memory that the mksSandbox process will use on your Host during normal operation. That said, if something is leaking here that might not be enough.

I'd also recommend you try upgrading your Host's graphics drivers. Our graphics team may be able to give you more specific suggestions after we've reviewed your logs.

I'm also a little puzzled by what you describe in Trial 3... After disabling 3D graphics on a VM and doing a clean PowerOn, there shouldn't be any mksSandbox.exe processes running on your Host at all?

Original Message:
Sent: Feb 27, 2025 04:28 PM
From: Yevgeni Shirukin
Subject: mksSandbox.exe memory bloat

Hello, I'm new here.

About four weeks ago, I installed three VMware virtual machines on my host system. Everything ran smoothly with high performance-no lag, no issues.

But suddenly, I started experiencing high RAM consumption by mksSandbox.exe, even after setting multiple limits in the VMware settings and VMX file. The process keeps consuming memory until the virtual machine crashes. Once it crashes, mksSandbox.exe collapses, and the RAM is released back to the system.

I have reinstalled my OS and VMware at least 10-20 times and tested various configurations:

High and low RAM reservations
High and low GPU allocations

No matter what I do, mksSandbox.exe keeps bloating until it crashes VMware.

I've searched Google, Reddit, and even asked ChatGPT, but I haven't found a solution. This forum is my last hope-does anyone know how to fix this issue?

🔍 The Issue

VMware Workstation consumes more RAM than assigned and does not properly release it.
mksSandbox.exe (VMware's graphics process) uses excessive memory (up to 18GB).
Standby List was initially a problem, but after fixes, VMware itself was the real culprit.
Memory is overcommitted, leading to 100% usage and causing performance issues.
Killing mksSandbox.exe frees RAM but also disconnects active games inside VMs.

✅ Fixes We Tried & Results

1️⃣ Adjust VMware Workstation Global Memory Settings

✅ Changes Made:

VMware Workstation → Edit → Preferences → Memory
- Set "Reserved Memory for All Running VMs" to 48GB (instead of 56GB).
- Prevents VMware from taking excessive memory from the host.

✅ Result:

Helped reduce RAM hoarding slightly, but VMware still consumed more than allocated.

2️⃣ Edit VMX Files to Force Hard Memory Limits

✅ Changes Made:

Opened each VM's .vmx file (found in C:\Users\YourUser\Documents\Virtual Machines\VMName\).
Added the following lines:
```
sched.mem.max = "X"sched.mem.min = "X"sched.mem.prealloc = "TRUE"MemTrimRate = "0"MemBalloonDisable = "TRUE"Mem.ShareScanGHz = "0"
```
- Replace "X" with the assigned RAM amount (in MB) for the VM.
- Example: If a VM has 6GB RAM, use sched.mem.max = "6144" and sched.mem.min = "6144".

✅ Result:

Forced VMware to use only the assigned memory, preventing hidden overcommitment.

3️⃣ Disabled 3D Acceleration to Reduce mksSandbox.exe Memory Usage

✅ Changes Made:

VM Settings → Hardware → Display
Unchecked "Accelerate 3D Graphics"
Clicked OK and restarted the VM.

✅ Result:

Drastically reduced mksSandbox.exe RAM usage (from 18GB to normal levels).
No visual impact for non-GPU-intensive applications.

4️⃣ Limited VMware's Graphics Memory Usage

✅ Changes Made:

Inside each VM → Reduced display resolution to 1280x720.
Disabled "Full Screen Mode" to reduce GPU memory overhead.

✅ Result:

Helped lower GPU-related RAM usage, but mksSandbox.exe was still consuming memory unless fully disabled.

5️⃣ Cleared Standby List (Initially a Problem)

✅ Changes Made:

Installed Intelligent Standby List Cleaner (ISLC) only on the host.
Configured it to:
- Purge Standby List when Free Memory is below 16000MB.
- Clear Standby List automatically every few minutes.

✅ Result:

Initially, this freed up RAM, but after fixing Standby List hoarding, VMware was still consuming memory dynamically.

6️⃣ Checked Resource Monitor for Hidden Memory Usage

✅ What We Found:

Commit Charge was always at 100%, meaning VMware was reserving more memory than it should.
mksSandbox.exe was still the largest RAM consumer.

✅ Result:

Proved that the real issue was VMware dynamically overcommitting RAM, not just the Standby List.

7️⃣ Attempted to Release RAM Without Closing VMware

✅ Changes Made:

Tried running the following command to force Windows to release unused RAM:
```
rundll32.exe advapi32.dll,ProcessIdleTasks
```
Tried manually reducing Working Set in Resource Monitor.

❌ Result:

Did NOT fix the issue. VMware was actively consuming RAM, not just holding it in Standby.

8️⃣ Set Low Priority for mksSandbox.exe (Temporary Fix)

✅ Changes Made:

Opened Task Manager (Ctrl + Shift + Esc).
Found mksSandbox.exe → Right-click → Set Priority → Low.
Found mksSandbox.exe → Right-click → Set Affinity → Limited to fewer CPU cores.

✅ Result:

NOTHING

Thanks in advance!

6. RE: mksSandbox.exe memory bloat
Best Answer

Recommend

Yevgeni Shirukin

Posted Mar 01, 2025 03:57 AM

Fingers crosed but after adding those lines to vmx it seems that it stopped bloating ram and mkssandbox ram is being released i mean it goes up to 180 and drops to 150-160

# Force DirectX 11
mks.enableDX12Renderer = "FALSE"
mks.enableDX11Renderer = "TRUE"

# Disable Vulkan
mks.vk.allowUnsupportedDevices = "FALSE"

# Limit VRAM to Prevent Overflows
svga.vramSize = "2097152" # 2GB VRAM
# OR
# svga.vramSize = "4194304" # 4GB VRAM

# Stop VMware from Rendering Minimized Windows
svga.noScreenBuffering = "TRUE"
mks.noScreenBuffering = "TRUE"

will recheck logs after more time to figure out what was that it seems Vulkan not running properly and Directx12 failing to render minimized to tray actions while 3D acceleration is up. And all is fine after Vulkan and Dx12 disabled and forrsed Dx11

Original Message

Original Message:
Sent: Feb 28, 2025 02:30 PM
From: Michael Banack
Subject: mksSandbox.exe memory bloat

It's possible switching to DX11 might help, but otherwise the ChatGPT analysis there is pretty much completely wrong or nonsensical to me.

If you can post your logs here, our development team can take a look and see if we can offer any suggestions.

Original Message:
Sent: Feb 28, 2025 12:42 PM
From: Yevgeni Shirukin
Subject: mksSandbox.exe memory bloat

Did some chat gpt analysis on logs got his will try to to forse Directx 11

Funny part that everything worked fine for weeks but i managed to reset BIOS by clicking back of pc i did bios update again did same setup clean os reinstal clean vm reinstal and this thing started to happen and keeps happening after multiple vm os reisntals :)

🛑 Major Issues Identified

1️⃣ VMware is Attempting to Use Vulkan but Failing

From mksSandbox-2.log:

pgsql
2025-02-28T06:42:47.319Z In(05) mks  Vulkan Renderer: No supported Vulkan device/driver found (See mks.vk.allowUnsupportedDevices or mks.vk.forceDevice configuration options).

VMware tries to initialize Vulkan but fails, likely causing mksSandbox.exe to fall back to DirectX 12.
When fallback happens, memory leaks can occur due to inefficient memory cleanup.

2️⃣ DirectX 12 is Being Used, but VRAM Management is Unstable

From mksSandbox-2.log:

yaml
2025-02-28T06:42:47.568Z In(05) mks  DX12Module: Selected adapter:2025-02-28T06:42:47.568Z In(05) mks  DX12Module:  NVIDIA GeForce RTX 4090

DirectX 12 is being selected for rendering, but VMware isn't properly managing VRAM allocations.
This can cause mksSandbox.exe to keep allocating VRAM without freeing it, leading to memory leaks.

3️⃣ mksSandbox.exe is Attempting to Handle a Minimized Window Incorrectly

The fact that mksSandbox.exe doesn't leak RAM when the window is not minimized suggests a rendering bug when handling hidden windows.
VMware might be trying to render frames even when the window is minimized, leading to VRAM not being released properly.

✅ Fixes to Stop mksSandbox.exe From Leaking RAM

🟢 Fix 1: Force DirectX 11 Instead of DirectX 12

Since Vulkan fails and DirectX 12 has memory management issues, forcing DirectX 11 can stabilize memory usage.

Steps:

Open the VMX file (YourVM.vmx) in a text editor.

Add the following lines:

ini
mks.enableDX12Renderer = "FALSE"mks.enableDX11Renderer = "TRUE"

Save the file and restart VMware Workstation.

✅ Effect: Forces DirectX 11, which has better memory management than DX12 in VMware.

🟢 Fix 2: Disable Vulkan to Prevent Unnecessary Fallback

Since VMware fails to use Vulkan, prevent it from attempting Vulkan rendering.

Steps:

Add this line to the VMX file:

ini
mks.vk.allowUnsupportedDevices = "FALSE"

Save and restart the VM.

✅ Effect: Prevents VMware from attempting Vulkan, reducing rendering errors.

🟢 Fix 3: Disable Background Rendering for Minimized Windows

Since mksSandbox.exe leaks RAM when the window is minimized, force it to stop rendering hidden windows.

Steps:

Add these lines to the VMX file:

ini
svga.noScreenBuffering = "TRUE"mks.noScreenBuffering = "TRUE"

Save and restart VMware Workstation.

✅ Effect: Stops unnecessary rendering when the VM is minimized.

🟢 Fix 4: Reduce VRAM Allocation to Prevent Memory Overflows

Currently, VMware is allocating too much VRAM but not managing it properly.

Steps:

Modify the VRAM allocation in the VMX file:

ini
svga.vramSize = "2097152"  # 2GB VRAM instead of 4GB

Save the file and restart VMware Workstation.

✅ Effect: Prevents excessive VRAM allocation that leads to memory leaks.

🟢 Fix 5: Use Remote Desktop Instead of VMware Console (Alternative)

If Fixes 1-4 don't work, try running the VM via Remote Desktop (mstsc.exe), which bypasses mksSandbox.exe completely.

Steps:

Enable Remote Desktop inside the VM:
- Open Settings → System → Remote Desktop.
- Enable "Allow Remote Desktop connections".
On your host machine, open mstsc.exe and connect to the VM.