XCOPY crashing server - help with memory.dmp

Hi Guys.

I have a situation where my server crashes every night due to an xcopy command Im running. Whilst I realise that I could use something else to copy the data I wonder if anyone could look at the below analysis from the memory dump and see if there is anything obvious.

Many regards

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
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: 80816c70, The address that the exception occurred at
Arg3: f3b43c98, 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!wcsstr+4d
80816c70 668b17 mov dx,word ptr [edi]

TRAP_FRAME: f3b43c98 -- (.trap fffffffff3b43c98)
ErrCode = 00000000
eax=0a2b3ad0 ebx=0000c049 ecx=f5df052e edx=00000077 esi=000a3cd8 edi=000a4000
eip=80816c70 esp=f3b43d0c ebp=f3b43d14 iopl=0 nv up ei pl nz ac pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010216
nt!wcsstr+0x4d:
80816c70 668b17 mov dx,word ptr [edi] ds:0023:000a4000=????
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: xcopy.exe

CURRENT_IRQL: 0

IRP_ADDRESS: 000a3d6e

LAST_CONTROL_TRANSFER: from 8085b4b3 to 8087b6be

STACK_TEXT:
f3b43864 8085b4b3 0000008e c0000005 80816c70 nt!KeBugCheckEx+0x1b
f3b43c28 808357a4 f3b43c44 00000000 f3b43c98 nt!KiDispatchException+0x3a2
f3b43c90 80835758 f3b43d14 80816c70 badb0d00 nt!CommonDispatchException+0x4a
f3b43ca4 8084043b 866848b8 00000000 000a2d00 nt!Kei386EoiHelper+0x186
f3b43d14 f5df05a3 000a3dae f5df052e 0007eea4 nt!IopCompleteRequest+0x3d3
WARNING: Stack unwind information not available. Following frames may be wrong.
f3b43d30 80834d3f 00000738 00000000 00000000 wincom32+0x5a3
f3b43d30 7c82ed54 00000738 00000000 00000000 nt!KiFastCallEntry+0xfc
0007ee6c 7c821904 77e612b7 00000738 00000000 ntdll!KiFastSystemCallRet
0007ee70 77e612b7 00000738 00000000 00000000 ntdll!ZwQueryDirectoryFile+0xc
0007eeec 71f869e4 000a0370 0007ef08 0009c608 kernel32!FindNextFileW+0xaa
0007f43c 01005224 0007f458 0007f460 00099aa8 ulib!FSN_DIRECTORY::GetNext+0xcc
0007f470 01005385 0009fe38 0007fc04 0009b1f0 xcopy!XCOPY::Traverse+0x2dc
0007f4b0 01005385 0009e4b8 0007fc04 0009b1f0 xcopy!XCOPY::Traverse+0x43d
0007f4f0 01005d57 0009c6d0 0007fc04 0009b1f0 xcopy!XCOPY::Traverse+0x43d
0007fe48 0100601a 00000000 00000000 7ffd5000 xcopy!XCOPY:oCopy+0x366
0007ff44 01006329 00000003 00034718 00032aa8 xcopy!main+0x68
0007ffc0 77e523cd 00000000 00000000 7ffd5000 xcopy!mainCRTStartup+0x12f
0007fff0 00000000 010061fa 00000000 78746341 kernel32!BaseProcessStart+0x23


STACK_COMMAND: kb

FOLLOWUP_IP:
wincom32+5a3
f5df05a3 85c0 test eax,eax

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: wincom32+5a3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wincom32

IMAGE_NAME: wincom32.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 45b4c0d7

FAILURE_BUCKET_ID: 0x8E_wincom32+5a3

BUCKET_ID: 0x8E_wincom32+5a3

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

 

I would be surprised if it is XCOPY itself that is the problem. If you run an XCOPY job that copies a large folder from one place to another, you are putting a big strain on your server. A strain that can be maintained for tens of minutes. Therefore, I think it more likely that your use of XCOPY has put strain on your hardware and in so doing has triggered a fault.

If I were in you position, I'd look to running a few thorough memory checks and a full hard disk check. Are you using RAID? It could be a RAID controller problem.