Server crashed - question dump analysis

Hey Everyone,

A few days ago, one of my servers crashed unexpectedly (2008 R2).  I first reviewed the event logs and found a few messages referencing the need for battery reconditioning in addition to an event 41 that logged.  That being the case, I was thinking the issue was related to the power source / battery.  However, I pulled the memory dump and that kind of has me going in another direction.  I'm not sure if the dump could still point towards the power source, or if I'm looking at a possible driver / memory issue.  Any ideas?

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: fffffa8037caf590, Object type of the object whose reference count is being lowered
Arg2: fffffa8038d0e720, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: 0000000000000001, 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:
------------------


DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x18

PROCESS_NAME:  sqlservr.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80001e30d8d to fffff80001e8ab80

STACK_TEXT:  
fffff880`0b914ad8 fffff800`01e30d8d : 00000000`00000018 fffffa80`37caf590 fffffa80`38d0e720 00000000`00000001 : nt!KeBugCheckEx
fffff880`0b914ae0 fffff800`02183054 : fffffa80`7de137d0 00000000`00000000 fffffa80`3a92c480 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x48d8a
fffff880`0b914b40 fffff800`02183604 : 00000000`00001215 fffffa80`7de137d0 fffff8a0`0b779700 00000000`00001215 : nt!ObpCloseHandleTableEntry+0xc4
fffff880`0b914bd0 fffff800`01e89e13 : fffffa80`3a92c480 fffff880`0b914ca0 00000000`00020002 fffffa80`3a768260 : nt!ObpCloseHandle+0x94
fffff880`0b914c20 00000000`779e13aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`36c9ef08 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x779e13aa


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+48d8a
fffff800`01e30d8d cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+48d8a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  51fb06cd

FAILURE_BUCKET_ID:  X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+48d8a

BUCKET_ID:  X64_0x18_CORRUPT_REF_COUNT_nt!_??_::FNODOBFM::_string_+48d8a

Followup: MachineOwner

Select all Open in new window