Hi, mine is an upper filter volume driver. Using driver verifier, under
very high I/O(File-system based) and cpu workload,
the system crash with PAGE_FAULT_IN_FREED_SPECIAL_POOL.
The crash always occurs with IRP that are associated IRP, that's why I am
posting the question here hoping
that some one that knows the internal of NTFS can point me to the cause of
the trouble since Asscoiated IRPS are most of the time created
by FS drivers, and the file-system in question here is NTFS.
Here is the OS info:
Windows 2000 Kernel Version 2195 (Service Pack 3) MP (2 procs) Free x86
compatible
Product: Server
Kernel base = 0x80400000 PsLoadedModuleList = 0x80483de0
Here is the entire !analyze -v from windbg.
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***
PAGE_FAULT_IN_FREED_SPECIAL_POOL (cc)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: b8412f50, memory referenced
Arg2: 00000000, value 0 = read operation, 1 = write operation
Arg3: 8041dd4d, if non-zero, the address which referenced memory.
Arg4: 00000000, Mm internal code.
Debugging Details:
READ_ADDRESS: b8412f50 Special pool
FAULTING_IP:
nt!IopfCompleteRequest+11d
8041dd4d 8b4750 mov eax,[edi+0x50]
MM_INTERNAL_CODE: 0
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xCC
TRAP_FRAME: f689bae0 -- (.trap fffffffff689bae0)
ErrCode = 00000000
eax=00000002 ebx=00000002 ecx=b8412f0c edx=8046e780 esi=87add588
edi=b8412f00
eip=8041dd4d esp=f689bb54 ebp=87add6ac iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!IopfCompleteRequest+11d:
8041dd4d 8b4750 mov eax,[edi+0x50]
ds:0023:b8412f50=????????
Resetting default context
LAST_CONTROL_TRANSFER: from 805282a0 to 8041dd4d
STACK_TEXT:
f689bb6c 805282a0 00000000 00000000 00000000 nt!IopfCompleteRequest+0x11d
f689bb84 bfe56c75 00001002 8052dcb1 8052db10 nt!IovCompleteRequest+0xa4
f689bbe0 bfe580af 88d70c30 01010000 00009806 MyFilter!WriteComplete+0xf6
f689bd44 bfe41949 88d70c30 01010000 bfe577db MyFilter!ReleaseRequest+0x8d4
f689bd5c bfe46146 88d70c30 00000000 00000000 MyFilter!HandleIO+0x1f
f689bd9c bfe47207 00000000 f689bddc 804554ce MyFilter!MainLoop+0x106
f689bda8 804554ce bfe7cde8 00000000 00000000 MyFilter!threadEntry+0xf
f689bddc 8046a9d2 bfe471f8 bfe7cde8 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
MyFilter!WriteComplete+f6
bfe56c75 ff75fc push dword ptr [ebp-0x4]
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: MyFilter!WriteComplete+f6
MODULE_NAME: MyFilter
IMAGE_NAME: MyFilter.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3f16ba8c
STACK_COMMAND: .trap fffffffff689bae0 ; kb
BUCKET_ID: 0xCC_MyFilter!WriteComplete+f6
Followup: MachineOwner
Using windbg !irp command, I could check out the associated IRP in question:
Irp is active with 4 stacks 6 is current (= 0x8655b4ec)
Mdl = 873c0848 Associated Irp = bf7b1f00 Thread 89059300: Irp is
completed.
Flags = 00000008
ThreadListEntry.Flink = 8655b3d8
ThreadListEntry.Blink = 8655b3d8
IoStatus.Status = 00000000
IoStatus.Information = 00002200
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = 0127d980
Tail.Overlay.Thread = 89059300
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = 8655b4ec
Tail.Overlay.OriginalFileObject = 00000000
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 88a72730 00000000 bfe5725c-88dbf058
\Driver\dmio MyFilter!CompleteWriteRequest
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 88a61030 00000000 bfec2834-86d407e8
\Driver\MyFilter Ntfs!NtfsMultiAsyncCompletionRoutine
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
Extra information not available in free build.
Extra Info:
-From my dispatch write routine I do:
1.IoMarkIrpPending.
2.Return STATUS_PENDING.
-From my completion routine I do:
1.if (Irp->PendingRequest){
IoMarkIrpPending(Irp)
}
2.Put request in Q.
3.Return STATUS_MORE_PROCESSING_REQUIRED.
-From my own worker thread:
1.Call IoCompleteRequest for the IRP.
-This stuff never happens if the I/O is only to raw devices.
It appears, that the I/O manager tries to access some field in the master
IRP which is already freed.
Now, it is possible that I do not handle my IRP correctly, therefore I have
put several DbgPrint statements through the life time of each associated IRP
printing the MasterIrp and IrpCount of the associated IRP. Using DbgView of
OSR I viewed the messages, and all seems normal yet the system crashed again
in the same way.
Could there be some race I am not aware of between the I/O manager
releasing master IRPs and the completion of associated IRPs that is
triggered because of my
weird handling of IRP completion?? Note that on single CPU machine this
thing never happens.
Please help!!!!!!!!!!!!!!!!!!!!!!