I have a disk filter driver which is writing some data continuously to a file on the same disk that is it monitoring. This file is memory mapped. I am flushing the file map using ZwFlushBuffersFile but even then when the machine reboot the file is completely zeroed out.
I tried everythin, ZwFlushBuffersFile, ZaFlushVirtualMemory. The file is mapped into system process’s address space, pointer to which I get during my DriverEntry function.
I am not sure what exactly I am doing wrong, but even after successful ZwFlushBuffersFile call the file data is completely lost. Just before calling ZwFlushBuffersFile I see that file has valid data in it. I am trying to flush file in the IRP_MJ_SHUTDOWM processing for the disk device object.
I added a scheduler thread and flushing periodically. But still the problem exists. If the file is mapped while IRP_MJ_SHUTDOWN is received it clears up the file. Not sure why
Not trying to be fancy, but I needed the memory map approach to access the bitmap that I am writing in that file. The memory address would have let me use RtlBitmap APIs easily. I did that in past through volume filter driver and it works fine. In this case it is a disk filter driver
Try to use a control device and register a shutdown notification for it so that your driver is called when the system is about to lose power. According to WdfControlDeviceInitSetShutdownNotification documentation, your "driver is notified when the system is losing its power, but before file systems are flushed, if you choose the WdfDeviceShutdown flag.
Well, when the system is losing power the very idea of flushing file buffers becomes rather tricky. The problem is that different hardware components have different ( in terms of latency) sensitivity to power outage. RAM is one of most power-sensitive parts, so it is one the first one to lose its charge, while disk controller may still be functional for some more milliseconds. What this means in practice is that that you may be flushing the data that had become invalid due to memory corruption. Probably, this is exactly what the OP is seeing - after all, it looks like RAM had simply lost its contents.
This problem has been recognized quite a while ago. This is why some more advanced higher-end hardware platforms/architectures offer a feature that is unavailable on an ordinary PC-grade machines, known as a power-failure interrupt. The purpose of this interrupt is to invoke a handler that cancels all outstanding IO operations in order to avoid flushing memory that had potentially already lost its context, thus avoiding a potential persistent data corruption.
I used these scheme to flush data that was collected by a monitoring driver. That worked fine.
An interesting test job would be to register two shutdown notification callbacks: the first with the WdfDeviceShutdown flag (filesystems are net yet flushed) and the second with WdfDeviceLastChanceShutdown (all filesystems has been flushed). The second should be called after the first. Opening a handle to the file in the second callback should fail and if not, the file information can be queried, for instance to look at its size to see if the data has been written correctly in the first callback.
Now the question is: can a driver register two of these callbacks ?
>Well, when the system is losing power the very idea of flushing file buffers becomes rather tricky
This is why nothing is flushed on power loss. Only the disks get auto-parked.
The problem here is not power loss. The poster wants to be the last man writing. And it’s just not possible when he has a memory mapped file. It can be possible if he writes by absolute LBAs.