James,
Most likely you are facing a situation where your code corrupts memory
through IRP
mishandling. The stack trace shows that the driver verifyer catch this error
while
validating the coherency of an IRP, at free Irp time. By checking the IRP
you can pinpoint
the routines in yuor driver which handled it, and check them for incorrect
handling.
Ciao, Dan
----- Original Message -----
From: “James Dunning”
To: “File Systems Developers”
Sent: Tuesday, September 03, 2002 11:50 AM
Subject: [ntfsd] How to route the source of the Special pool detected memory
corru ption?
> Hi, I am currently having problems with Windows XP stability! the system
> seems to crash at random frequently, usually during bootup, and
occasionally
> after the system has booted up…
>
> I am having problems trying to pinpoint the source of the problem, upon
> analysis of the crash dump file, WinDBG reports that there was a
> SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION, probably caused by ntoskrnl.exe.
> Which doesnt really make sense, I am wondering whether it could be
possible
> that my file system driver could be causing the problem, and the problem
> isnt being detected until later on?
> Is there anyone out there that could advise me how to root the source of
the
> this problem? I have tried the PoolTag utility, but i cant seem to locate
> any tags created by my filesystem driver… is there something i must to
> display my tags?
>
> Regards
> James Dunning
>
>
> kd> !analyze -v
>
*************************************************************************
>
> *
> *
> * Bugcheck Analysis
> *
> *
> *
>
*************************************************************************
>
>
> SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
> Special pool has detected memory corruption. Typically the current
thread’s
> stack backtrace will reveal the guilty party.
> Arguments:
> Arg1: 91c7ef68, address trying to free
> Arg2: 91c7e6fe, address where bits are corrupted
> Arg3: 00410094, (reserved)
> Arg4: 00000023, caller is freeing an address where nearby bytes within the
> same page have been corrupted
>
> Debugging Details:
> ------------------
>
>
> SPECIAL_POOL_CORRUPTION_TYPE: 23
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xC1
>
> LAST_CONTROL_TRANSFER: from 80650568 to 804fc1bb
>
> IRP_ADDRESS: 91c7ef68
>
> STACK_TEXT:
> f8be9b5c 80650568 000000c1 91c7ef68 91c7e6fe nt!KeBugCheckEx+0x19
> f8be9b9c 8053740b 91c7ef68 f8be9c17 ff5bcbc8 nt!MmFreeSpecialPool+0x299
> f8be9bd4 8063f46d 91c7ef68 00000000 8063f5f7 nt!ExFreePoolWithTag+0x45
> f8be9be0 8063f5f7 ff5c2c18 91c7ef68 00000000 nt!VfIrpFree+0xc
> f8be9bfc 8063c9e2 00000000 91c7ef68 f8be9c5c nt!VerifierIoFreeIrp+0x127
> f8be9c0c 804ed17d 91c7ef68 00000103 806b52f0 nt!IovFreeIrpPrivate+0x3f
> f8be9c5c 80571c40 91c7efa8 f8be9c98 f8be9ca4 nt!IopCompleteRequest+0x316
> f8be9c84 8056dc14 ff6bae78 00000000 ff5c2c18
> nt!IopSynchronousServiceTail+0x94
> f8be9d38 804d4e91 000001b0 000001e5 00000000 nt!NtWriteFile+0x5de
> f8be9d38 7ffe0304 000001b0 000001e5 00000000 nt!KiSystemService+0xc4
> 006cfcf8 00000000 00000000 00000000 00000000
> SharedUserData!SystemCallStub+0x4
>
>
> FOLLOWUP_IP:
> nt!MmFreeSpecialPool+299
> 80650568 cc int 3
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nt!MmFreeSpecialPool+299
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntoskrnl.exe
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3b7de38f
>
> STACK_COMMAND: kb
>
> BUCKET_ID: 0xC1_nt!MmFreeSpecialPool+299
>
> Followup: MachineOwner
> ---------
>
>
>
> General Dynamics United Kingdom Limited
> Registered in England and Wales No. 1911653
> Registered Office: 100 New Bridge Street, London, EC4V 6JA
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>