We had that same error and it ending up being the memory on the raid card. Swapped with a backup server we had retired from another client and it came right up with zero issues.
Greg Sweers CEO ACTS360.com<http://www.acts360.com/> P.O. Box 1193 Brandon, FL 33509 813-657-0849 Office 813-758-6850 Cell 813-341-1270 Fax From: Kelli Sterley [mailto:kjsterley.li...@gmail.com] Sent: Thursday, February 03, 2011 11:12 AM To: NT System Admin Issues Subject: Memory Dump File I am trying to decipher a memory dump on a Win2003 server. From everything I can read within, it looks like bad memory. We also had a hard drive fail (two drives, RAID 1, 2 partitions) which was replaced a day or so before this memory dump. Does it look like memory to anyone else? Or maybe the controller? This server is 4 years old and has just begun acting up. We are running AppAssure Replay for our backups and the crashes seem to co-inside with backing up our E drive. It almost finishes but each time it gets about 3/4 done, it will crash. I think it's just a coincidence but maybe not? It has blue screened 4 times in the last week, 3 produced mini dumps but the last did not produce one. Thanks for any help... Kelli ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 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:\tools\symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible Product: Server, suite: TerminalServer SingleUserTS Blade Built by: 3790.srv03_sp2_gdr.100216-1301 Machine Name: Kernel base = 0x80800000 PsLoadedModuleList = 0x808af9c8 Debug session time: Mon Jan 31 21:45:38.518 2011 (UTC - 5:00) System Uptime: 0 days 10:14:37.652 Loading Kernel Symbols ............................................................... ...................................................... Loading User Symbols Loading unloaded module list .. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 77, {c000009d, c000009d, 0, 1277000} Probably caused by : memory_corruption ( nt!MiMakeOutswappedPageResident+40b ) Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_STACK_INPAGE_ERROR (77) The requested page of kernel data could not be read in. Caused by bad block in paging file or disk controller error. In the case when the first arguments is 0 or 1, the stack signature in the kernel stack was not found. Again, bad hardware. An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates the data could not be read from the disk due to a bad block. Upon reboot autocheck will run and attempt to map out the bad sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging file is on a SCSI disk device, then the cabling and termination should be checked. See the knowledge base article on SCSI termination. Arguments: Arg1: c000009d, status code Arg2: c000009d, i/o status code Arg3: 00000000, page file number Arg4: 01277000, offset into page file Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc000009d - STATUS_DEVICE_NOT_CONNECTED DISK_HARDWARE_ERROR: There was error with disk hardware BUGCHECK_STR: 0x77_c000009d DEFAULT_BUCKET_ID: DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from 80863624 to 8087c4a0 STACK_TEXT: f791ecc8 80863624 00000077 c000009d c000009d nt!KeBugCheckEx+0x1b f791ed34 8084ebb2 c03dc36c c03dc36c 00000001 nt!MiMakeOutswappedPageResident+0x40b f791ed68 8084ebf8 89c58db0 f791ed78 f70dc000 nt!MiInPageSingleKernelStack+0x104 f791ed8c 8084ec17 89c58db0 00000000 89f8a020 nt!MmInPageKernelStack+0x39 f791eda4 8084abcd 89c58e10 809208bb 00000000 nt!KiInSwapKernelStacks+0x16 f791edac 809208bb 00000000 00000000 00000000 nt!KeSwapProcessOrStack+0x7c f791eddc 8083fe9f 8084ab56 00000000 00000000 nt!PspSystemThreadStartup+0x2e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 STACK_COMMAND: kb FOLLOWUP_IP: nt!MiMakeOutswappedPageResident+40b 80863624 cc int 3 SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: nt!MiMakeOutswappedPageResident+40b FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4b7aa3ac IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: 0x77_c000009d_nt!MiMakeOutswappedPageResident+40b BUCKET_ID: 0x77_c000009d_nt!MiMakeOutswappedPageResident+40b Followup: MachineOwner --------- ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
