I’m trying to veto the bypassed operation. To do this, in PreCallback in case of receiving IRP_MJ_FILE_SYSTEM_CONTROL and Data->Iopb->Parameters.File System Control.Common.FsControlCode == FSCTL_MANAGE_BYPASS_IOS calling this function

Then I finish PreCallback with the status FLT_PREOP_COMPLETE.

The problem is that in USER_SPACE, in this case, garbage arrives in the outputbuffer. And I don’t understand why.
Can someone suggest?

I act according to the instructions: https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/bypassio-operations

Example code

if (Data->Iopb->Parameters.FileSystemControl.Common.FsControlCode == FSCTL_MANAGE_BYPASS_IO) {
        UNICODE_STRING reason;
        PFS_BPIO_INPUT in;

        in = Data->Iopb->Parameters.FileSystemControl.Buffered.SystemBuffer;
        if (in) {
                if (in->Operation == FS_BPIO_OP_ENABLE || in->Operation == FS_BPIO_OP_QUERY) {
                        RtlInitUnicodeString(&reason, L"does not support bypassio");
                        status = FltVetoBypassIo(Data, FltObjects, STATUS_ACCESS_DENIED, &reason);
                        return FLT_PREOP_COMPLETE;

Did you do this bit:

Update the FS_BPIO_OUTPUT structure, including the operation NTSTATUS describing
why the enable request was vetoed, the driver’s name, and a unique, descriptive string
with additional details about why you vetoed the enable request.

Your code doesn’t show that bit.

Yes, I figured it out, thank you very much. A rather strange situation, you need to update the structure in Data->Iopb->Parameters.FileSystemControl.Buffered.SystemBuffer in PostCallback.

PostCallback!! What the documentation does not say a word about. And it confuses me

And theoretically, it is not necessary to call FltVetoBypassIo at all
Which is very strange…

How do you return Bypass in PostOp?
That makes 0 sense, as the I/O already went down. FltMgr would need to
renegotiate with the FS after.