首页 > 解决方案 > Minifilter cause lag on disk management and system restore

问题描述

I am trying to determine why my filter causes diskmanagement, diskmgmt.msc, to lag. It gets stuck for a lengthy period until it shows or not at all.

My investigation and conclusion has narrowed the problem down quite a lot. I will write some code which is heavily shortend for a easy read. I'm fairly certain it is sufficient to answer the question.

You see, the code below works. Result is the value which is returned.

    if(Data->Iopb->MajorFunction == IRP_MJ_VOLUME_MOUNT)
        {
dev = diskDevice->DeviceType;
        if((FILE_DEVICE_MASS_STORAGE == dev) || (FILE_DEVICE_DISK == dev) || 
                    (FILE_DEVICE_DISK_FILE_SYSTEM == dev) || (FILE_DEVICE_VIRTUAL_DISK == dev)
                    || (FILE_DEVICE_FILE_SYSTEM == dev) || (dev >= 32768))
                    {
                        if(FLT_FSTYPE_NTFS == fs_type)
                        {
                            Result = FLT_PREOP_SUCCESS_WITH_CALLBACK; 

                        }
                        else
                        {
                            Result = FLT_PREOP_SUCCESS_NO_CALLBACK;
                        }
                    }

        }

If the "else" would be FLT_PREOP_SUCCESS_WITH_CALLBACK;, it would lag.

So, my assumption here is that there is a specific behaviour to some specific FLT_FSTYPE other than NTFS. My question is therefore, which one has specific requirements?

My PostOperation function does not do a whole lot other than logging. That function always returns FLT_POSTOP_FINISHED_PROCESSING.

标签: cdriverlagminifilter

解决方案


好的,我的问题不是由枚举值或涉及的任何“魔法”引起的。枚举决定 postOperation 是否应该运行。常识说这就是问题所在。正如我所说,我在那里所做的只是记录东西。是的,这就是问题所在。我使用函数 FltSendMessage。由于我没有计时器并且设置为 NULL,因此它将无限期地等待。这就是它卡住的地方。我的问题是内核和用户空间之间的通信存在错误。就我而言,用户态应用程序失败了。当它失败时,它不会向驱动程序发送确认,因此它会等待。


推荐阅读