VMware Workstation

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?

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

It seems that setsvga.vramSizetotally doesn't work - it will auto reset to default when vm launch. 

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

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"

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


KopijuotiRedaguoti


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


KopijuotiRedaguoti


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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   
   ini
   
   
   KopijuotiRedaguoti
   
   
   mks.vk.allowUnsupportedDevices = "FALSE"
   
   

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

1. Enable Remote Desktop inside the VM:
   • Open Settings → System → Remote Desktop.
   • Enable "Allow Remote Desktop connections".
2. 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?

It is highly disappointing to see numerous reports in forums regarding issues with VMware Workstation Pro17.6.3 Windows 11, particularly concerning 3D acceleration on hosts running Windows 11 Pro, Windows 10 Pro, and the latest Windows updates. Unfortunately, there is still no hotfix or update from Broadcom to resolve this matter.

I have made several changes to the VMX configuration, but none have yielded positive results.

The issue: When using VMware with 3D acceleration, the host GPU is not utilized in the m.Sandbox, causing problems with DirectX 12, Vulkan, and a slowdown in VMware graphics. Rendering issues and other complications necessitate disabling 3D acceleration.

Additionally, issue significantly increases RAM usage, which is consumed by the Sandbox.

We respectfully request a resolution for this issue or the release of update 17.6.4. Thank you.

this solution DONT work for me.

Original Message:
Sent: Apr 17, 2025 05:49 AM
From: Aa Aa
Subject: mksSandbox.exe memory bloat

It seems that setsvga.vramSizetotally doesn't work - it will auto reset to default when vm launch. 

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

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"

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

1. Enable Remote Desktop inside the VM:
   • Open Settings → System → Remote Desktop.
   • Enable "Allow Remote Desktop connections".
2. 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?

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

Where did you find these two configurations? Is there documentation or any other discussion about it?

```

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

```

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

I don't believe those are real configuration settings in any current VMware product.

Where did you find these two configurations? Is there documentation or any other discussion about it?

```

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

```

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"

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.

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
KopijuotiRedaguoti
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
KopijuotiRedaguoti
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:

1. Open the VMX file (YourVM.vmx) in a text editor.
2. Add the following lines:

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

3. 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:

1. Add this line to the VMX file:

   ini
   KopijuotiRedaguoti
   mks.vk.allowUnsupportedDevices = "FALSE"

2. 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:

1. Add these lines to the VMX file:

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

2. 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:

1. Modify the VRAM allocation in the VMX file:

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

2. 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:

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

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

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?

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?

Maybe you wanna check this https://community.broadcom.com/vmware-cloud-foundation/discussion/bug-report-unnecessary-library-loading-in-vmware-workstation