Stop errors in the 7's family tend to be storage related -- Disks or disk controllers.
The fact that you've had drive appear to go bad, and that the failure occurs during a backup of drive E:, reinforces that belief for me. http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=stop+0x77 <http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=stop+0x77>You can try swapping out physical memory, but I'll bet that your disk controller (stand-alone or motherboard embedded) is the real source of your problems here. Where is your pagefile currently stored? Try moving it somewhere else, as the disk it is on might have problems, if not the whole controller. *ASB *(Find me online via About.Me <http://about.me/Andrew.S.Baker/bio>) *Exploiting Technology for Business Advantage... * On Thu, Feb 3, 2011 at 11:12 AM, Kelli Sterley <[email protected]>wrote: > 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 [email protected] with the body: unsubscribe ntsysadmin
