I am getting bugcheck DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS (cb) using the swapbuffers sample on an XP machine. I removed the registration for the read and write callbacks since I am only interested in the directory control callbacks.
Has anyone seen this before or have any ideas what I might do to resolve it?
The BSOD itself points to fltmgr.sys. Enabling verifier on swapbuffers.sys does not provide any addition info that I can see. The bugcheck appears in a different process each time I repro it.
Here is the stack:
eea15c3c 80525f72 000000cb 8062b3f5 baf11308 nt!KeBugCheckEx+0x1b
eea15c80 8058dfca 85e284f8 85e25da8 85e25ff0 nt!MmCleanProcessAddressSpace+0x353
eea15d08 805739b4 00000000 85e25da8 00000000 nt!PspExitThread+0x621
eea15d28 8058e369 85e25da8 00000000 eea15d64 nt!PspTerminateThreadByPointer+0x52
eea15d54 804dd99f 00000000 00000000 0012ff1c nt!NtTerminateProcess+0x118
eea15d54 7c90eb94 00000000 00000000 0012ff1c nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012ff1c 00000000 00000000 00000000 00000000 0x7c90eb94
So, please, allow me to ask first - does the problem arise if you use the
unmodified swapbuffers?
wrote in message news:xxxxx@ntfsd…
>I am getting bugcheck DRIVER_LEFT_LOCKED_PAGES_IN_PROCESS (cb) using the
>swapbuffers sample on an XP machine. I removed the registration for the
>read and write callbacks since I am only interested in the directory
>control callbacks.
>
> Has anyone seen this before or have any ideas what I might do to resolve
> it?
>
> The BSOD itself points to fltmgr.sys. Enabling verifier on
> swapbuffers.sys does not provide any addition info that I can see. The
> bugcheck appears in a different process each time I repro it.
>
> Here is the stack:
>
> eea15c3c 80525f72 000000cb 8062b3f5 baf11308 nt!KeBugCheckEx+0x1b
> eea15c80 8058dfca 85e284f8 85e25da8 85e25ff0
> nt!MmCleanProcessAddressSpace+0x353
> eea15d08 805739b4 00000000 85e25da8 00000000 nt!PspExitThread+0x621
> eea15d28 8058e369 85e25da8 00000000 eea15d64
> nt!PspTerminateThreadByPointer+0x52
> eea15d54 804dd99f 00000000 00000000 0012ff1c nt!NtTerminateProcess+0x118
> eea15d54 7c90eb94 00000000 00000000 0012ff1c nt!KiFastCallEntry+0xfc
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0012ff1c 00000000 00000000 00000000 00000000 0x7c90eb94
>
>
>
>
I considered that, but I have not yet tested it unmodified since I have no interest in read/write.
I will try it tomorrow when able.
However, I really don’t see any connection between the three operations since each allocates its own buffers and MDLs. I also don’t see how read/write would have any connection to a directory query.
Well, it’s kind of a ‘null’ test - might be informative for your 
wrote in message news:xxxxx@ntfsd…
>I considered that, but I have not yet tested it unmodified since I have no
>interest in read/write.
>
> I will try it tomorrow when able.
>
> However, I really don’t see any connection between the three operations
> since each allocates its own buffers and MDLs. I also don’t see how
> read/write would have any connection to a directory query.
>
Ok, I just tested this and it still BSODs with the same bugcheck. I also downloaded the latest WDK last night and did a Windiff on the source code in the latest and a previous version of the WDK and they are identical.
Did you modify the SwapBuffers code or did you just remove processing of IRP_MJ_READ/WRITE?
xxxxx@charter.net wrote:
Ok, I just tested this and it still BSODs with the same bugcheck. I also downloaded the latest WDK last night and did a Windiff on the source code in the latest and a previous version of the WDK and they are identical.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
I just commented out the entries for IRP_MJ_READ/IRP_MJ_WRITE in the FLT_OPERATION_REGISTRATION structure. But as I noted in my previous post, it doesn’t make any difference. The unmodified code BSODs with the same bugcheck.
I have tried many things to get this to stop bugchecking. I have tried not calling FltDoCompletionProcessingWhenSafe, I have tried freeing the MDLs myself, I have tried not allocating any new MDLs at all, etc and it still bugchecks. Note that it only happens when a process is shutting down. That seems like a big clue, but I don’t know what it means.
What does the Filter Manager do with the callback data structure when FltSetCallbackDataDirty is called and I return? Does it or is it supposed to cleanup anything when a pointer to an MDL is changed?
Given all that I have tried, I really don’t feel like the bug is in SwapBuffers. I think it is in the filter manager, but I am not sure how to prove it either.
Any ideas?
Could you provide some more details on how you get this? I’d like to know the OS version and the steps you actually take to repro this (like, do you install the minifilter and then kill processes or do you unload the minifilter before you kill processes and so on). I’d really like to take a look.
When you call FltSetCallbackDataDirtyfilter manager tries to do the right thing (though I don’t remember of the top of my head what that is…), meaning that it’s supposed to figure out how the buffers and the MDLs have changed and restore them on the way back up. But again, I need to take another good look at this.
I’ll ask one more time, just to make sure. Other than commenting out the lines in the sample where the callbacks for the read and write operations were defined, did you change anything else at all? (and I really mean anything.). Or better yet, could you send me a private email with the modified sample (I won’t ask you to post it here since I’m not sure about copyright)?
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
Alex – Check your inbox for the code with the read/write callbacks disabled. Let me know if you don’t receive it.
Keep in mind that even the totally unmodified sample BSODs with the same bugcheck as my modified code. I reverified this again this morning.
I have done some more analysis on this and have isolated the MDL to be the one that is allocated in the sample in SwapPreDirCtrlBuffers. I see the address of the MDL logged in Windbg and then shortly after the BSOD occurs showing the same MDL address. I used a DebugLevel of 0x9.
OS Version: XP Pro SP2, Version 2002, 2600.xpsp_sp2_qfe.070227-2300
FltMgr.sys Version: 5.1.2600.2978
I just did a W2K3 x86 Free build of swapbuffers using the WDK 6000 build environment, installed it on the machine using the provided inf, set the swapbuffers to boot start, rebooted, and then tried to logon to the console session. I don’t really even think you need to logon as long as processes are starting, touching the file system, and then exiting. I do not manually stop or start anything.
Don’t we need to free the MDL allocated in SwapPreDirCtrlBuffers somewhere or is fltmgr supposed to do it? In SwapPostDirCtrlBuffers and SwapPostDirCtrlBuffersWhenSafe We free the newBuffer allocated in SwapPreDirCtrlBuffers, but the code never frees newMdl nor and MDL that might already be in iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress (if that’s possible).
Hello,
Yeah, it turns out there is a (known) bug in the sample (well, it wasn’t known to me that’s for sure). For what it’s worth, the SwapBuffers sample should get some love in the next WDK release. If you want to fix it yourself until then you need to look into better handling of chained MDLs (sorry I can’t be of more help here).
Filter manager should take care of freeing the MDLs and the buffers after your post completion is called.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
So, let me make sure I have this right.
Are you saying that the Filter Manager should be cleaning up, but since it isn’t the SwapBuffers sample needs to do it or take a different approach if I want to fix it in the short-term?
No (and I’m sorry my previous post didn’t make it clear), as far as I can tell the bug is not in filter manager but rather in the sample. Whoever did the original analysis figured this out but it’s not immediately obvious to me what exactly is happening. I’ll ask the owner of the bug for more info…
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
Thanks for the clarification Alex. I would really like to resolve this, b/c it will be one less bug in my code.
When you get the original MDL, is it a chain of MDLs? From what Alex
has said, my suspicion is that the code doesn’t handle this case because
MDL chains were not typically used at the time it was written.
Tony
OSR
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@charter.net
Sent: Thursday, August 07, 2008 12:43 PM
To: ntfsd redirect
Subject: RE:[ntfsd] SwapBuffers and Bugcheck 0xCB
Thanks for the clarification Alex. I would really like to resolve this,
b/c it will be one less bug in my code.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, I am not seeing any MDL chains prior to the bugcheck. I put in some additional logging to log out the address in MDL->Next if it is not NULL where ever newMdl and iopb->Parameters.DirectoryControl.QueryDirectory.MdlAddress are used and Next is never non-NULL.
When I have a kernel debugger attached Windbg spits out “A driver has leaked 4096 bytes of physical memory.” and then nt!DbgBreakPoint causes the debugger to break-in. Why does this not display the address that was leaked and where does this come from? It would be quite handy here if it would tell me what was leaked.
The bugcheck tells me it’s the MDL allocated in PreSwapDirCtrlBuffers. Where should that MDL be freed?
That MDL should be freed by filter manager. I’ll try to repro it and I’ll let you know what I find (it might take a couple of days).
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
That would make sense, b/c all attempts to free it myself have been unsuccessful.
Chained MDL? Then surely we are in IRP_MN_MDL[_COMPLETE] case? IIRC this is
a different callback in filter manager world.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
When you get the original MDL, is it a chain of MDLs? From what Alex
has said, my suspicion is that the code doesn’t handle this case because
MDL chains were not typically used at the time it was written.
Tony
OSR
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@charter.net
Sent: Thursday, August 07, 2008 12:43 PM
To: ntfsd redirect
Subject: RE:[ntfsd] SwapBuffers and Bugcheck 0xCB
Thanks for the clarification Alex. I would really like to resolve this,
b/c it will be one less bug in my code.
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Actually, I spent a few minutes looking at this example today. It’s not
a very good one, unfortunately, although I didn’t see what is causing
his specific issue (but then again, it’s always tough from just the bug
check code.) From what Alex has said, this is a known (but not fixed)
issue.
Tony
OSR