Diagnose low-memory warnings without disabling the Windows page file

Online tweaks often recommend disabling pagefile.sys to make Windows 11 faster. Microsoft explains that page-file sizing supports system commit and crash dumps; a poorly chosen limit can trigger allocation errors even with apparently free RAM. First determine whether the warning comes from one leaky app, genuinely insufficient memory, a nearly full system drive or a custom page-file setting. A measured fix is safer than a fixed formula copied from another computer.

Before you start​

Save work, back up important files and record the exact warning and apps open at that time. Check C: free space and installed RAM. In Task Manager's Performance > Memory view, note usage and committed memory under the failing workload. Record the current Virtual memory setting before changing it. On a managed PC, follow IT policy.

Do it step by step​

1. Reproduce the warning with the ordinary workload and sort Task Manager's Processes by Memory. Observe whether one process grows continuously over time.
2. Inspect Performance > Memory and compare Commit values with the limit, not just physical RAM usage. A high cache reading alone is not a shortage.
3. Open Advanced system settings > Performance > Advanced > Virtual memory and check whether Automatically manage paging file size is enabled. Record any custom limit.
4. If a restrictive custom setting exists, use the supported system-managed setting after checking disk space, then restart and repeat the workload.
5. Update or repair a leaky app if it dominates committed memory. Close excessive tabs or add supported RAM when the workload routinely exceeds capacity.
6. Retest the exact scenario and confirm no allocation warning or crash. Keep sufficient disk space for Windows updates and crash dumps; do not move the only page file blindly.

Check the result​

The warning disappears in a repeatable test or a specific app's abnormal memory growth is documented for its vendor, with a page file that supports the machine's workload.

If something goes wrong​

If errors persist, inspect app logs and storage health. If a crash dump is absent, verify dump configuration and boot-volume page-file requirements. Avoid changing several registry and page-file settings at once.

Know the limit​

There is no universal ideal page-file size. Automatic management is a sound starting point for most users; application commit needs and crash-dump requirements can change the needed size. Microsoft page-file sizing Microsoft performance guidance

Decision checkpoint​

Memory counters require context. A busy browser can reserve memory without actively using all of it, while commit near the limit can cause failures before physical RAM looks completely full. An app crash after hours may indicate a leak; a warning immediately at launch may be a sizing or compatibility issue. Keep a timestamped observation from the same workload. If you need diagnostic dumps for a crash, preserve the page-file configuration that allows Windows to write them.

Aftercare​

Review commit and disk free space after the fix. If the same program's usage keeps climbing, send the vendor a reproducible memory observation instead of repeatedly increasing the page file. Preserve a functioning crash-dump configuration.