Tracking File/Directory Creates for an Auditing Minifilter

I am trying to develop an auditing minifilter that captures all file/dir/share create/delete/rename/read/writes occurring on a volume. I followed the minispy code that MSFT released and made the following modifications to identify file/dir creates. I replaced the handler for IRP_MJ_CREATE with the following handler

#pragma warning(suppress: 6262) // higher than usual stack usage is considered safe in this case
    _Inout_ PFLT_CALLBACK_DATA Data,
    _Flt_CompletionContext_Outptr_ PVOID *CompletionContext
) {
    BOOLEAN interested = FALSE;
    ULONG createOptions = Data->Iopb->Parameters.Create.Options;
    UCHAR disp = (createOptions >> 24) & 0xFF;
    if (
        FlagOn(createOptions, FILE_DELETE_ON_CLOSE) ||
        disp == FILE_SUPERSEDE ||
        disp == FILE_CREATE ||
        disp == FILE_OPEN_IF ||
        disp == FILE_OVERWRITE_IF) {
        // We are only interested in creates & delete.
        // All of the above disposition values can potentially create the file.
        // Whether the file was actually created or a existing file was opened can
        // only be determined in PostOperationCallback via IoStatus.Information
        interested = TRUE;

   if (interested) {
        // Follow the minispy path as before.
       return SpyPreOperationCallback(Data, FltObjects, CompletionContext);
  } else {
      // We are not interested. Don't call the PostOp callback.
      *CompletionContext = NULL;

In user-space I check the IOStatus.information == FILE_CREATED to verify that the file was actually created and not just opened or overwritten. It seems to work from the shell and windows explorer but I am not sure if this code catches all possible ways in which files can be created. Feedback is welcome…

Your code says that you are interested in deletes. I assume that is work in progress (you’ll need much more for that).

As for your question three things (at least) spring to mind, depending on whether you care about files or about directory entries:

  • Rename creates and deletes directory entries
  • Hard link creation creates directory entries
  • Sort of as an extreme, aborting a transaction which deleted (or renamed) a file can (kinda-sorta) cause the file to be created.

There is almost certainly more.

yes delete/rename is WIP. what IRP does hard link creation generate ??

what IRP does hard link creation generate

IRP_MJ_SET_INFORMATION / FileLinkInformation

Hard link creation is like rename, but without the DIRENT deletion