Windows Stop Code PFN_REFERENCE_COUNT (0x0000001C): Meaning, Causes, and Troubleshooting
Quick Answer PFN_REFERENCE_COUNT is Windows bug check 0x0000001C. It means Windows detected a reference-count error. Microsoft identifies possible mechanisms...
Quick Answer
PFN_REFERENCE_COUNT is Windows bug check 0x0000001C. It means Windows detected a reference-count error. Microsoft identifies possible mechanisms including a count that overflows, underflows, or an object used after it has been freed. Examine the crash stack to determine the fault. Microsoft Learn
Despite PFN in its name, this bug check can report multiple types of reference-count errors; it is not necessarily related to Memory Manager page frame numbers. Microsoft marks all four bug-check parameters as not used. The useful evidence is therefore primarily the dump’s stack, execution context, and the lifetime of the object involved. Microsoft Learn
What Is a Reference Count?
A reference count tracks how many valid uses or owners of an object remain. Code increases the count when it takes a reference and decreases it when that reference is released. When the last valid reference is released, the object can become eligible for cleanup.
A bug occurs when the accounting no longer matches reality. For example, a code path might release a reference twice, continue using an object after its final release, or repeatedly add references without the expected matching releases. The specific object and faulty path must be established from the dump and, for driver developers, the relevant source code.
What Microsoft Documents About 0x1C
| Item | Documented meaning |
|---|---|
| Bug-check value | 0x0000001C |
| Symbolic name | PFN_REFERENCE_COUNT |
| Condition | A reference-count error was detected. |
| Possible mechanisms | Counter overflow, counter underflow, or use of an object after it was freed. |
| PFN requirement | The error is not necessarily related to Memory Manager PFNs. |
| Parameters 1–4 | All marked not used. |
| Recommended first analysis | Examine the stack; use WinDbg’s !analyze extension. |
Three Failure Patterns to Investigate
Reference-count underflow
An underflow means code decremented a count beyond its valid range. A common programming pattern to investigate is an unmatched release: one path releases an object, then an error or cleanup path releases it again.
This is an example of how an underflow can arise, not a determination that every 0x1C crash is a double release. Microsoft identifies underflow as one possible cause; the stack and source path must establish what actually happened. Microsoft Learn
Reference-count overflow
An overflow occurs when repeated increments exceed the count’s representable range or otherwise violate its expected state. Investigate loops, repeated callbacks, and paths that take references without corresponding releases when the dump suggests this pattern. Microsoft Learn
Use after free
An object may be destroyed after its final reference is released, while another code path still holds a pointer to it. Accessing or referencing that stale pointer can expose a lifetime error. Pay particular attention to asynchronous work, cancellation, and cleanup paths if they appear on the failing stack. Microsoft explicitly identifies use after free as a possible mechanism for 0x1C. Microsoft Learn
Why “PFN” in the Name Can Be Misleading
A page frame number identifies a physical memory page in Windows memory-management terminology. It would be natural to see PFN_REFERENCE_COUNT and assume that the crash must involve a physical page or defective RAM.
Microsoft explicitly cautions against that inference: 0x1C is used for multiple kinds of reference-count error and need not concern Memory Manager PFNs. A RAM test or memory-manager diagnosis should follow evidence from the particular crash, not the name alone. Microsoft Learn
How to Investigate 0x1C with WinDbg
1. Preserve the crash dump
Keep the dump generated by the affected system. A screenshot confirms the displayed code, but the dump can show the call stack and execution context Microsoft recommends examining.
2. Run the initial analysis
Open the dump in WinDbg and enter:
!analyze -vMicrosoft specifically recommends !analyze to display information that may help determine the root cause of 0x1C. Record the analysis, faulting thread, named modules, and stack. Microsoft Learn
3. Examine the stack
Display a detailed stack trace:
kvIdentify the object-related operations leading to the bug check. Look for code that acquires, increments, decrements, closes, or cleans up a reference. A module appearing on the stack is a lead; inspect its role before blaming it.
4. Trace the object’s lifetime
If you maintain the implicated code, reconstruct how the object was created, referenced, released, and destroyed. For each path, ask:
- Was a reference taken before the object was passed to another thread or callback?
- Does every successful acquisition have exactly one corresponding release?
- Can cancellation and completion both perform cleanup?
- Can an error path release an object already released on the normal path?
- Can queued work run after the owner frees the object?
The answer should come from the actual code path and dump evidence. This approach targets the mechanisms Microsoft lists for 0x1C. Microsoft Learn
5. Compare repeated crashes
If multiple dumps exist, compare their stacks and implicated object paths. A recurring path is more informative than a single occurrence with little context.
Guidance for End Users
If you do not develop the driver involved, there is no universal setting to change for PFN_REFERENCE_COUNT. Start by keeping the dumps and noting when the problem began. If analysis points consistently to a third-party driver, obtain an appropriate update or rollback from its vendor.
Do not assume that replacing RAM, enlarging the page file, or changing Windows memory settings will correct a reference-lifetime bug. Those actions should be considered only when separate evidence supports them.
PFN_REFERENCE_COUNT vs PFN_SHARE_COUNT
These adjacent codes have different documented status and meaning:
| Code | Name | Microsoft’s description |
|---|---|---|
0x0000001B |
PFN_SHARE_COUNT |
No longer used within Windows. |
0x0000001C |
PFN_REFERENCE_COUNT |
Reports a reference-count error, which need not involve Memory Manager PFNs. |
Do not carry the “no longer used” status of 0x1B over to 0x1C. learn.microsoft.com
Frequently Asked Questions
What does PFN_REFERENCE_COUNT mean?
Windows detected a reference-count error and reported bug check 0x0000001C. Microsoft Learn
Is this stop code still used?
Microsoft’s dedicated 0x1C page describes its current diagnostic meaning. It does not mark it as retired. That differs from 0x1B, which Microsoft explicitly says is no longer used. Microsoft Learn
Does it always mean a page frame number is corrupt?
No. Microsoft says 0x1C covers multiple reference-count errors and is not necessarily related to Memory Manager PFNs. Microsoft Learn
What are its four parameters?
Microsoft’s 0x1C parameter table marks Parameters 1, 2, 3, and 4 as “Not used.” Focus on the stack and other dump context. Microsoft Learn
Does it prove my physical RAM is faulty?
No. The documented mechanisms include count overflows, underflows, and use after free. The stop code alone does not establish a RAM fault. Microsoft Learn
Which WinDbg command should I start with?
Run !analyze -v, then examine the stack and relevant object-lifetime path. Microsoft recommends both the analysis extension and examination of the stack. Microsoft Learn
Summary
PFN_REFERENCE_COUNT (0x0000001C) reports a reference-count error. Possible mechanisms include overflow, underflow, and use after free. Its four parameters are documented as not used, and the failure may involve an object unrelated to page frame numbers. The most productive investigation is to analyse the dump’s stack and trace the implicated object’s references from creation through cleanup. Microsoft Learn
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.