Windows 2003 Server SP1 crashing

I have a Windows 2003 SP1 server running on a DL380 G3. The server has been in production for about 5 months now. The server just started rebooting itself. It happened twice so far. I have attached the two memory dump. Thanks for any help.


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


Loading Dump File [C:\Documents and Settings\dprieto\Desktop\Tereus\Mini111505-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988
Debug session time: Tue Nov 15 03:06:18.170 2005 (GMT-5)
System Uptime: 3 days 17:31:26.210
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
................................................................................................................................
Loading unloaded module list
........................
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c000001d, f6a1a735, f5132d3c, 0}

Unable to load image Haspnt.sys, Win32 error 2
*** WARNING: Unable to verify timestamp for Haspnt.sys
*** ERROR: Module load completed but symbols could not be loaded for Haspnt.sys
Probably caused by : Haspnt.sys ( Haspnt+8735 )

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

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: c000001d, The exception code that was not handled
Arg2: f6a1a735, The address that the exception occurred at
Arg3: f5132d3c, Trap Frame
Arg4: 00000000

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


EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal Instruction An attempt was made to execute an illegal instruction.

FAULTING_IP:
Haspnt+8735
f6a1a735 03e1 add esp,ecx

TRAP_FRAME: f5132d3c -- (.trap fffffffff5132d3c)
ErrCode = 00000000
eax=8001003b ebx=0040001b ecx=00000000 edx=f6a141a8 esi=0040001b edi=f6a14bf2
eip=f6a1a735 esp=f5132db0 ebp=f5132db0 iopl=0 nv up di ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010082
Haspnt+0x8735:
f6a1a735 03e1 add esp,ecx
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x8E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0040a203 to f6a1a735

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f5132db0 0040a203 0040996b 00000220 40000003 Haspnt+0x8735
f5132db4 0040996b 00000220 40000003 00610023 0x40a203
f5132db8 00000000 40000003 00610023 00000023 0x40996b


FAILED_INSTRUCTION_ADDRESS:
Haspnt+8735
f6a1a735 03e1 add esp,ecx

FOLLOWUP_IP:
Haspnt+8735
f6a1a735 03e1 add esp,ecx

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: Haspnt+8735

MODULE_NAME: Haspnt

IMAGE_NAME: Haspnt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3be2ae2a

STACK_COMMAND: .trap fffffffff5132d3c ; kb

FAILURE_BUCKET_ID: 0x8E_BAD_IP_Haspnt+8735

BUCKET_ID: 0x8E_BAD_IP_Haspnt+8735

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



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


Loading Dump File [C:\Documents and Settings\dprieto\Desktop\Tereus\Mini111905-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows Server 2003 Kernel Version 3790 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988
Debug session time: Sat Nov 19 06:49:35.480 2005 (GMT-5)
System Uptime: 4 days 3:42:17.551
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
................................................................................................................................
Loading unloaded module list
.........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 80834f03, f49bfcf0, 0}

Probably caused by : hardware ( nt!CcScanDpc+9 )

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

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: 80834f03, The address that the exception occurred at
Arg3: f49bfcf0, Trap Frame
Arg4: 00000000

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!CcScanDpc+9
80834f03 fa cli

TRAP_FRAME: f49bfcf0 -- (.trap fffffffff49bfcf0)
ErrCode = 00000002
eax=f773d7c0 ebx=0040001b ecx=00000000 edx=f664d1a8 esi=0040001b edi=f664d1a8
eip=80834f03 esp=f49bfd64 ebp=f49bfd64 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!CcScanDpc+0x9:
80834f03 fa cli
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x8E

CURRENT_IRQL: 0

CLI_FAULT_INSTR:
nt!CcScanDpc+9
80834f03 fa cli

LAST_CONTROL_TRANSFER: from badb0d00 to 80834f03

STACK_TEXT:
f49bfd68 badb0d00 f664d1a8 00000000 00000000 nt!CcScanDpc+0x9
WARNING: Frame IP not in any known module. Following frames may be wrong.
f49bfd7c 00000000 00000000 00000000 00000000 0xbadb0d00


FOLLOWUP_IP:
nt!CcScanDpc+9
80834f03 fa cli

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!CcScanDpc+9

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .trap fffffffff49bfcf0 ; kb

MODULE_NAME: hardware

FAILURE_BUCKET_ID: CLI_FAULT

BUCKET_ID: CLI_FAULT

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

 

Hi,

The first minidump is crashed with NT status code c000001d (ie illegal instruction). Usually it is caused by IP_MISALIGNED and it happens when CPU instruction pointer fails to point to the beginning of a valid instruction. Instead, it points into the middle of an instruction. This is believed to be a hardware problem, possibly caused by over-clocking, over-heating, power supply problem or faulty motherboard.

The second minidump is crashed with CLI_FAULT (ie clear interrupt fault) and this is symptom of faulty motherboard.

 

Status update

Hi dap,

Do you have any update?