Bluescreen: Reference_by_pointer

Ripshod

Ripshod

Ripshod

Associate
Joined
17 Feb 2010
Posts
699
[Solved]-Bluescreen: Reference_by_pointer

It's a wierd one, don't think I've ever seen anyone with this bluescreen

Bluescreen said Reference_by_pointer

Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 2057

Additional information about the problem:
BCCode: 18
BCP1: FFFFFA8006DE79B0
BCP2: FFFFFA800A36D210
BCP3: 0000000000000001
BCP4: 0000000000000001
OS Version: 6_1_7601
Service Pack: 1_0
Product: 256_1

AMD PhenomII x6 1090T
Gigabyte GA-890FXA-UD5
2x4GB Corsair XMS3
Corsair H80i cooler
Corsair HX850W PSU
HIS HD 7950 FAN 3GB
Sapphire HD 5770 Vapor-x
2xOCZ Vertex3 120GB Raid0

It's my own system and everything was at stock clocks when it happened. Machine was folding a Core_17 when it happened if that means owt.

Any suggestions where to start? Maybe I shouldn't worry til it becomes more than a one-off?

Voltages and temps were/are fine. As in all voltages are virtually bang-on, 7950 never goes over 70C, the cpu 45C
 
Last edited:
According to MSDN:

Cause

The reference count of an object is illegal for the current state of the object. Each time a driver uses a pointer to an object, the driver calls a kernel routine to increase the reference count of the object by one. When the driver is done with the pointer, the driver calls another kernel routine to decrease the reference count by one.
Drivers must match calls to the routines that increase (reference) and decrease (dereference) the reference count. This bug check is caused by an inconsistency in the object's reference count. Typically, the inconsistency is caused by a driver that decreases the reference count of an object too many times, making extra calls that dereference the object. This bug check can occur because an object's reference count goes to zero while there are still open handles to the object. It might also occur when the object's reference count drops below zero, whether or not there are open handles to the object.

Resolution

Make sure that the driver matches calls to the routines that increase and decrease the reference count of the object. Make sure that your driver does not make extra calls to routines that dereference the object (see Parameter 2).
You can use a debugger to help analyze this problem. To find the handle and pointer count on the object, use the !object debugger command.

kd> !object address

Where address is the address of the object given in Parameter 2.

Means nowt to me :)
 
Wow, now I am baffled. Seems we need to be driver writers to understand what they're even saying there. micro$oft making life hard again :(
 
Last edited:
Ripshod said:
Wow, now I am baffled. Seems we need to be driver writers to understand what they're even saying there. I guess that comes from micro$oft??
Click to expand...

There are 2 letters I would change there ;)

Have you tried using Blue Screen Viewer yet? There is a function to search the bug check using Google within the app.
 
Just done the google search through bluescreenview. Only results I'm getting are to do with ATI drivers. However the dump refers to driver ntoskrnl.exe, address ntoskrnl.exe+74540.

Can't find any more info online than the above. Tell me what to post here if you guys can help me?

*edit*

Dump File : 022814-17425-01.dmp
Crash Time : 28/02/2014 17:56:08
Bug Check String : REFERENCE_BY_POINTER
Bug Check Code : 0x00000018
Parameter 1 : fffffa80`06de79b0
Parameter 2 : fffffa80`0a36d210
Parameter 3 : 00000000`00000001
Parameter 4 : 00000000`00000001
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+74540
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 6.1.7601.22436 (win7sp1_ldr.130828-1532)
Processor : x64
Crash Address : ntoskrnl.exe+74540
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\022814-17425-01.dmp
Processors Count : 6
Major Version : 15
Minor Version : 7601
Dump File Size : 276,312
Dump File Time : 28/02/2014 17:57:39
 
Running that now m8. Only thing I could think of myself. Starting with my main drive, but gonna also do the storage drives as they're nearly 4yrs old with 33000+ hours on them. I didn't include the storage drives in my spec list :(. 2x1TB WD Green.
 
thanks for the pointer snips. Raided SSDs are fine and dandy. But the first of my storage drives has 1400 'unstable sectors' reported by SMART, and one 'damaged' 381MB block after a full error scan. Second one testing now.

I think it's time to get some external storage and transfer all my data.
 
Yeah sounds like your mech drives are on the way out dude - cheap as chips these days so get em replaced if your data is important to you!
 
You must log in or register to reply here.
Back
Top Bottom