Windows Stop Code PFN_SHARE_COUNT (0x0000001B): Meaning and Verification
Quick Answer PFN_SHARE_COUNT is the symbolic name for Windows bug check 0x0000001B. The most important fact is that Microsoft says this bug-check code is no ...
Quick Answer
PFN_SHARE_COUNT is the symbolic name for Windows bug check 0x0000001B. The most important fact is that Microsoft says this bug-check code is no longer used within the Windows operating system. Its dedicated page provides no parameter definitions, specific cause, or repair procedure. Microsoft Learn
If you found this entry in a stop-code list, it is best treated as a reference entry. If a computer appears to have crashed with 0x0000001B, verify the exact value in its original crash dump before drawing conclusions about a memory problem.
What Is PFN?
PFN commonly refers to a page frame number in Windows memory-management terminology. The phrase share count suggests accounting for uses of a physical page. That background helps explain the wording of the symbolic name, but Microsoft’s dedicated 0x1B entry does not describe a specific share-count failure or say how its parameters should be decoded.
Consequently, the name should not be presented as proof that RAM is faulty, a page was mapped too many times, or a particular driver mishandled memory. Those would be diagnoses requiring evidence beyond the code’s published description. Microsoft Learn
Stop Code at a Glance
| Item | Documented information |
|---|---|
| Bug-check value | 0x0000001B |
| Symbolic name | PFN_SHARE_COUNT |
| Current use | Microsoft says it is no longer used within Windows. |
| Published parameter definitions | None on the dedicated 0x1B page. |
| Published cause or fix | None on the dedicated 0x1B page. |
Why Does an Unused Code Still Appear in Lists?
Microsoft’s bug-check code reference retains an entry mapping 0x0000001B to PFN_SHARE_COUNT. Its dedicated page supplies the qualification that the code is no longer used. A reference listing can preserve a name even when the current operating system does not use that bug check. Microsoft Learn
This distinction matters when building a knowledge base: listing the code accurately is useful, but presenting a detailed “0x1B fix” for current Windows systems would imply documentation and diagnostic certainty that Microsoft does not provide.
How to Verify an Apparent 0x1B Crash
1. Check the complete hexadecimal value
Confirm all digits from the original blue screen, event record, or dump. 0x0000001B, 0x0000011B, and 0x0000001C are different bug-check values. Do not rely on a partial code in a screenshot or search result.
2. Open the crash dump in WinDbg
If a dump exists, open it in WinDbg and run:
!analyze -vThis displays analysis of the recorded bug check and may show its arguments, stack, and relevant execution context. Microsoft recommends !analyze as a general starting point for investigating stop codes. learn.microsoft.com
To display the bug-check data directly, you can also use:
.bugcheckRecord the code and four arguments exactly as reported. Microsoft documents .bugcheck for displaying bug-check data. learn.microsoft.com
3. Compare the dump with the reported label
If the dump shows a different code, investigate that actual code. If it really reports 0x1B, retain the dump, Windows version, and WinDbg output for specialist analysis. Microsoft’s page does not explain how a current Windows installation would reach this retired bug-check value.
4. Avoid guessing at the parameter meanings
Because Microsoft supplies no 0x1B parameter table, do not label one argument a PFN, a share count, or an address solely from its position. Interpret any value only when supported by the particular dump and debugger context.
Is PFN_SHARE_COUNT the Same as PFN_REFERENCE_COUNT?
No. They are adjacent but distinct entries in Microsoft’s bug-check reference:
| Value | Name |
|---|---|
0x0000001B |
PFN_SHARE_COUNT |
0x0000001C |
PFN_REFERENCE_COUNT |
The similarity of their names does not make their values or diagnostic interpretations interchangeable. Verify the complete code before choosing an article to consult. learn.microsoft.com
Should You Run a RAM Test?
A computer with repeated blue screens may warrant memory testing when its actual crash evidence points that way. The name PFN_SHARE_COUNT by itself does not establish that need, and Microsoft’s dedicated 0x1B reference does not prescribe a RAM test. First confirm the stop code and examine the dumps. Microsoft Learn
Likewise, there is no documented 0x1B-specific registry change, driver update, or hardware replacement to apply solely on the basis of this entry.
Frequently Asked Questions
Is PFN_SHARE_COUNT an active Windows bug check?
Microsoft says 0x0000001B is no longer used within the Windows operating system. Microsoft Learn
Does it prove my RAM is defective?
No. Microsoft’s 0x1B page does not identify faulty RAM as its cause. Verify the actual crash code and supporting evidence before diagnosing hardware. Microsoft Learn
What do the four parameters mean?
Microsoft does not publish parameter definitions on the dedicated 0x1B page. Record the arguments from the dump without assigning unsupported meanings. Microsoft Learn
Why can I find the code online if Windows no longer uses it?
It remains listed as a named value in Microsoft’s bug-check reference. The dedicated entry clarifies its current status. learn.microsoft.com
What should I do if WinDbg really reports 0x1B?
Preserve the dump and record the Windows build, bug-check arguments, stack, and !analyze -v output. Seek case-specific debugging assistance rather than applying a generic “PFN share count” fix.
Summary
PFN_SHARE_COUNT (0x0000001B) is a documented bug-check name and value, but Microsoft says the code is no longer used within Windows. For an apparent real-world occurrence, the first task is to verify the exact bug-check value in the crash dump. The symbolic name alone does not establish a cause or justify a repair. Microsoft Learn
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.