Queue irp problem

NTFSD
1

Hi,
do the IRP_MJ_CREATE and IRP_MJ_CLEANUP have to be in the same process? I pass down IRP_MJ_CREATE in user-porcess ,and then transmit IRP_MJ_CLEANUP in system-process.Normally, my program goes well. When i rename a file, the first pair of create and cleanup is right, but the second IRP_MJ_CREATE get STATUS_SHARING_VIOLATION.
If I do not transmit IRP_MJ_CLEANUP in system-process, my program is all right.

  1. Does the IRP_MJ_CLEANUP which i transmit before cause a problem?
  2. Should I update the IRP_MJ_CLEANUP (eg: Irp->ThreadListEntry or other thread-associated parameters)?
  3. Should I do someting in system process?
2

Does transmit mean that you are FSFilter and you are passing the IRP_MJ_CLEANUP in system thread instead of arbitrary thread? I such case I don’t think the FSFs are allowed to do such things. I know IRP_MJ_CLEANUP doesn’t have buffer any buffer, but generally FSD wouldn’t be able to process Neither I/O asynchronously. I.E. allocate MDL, lock it etc.

3

recomended article:
http://www.calsoftlabs.com/whitepapers/filter-driver.html

4

Thanks Bronislav Gabrhelik. You get it. I am passing the IRP_MJ_CLEANUP
in system thread instead of user thread. As you said, the IRP_MJ_CLEANUP doesn’t buffer any buffer, so I think there may be nothing wrong with buffer.

5

Simply you cannot do such things. The FSD might need to gain access token from current thread/process (or whatever else), which is not available in system thread/process.

Anyway you didn’t mention what is your underlying FSD, but it is not important.
Analyze again what is your goal. I believe it is side effect that you pass IRP_MJ_CLEANUP in the system thread. If you need to do some job in system thread do only this job, but do not do passing of IRP.

Here is an excerpt from WinNT File system internals pg. 131. In the article above you can read the same.

Typically, only file system drivers or filter drivers that intercept file system requests should expect that their dispatch routines will be executed directly in the context of user-mode threads. Other drivers cannot expect this, simply because higher-level drivers might have posted the user request to be executed asynchronously in the context of a worker thread, or your driver code might be executed in response to an interrupt as discussed previously.

-bg

6

Thanks for your help, Bronislav Gabrhelik.
Now I change the architecture of my program.

7

> Simply you cannot do such things. The FSD might need to gain access token

from current thread/process (or whatever else), which is not available in
system
thread/process.

For the record byte range locking won’t work either - the FsRtl library
assocuiated locks with a (FileObject,Process) pair and given that most FSD’s
tear down locks in cleanup processing the file unlock will never happen if
cleanup happens in the wrong process