Another BSOD 64 bit

I get this on bootup about once every two weeks

Could use some help

minidump attached

Howzits said:

I get this on bootup about once every two weeks

Could use some help

minidump attached

Hi and welcome

Pretty straight forward caused by your PCtools. (pctcore64.sys)

Code:

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


Loading Dump File [C:\Users\K\Desktop\122309-30326-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*d:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02c60000 PsLoadedModuleList = 0xfffff800`02e9de50
Debug session time: Wed Dec 23 08:27:28.679 2009 (GMT-5)
System Uptime: 0 days 0:01:51.270
Loading Kernel Symbols
...............................................................
................................................................
............................................
Loading User Symbols
Loading unloaded module list
..........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

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

Unable to load image \SystemRoot\system32\drivers\PCTCore64.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for PCTCore64.sys
*** ERROR: Module load completed but symbols could not be loaded for PCTCore64.sys
Probably caused by : PCTCore64.sys ( PCTCore64+2095f )

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

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

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: fffffa8006559860, 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:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80002c67fac to fffff80002cd1f00

STACK_TEXT:  
fffff880`06b04948 fffff800`02c67fac : 00000000`00000018 00000000`00000000 fffffa80`06559860 00000000`00000002 : nt!KeBugCheckEx
fffff880`06b04950 fffff880`0106b95f : fffff880`06b04ba0 fffff8a0`0894ad70 fffff8a0`0346ef30 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x46661
fffff880`06b049b0 fffff880`06b04ba0 : fffff8a0`0894ad70 fffff8a0`0346ef30 00000000`00000000 fffff8a0`0346ef30 : PCTCore64+0x2095f
fffff880`06b049b8 fffff8a0`0894ad70 : fffff8a0`0346ef30 00000000`00000000 fffff8a0`0346ef30 fffff880`0107a7ed : 0xfffff880`06b04ba0
fffff880`06b049c0 fffff8a0`0346ef30 : 00000000`00000000 fffff8a0`0346ef30 fffff880`0107a7ed fffff8a0`0894ad70 : 0xfffff8a0`0894ad70
fffff880`06b049c8 00000000`00000000 : fffff8a0`0346ef30 fffff880`0107a7ed fffff8a0`0894ad70 fffff8a0`0894ad70 : 0xfffff8a0`0346ef30


STACK_COMMAND:  kb

FOLLOWUP_IP: 
PCTCore64+2095f
fffff880`0106b95f ??              ???

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  PCTCore64+2095f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: PCTCore64

IMAGE_NAME:  PCTCore64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ab9aadb

FAILURE_BUCKET_ID:  X64_0x18_PCTCore64+2095f

BUCKET_ID:  X64_0x18_PCTCore64+2095f

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

Thanks very much.

did not expect that - they have been most reliable