HP ProLiant DL380 G3 Running Windows Server 2000 has crashed between 6-7:30am for the past 5 days
- by user109717
I have a HP ProLiant DL380 G3 running Windows Server 2000 that has been crashing everyday between 6-730am. This started when I changed out a failing hard drive 6 days ago. I have looked at the scheduled tasks which does not have anything pertaining to this issue. Below are the only things I see in the system log and some of the dump files. Can this be a hardware issue if this happens at a certain time frame everyday? Any help is greatly appreciated. Thanks
The previous system shutdown at 6:07:55 AM on 2/7/2012 was unexpected.
System Information Agent: Health: The server is operational again.
The server has previously been shutdown by the Automatic Server
Recovery (ASR) feature and has just become operational again.
[SNMP TRAP: 6025 in CPQHLTH.MIB]
BugCheck 7A, {3, c0000005, 3400028, 0}
Probably caused by : memory_corruption ( nt!MiMakeSystemAddressValidPfn+42 )
Followup: MachineOwner
0: kd !analyze -v
*
Bugcheck Analysis *
*
KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: 00000003, lock type that was held (value 1,2,3, or PTE address)
Arg2: c0000005, error status (normally i/o status code)
Arg3: 03400028, current process (virtual address for lock type 3, or PTE)
Arg4: 00000000, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
MODULE_NAME: nt
IMAGE_NAME: memory_corruption
BugCheck A, {0, 2, 1, 804137d6}
Probably caused by : ntkrnlmp.exe ( nt!CcGetVirtualAddress+ba )
*
Bugcheck Analysis *
*
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 804137d6, address which referenced memory
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
