Windows Resource Exhaustion (Event ID 2004) across multiple PCs causing application crashes

1. Yes. The described behavior is consistent with a system-wide virtual memory/commit limit problem rather than a single obvious leaking process. Event ID 2004 is raised when the system detects a low virtual memory (commit) condition and logs the top consumers at that moment. Those processes are often “victims” or just the largest visible consumers, not necessarily the root cause. The key metric to focus on is total committed virtual memory versus the system commit limit, not just individual process working sets. In Task Manager, the default “Memory” column shows working set (physical RAM in use). For diagnosing this issue, the important metric is Commit size (per-process) and total committed bytes versus commit limit at the system level. High commit usage across the system, even if spread across many processes, will trigger Event ID 2004 and can cause application failures such as 0xc0000005 when allocations fail.
2. Yes. Event ID 2004 is directly related to virtual memory/commit pressure, which depends on:
   • Physical RAM
   • Page file configuration (size and whether it is enabled)
   If the page file is too small or disabled, the commit limit (RAM + page file) can be reached more easily, causing low virtual memory conditions and Event ID 2004. This is true even if no single process appears to be “leaking” excessively. Ensuring an adequately sized page file (or allowing Windows to manage it) is a key part of mitigating commit-limit exhaustion.
3. Recommended approach to identify the root cause: a. Focus on commit usage, not just working set
   • In Task Manager, add the Commit size column and monitor which processes have large or steadily increasing commit values over time.
   • Use tools designed for virtual memory analysis:
     • VMMap to classify allocations in a suspect process and determine the type of memory growth (heap, stack, private, mapped, etc.).
   b. System-wide performance data collection
   • Use Perfmon (Performance Monitor) to collect counters related to memory and commit pressure. Perfmon is specifically recommended for resource troubleshooting and can be collected remotely, scheduled, and run for long durations. This helps correlate commit growth with time and workload.
   • On Azure VMs, PerfInsights uses Perfmon as an extra log source for slow/advanced scenarios, but the same principle applies on-prem: collect and analyze Perfmon logs to see how committed bytes approach the commit limit.
   c. Deep-dive with Windows Performance Toolkit
   • Use Windows Performance Recorder (WPR) to capture a trace during the period when commit usage is rising.
   • Analyze the trace with Windows Performance Analyzer (WPA) to see which processes and allocation stacks are driving commit growth. This is the recommended method for detailed memory-leak investigations.
   d. Per-process leak classification
   • Once a suspect process is identified (for example, one whose commit size grows steadily and does not stabilize), attach VMMap to that process to determine the leak type.
   • For first-party processes, public symbols can be used with WPA/WinDbg to identify specific functions responsible for allocations.
   • For third-party processes, the allocation stack will still show the responsible module; the vendor can then be engaged with that data.
4. Yes. There are known scenarios where system-level or driver-level issues cause high memory usage and application crashes:
   • On Windows Server 2008, Microsoft documented a problem where applications encounter unexpected high memory usage and crash due to underlying OS components (for example, ntdll, ntoskrnl, csrsrv) requiring an update. This demonstrates that system-level defects can cause global memory pressure and application failures.
   • In general guidance for high memory issues on Windows (including Azure VMs), system processes such as WmiPrvSE or Svchost, as well as platform agents (RDAgent, OMS, security extensions), are called out as potential drivers of memory pressure. The recommendation is to ensure the OS is on the latest cumulative updates and that such components are on their latest versions.
   • When Event ID 2004 is logged, it is explicitly indicating a low virtual memory condition at the system level. If no single user-mode process is clearly leaking, the root cause can be:
     • A kernel-mode or driver leak (for example, nonpaged/paged pool growth)
     • A system service or agent with a memory leak
     • OS-level issues addressed by cumulative updates or hotfixes
   In such cases, the same methodology applies: collect detailed traces (WPR/WPA), examine kernel and pool usage, and ensure the system is fully patched. If the leak is in a Microsoft or Azure agent component, escalation to support is recommended after confirming latest builds are in use.

Summary of practical steps:

1. Verify page file is enabled and sized appropriately (or set to system-managed) to avoid premature commit-limit exhaustion.
2. Monitor Commit size per process and total committed bytes versus commit limit.
3. Use Perfmon for long-term collection of memory/commit counters.
4. Capture WPR traces and analyze with WPA to identify which processes and modules are driving commit growth.
5. For any suspect third-party process or driver, engage the vendor with allocation-stack evidence.
6. Ensure OS and system components are on the latest cumulative updates, as some high-memory/crash scenarios are known and fixed by updates.

References:

• Application or service memory leaks troubleshooting guidance
• Troubleshoot high memory issues on Azure Windows virtual machines
• Applications encounter unexpected high memory usage and crash in Windows Server 2008