Windows Stop Code 0x0000003F: NO_MORE_SYSTEM_PTES

Quick Answer

NO_MORE_SYSTEM_PTES (0x0000003F) occurs when Windows cannot satisfy a system page table entry allocation. Microsoft explains that fragmentation commonly leaves no sufficiently large contiguous block for a driver’s request, even when free entries remain. Its documentation identifies video drivers and some backup programs as examples of components that make large kernel-memory allocations. Microsoft Learn

For recurring crashes, review recent driver and backup-software changes, preserve a crash dump, and investigate the allocation with WinDbg. The stop code alone does not justify replacing RAM or applying a registry adjustment.

What Are System PTEs?

A page table entry, or PTE, is part of the information Windows uses to map virtual memory to physical memory. System PTEs support mappings in system address space, including mappings used by drivers. They are a memory-management resource, rather than ordinary files or disk space. Microsoft Learn

For diagnosis, the distribution of available entries matters. WinDbg can report both the total number of free PTEs and the largest free block. A large total does not necessarily mean that one sufficiently large block is available. Microsoft Learn

Bug-Check Parameters

These values describe the failed allocation and resource state. Microsoft Learn

Before You Begin

• Save your work and back up important files.
• Record the crash time and the activity underway, particularly a backup, restore, or other intensive operation.
• Note recent driver installations and software updates.
• Have administrator access available for driver changes.
• Before modifying backup software, confirm that a usable backup and recovery method remain available.
• Keep the BitLocker recovery key available if Windows recovery options are needed. support.microsoft.com

The interface steps below use Windows 11 terminology. Older versions can have different menus.

Recommended Troubleshooting

1. Identify a Repeatable Pattern

Record whether the crash occurs during the same workload or after a similar period of uptime.

If a scheduled job coincides with the crash, compare its logs and start time with the Windows failure. This provides a lead for investigation; timing alone does not establish the cause.

2. Review a Relevant Driver Change

If the issue began after a driver update:

1. Right-click Start and select Device Manager.
2. Open the suspected device’s Properties.
3. Select Driver > Roll Back Driver, when available.
4. Follow the prompts and restart if requested.

If rollback is unavailable or unsuitable, obtain a compatible driver through Windows Update or the device manufacturer’s official website. Change one suspected component at a time. support.microsoft.com

If the change introduces a new problem, restore the previous driver where possible or reinstall the appropriate manufacturer driver.

3. Review Recently Changed Backup or Disk-Intensive Software

Check the vendor’s compatibility requirements and available fixes for the installed version.

If evidence points to the product, use its supported update, rollback, or removal procedure. Coordinate any interruption to scheduled backups with the administrator responsible for recovery.

A temporary scheduling change may help test a suspected workload, but it should not leave the system without a backup plan.

4. Apply Applicable Windows Updates

Open Settings > Windows Update > Check for updates and install applicable updates. Restart when required.

This is part of Microsoft’s general stop-error troubleshooting; it is not a guaranteed repair for this particular allocation failure. support.microsoft.com

If Windows Cannot Start Normally

1. Access the Windows Recovery Environment.
2. Select Troubleshoot > Advanced options > Startup Settings > Restart.
3. Press 4 or F4 to start Safe Mode.
4. Investigate or reverse the suspected recent change.
5. Restart normally to test.

Safe Mode loads a limited set of drivers and services. An encrypted device may require its BitLocker recovery key. support.microsoft.com

Advanced Troubleshooting with WinDbg

1. Preserve the Crash Dump

Default dump locations include:

A dump exists only if Windows was configured and able to write it. A small dump can omit memory needed for detailed analysis; support personnel may request a kernel dump. learn.microsoft.com

2. Examine the Allocation

Open the dump in WinDbg with appropriate symbols and run:

!analyze -v

Then inspect free system PTEs:

!sysptes 1

The second command displays free-PTE information. Review the available blocks, total free entries, and largest free block alongside the failed request.

For mappings of locked pages, an experienced debugger can also use:

!sysptes 4

This requests detailed information about system PTEs allocated to those mappings. Available output depends on the captured data and target system. These commands examine the dump; they do not repair Windows. learn.microsoft.com

3. Treat Registry Guidance as a Specialist Procedure

Microsoft’s bug-check article includes PTE registry tuning and TrackPtes diagnostics. Those instructions require validation against the affected Windows version and architecture; they should not be treated as a universal configuration for current systems. Microsoft Learn

Have Microsoft Support or the relevant vendor specify any required change, its expected effect, and the rollback procedure. Begin with dump analysis before altering memory-management settings.

How to Verify the Fix

After a targeted correction:

1. Restart Windows normally.
2. Run the workload that previously preceded the crash.
3. Confirm that affected devices and applications function correctly.
4. Confirm that scheduled backups complete and recovery remains available.
5. Monitor for at least the period in which the original failure typically appeared.

If the crash returns, preserve the new dump and compare it with the earlier failure before making another change.

Frequently Asked Questions

Does this mean the computer has run out of physical RAM?

The stop code describes a system-PTE allocation problem. It does not, by itself, establish that the computer needs more RAM.

Can free PTEs remain when this crash happens?

Yes. Fragmentation can prevent a sufficiently large contiguous allocation despite free entries remaining. Microsoft Learn

Will increasing the page file fix it?

The code alone does not justify changing the page-file size. Determine the failed allocation and responsible component first.

Does “fragmentation” mean I should defragment the disk?

No. Here it refers to the availability of system PTE blocks. Disk defragmentation does not address that allocation structure.

Should I immediately uninstall backup software?

Use the crash timing, product logs, and dump findings to decide. Any removal should follow the vendor’s procedure and preserve an effective backup and recovery plan.

Conclusion

For recurring NO_MORE_SYSTEM_PTES crashes, investigate the failed allocation and recent changes to drivers or intensive workloads. WinDbg’s PTE information can help distinguish the total available resource from the size of the blocks available. Apply a targeted correction and verify it under the original workload.

Sources

• Microsoft Learn — Bug Check 0x3F: NO_MORE_SYSTEM_PTES.
• Microsoft Learn — !sysptes.
• Microsoft Learn — Stop code error or bug check troubleshooting.
• Microsoft Learn — Small Memory Dump.
• Microsoft Support — Update drivers through Device Manager in Windows.
• Microsoft Support — Windows startup settings.
• Microsoft Support — Troubleshooting Windows unexpected restarts and stop code errors.
• Microsoft Sysinternals — Sysinternals Newsletter, Volume 2, Number 3, historical background on system PTE mappings.