Re[2]: 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.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.

Sent from Mailhttps: for Windows 10

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:>

Thanks very much Pete.

I take your point about architecture and I’ll look into re-architecting along the lines you suggest.

Could you help me understand what it is about APC_LEVEL that precludes file operations?

Ian.

>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)

-scott
OSR
@OSRDrivers

That’s great. Thanks Scott.