0x00000018 REFERENCE_BY_POINTER Stop Code Fix Guide

0x00000018 (REFERENCE_BY_POINTER) usually means a driver or kernel component corrupted an object’s reference count. I sort these crashes into three buckets first: a recent driver change, a disk or volume filter issue, or a repeatable hardware fault. Skip that split and you can burn days on canned repairs while the system keeps blue-screening and the chance of data loss goes up. This guide maps the decision path, the checks that confirm each bucket, and the point where replacing parts stops being guesswork (per Microsoft support). (Microsoft Learn)

This guide is part of our Windows BSOD stop codes: full list and fixes series.

What does 0x00000018 mean in Windows?

Read the bugcheck before you change anything. The four parameters tell you where to look first, and Parameter 2 matters most because it is the object address you can inspect in WinDbg. Event Viewer then gives you the reboot event and saved dump path, so you start from evidence instead of hunches.

How to read the four bugcheck parameters

Bug Check 0x18 has four parameters. Parameter 1 is the object type whose reference count is being lowered. Parameter 2 is the object whose reference count is being lowered. Parameters 3 and 4 are reserved, according to Microsoft debugger documentation.

In plain English, this usually points to a driver getting its reference or dereference calls wrong. Drivers have to balance those calls, and I often see an extra dereference call in bad dumps. That can push the count to zero while handles are still open, or even below zero.

Why Parameter 2 matters most

Parameter 2 is the address to carry into WinDbg. After you open the dump, run !analyze, note the four parameters, then run !object <Parameter2>. The !object command can show handle and pointer counts, which helps you tell a plain driver bug from broader memory corruption (per Microsoft debugger docs).

Fastest first step

1. Open Event Viewer with eventvwr.msc.
2. Go to Windows Logs > System.
3. Find the reboot-from-bugcheck event near the crash time.
4. Record the stop code, the four parameters, and the saved dump path shown in the event.
5. Open the dump in WinDbg and run !analyze.

0x00000018 triage table: match the crash to the likely subsystem

Use this page to sort the case. The job is to decide who owns the next move before you start repair commands: a driver vendor, the OEM firmware team, or the parts bin. Most cases begin with device drivers. Less often, the storage stack or a mounted-volume case is involved. Hardware usually comes later unless the evidence keeps dragging you there.

One-page triage table

How to use the table

Start with the symptom cluster, then check whether the same driver, trigger, or Parameter 2 address keeps coming back. Repetition beats guesswork. If the trigger is stable, chase that bucket first. If everything looks random, move hardware higher on the list.

Likely causes of 0x00000018, ranked by how often they show up

Most often, this points to driver misuse. After that come storage and volume edge cases, especially where filter drivers sit in the file or disk path. RAM faults and broader corruption are less common, but they move up fast when stacks change every crash. Firmware and chipset issues usually act as aggravators around sleep, resume, docking, or storage-controller behavior.

Ranked decision path

1. Driver reference or dereference misuse. Start here if the crash began after a driver change or a new device.
2. Storage, filter driver, or mounted-volume edge case. Move here if backups, AV, encryption, external storage, or volume changes line up with the crash.
3. RAM faults or broader corruption. Raise this higher if stop codes vary or the faulting module never repeats.
4. BIOS and chipset path. Use this when the pattern clusters around wake, dock, hot-plug, or controller behavior.

How do I check which driver caused 0x00000018?

Start in Event Viewer, then go straight to the dump. The sequence that works is System log, reboot event, saved dump path, WinDbg !analyze, and then !object against Parameter 2. If the same third-party driver appears in the stack after a recent change, that is your first rollback target.

Step 1: Pull the reboot event and dump path

1. Press Win + R, run eventvwr.msc.
2. Open Windows Logs > System.
3. Sort by Level or Date and Time, then open the event at the reboot time.
4. Write down the bugcheck code and the dump file path listed in the message.

Step 2: Read the dump in WinDbg

1. Open the dump in WinDbg.
2. Run !analyze as Microsoft recommends for crash dump analysis.
3. Read the faulting stack for a repeating third-party driver name.
4. Run !object <Parameter2> to inspect the object address and its counts.

Step 3: Roll back or disable the suspect

1. Open Device Manager.
2. Open the suspect device > Properties > Driver.
3. Select Roll Back Driver if available, or Uninstall Device and reboot.
4. Install the replacement driver from the device maker or OEM support page, not a driver updater tool.
5. If present, disable related filter software tied to storage, security, backup, VPN, docking, or virtualization and retest.

Can a volume mount issue cause stop code 0x00000018?

Yes. If crashes line up with backup jobs, encryption, external disks, VHD activity, or mount and unmount actions, move the storage stack ahead of RAM on the suspect list. On Windows Server 2012 and 2012 R2, there is also a known mounted-volume hotfix path to check before you replace parts.

Step 1: Look for storage triggers

1. Check whether the crash follows sleep, resume, docking, hot-unplug, external drive changes, or new storage software.
2. Remove or uninstall the most recent backup, antivirus, encryption, virtualization, or disk utility layer.
3. Retest the same workload that triggered the crash.

Step 2: Run integrity checks after driver triage

1. Open Command Prompt as administrator.
2. Run sfc /scannow and review whether Windows Resource Protection found corruption and repaired it.
3. Then run DISM /Online /Cleanup-Image /RestoreHealth to repair the component store that SFC depends on.
4. If disk corruption is suspected, run chkdsk and schedule the scan if prompted.

Step 3: Check the older server hotfix case

Microsoft Support has a stop error article for 0x00000018 on Windows Server 2012 and Windows Server 2012 R2 volumes. If the server matches that mounted-volume pattern, confirm prerequisite update 2919355 first, then follow the hotfix path instead of treating it as random hardware failure.

Can faulty RAM trigger 0x00000018?

Yes, but I usually chase it after I weigh driver and storage clues. Move RAM higher when stacks change every crash, Parameter 2 never repeats, other stop codes appear, or the system shows broader corruption such as install failures, archive errors, or app crashes outside the blue screen window.

Step 1: Run the built-in memory test

1. Press Win + R, run mdsched.exe.
2. Select Restart now and check for problems.
3. After Windows restarts, review the result in Event Viewer > Windows Logs > System.

Step 2: Remove variables before replacing parts

1. Undo any CPU, RAM, or GPU overclock in BIOS.
2. Shut down, reseat RAM, and retest.
3. If multiple modules are installed, test one module at a time if the platform allows it.
4. If crashes persist with mixed stop codes, move to OEM diagnostics or known-good RAM.

Step 3: Decide when hardware owns the case

Hardware replacement moves to the front when dumps stop naming the same software path, memory tests fail, or crashes continue after driver rollback and storage cleanup. At that point, swapping RAM is usually a better use of time than more system file repair.

Does updating BIOS help stop 0x00000018 crashes?

Sometimes. BIOS and chipset updates are worth doing when the crash clusters around sleep, resume, docking, PCIe hot-plug, or storage-controller behavior. They should not be your first move on every system, but they are a good next step once the trigger points toward power-state or bus handling.

When the OEM path makes sense

1. Go to the PC or motherboard maker’s support page.
2. Install the newest BIOS offered for the exact model.
3. Install the current chipset and storage-controller drivers from the same support page.
4. Retest the wake, dock, or storage action that caused the crash.

What this section does and does not fix

If a third-party driver is named in the dump, fix that first. If the system crashes only on wake or device attach, firmware moves up the list. ASUS, Dell, Lenovo, HP, and white-box systems all follow the same logic: match the update to the trigger, then retest the trigger.

What should I do first when Windows keeps rebooting with 0x00000018?

Stabilize the machine long enough to collect evidence, then work in order: Event Viewer, dump analysis, rollback of recent drivers, storage-stack checks, memory test, and only then deeper repair steps. If normal boot loops too fast, use Safe Mode so the first pass is about data collection, not blind repair.

If that didn’t work, try this next

1. Boot into Safe Mode if normal boot is unstable.
2. Use msconfig for a clean boot if a recent app or service may be involved.
3. Build a case packet: the System log event, dump file, WinDbg !analyze output, !object output for Parameter 2, and exact repro steps.
4. Send that packet to the driver vendor if a module repeats, or to OEM support if the trigger is wake, dock, BIOS, or storage-controller related.
5. If software paths are exhausted, run OEM diagnostics and consider Reset This PC only after data is backed up and the hardware picture is still unclear.

Prevention

Avoid stacking multiple low-level tools at once. If a new VPN, backup agent, endpoint security tool, or docking package was added recently, install one change at a time and keep a restore path through driver rollback or uninstall.

Frequently asked questions

Is 0x00000018 the same as REFERENCE_BY_POINTER?

Yes. In practice, WinDbg and Event Viewer will help more than generic cleanup commands. Start with eventvwr.msc, note the dump path from the System log bugcheck event, open the dump, run !analyze, and inspect Parameter 2 with !object.

What usually causes bugcheck 0x00000018?

Most cases trace back to a driver that mismatches reference and dereference calls, often by dereferencing an object too many times. After that, check storage and volume filter drivers, then RAM or broader corruption if dumps and stacks change from one crash to the next.

How do I read the bugcheck parameters for 0x00000018?

Parameter 1 is the object type, Parameter 2 is the object address, and Parameters 3 and 4 are reserved. The practical move is to run !analyze in WinDbg, copy Parameter 2, then run !object <address> to inspect handle and pointer counts.

Can faulty RAM trigger 0x00000018?

Yes, especially when the crash pattern is random and no single driver repeats in the stack. Run mdsched.exe, choose Restart now and check for problems, remove any overclock, and retest before deciding that the issue belongs to the motherboard or memory kit.

Is there a Microsoft hotfix for 0x00000018 in older Windows versions?

There is a Microsoft Support path for Windows Server 2012 and Windows Server 2012 R2 when the stop code is tied to mounted volumes. Check whether the system fits that scenario, confirm prerequisite update 2919355, and use that route before swapping hardware.

What if searches mention “0x00000018 can’t” or “0x00000018 ASUS”?

Those variants usually reflect boot-loop or vendor-specific searches, not a different stop code. The workflow stays the same: Safe Mode if needed, Event Viewer for the dump path, WinDbg for !analyze and !object, then OEM BIOS and chipset updates only if the trigger points to wake, dock, or storage behavior.