Help Please

STOP 0x00000018: REFERENCE_BY_POINTER

Usual causes: Device driver, kernel, hardware

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Owner\Downloads\070310-24343-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*Symbol information
Executable search path is: 
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Machine Name:
Kernel base = 0xfffff800`02c4b000 PsLoadedModuleList = 0xfffff800`02e88e50
Debug session time: Sat Jul  3 15:23:04.856 2010 (GMT-4)
System Uptime: 0 days 0:14:33.684
Loading Kernel Symbols
...............................................................
................................................................
..........................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 18, {0, fffffa8005f52900, 2, ffffffffffffffff}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+46451 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: fffffa8005f52900, Object whose reference count is being lowered
Arg3: 0000000000000002, Reserved
Arg4: ffffffffffffffff, Reserved
    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 increment the reference count of the object. When the driver is done with the
    pointer the driver calls another kernel routine to decrement the reference count.
    Drivers must match calls to the increment and decrement routines. This bugcheck
    can occur because an object's reference count goes to zero while there are still
    open handles to the object, in which case the fourth parameter indicates the number
    of opened handles. It may also occur when the object’s reference count drops below zero
    whether or not there are open handles to the object, and in that case the fourth parameter
    contains the actual value of the pointer references count.

Debugging Details:
------------------


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x18

PROCESS_NAME:  svchost.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80002c52fac to fffff80002cbb600

STACK_TEXT:  
fffff880`02bfc428 fffff800`02c52fac : 00000000`00000018 00000000`00000000 fffffa80`05f52900 00000000`00000002 : nt!KeBugCheckEx
fffff880`02bfc430 fffff800`02fb7f09 : fffff880`02bfcca0 fffff880`02bfc7d8 00000000`00000017 00000000`00000006 : nt! ?? ::FNODOBFM::`string'+0x46451
fffff880`02bfc490 fffff800`02fb87d6 : 00000000`00000001 00001f80`00000000 fffff8a0`00000001 00000000`00000001 : nt!ObpWaitForMultipleObjects+0x2d3
fffff880`02bfc960 fffff800`02cba853 : fffffa80`05f45060 00000000`004efb38 fffff880`02bfcbc8 fffff880`02bfcc00 : nt!NtWaitForMultipleObjects+0xe5
fffff880`02bfcbb0 00000000`7747046a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`004efb18 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7747046a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+46451
fffff800`02c52fac cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+46451

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4b88cfeb

FAILURE_BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+46451

BUCKET_ID:  X64_0x18_nt!_??_::FNODOBFM::_string_+46451

Followup: MachineOwner
---------

This dump doesn't tell us much except that it points to hardware or drivers.

To answer your question, yes, it could be the motherboard; but I would have expected some different error codes if it were the motherboard. I am still leaning toward the video card based on what I have seen.

Thanks for the update. Let us know how another video card does.

Antec is a reputable brand, but every product has a certain risk of failure.

If the PSU is faulty, it can result in random errors difficult to diagnose. BSODs are a possibility.

If you have another PSU to test, for it.

Do you have any new dmp files? I have to suspect hardware since you are having problems in BIOS.

I would say that since you are stable with one stick, the indication is definitely a RAM problem. We will know more when you test the other stick.

When you start asking about the capabilities of your board and its effect, you are out of my area of limited expertise. I am not a hardware guy. If your system is struggling to run your RAM, yes it can definitely trigger crashes. I have never delved into RAM voltages, overclocking, under clock, etc. But there are some good hardware folks here. I will post a call for help with your questions. Stay tuned.