You should not call any of the createfile APIs at APC level. That said,
you can queue a request to a worker thread and then block until it
completes. But note that there are cases where you may never see a close
request on a file, or it may be long after any user mode application has
closed it. I would recommend triggering off the cleanup and if you do
get additional paging writes after the cleanup, you would only need to
do this processing once, correct? I am only guessing from your
description though …
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: “xxxxx@gmail.com” To: “Windows File Systems Devs Interest List” Sent: 10/5/2017 1:25:58 PM Subject: RE:[ntfsd] Creating an ADS stream in a Mini Filter
>P.S. Why can’t I create a file at APC level anyway? > >— >NTFSD is sponsored by OSR > > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:</http:></http:>
BTW having a higher IRQL thread wait for one at a lower level to complete a task is an inherent design problem. It may appear to work just fine for a long time, but it relies on the assumption that you have a machine with an adequate number of cores for another one to ?go do some work for me while I hold this one? (not strictly true for the lower IRQL levels that can be preempted)
the architecturally appropriate choice is to have ?work? and the progress on each item to be done tracked by data rather than thread context. This is one of the things quite different about Windows than many other operating systems.
You may say, it?s easy for me to say as I don?t have to fix you code. This is true, but if you can figure out how to break your algorithms into appropriate phases of work ? each one to be executed by some arbitrary thread as it picks up the next job that is completely defined by the data ? you will be much happier writing code in Windows KM; and for that matter in KM or UM on any OS.
From: PScott mailto:xxxxx Sent: October 5, 2017 7:42 PM To: Windows File Systems Devs Interest Listmailto:xxxxx Subject: Re[2]: [ntfsd] Creating an ADS stream in a Mini Filter
You should not call any of the createfile APIs at APC level. That said, you can queue a request to a worker thread and then block until it completes. But note that there are cases where you may never see a close request on a file, or it may be long after any user mode application has closed it. I would recommend triggering off the cleanup and if you do get additional paging writes after the cleanup, you would only need to do this processing once, correct? I am only guessing from your description though …
Pete
– Kernel Drivers Windows File System and Device Driver Consulting www.KernelDrivers.comhttp: 866.263.9295
------ Original Message ------ From: “xxxxx@gmail.com” To: “Windows File Systems Devs Interest List” Sent: 10/5/2017 1:25:58 PM Subject: RE:[ntfsd] Creating an ADS stream in a Mini Filter
>P.S. Why can’t I create a file at APC level anyway? > >— >NTFSD is sponsored by OSR > > >MONTHLY seminars on crash dump analysis, WDF, Windows internals and >software drivers! >Details at http: > >To unsubscribe, visit the List Server section of OSR Online at >http:
— NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
>I don’t want to make the tagging asynchronous because sometimes the file
gets renamed after it has been closed.
You have the rename problem even if you did this inline at IRP_MJ_CLOSE
time. The IRP_MJ_CLOSE just means that a File Object is going away, there
could be another FIle Object out there being used to rename at the same
time.
If this is on the network there’s not much you can do about this as another
client can rename from underneath you (modulo sharing, but that’s moot
post-IRP_MJ_CLEANUP anyway). If you’re local only then you can intercept the
rename.
P.S. Why can’t I create a file at APC level anyway?
TL;DR: It can cause a deadlock
FltCreateFile calls ZwCreateFile, which is the Native API for creating a
File Object. This operation is synchronous and is (potentially) completed by
queuing a Special Kernel APC (SKAPC) to the requesting thread. If you’re at
APC_LEVEL, SKAPCs are disabled. So, the I/O Manager sends the IRP_MJ_CREATE
and blocks waiting for the SKAPC to be delivered to the requesting thread.
However, the requesting thread is running at APC_LEVEL and thus blocking the
APC. The result is a single threaded deadlock (the most humiliating of all
the deadlocks)