Windows 11 Using 100% RAM and Running Slow? Try This Fix

Quick Answer

If a Windows 11 computer uses 98–100% of its RAM while idle and Task Manager does not show a process responsible for the usage, investigate kernel memory, driver allocations, and recently installed Windows updates. An unusually large nonpaged pool or paged pool can indicate a kernel or driver memory-allocation problem.

In one documented troubleshooting case involving a laptop with an Intel Core Ultra 9 processor and 32 GB of RAM, PoolMon showed exceptionally large memory allocations associated with storage and file-system I/O-related tags. The user then uninstalled three recent Windows update entries and restarted the computer. Idle RAM usage reportedly dropped from 98–100% to approximately 21–30%.

The update history screenshots included KB5127648 and KB5121794, with KB5121794 appearing in two entries. This result makes recent updates a reasonable troubleshooting focus, but it does not prove that a particular KB caused the memory problem. The article below explains how to identify the actual installed updates, test a suspected update safely, and verify whether the improvement lasts.

Symptoms and Troubleshooting Scenario

The reported computer exhibited the following symptoms:

• Windows 11 showed approximately 98–100% RAM usage while idle.
• The laptop had 32 GB of RAM and an Intel Core Ultra 9 processor.
• Task Manager's Processes tab did not explain the total memory usage.
• Available physical memory fell to a very low level.
• The nonpaged pool was approximately 13.7 GB, the paged pool approximately 5.4 GB, and committed memory approximately 39 GB.
• PoolMon showed large allocations associated with storage and file-system I/O-related tags.
• After three recent Windows update entries were uninstalled and the computer restarted, idle RAM usage reportedly returned to approximately 21–30%.

This is a useful real-world troubleshooting observation. However, it does not establish whether the root cause was a Windows update, a driver interaction, a third-party file-system filter, or another system component affected by the update changes.

Windows Update KB Numbers Identified in the Screenshots

The update-removal dialogs supplied with this troubleshooting case showed the following identifiers and descriptions.

Microsoft's documentation identifies KB5127648 as the October 13, 2026 cumulative security update for Windows 11 versions 24H2, 25H2, and 26H2. Microsoft's documentation identifies KB5121794 as the feature enablement package for Windows 11 version 26H2. Neither source establishes that these updates caused the RAM issue described in this case.

Important: The screenshots show three update-removal dialogs, but only two distinct KB identifiers can be read from the supplied images. The identifier of the third distinct update, if there was one, is not established by those screenshots. Do not invent or guess the missing KB number. Readers should use their own Update History to identify all entries they removed.

Why Check Updates Installed in the Previous 2–3 Days?

If the computer was working normally and then began using nearly all available RAM shortly after Windows installed updates, the installation timeline is a valuable diagnostic clue.

Checking updates installed in the previous two or three days can help establish whether the symptom appeared immediately after a system change. This is a troubleshooting method, not proof that an update is defective. Windows updates may change operating-system components, drivers, security behavior, or compatibility with installed software, and the actual cause can involve an interaction between components.

Use the following approach:

1. Identify when the high memory usage first appeared.
2. Check Windows Update history for updates installed shortly before that time.
3. Record each update's KB number, description, and installation date.
4. Compare those dates with driver updates, security-software updates, and other software changes.
5. Check Microsoft's release information for the applicable Windows version and KB numbers.
6. If the evidence points to a recent update and Windows permits its removal, consider a controlled rollback after reviewing the risks.

Do not assume that the newest update is necessarily the cause. The problem may have started with an earlier update or with software that became incompatible after an update was installed.

Step 1: Identify Your Windows Version and Build

Before investigating a particular KB number, identify the exact Windows version and OS build. Windows 11 versions can share update packages or servicing components, so version information helps ensure that you consult the appropriate Microsoft documentation.

1. Press Windows + R.
2. Type winver and press Enter.
3. Record the Windows version and OS build displayed in the dialog.
4. Keep this information with the update KB numbers and installation dates.

Do not assume that every Windows 11 computer is running the same version or build as the computer in this case.

Step 2: Check Windows Update History for the Last 2–3 Days

Windows Update history is the best starting point for identifying recently installed updates.

1. Open Settings.
2. Select Windows Update.
3. Open Update history.
4. Review the sections for quality updates, driver updates, definition updates, and other relevant update categories.
5. Look for entries installed during the two or three days before the problem began.
6. Record the KB number, description, and installation date of each relevant entry.

Not every history entry is a separate cumulative Windows update. Feature enablement packages, servicing stack updates, .NET updates, driver updates, and other components can appear as separate entries. Record their full descriptions rather than treating every entry as the same type of update.

Optional: List installed Windows hotfix entries in PowerShell

Open PowerShell and run the following read-only command:

Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object HotFixID, Description, InstalledOn |
Format-Table -AutoSize

This command lists hotfix records exposed through the Windows hotfix interface. It is useful as a supplementary check, but it may not show every type of update, including every enablement package or other servicing component. Use Settings > Windows Update > Update history as the primary reference for the complete visible update history.

Step 3: Check the Latest KB Numbers Against Microsoft's Documentation

Once you have recorded the actual KB identifiers, open the relevant Microsoft support article or Windows release-health page. Confirm that the documentation applies to your Windows version and build.

• Microsoft Support: KB5127648, October 13, 2026 Windows 11 security update
• Microsoft Support: KB5121794, Windows 11 version 26H2 enablement package
• Microsoft Learn: Windows release health and known issues

Look for known issues, compatibility notes, revised documentation, and any later update that resolves a reported problem. A lack of a matching issue in Microsoft's documentation does not prove that an update cannot be involved in an individual computer's problem.

For the updates in this case, the available evidence supports identifying the KB numbers and checking their documentation. It does not support claiming that Microsoft has confirmed either KB5127648 or KB5121794 as the cause of this particular memory issue.

Step 4: Confirm Whether the Problem Is Ordinary Application Usage or Kernel Memory

Open Task Manager with Ctrl + Shift + Esc, select Performance, and then select Memory. Record the total memory, in-use memory, available memory, committed memory, and pool values shown.

If the Processes tab does not explain the overall memory usage, investigate the system memory breakdown before terminating applications or changing services.

In this case, the nonpaged pool was reported at approximately 13.7 GB, the paged pool at approximately 5.4 GB, and committed memory near 39 GB. These unusually high values justified investigating kernel and driver allocations. They did not, by themselves, identify the responsible component.

Step 5: Use PoolMon to Investigate Kernel Memory Allocations

PoolMon is a Windows Driver Kit utility that groups kernel pool allocations by memory tag. It can help identify which allocation categories account for a large amount of memory.

Run PoolMon

In the investigated system, PoolMon was installed at the following path:

C:\Program Files (x86)\Windows Kits\10\Tools\10.0.28000.0\x64\poolmon.exe

The tag database was located at:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\triage\pooltag.txt

These paths are specific to that installation. Your installation directory and Windows Kits version may differ.

Open PowerShell as an administrator and run the following command, adjusting the paths if necessary:

& "C:\Program Files (x86)\Windows Kits\10\Tools\10.0.28000.0\x64\poolmon.exe" /p /b /g "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\triage\pooltag.txt"

The command opens PoolMon, requests a nonpaged-pool view, sorts by bytes, and provides a tag database for descriptions where available.

Interpret the largest allocation tags

The initial results from this case included the following approximate allocations:

The four tags accounted for approximately 8.7 GiB. This pointed the investigation toward storage and file-system I/O, but tag descriptions do not prove that a particular driver is defective. A tag can be shared or may not identify the component responsible for the underlying allocation.

For a suspected memory leak, record the largest tag values, leave the computer idle for several minutes, and compare the values again. A tag that continues to grow without a corresponding workload deserves further investigation.

Step 6: Inspect File-System Filters and Drivers Without Disabling Them

File-system filter drivers can be installed by antivirus products, backup software, encryption tools, synchronization utilities, and application-control software. Storage-controller drivers can also participate in disk I/O.

The following command lists registered file-system filters:

fltmc filters

In this case, the output included sascan and SAAppCtl. The service configuration showed that sascan.sys belonged to the Anti-Virus filter group and saappctl.sys belonged to the Content Screener filter group.

These entries were worth investigating, but the troubleshooting evidence did not prove that either driver caused the memory usage. Their publishers and associated products should be identified before any change is made.

Do not manually disable boot-start storage or file-system filter drivers as an experiment. Such changes can affect booting, disk access, or security protection. If a particular vendor's software is identified as a likely cause, prefer its supported update, repair, or removal procedure.

Step 7: Consider a Controlled Rollback of a Recent Update

If the high memory usage began shortly after a specific update and other evidence supports a connection, removing that update may help determine whether the problem is related to the updated environment.

Before uninstalling an update:

• Record the exact KB number and installation date.
• Check Microsoft's documentation for known issues and applicable workarounds.
• Save your work and back up important data.
• Consider whether removing a security update would leave the computer exposed to vulnerabilities.
• Confirm that the update is removable through Windows' supported interface.

Uninstall an update through Settings

1. Open Settings.
2. Go to Windows Update and open Update history.
3. Select Uninstall updates.
4. Locate the specific update by its KB number or description.
5. Confirm the removal if you have decided that rollback is appropriate.
6. Restart the computer if prompted.
7. Allow Windows to finish starting before measuring memory usage again.

Not all updates can be uninstalled through Settings. The available options depend on the update type and Windows version.

Step 8: Verify the Result After Restarting

A lower memory reading after reboot is encouraging, but the result should be checked over time.

1. Allow startup tasks and background services to settle.
2. Open Task Manager and record memory usage, available memory, committed memory, and pool values.
3. Leave the computer idle for several minutes and see whether usage remains stable.
4. If the nonpaged pool was previously very large, run PoolMon again and compare the same tags.
5. Check memory usage again after normal computer use and another restart.
6. Review Update History to determine which updates remain installed and whether Windows installed replacements.

In this troubleshooting case, reported idle memory usage dropped to approximately 21–30% after the update-removal operation and restart. That was a substantial improvement from the earlier 98–100% usage. Long-term stability and repeatable measurements would provide stronger evidence that the symptom has been resolved.

What to Do If the Problem Returns

If RAM usage rises to 98–100% again, gather fresh evidence before removing more updates or changing drivers.

• Record the Windows version and OS build using winver.
• Record the KB numbers and dates of recent updates.
• Check Task Manager's memory breakdown.
• Run PoolMon and identify the tags using the most memory.
• Compare the same tag values over time to determine whether allocations are growing.
• Identify relevant drivers or third-party software before making changes.
• Check the applicable Microsoft Windows release-health page for confirmed issues and mitigations.

If the evidence suggests a specific update is involved, consult Microsoft's supported rollback or recovery instructions. For broader Windows recovery operations, back up important data and understand the effect of the selected procedure before proceeding.

Frequently Asked Questions

Should I check Windows updates installed during the last 2–3 days?

Yes, if the problem appeared recently. Compare the date when memory usage became abnormal with the installation dates of quality updates, feature enablement packages, driver updates, and relevant software changes. The timing is a useful clue, not proof of causation.

Which KB numbers were visible in this troubleshooting case?

The screenshots show KB5127648 and KB5121794. KB5121794 appears in two entries, one of which includes the text “2026.07 D.” The available screenshots do not establish a third distinct KB identifier. Use your own Update History to identify all entries that were actually removed.

Does KB5127648 definitely cause 100% RAM usage?

No. The available evidence does not establish that KB5127648 caused the memory issue. The improvement after multiple update entries were removed makes the update timeline relevant, but the precise cause remains unconfirmed.

Is KB5121794 a regular monthly security update?

No. Microsoft documents KB5121794 as the enablement package for Windows 11 version 26H2. Its purpose differs from a normal monthly cumulative security update.

Why can Task Manager show low process memory while overall RAM usage is high?

Overall physical memory usage includes kernel allocations and other system memory that may not be obvious from the Processes tab. Check the Performance > Memory breakdown and investigate unusually large pool values when application usage does not explain the total.

Does a large nonpaged pool prove a driver memory leak?

No. It is a strong reason to investigate kernel allocations when the value is unusually large or grows continuously. PoolMon and additional driver diagnostics may help identify the responsible component, but the measurement alone does not prove the exact cause.

Is it safe to uninstall Windows security updates?

Removing a security update can reduce protection. Use the procedure only when appropriate, review Microsoft's guidance, and restore a corrected or replacement update when one is available.

Is 21–30% idle RAM usage normal?

It can be reasonable, depending on background services, drivers, security software, cached data, and other system activity. A stable reading with adequate available memory is generally more informative than a fixed percentage.

Conclusion

When Windows 11 uses nearly all physical RAM while idle and Task Manager does not explain the usage, check the memory breakdown, investigate unusually large kernel pool allocations, and correlate the start of the problem with recent system changes.

In this case, PoolMon showed unusually large storage and file-system I/O-related allocations. After three recent update entries were uninstalled and the computer restarted, reported idle RAM usage fell from 98–100% to approximately 21–30%. The screenshots identify KB5127648 and KB5121794, with KB5121794 appearing twice. They do not establish three distinct KB identifiers or prove that a specific update caused the issue.

For a reliable diagnosis, record the exact update history, compare memory measurements before and after changes, check Microsoft's release information, and avoid disabling security or storage drivers without evidence. If rollback improves the system, treat that as a diagnostic clue and look for a supported, secure update path rather than permanently leaving important security updates uninstalled.

Sources

• Microsoft Support: KB5127648, October 13, 2026 Windows 11 security update
• Microsoft Support: KB5121794, Windows 11 version 26H2 enablement package
• Microsoft Learn: Windows release health
• Microsoft Support: How to uninstall a Windows update
• Microsoft Learn: PoolMon