minifilter conflict with other filters (sometimes)

NTFSD
1

Hi All,

After having a rather successful encryption mini-driver implementation, I’ve run into BSODs with antivirus and volume shadowing (symsnap) drivers, but only on an automatic CD burning station.

I’ve run with full driver verifier, checked kernel/fltmgr builds, and clean preFast; but it has been to no avail. It only happens when the driver is enabled, but the driver (named windtalk) is not in any of the stack traces.

I was hoping someone here may be able to give me an idea of what I might be doing, or some things to look at in the kernel dumps. I’ve looked at:
stack overflows
memory usage
hung threads (!stacks and !process 0 7)

I’ve included two of the basic !analyze -v output below (make sure to trim your replies!).

I’d appreciate any ideas you may have.

Thanks!

Justin

Justin M. Walker, CDIA+, ECMp  
<xxxxx><br>Performance Testing Engineer<br>Hyland Software <http:><br>Office: 440.788.5461<br>Mobile: 216.956.0576<br>Fax: 440.788.5561<br><br> *******************************************************************************<br>* *<br>* Bugcheck Analysis *<br>* *<br>******************************************************************************* <br><br>NTFS_FILE_SYSTEM (24)<br> If you see NtfsExceptionFilter on the stack then the 2nd and 3rd<br> parameters are the exception record and context record. Do a .cxr<br> on the 3rd parameter and then kb to obtain a more informative stack<br> trace.<br>Arguments:<br>Arg1: 001902fe<br>Arg2: f78ee7cc<br>Arg3: f78ee4c8<br>Arg4: 80550ae2<br><br>Debugging Details:<br>------------------<br><br>EXCEPTION_RECORD: f78ee7cc -- (.exr fffffffff78ee7cc)<br>ExceptionAddress: 80550ae2 (nt!ExDeferredFreePool+0x00000107)<br> ExceptionCode: c0000005 (Access violation)<br> ExceptionFlags: 00000000<br>NumberParameters: 2<br> Parameter[0]: 00000001<br> Parameter[1]: 00000000<br>Attempt to write to address 00000000<br><br>CONTEXT: f78ee4c8 -- (.cxr fffffffff78ee4c8)<br>eax=c0000120 ebx=00000000 ecx=000001ff edx=c0000120 esi=8a6e5050 edi=00000000<br>eip=80550ae2 esp=f78ee894 ebp=f78ee8d4 iopl=0 nv up ei ng nz ac po cy<br>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297<br>nt!ExDeferredFreePool+0x107:<br>80550ae2 893b mov [ebx],edi ds:0023:00000000=????????<br>Resetting default scope<br><br>DEFAULT_BUCKET_ID: DRIVER_FAULT<br><br>ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".<br><br>WRITE_ADDRESS: 00000000 <br><br>BUGCHECK_STR: 0x24<br><br>LAST_CONTROL_TRANSFER: from 80550ac7 to 80550ae2<br><br>STACK_TEXT: <br>f78ee8d4 80550ac7 00000001 804dbe35 f78ee980 nt!ExDeferredFreePool+0x107<br>f78ee914 805503e3 e1144c58 00000000 f78ee930 nt!ExFreePoolWithTag+0x47f<br>f78ee924 f7b547bb e1144c58 f78ee958 f7b9111c nt!ExFreePool+0xf<br>f78ee930 f7b9111c f7b71a20 e1144c58 8a4b89b0 Ntfs!ExFreeToPagedLookasideList+0x1e<br>f78ee958 f7b583bf 8a17bb30 f78ee980 f78ee98b Ntfs!NtfsDeleteFcb+0x205<br>f78ee9a4 f7b79c7c 8a17bb30 8a4b8850 e1144c58 Ntfs!NtfsTeardownFromLcb+0x1fd<br>f78ee9fc f7b547b0 8a17bb30 e1144d20 00000000 Ntfs!NtfsTeardownStructures+0x125<br>f78eea28 f7b774b5 8a17bb30 01144d20 00000000 Ntfs!NtfsDecrementCloseCounts+0x9e<br>f78eeaac f7b77254 8a17bb30 e1144d20 e1144c58 Ntfs!NtfsCommonClose+0x397<br>f78eeb4c 804e13d9 8a4b8770 8914f008 8914f1d8 Ntfs!NtfsFsdClose+0x21f<br>f78eeb5c f744bd80 804e84d5 8a4b9f30 8a4b9f74 nt!IopfCallDriver+0x31<br>WARNING: Stack unwind information not available. Following frames may be wrong.<br>f78eeb70 f74453e7 8a4b9eb0 8914f008 00000000 symsnap+0x8d80<br>f78eeb90 f744b73c 8a4b9f30 8914f008 0021f400 symsnap+0x23e7<br>f78eec64 f744bba0 8a4b9df8 8914f008 00000000 symsnap+0x873c<br>f78eec80 804e13d9 8a4b9df8 8914f008 8914f008 symsnap+0x8ba0<br>f78eecfc 8057c40b 88ab9e60 00000000 00000000 nt!IopfCallDriver+0x31<br>f78eed34 8056c78f 00ab9e78 00000000 88ab9e60 nt!IopDeleteFile+0x132<br>f78eed50 804e1957 88ab9e78 00000000 806ffa4c nt!ObpRemoveObjectRoutine+0xdf<br>f78eed68 804f60d2 806ffaa8 8a2dd3f0 80566b34 nt!ObfDereferenceObject+0x4c<br>f78eed8c 8051b154 e1b32008 00000000 8a6b4020 nt!MiSegmentDelete+0xed<br>f78eedac 80574128 00000000 00000000 00000000 nt!MiDereferenceSegmentThread+0xa7<br>f78eeddc 804ec781 80509641 00000000 00000000 nt!PspSystemThreadStartup+0x34<br>00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16<br><br>FOLLOWUP_IP: <br>nt!ExDeferredFreePool+107<br>80550ae2 893b mov [ebx],edi<br><br>SYMBOL_STACK_INDEX: 0<br><br>FOLLOWUP_NAME: Pool_corruption<br><br>SYMBOL_NAME: nt!ExDeferredFreePool+107<br><br>MODULE_NAME: Pool_Corruption<br><br>IMAGE_NAME: Pool_Corruption<br><br>DEBUG_FLR_IMAGE_TIMESTAMP: 0<br><br>STACK_COMMAND: .cxr fffffffff78ee4c8 ; kb<br><br>FAILURE_BUCKET_ID: 0x24_nt!ExDeferredFreePool+107<br><br>BUCKET_ID: 0x24_nt!ExDeferredFreePool+107<br><br>Followup: Pool_corruption<br>---------<br><br> *******************************************************************************<br>* *<br>* Bugcheck Analysis *<br>* *<br>******************************************************************************* <br><br>KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)<br>This is a very common bugcheck. Usually the exception address pinpoints<br>the driver/function that caused the problem. Always note this address<br>as well as the link date of the driver/image that contains this address.<br>Some common problems are exception code 0x80000003. This means a hard<br>coded breakpoint or assertion was hit, but this system was booted<br>/NODEBUG. This is not supposed to happen as developers should never have<br>hardcoded breakpoints in retail code, but ...<br>If this happens, make sure a debugger gets connected, and the<br>system is booted /DEBUG. This will let us see why this breakpoint is<br>happening.<br>Arguments:<br>Arg1: c0000005, The exception code that was not handled<br>Arg2: 8054a71c, The address that the exception occurred at<br>Arg3: ba14d6f8, Trap Frame<br>Arg4: 00000000<br><br>Debugging Details:<br>------------------<br><br>EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".<br><br>FAULTING_IP: <br>nt!ExFreePoolWithTag+43c<br>8054a71c 668b4b04 mov cx,[ebx+0x4]<br><br>TRAP_FRAME: ba14d6f8 -- (.trap ffffffffba14d6f8)<br>ErrCode = 00000000<br>eax=f78b2120 ebx=00000000 ecx=00000000 edx=00000000 esi=c0000120 edi=80563c20<br>eip=8054a71c esp=ba14d76c ebp=ba14d7a0 iopl=0 nv up ei pl zr na po nc<br>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246<br>nt!ExFreePoolWithTag+0x43c:<br>8054a71c 668b4b04 mov cx,[ebx+0x4] ds:0023:00000004=????<br>Resetting default scope<br><br>DEFAULT_BUCKET_ID: DRIVER_FAULT<br><br>BUGCHECK_STR: 0x8E<br><br>LAST_CONTROL_TRANSFER: from 8054a95f to 8054a71c<br><br>STACK_TEXT: <br>ba14d7a0 8054a95f c0000128 00000000 ba14d7bc nt!ExFreePoolWithTag+0x43c<br>ba14d7b0 b87410b5 c0000128 ba14d7d4 b873208f nt!ExFreePool+0xf<br>WARNING: Stack unwind information not available. Following frames may be wrong.<br>ba14d7bc b873208f c0000128 862e4540 b873389c mfehidk!DEVICEDISPATCH::LowerDevicePassThrough+0x1289<br>ba14d7d4 b873314c 00000001 862e5e28 b874eb4c mfehidk+0x808f<br>ba14d7f4 b873b1d3 00dcde4c 00dcde40 ba14d854 mfehidk+0x914c<br>ba14d82c b873d7c5 862e5e28 ba14d830 ba14d848 mfehidk+0x111d3<br>ba14d868 f6efda40 ffffffff 80538d00 804da150 mfehidk+0x137c5<br>ba14d890 7c8099f0 001780f8 00000001 ba14db60 serial!SerialCIsrSw+0x10<br>ba14d978 80502d48 00000000 8654d868 804fac40 kernel32!LocalAlloc+0x168<br>ba14da38 b873f0c9 86352e98 864c5da0 ba14da70 nt!KiSwapThread+0xac<br>ba14da48 b873f119 ba14da58 86321030 863df2d8 mfehidk+0x150c9<br>ba14da80 80582341 86771bf0 85795db4 ba14dc18 mfehidk!DEVICEDISPATCH::DispatchPassThrough+0x48<br>ba14db70 bf81368f 00000002 ba14dbb4 00000018 nt!IopParseDevice+0xde5<br>ba14dbf4 bf813836 bbe62be8 00000403 00000780 win32k!SfnDWORD+0xa8<br>ba14dc3c bf8446a8 00e62be8 00000403 00000780 win32k!xxxSendMessageToClient+0x118<br>ba14dcac bf801f00 e2d1aaa8 ba14dd64 00000000 win32k!xxxReceiveMessage+0x2b5<br>ba14dce8 bf80370a ba14dd14 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x1d7<br>ba14dd48 8054086c 00dcfe20 00000000 00000000 win32k!NtUserPeekMessage+0x40<br>ba14dd48 7c90eb94 00dcfe20 00000000 00000000 nt!KiFastCallEntry+0xfc<br>00dcfd80 7c90eae3 00dcfd90 00000018 00542be8 ntdll!KiFastSystemCallRet<br>00dcfd80 80500c14 00dcfd90 00000018 00542be8 ntdll!KiUserCallbackDispatcher+0x13<br>ba14db14 805a0829 ba14dbd0 ba14dbd4 ba14dba4 nt!KiCallUserMode+0x4<br>ba14db70 bf81368f 00000002 ba14dbb4 00000018 nt!KeUserModeCallback+0x87<br>ba14dbf4 bf813836 bbe62be8 00000403 00000780 win32k!SfnDWORD+0xa8<br>ba14dc3c bf8446a8 00e62be8 00000403 00000780 win32k!xxxSendMessageToClient+0x118<br>ba14dcac bf801f00 e2d1aaa8 ba14dd64 00000000 win32k!xxxReceiveMessage+0x2b5<br>ba14dce8 bf80370a ba14dd14 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x1d7<br>ba14dd48 8054086c 00dcfe20 00000000 00000000 win32k!NtUserPeekMessage+0x40<br>ba14dd48 7c90eb94 00dcfe20 00000000 00000000 nt!KiFastCallEntry+0xfc<br>00dcfd80 7c90eae3 00dcfd90 00000018 00542be8 ntdll!KiFastSystemCallRet<br>00dcfda4 7e4193e9 7e4193a8 00dcfe20 00000000 ntdll!KiUserCallbackDispatcher+0x13<br>00dcfdd0 7e419402 00dcfe20 00000000 00000000 USER32!NtUserPeekMessage+0xc<br>00dcfdfc 7c9f52bd 00dcfe20 00000000 00000000 USER32!PeekMessageW+0xbc<br>00dcfe3c 7c9f51d3 00000000 00000000 00000000 SHELL32!CChangeNotify::_HandleMessages+0x43<br>00dcff4c 7ca0ab7c 77f76f02 00000000 7c80995a SHELL32!CChangeNotify::_MessagePump+0x52<br>00dcff50 77f76f02 00000000 7c80995a 00090000 SHELL32!CChangeNotify::ThreadProc+0x1e<br>00dcffb4 7c80b683 00000000 7c80995a 00090000 SHLWAPI!WrapperThreadProc+0x94<br>00dcffec 00000000 77f76e93 00c9f4d4 00000000 kernel32!BaseThreadStart+0x37<br><br>FOLLOWUP_IP: <br>nt!ExFreePool+f<br>8054a95f 5d pop ebp<br><br>SYMBOL_STACK_INDEX: 1<br><br>FOLLOWUP_NAME: Pool_corruption<br><br>SYMBOL_NAME: nt!ExFreePool+f<br><br>MODULE_NAME: Pool_Corruption<br><br>IMAGE_NAME: Pool_Corruption<br><br>DEBUG_FLR_IMAGE_TIMESTAMP: 0<br><br>STACK_COMMAND: .trap ffffffffba14d6f8 ; kb<br><br>FAILURE_BUCKET_ID: 0x8E_nt!ExFreePool+f<br><br>BUCKET_ID: 0x8E_nt!ExFreePool+f<br><br>Followup: Pool_corruption<br>---------</http:></xxxxx>
2

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Thursday, January 31, 2008 10:00 AM
Subject: [ntfsd] minifilter conflict with other filters (sometimes)

Justin,

In general, when you have varying stop codes as these two dumps show, your
thrashing
memory somewhere.

I’m neither a pro at writing drivers or reading dumps, but I do see in both
dumps that
your crash happens soon after an ExFreePool call.

In the first dump:

f78ee8d4 80550ac7 00000001 804dbe35 f78ee980 nt!ExDeferredFreePool+0x107
f78ee914 805503e3 e1144c58 00000000 f78ee930 nt!ExFreePoolWithTag+0x47f
f78ee924 f7b547bb e1144c58 f78ee958 f7b9111c nt!ExFreePool+0xf

and in the second dump:

ba14d7a0 8054a95f c0000128 00000000 ba14d7bc nt!ExFreePoolWithTag+0x43c
ba14d7b0 b87410b5 c0000128 ba14d7d4 b873208f nt!ExFreePool+0xf

In both dumps, your driver appears to blowup shortly after you free a pool.
If I were you,
I’d look at the logic of allocating and freeing these pools. Accessing a
pool that has already
been freed could result in varying crashes.

I don’t believe DV would catch this type of error.

Just my two cents,

Good Luck,

Matt

3

Hi Matt,

Yea, that’s one of the first things I checked out. However, the pools seem to belong to these 3rd party drivers (such as mfehidk-mcafee). I made sure to tag all my pool allocations. I thought I must be thrashing a pointer somewhere, but I do all my deallocations with tags as well.

I am going to take a closer look at them though. Thanks for the advice!

-Justin

4

I should probably specify that the dump files come from two different computers. One has McAfee installed (and only bugchecks when it’s on) and the other has some sort of backup or imaging software installed, thus the symsnap driver.

-Justin

5

Hi.

Is this error bound to a particular OS?

I am just guessing, but when I take a look at first dump…the problem
“referencing FileObjects, that reside on the stack” comes into my mind. Are
you referencing FileObjects in your driver?

Regards

wrote news:xxxxx@ntfsd…
> Hi All,
>
> After having a rather successful encryption mini-driver implementation,
> I’ve run into BSODs with antivirus and volume shadowing (symsnap) drivers,
> but only on an automatic CD burning station.
>
> I’ve run with full driver verifier, checked kernel/fltmgr builds, and
> clean preFast; but it has been to no avail. It only happens when the
> driver is enabled, but the driver (named windtalk) is not in any of the
> stack traces.
>
> I was hoping someone here may be able to give me an idea of what I might
> be doing, or some things to look at in the kernel dumps. I’ve looked at:
> stack overflows
> memory usage
> hung threads (!stacks and !process 0 7)
>
> I’ve included two of the basic !analyze -v output below (make sure to trim
> your replies!).
>
> I’d appreciate any ideas you may have.
>
> Thanks!
>
> Justin
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Justin M. Walker, CDIA+, ECMp
>
> Performance Testing Engineer
> Hyland Software http:
> Office: 440.788.5461
> Mobile: 216.956.0576
> Fax: 440.788.5561
>
>
>
></http:>

6

Yes, I do reference FileObjects as a way to keep track of context information. I hash and track the handles and I hope I haven’t done something stupid in doing that. Is there a precaution I should be taking when referencing it?

Here are the basic operations of the driver:

PreCreate
Try to find guid postfix on filename
If it exists, remove it, save the handle, send a reparse

PostCreate
Clear Cache / Mapped Files

PreRead
Change read size for encryption blocks

PostRead
Decrypt, send back original file read size

PreCleanup
Remove file handles from hash, cleanup contexts

Thanks!

Justin

7

Furthermore RefCount will be bumped implicitly by initiating cached I/O on a
FileObj.

Read this article to get more information:
http://www.osronline.com/article.cfm?article=219

Maybe this objective is related to your problem. Good luck.

wrote news:xxxxx@ntfsd…
> Yes, I do reference FileObjects as a way to keep track of context
> information. I hash and track the handles and I hope I haven’t done
> something stupid in doing that. Is there a precaution I should be taking
> when referencing it?
>
> Here are the basic operations of the driver:
>
> PreCreate
> Try to find guid postfix on filename
> If it exists, remove it, save the handle, send a reparse
>
> PostCreate
> Clear Cache / Mapped Files
>
> PreRead
> Change read size for encryption blocks
>
> PostRead
> Decrypt, send back original file read size
>
> PreCleanup
> Remove file handles from hash, cleanup contexts
>
>
>
> Thanks!
>
> Justin
>