SRV.sys BSOD
Hi Experts,
I'm in a dilly of a pickle... about twice a week one of our servers Blue screens. I have copied the MiniDump below. Can anyone shed some light? Please?
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Program Files\Debugging Tools for Windows (x86)\Mini091608-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: C:\Program Files\Debugging Tools for Windows (x86)\sym
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070304-
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Tue Sep 16 15:51:14.458 2008 (GMT+10)
System Uptime: 13 days 7:06:25.132
Loading Kernel Symbols
..........................
Loading User Symbols
Loading unloaded module list
..........................
**************************
* *
* Bugcheck Analysis *
* *
**************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {c0000005, 8082e031, b6217b78, b6217874}
Probably caused by : srv.sys ( srv!SrvTerminateWorkerThre
Followup: MachineOwner
---------
1: kd> !analyze -v
**************************
* *
* Bugcheck Analysis *
* *
**************************
SYSTEM_THREAD_EXCEPTION_NO
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8082e031, The address that the exception occurred at
Arg3: b6217b78, Exception Record Address
Arg4: b6217874, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
nt!KiDeliverApc+129
8082e031 3900 cmp dword ptr [eax],eax
EXCEPTION_RECORD: b6217b78 -- (.exr 0xffffffffb6217b78)
ExceptionAddress: 8082e031 (nt!KiDeliverApc+0x0000012
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000029
Attempt to read from address 00000029
CONTEXT: b6217874 -- (.cxr 0xffffffffb6217874)
eax=00000029 ebx=80a5a530 ecx=8082196c edx=9f560d98 esi=00000001 edi=9f560dd8
eip=8082e031 esp=b6217c40 ebp=b6217c74 iopl=0 nv up ei pl nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
nt!KiDeliverApc+0x129:
8082e031 3900 cmp dword ptr [eax],eax ds:0023:00000029=00000000
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
CURRENT_IRQL: 1
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
READ_ADDRESS: 00000029
BUGCHECK_STR: 0x7E
EXCEPTION_STR: 0x0
LAST_CONTROL_TRANSFER: from 80a5c199 to 8082e031
STACK_TEXT:
b6217c74 80a5c199 00000000 00000000 00000000 nt!KiDeliverApc+0x129
b6217c94 80a5c3d9 80947701 00000000 00000038 hal!HalpDispatchSoftwareIn
b6217cb0 80a5c456 00000000 80947700 b6217d44 hal!HalpCheckForSoftwareIn
b6217cc0 8094bf3a 9e4fcdb0 9e4fcff0 00000000 hal!KfLowerIrql+0x62
b6217d44 8094c63f 00000000 00000102 00000000 nt!PspExitThread+0x40
b6217d5c 8094c9dc 9e4fcdb0 00000000 00000001 nt!PspTerminateThreadByPoi
b6217d70 b90b391d 00000000 00000000 00000010 nt!PsTerminateSystemThread
b6217d84 b90ce399 00000000 9e4fcdb0 00000000 srv!SrvTerminateWorkerThre
b6217dac 80949b7c 004f7260 00000000 00000000 srv!WorkerThread+0xa1
b6217ddc 8088e062 b90c7602 a24f7260 00000000 nt!PspSystemThreadStartup+
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
srv!SrvTerminateWorkerThre
b90b391d 5e pop esi
SYMBOL_STACK_INDEX: 7
SYMBOL_NAME: srv!SrvTerminateWorkerThre
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: srv
IMAGE_NAME: srv.sys
DEBUG_FLR_IMAGE_TIMESTAMP:
STACK_COMMAND: .cxr 0xffffffffb6217874 ; kb
FAILURE_BUCKET_ID: 0x7E_srv!SrvTerminateWorke
BUCKET_ID: 0x7E_srv!SrvTerminateWorke
Followup: MachineOwner
---------
I'm in a dilly of a pickle... about twice a week one of our servers Blue screens. I have copied the MiniDump below. Can anyone shed some light? Please?
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Program Files\Debugging Tools for Windows (x86)\Mini091608-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: C:\Program Files\Debugging Tools for Windows (x86)\sym
Executable search path is:
Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp2_gdr.070304-
Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Debug session time: Tue Sep 16 15:51:14.458 2008 (GMT+10)
System Uptime: 13 days 7:06:25.132
Loading Kernel Symbols
..........................
Loading User Symbols
Loading unloaded module list
..........................
**************************
* *
* Bugcheck Analysis *
* *
**************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {c0000005, 8082e031, b6217b78, b6217874}
Probably caused by : srv.sys ( srv!SrvTerminateWorkerThre
Followup: MachineOwner
---------
1: kd> !analyze -v
**************************
* *
* Bugcheck Analysis *
* *
**************************
SYSTEM_THREAD_EXCEPTION_NO
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8082e031, The address that the exception occurred at
Arg3: b6217b78, Exception Record Address
Arg4: b6217874, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
FAULTING_IP:
nt!KiDeliverApc+129
8082e031 3900 cmp dword ptr [eax],eax
EXCEPTION_RECORD: b6217b78 -- (.exr 0xffffffffb6217b78)
ExceptionAddress: 8082e031 (nt!KiDeliverApc+0x0000012
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000029
Attempt to read from address 00000029
CONTEXT: b6217874 -- (.cxr 0xffffffffb6217874)
eax=00000029 ebx=80a5a530 ecx=8082196c edx=9f560d98 esi=00000001 edi=9f560dd8
eip=8082e031 esp=b6217c40 ebp=b6217c74 iopl=0 nv up ei pl nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
nt!KiDeliverApc+0x129:
8082e031 3900 cmp dword ptr [eax],eax ds:0023:00000029=00000000
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
CURRENT_IRQL: 1
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
READ_ADDRESS: 00000029
BUGCHECK_STR: 0x7E
EXCEPTION_STR: 0x0
LAST_CONTROL_TRANSFER: from 80a5c199 to 8082e031
STACK_TEXT:
b6217c74 80a5c199 00000000 00000000 00000000 nt!KiDeliverApc+0x129
b6217c94 80a5c3d9 80947701 00000000 00000038 hal!HalpDispatchSoftwareIn
b6217cb0 80a5c456 00000000 80947700 b6217d44 hal!HalpCheckForSoftwareIn
b6217cc0 8094bf3a 9e4fcdb0 9e4fcff0 00000000 hal!KfLowerIrql+0x62
b6217d44 8094c63f 00000000 00000102 00000000 nt!PspExitThread+0x40
b6217d5c 8094c9dc 9e4fcdb0 00000000 00000001 nt!PspTerminateThreadByPoi
b6217d70 b90b391d 00000000 00000000 00000010 nt!PsTerminateSystemThread
b6217d84 b90ce399 00000000 9e4fcdb0 00000000 srv!SrvTerminateWorkerThre
b6217dac 80949b7c 004f7260 00000000 00000000 srv!WorkerThread+0xa1
b6217ddc 8088e062 b90c7602 a24f7260 00000000 nt!PspSystemThreadStartup+
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
srv!SrvTerminateWorkerThre
b90b391d 5e pop esi
SYMBOL_STACK_INDEX: 7
SYMBOL_NAME: srv!SrvTerminateWorkerThre
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: srv
IMAGE_NAME: srv.sys
DEBUG_FLR_IMAGE_TIMESTAMP:
STACK_COMMAND: .cxr 0xffffffffb6217874 ; kb
FAILURE_BUCKET_ID: 0x7E_srv!SrvTerminateWorke
BUCKET_ID: 0x7E_srv!SrvTerminateWorke
Followup: MachineOwner
---------
ASKER
Srv.sys File Versoin: 5.2.3790.3959
mini dump is attached.
thanks.
mini dump is attached.
thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I think the latest service pack resolves SRV.sys problems. So, you might try downloading the latest SP before applying the hotfix, or at least looking at the latest SP to see what fixes are on that Service Pack.
Looking at the file version, I am assuming you are already at SP2 level and the hotfix is post-SP2. So there won;t be any issues in updating the binary to the latest available.
Let me know if you have any questions
Let me know if you have any questions
ASKER
thanks ashishsa. I will try installing the MS hotfix in the next few days, and I'II let you know in about a week after that If the server has stopped Blue screening.
yes, the server is already on SP2.
yes, the server is already on SP2.
ASKER
thanks Ashishsa,
I have applied the hotfix to move srv.sys from Srv.sys File Versoin: 5.2.3790.3959 to Srv.sys File Versoin: 5.2.3790.4293
the server hasn't crashed with the BSOD since.
I'm very greatful for you assistance.
I have applied the hotfix to move srv.sys from Srv.sys File Versoin: 5.2.3790.3959 to Srv.sys File Versoin: 5.2.3790.4293
the server hasn't crashed with the BSOD since.
I'm very greatful for you assistance.
Also what is the version of srv.sys file on your machine?