Windows Stop Code REFERENCE_BY_POINTER (0x00000018): Meaning, Parameters, and Troubleshooting
Quick answer REFERENCE_BY_POINTER is Windows bug check 0x00000018. It means that a kernel object’s reference count is invalid for the object’s current state....
Quick answer
REFERENCE_BY_POINTER is Windows bug check 0x00000018. It means that a kernel object’s reference count is invalid for the object’s current state. A common cause is a driver releasing a reference more times than it acquired one. The count may reach zero while handles to the object are still open, or it may fall below zero. The stop code identifies a reference-count problem; finding the responsible driver usually requires examining a crash dump. Microsoft Learn
What is an object reference count?
Windows uses kernel objects to represent resources such as devices, files, processes, threads, and events. A driver can acquire a counted reference while it uses an object and release that reference when it is finished. These acquisitions and releases must be balanced. Microsoft Learn
Consider a driver that acquires one reference to an object. It should release that reference once. If it releases the same reference twice, the object’s count no longer reflects who is using it. That is an under-reference. It can cause an object to be deleted prematurely while another part of the system still needs it. Conversely, failing to release a reference can keep an object alive unnecessarily; that is a leak. Microsoft associates 0x18 particularly with the former kind of mismatch: too many dereferences. Microsoft Learn
The word “pointer” in the stop-code name refers to the way kernel code holds and uses an object. This error does not mean that a mouse pointer or touchpad is malfunctioning.
REFERENCE_BY_POINTER parameters
Microsoft defines the four bug-check parameters as follows. Microsoft Learn
| Parameter | Meaning | Diagnostic use |
|---|---|---|
| 1 | Object type of the object whose reference count is being lowered | Helps identify the kind of kernel object involved. |
| 2 | Address of the object whose reference count is being lowered | Use this address when inspecting the object in WinDbg. |
| 3 | Reserved | No code-specific interpretation is published. |
| 4 | Reserved | No code-specific interpretation is published. |
Parameter 2 is an object address, not a driver address. Parameters 3 and 4 should not be assigned meanings from an example crash or an unrelated stop code.
What causes the error?
Microsoft describes the immediate cause as an object reference count that is inconsistent with the object’s state. Typically, a driver has called a dereference routine too many times. Two documented situations are: Microsoft Learn
- The object’s reference count reaches zero while handles to it remain open.
- The reference count falls below zero, whether or not handles remain open.
The underlying programming mistake may be in a particular driver code path, such as cleanup that releases a reference already released elsewhere. That example is an inference about how a mismatch could arise, not a claim that every 0x18 crash has the same faulty routine. The dump and, when available, reference history are needed to establish what happened in a specific case.
How to investigate the crash in WinDbg
1. Confirm the bug check and capture its arguments
Open the crash dump and run:
!analyze -v
.bugcheck!analyze -v requests detailed bug-check analysis. .bugcheck displays the recorded code and parameters. Confirm that the code is 0x18, then copy all four parameter values before investigating the object. Microsoft Learn
Read the stack and any named drivers as investigative leads. A driver shown near the failure is relevant, but its presence alone does not prove that it made the unmatched reference-count call.
2. Inspect the object identified by Parameter 2
Microsoft specifically recommends using !object with the object address from Parameter 2:
!object <Parameter-2-address>To request the object type, name, and reference counts explicitly, use:
!object <Parameter-2-address> 0x1Depending on the available dump data and the object’s state, the output can show values such as HandleCount and PointerCount. If the debugger cannot read the object, do not infer that a zero or missing count was observed; the information may no longer be available in that dump. Microsoft Learn
3. Trace who acquired and released references
If you maintain the suspected driver, review every path that acquires and releases a reference to the object: successful operations, errors, cancellation, cleanup, and unload. Microsoft’s recommended correction is to match reference and dereference calls and remove extra dereferences. Microsoft Learn
For a reproducible issue, object reference tracing can record the acquisition and release history. When enabled, WinDbg’s !obtrace can show reference operations and their call stacks. Microsoft notes that reference tracing is off by default, so it generally must be enabled before reproducing the problem; an old dump will not necessarily contain that history. Tagged references can make mismatched calls easier to find. Microsoft Learn
Microsoft also suggests setting a breakpoint in the code leading to the stop and stepping through it when a suitable live debugging setup is available. That approach is most useful to a driver developer who can reproduce the failure. Microsoft Learn
Troubleshooting steps for PC users
You do not need to interpret object addresses to take the first useful steps:
- Record the stop code and timing. Note whether crashes began after a driver update, new device, or software installation.
- Check Event Viewer’s System log. Microsoft recommends looking for additional errors that could help identify an affected device or driver. Microsoft Learn
- Investigate an identified driver. If the crash analysis consistently identifies a driver, check with its manufacturer for an appropriate update. If the problem began after a change, consider reversing that change to test whether the crashes stop. Microsoft Learn
- Check recently installed hardware. Confirm that it and its driver are compatible with your version of Windows. Microsoft Learn
- Keep the crash dump if the problem continues. The stop-code name describes the reference-count failure, while the dump can help locate the code path responsible.
There is no universal 0x18 repair command. Replacing hardware, reinstalling Windows, or changing unrelated drivers without evidence can leave the underlying reference-count issue unresolved.
Guidance for driver developers
Treat references as an ownership obligation: every acquired reference needs a corresponding release, and each release must belong to a reference the code still owns. Review transitions where ownership moves between routines or asynchronous operations, especially paths that can exit early. Microsoft’s object-reference guidance recommends comparing the reference and dereference calls associated with a particular object; tagged calls and !obtrace can help expose an imbalance. Microsoft Learn
A productive investigation combines three views:
| Evidence | Question it helps answer |
|---|---|
!analyze -v and call stack |
Where did Windows detect the inconsistent count? |
!object on Parameter 2 |
What object was involved, and what count information is still available? |
| Reference tracing from a reproduction | Which paths acquired and released references to that object? |
The code that detects the bad count may differ from the earlier code path that caused it. Comparing the operations across a reproduction is more reliable than changing the first driver name shown by a debugger.
Frequently asked questions
Is REFERENCE_BY_POINTER a hardware failure?
The documented mechanism is an inconsistent kernel object reference count, typically involving excess dereference calls by a driver. The code alone does not establish a physical hardware failure. A newly installed device can still be relevant because its driver may be involved. Microsoft Learn
What does Parameter 2 tell me?
It gives the address of the object whose reference count was being lowered. In WinDbg, use that address with !object to inspect information available about the object. It does not directly name the faulty driver. Microsoft Learn
Why does the error mention open handles?
Microsoft says 0x18 can occur when the reference count reaches zero despite handles still being open. That mismatch means the object’s recorded lifetime no longer agrees with its continued use. The bug check can also occur if the count falls below zero without open handles. Microsoft Learn
Can !object always show the bad count?
No. Its output depends on whether the relevant object data is available and readable in the debugging session. Use its result together with the dump’s stack and other evidence; a failed lookup is not itself a diagnosis. Microsoft Learn
What is the difference between an under-reference and a leak?
An under-reference releases more references than the code owns and can allow premature object deletion. A leak leaves references outstanding, preventing deletion. Microsoft describes 0x18 as typically resulting from excess dereferences. Microsoft Learn
Summary
REFERENCE_BY_POINTER (0x00000018) signals an invalid kernel object reference count, commonly because a driver released an object reference too many times. Parameter 1 identifies the object type, Parameter 2 identifies the object, and Parameters 3 and 4 are reserved. Investigate the dump, inspect the object if possible, and trace reference ownership to locate and correct the mismatch. Microsoft Learn
Sources
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.