Investigating 0x805000f STOP errors when copying files on Windows 2003

[chris_hk1]

I have a Windows 2003 installation sitting on an Intel 945GNTL MB, 2.8 GHz P4, 3GB of RAM. For over half a year, the Windows 2003 crash randomly when copying files, causing file corruption/data lost and virtually an unusable server. Quite a bit of time is devoted investigating the problem, and I appreciate if you can help me out

I learned that a server dump may pin point the root of the problem, and I want to dig it out and fix the problem...please let me know any findings, thanks

Case reproduction

1. The case is reproducible either HDD to HDD or network to HDD copy/move operations
2. The case is reproducible using 3 different models of harddrives from 2 manufracturers
3. The case is reproducible in a FRESH installation of Windows 2003 SP2 with a slow (not quick) format, power supply and system/HDD cooling not a problem
4. The case is reproducible when write operation is performed - crash randomly and causing data lost/file corruption -> unuseable server
5. The case is not reproducible when read operation is performed

Event log entry

Event ID:
1076

Description:
The reason supplied by user HKSRV01\Administrator for the last unexpected shutdown of this computer is: System Failure: Stop error
Reason Code: 0x805000f
Bug ID:
Bugcheck String: 0x0000007e (0xc0000005, 0x8088c10b, 0xb95fab28, 0xb95fa824)
Comment: 0x0000007e (0xc0000005, 0x8088c10b, 0xb95fab28, 0xb95fa824)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Debugger output

Opened log file 'c:\debuglog.txt'
kd> .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
kd> .reload;!analyze -v;r;kv;lmnt;.logclose;q
Loading Kernel Symbols
...................................................................................................................
Loading User Symbols

Loading unloaded module list
..........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8088c10b, The address that the exception occurred at
Arg3: b95fab28, Exception Record Address
Arg4: b95fa824, Context Record Address

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!ExDeferredFreePool+105
8088c10b 8b10 mov edx,dword ptr [eax]

EXCEPTION_RECORD: b95fab28 -- (.exr ffffffffb95fab28)
.exr ffffffffb95fab28
ExceptionAddress: 8088c10b (nt!ExDeferredFreePool+0x00000105)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 32731123
Attempt to read from address 32731123

CONTEXT: b95fa824 -- (.cxr ffffffffb95fa824)
.cxr ffffffffb95fa824
eax=32731123 ebx=00000000 ecx=000001ff edx=00000000 esi=8a9bd060 edi=e553a000
eip=8088c10b esp=b95fabf0 ebp=b95fac28 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!ExDeferredFreePool+0x105:
8088c10b 8b10 mov edx,dword ptr [eax] ds:0023:32731123=????????
.cxr
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

READ_ADDRESS: 32731123

BUGCHECK_STR: 0x7E

LAST_CONTROL_TRANSFER: from 8088c881 to 8088c10b

STACK_TEXT:
b95fac28 8088c881 8a9bd060 8997fd48 e553ba40 nt!ExDeferredFreePool+0x105
b95fac7c b8e08722 e553ba38 00000000 b8e0f155 nt!ExFreePoolWithTag+0x54b
b95fac88 b8e0f155 00000015 e553ba40 8997fd48 srv!SrvFreePagedPool+0x2a
b95fac9c b8e114a7 899c1bf0 e553ba40 8976f148 srv!SrvFreeTransaction+0x70
b95facb0 b8e0eb06 00000000 8976f148 e553ba40 srv!SrvDereferenceTransaction+0x6b
b95face8 b8e12772 00000014 00000000 8976f148 srv!SrvCompleteExecuteTransaction+0xd0
b95fad00 b8e11432 b8e0380c 8976f148 89996738 srv!ExecuteTransaction+0x352
b95fad78 b8df4e87 8976f150 89996700 b8e086c7 srv!SrvSmbTransaction+0x7ac
b95fad84 b8e086c7 00000000 8920a8a8 00000000 srv!SrvProcessSmb+0xb7
b95fadac 809418f4 00996700 00000000 00000000 srv!WorkerThread+0x138
b95faddc 80887f4a b8e08602 89996700 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


FOLLOWUP_IP:
nt!ExDeferredFreePool+105
8088c10b 8b10 mov edx,dword ptr [eax]

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

SYMBOL_NAME: nt!ExDeferredFreePool+105

MODULE_NAME: Pool_Corruption

STACK_COMMAND: .cxr 0xffffffffb95fa824 ; kb

FAILURE_BUCKET_ID: 0x7E_nt!ExDeferredFreePool+105

BUCKET_ID: 0x7E_nt!ExDeferredFreePool+105

Followup: Pool_corruption
---------
(Refer to attachment for the rest)