Skip to main content

Windows memory stress

Last updated on

Windows memory stress is a Windows chaos fault that consumes MEMORY_CONSUMPTION MB (or MEMORY_PERCENTAGE percent of total RAM when MEMORY_CONSUMPTION=0) on the target Windows VM for DURATION, then releases the memory. The fault runs through the Windows chaos agent installed as a service on the target VM.

Use this fault to test how a workload on a Windows VM behaves when memory headroom shrinks: whether the OS swaps gracefully, whether GC-heavy applications (.NET) pause, and whether monitoring detects the saturation within the alerting SLA.

Run your first experiment

If you have not configured the chaos infrastructure yet, go to Quickstart to install the chaos infrastructure and run an experiment end to end.

Use cases​

  • Memory pressure on a Windows VM: When RAM utilization climbs, does the workload degrade gracefully?
  • .NET GC behavior: Does the GC pause for an unacceptable duration under pressure?
  • Page-file growth: Does the workload survive when Windows starts using the page file aggressively?

Prerequisites​

Supported environments​

PlatformSupport status
Windows Server VMs with the Windows chaos agent installedSupported
Linux VMsNot supported (use VMware memory hog or Linux memory stress)

Permissions required​

This fault is classified as Basic. The chaos agent must be installed with administrator privileges; the fault itself can run as a non-administrator user.

Fault tunables​

Chaos parameters

TunableDescriptionDefault
DURATIONTotal duration of the fault as a Go duration string (for example 30s, 5m).30s
MEMORY_CONSUMPTIONAmount of memory to consume in MB. Set to 0 to use MEMORY_PERCENTAGE instead.0
MEMORY_PERCENTAGEPercentage of total RAM to consume (used when MEMORY_CONSUMPTION=0).50
MODEtouch (writes to allocated pages) or commit (allocates without writing). touch exerts real pressure; commit is gentler.touch
MEMORY_STEP_IN_MBMemory allocated per step in MB. 0 means a single allocation.0
PACEDelay in seconds between allocation steps. 0 means as fast as possible.0
VERBOSITYVerbosity of fault logs: low, medium, or high.low
RAMP_TIMEWait period in seconds before and after the fault.0

Tunables that apply to every fault are documented in common tunables for all faults.

Fault execution in brief​

The Windows chaos agent on the target VM allocates MEMORY_CONSUMPTION MB (or MEMORY_PERCENTAGE percent of RAM) using MODE semantics in MEMORY_STEP_IN_MB chunks every PACE seconds, holds the memory for DURATION, then releases it.

Expected behavior during fault execution​

  • Available memory on the target VM drops for the duration.
  • Workloads with high memory pressure may hit GC pauses, page-file growth, or out-of-memory errors.
  • Performance Monitor Memory\Available MBytes reflects the drop.
  • After the duration ends, memory is released and returns to baseline.
When the fault ends

The chaos agent releases the allocated memory. Available memory returns to baseline within seconds.

Signals to watch​

Verify the fault execution effect​

  1. Open Task Manager → Performance → Memory.

    "In use" should rise during the chaos window.

  2. Run Get-Counter '\Memory\Available MBytes' -Continuous in PowerShell.

    Available MB should drop during the chaos window.

Recovery and cleanup​

  • End of duration: The chaos agent releases the memory.
  • Abort: Stopping the experiment also releases the memory.
  • Manual recovery: Open Task Manager and end the chaos process if it survived.

Limitations​

  • OOM risk: Setting MEMORY_PERCENTAGE close to 100 may push critical processes out of memory or trigger page-file thrashing.
  • touch vs commit: commit does not exert real pressure on most Windows configurations; use touch to verify behavior under genuine memory pressure.

Troubleshooting​

Windows memory stress has no observable effect in Harness Chaos Engineering

If MODE=commit and Windows is not committed-memory constrained, the fault may not produce visible pressure. Switch to MODE=touch.

VM became unresponsive during memory stress

MEMORY_PERCENTAGE was likely too high. Reduce it (start with 30-50%) and ensure the page file is sized appropriately. Reboot the VM through your cloud or hypervisor console to recover.