Hi,
We have a Windows 2008 File server that is crashing at least once a day because of the rxservice. See below for a debug of the memory.dmp file of the affected server.
Is anyone else seeing this problem?
CPS Version : 12.5.417.4602
John
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: SRV*C:\symbolfiles*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2008/Windows Vista Kernel Version 6001 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 6001.18145.amd64fre.vistasp1_gdr.080917-1612
Machine Name:
Kernel base = 0xfffff800`01806000 PsLoadedModuleList = 0xfffff800`019cbdb0
Debug session time: Mon Mar 23 12:15:20.660 2009 (GMT+0)
System Uptime: 2 days 14:10:33.062
Loading Kernel Symbols
...............................................................
................................................................
..........
Loading User Symbols
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 18, {bad0b0b0, fffffa801abaa210, 2, ffffffffffffffff}
*** ERROR: Module load completed but symbols could not be loaded for CpsFsJnl.sys
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
Probably caused by : CpsFsJnl.sys ( CpsFsJnl+1a3ac )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 00000000bad0b0b0, Object type of the object whose reference count is being lowered
Arg2: fffffa801abaa210, 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 objects 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:
------------------
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 000007ff`fffd4018). Type ".hh dbgerr001" for details
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x18
PROCESS_NAME: rxservice.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff800018c3b75 to fffff8000185b350
STACK_TEXT:
fffffa60`04be7818 fffff800`018c3b75 : 00000000`00000018 00000000`bad0b0b0 fffffa80`1abaa210 00000000`00000002 : nt!KeBugCheckEx
fffffa60`04be7820 fffffa60`0315c3ac : fffffa80`00000000 fffffa60`00000000 00000000`00000000 fffff800`01939100 : nt! ?? ::FNODOBFM::`string'+0x2a764
fffffa60`04be78b0 fffffa60`0315e54c : fffffa80`0dfcb1a0 fffffa80`21118c50 fffffa80`4d76fee0 fffffa60`00000020 : CpsFsJnl+0x1a3ac
fffffa60`04be7930 fffffa60`0314663b : fffffa80`0dfcb050 fffffa80`4d76fee0 fffffa80`4d76fee0 00000000`00000001 : CpsFsJnl+0x1c54c
fffffa60`04be79c0 fffff800`01adf31a : fffffa80`0dfcb050 fffffa80`4d76fee0 fffffa80`0e7992c0 fffffa80`00000020 : CpsFsJnl+0x463b
fffffa60`04be79f0 fffff800`01af7fe6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5da
fffffa60`04be7b40 fffff800`0185adf3 : 00000000`00000000 fffffa60`04be7ca0 00000000`00000000 00000000`00000001 : nt!NtDeviceIoControlFile+0x56
fffffa60`04be7bb0 00000000`775a5aea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0478f878 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x775a5aea
STACK_COMMAND: kb
FOLLOWUP_IP:
CpsFsJnl+1a3ac
fffffa60`0315c3ac eb27 jmp CpsFsJnl+0x1a3d5 (fffffa60`0315c3d5)
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: CpsFsJnl+1a3ac
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: CpsFsJnl
IMAGE_NAME: CpsFsJnl.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 48bee06c
FAILURE_BUCKET_ID: X64_0x18_BADMEMREF_CpsFsJnl+1a3ac
BUCKET_ID: X64_0x18_BADMEMREF_CpsFsJnl+1a3ac
Followup: MachineOwner