Windows Stop Code CACHE_MANAGER (0x00000034): Meaning, Parameters, and Troubleshooting
Quick answer CACHE_MANAGER is Windows bug check 0x00000034. It indicates that a problem occurred in the file system’s cache manager. Microsoft identifies dep...
Quick answer
CACHE_MANAGER is Windows bug check 0x00000034. It indicates that a problem occurred in the file system’s cache manager. Microsoft identifies depletion of nonpaged pool memory as one possible cause: if that pool is exhausted, or becomes very low during indexing while another kernel driver needs it, the system can stop. This is a possible cause, not a diagnosis of every 0x34 crash. Microsoft Learn
The first bug-check parameter records source file and line information for the point where Windows issued the stop. Parameters 2–4 are reserved. To identify what happened on a particular computer, examine the crash dump and the system’s memory usage rather than treating the name CACHE_MANAGER as proof that a cache setting or disk needs changing. Microsoft Learn
What is the file system cache manager?
Windows caches file data in memory to support file-system operations. CACHE_MANAGER names the Windows component in which the problem was detected. It does not mean the user should clear a browser cache, delete temporary files, or change an application’s cache setting.
Microsoft’s 0x34 reference focuses on nonpaged pool, a category of kernel memory whose contents must remain resident in physical memory rather than being paged out. If the pool becomes unavailable when a kernel component needs an allocation, Windows may be unable to continue the operation safely. Microsoft documents pool depletion as a possible route to this bug check. Microsoft Learn
CACHE_MANAGER parameters
Microsoft defines the four parameters as follows. Microsoft Learn
| Parameter | Meaning | How to interpret it |
|---|---|---|
| 1 / Arg1 | Source file and line information | The high 16 bits identify an internal source file by number; the low 16 bits identify the source line where the bug check occurred. |
| 2 / Arg2 | Reserved | No published 0x34 meaning. |
| 3 / Arg3 | Reserved | No published 0x34 meaning. |
| 4 / Arg4 | Reserved | No published 0x34 meaning. |
For example, the first four hexadecimal digits of a full eight-digit Arg1 value represent the source-file identifier, while the last four represent the line number. This explains the format, not the identity of a publicly named source file. Arg1 is not documented as an NTSTATUS code, a memory address, or the amount of pool memory remaining. Microsoft Learn
What causes a 0x34 crash?
Microsoft specifically describes this possible sequence:
- Available nonpaged pool memory becomes very low or is depleted.
- During an indexing operation, another kernel-mode driver may also request nonpaged pool memory.
- The inability to satisfy the needed allocation can result in the CACHE_MANAGER bug check. Microsoft Learn
The article does not say that indexing is the cause of every 0x34 crash. Nor does it identify a universal driver responsible for low pool availability. Investigation needs to establish whether pool pressure was present and, if so, what consumed the pool.
A high allocation count under a pool tag may be a clue. It could reflect expected workload or a leak; the key is whether usage grows abnormally and fails to return when the work finishes. Microsoft documents PoolMon as a tool for viewing allocations by tag and for investigating kernel-mode pool leaks. Microsoft Learn
Troubleshooting for a Windows PC
1. Record the crash details
Note the exact stop code 0x00000034, the time, whether it repeats, and what the computer was doing. Record any recent hardware, driver, or Windows changes. If a crash dump exists, retain it for analysis.
The stop-code name identifies the component reporting the error. The circumstances and dump help determine whether the documented nonpaged-pool scenario fits this crash.
2. Look for a repeatable workload or change
If crashes happen consistently during file-heavy activity or after a particular driver installation, investigate that pattern. If the issue started immediately after adding a device or changing a driver, check the relevant manufacturer’s supported driver and device compatibility. Change one thing at a time and observe whether the crash recurs.
This is general evidence-based troubleshooting. Microsoft’s 0x34 article does not identify a particular device category as the standard cause. Microsoft Learn
3. Check whether nonpaged pool pressure is supported by evidence
A support engineer can examine a dump or monitor a running system for nonpaged pool usage. If the pool was not unusually low, adding RAM solely because the stop code says CACHE_MANAGER may miss the cause.
Microsoft’s stated resolution for a nonpaged-pool depletion problem is to add physical memory, which can increase the amount of nonpaged pool available to the kernel. Apply that recommendation when depletion has been established and the machine can benefit from more memory. If usage is climbing because of a software leak, identify and correct the source of the growth as well. Microsoft Learn
Investigating CACHE_MANAGER with WinDbg
Confirm the code and arguments
Open an available kernel crash dump in WinDbg and begin with:
!analyze -v
.bugcheck!analyze -v requests detailed bug-check analysis; .bugcheck displays the recorded code and parameters. Confirm 0x34, retain the full value of Arg1, and inspect the stack and memory-related information available in the dump. The source-file identifier in Arg1 is not by itself a root-cause identifier. Microsoft Learn
Inspect memory and pool usage
Depending on the dump’s contents, these WinDbg extensions can help assess the pool-depletion hypothesis:
!vm
!poolused!vm summarizes virtual-memory usage, including nonpaged pool statistics. !poolused reports pool allocations grouped by pool tag, with paged and nonpaged usage. Compare the results with the available system context; a small dump may not contain enough data for every command or a conclusive assessment. Microsoft Learn
If one tag accounts for substantial or steadily growing usage, investigate which component makes those allocations. A tag or a module near the crash is an investigative lead. It does not automatically prove a leak or identify the code that failed to free memory.
Reproduce and monitor persistent growth
On a machine that can run long enough to observe the problem, PoolMon displays kernel pool allocations by tag and helps track allocation and free patterns over time. Microsoft’s pool-leak guidance uses it to look for allocations whose byte counts continue to grow without an apparent reason. Monitoring before the next crash can be more useful than examining a single snapshot after pool exhaustion. Microsoft Learn
A productive investigation is:
| Finding | Next question |
|---|---|
| Nonpaged pool was very low | Which tags consumed it, and did their usage rise over time? |
| One tag grew persistently | Which driver or component allocated under that tag? |
| Pool usage looked normal | What other evidence does the stack or repeated crash pattern show? |
| Several dumps implicate the same path | Can that path be reproduced and inspected by its developer? |
Guidance for driver developers
Review allocation and release paths for any driver implicated by pool usage or repeated dumps. Pay particular attention to error handling, cancellation, and cleanup paths where an allocation might remain outstanding. Use pool-tag data to narrow the investigation, then verify the actual allocating code; a shared or unfamiliar tag should not be treated as proof against one driver.
If the problem is a genuine shortage under a supported workload, adding physical memory may address the documented pool-depletion condition. If a driver’s allocations grow because resources are not released, fixing that behavior addresses the underlying growth. The 0x34 code alone does not distinguish these situations. Microsoft Learn
Frequently asked questions
Does CACHE_MANAGER mean I should clear my browser cache?
No. This stop code concerns the Windows file system’s cache manager, not a web browser’s stored files. Microsoft Learn
Does 0x34 always mean the computer needs more RAM?
No. Microsoft identifies nonpaged pool depletion as one possible cause and recommends adding physical memory to resolve that specific condition. First determine whether depletion actually occurred and whether usage reflects workload or a leak. Microsoft Learn
Is Parameter 1 an error status code?
No. Microsoft defines it as encoded source file and line information. Its upper 16 bits identify the source file by an internal number, and its lower 16 bits identify the line. Microsoft Learn
What do Parameters 2, 3, and 4 mean?
Microsoft marks all three reserved. Its 0x34 article does not assign them diagnostic meanings. Microsoft Learn
Can PoolMon tell me which driver is at fault?
PoolMon can show pool usage by tag and may help map tags to components. A growing tag provides a lead; it still takes investigation to determine whether the growth is abnormal and which allocation path caused it. Microsoft Learn
Summary
CACHE_MANAGER (0x00000034) indicates a problem in Windows’ file-system cache manager. Parameter 1 encodes source-file and line information; the other parameters are reserved. Microsoft documents nonpaged pool depletion as one possible cause and recommends adding physical memory when that depletion is established. Use crash analysis and pool-usage data to determine whether that explanation fits the particular system and what consumed the memory. Microsoft Learn
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.