CcFlushCache - flushing zero-length range

Hello,

I am porting a legacy FSFD to Windows 7. The FSFD is using helper stream file objects.
Lately I have noticed an interesting behaviour:

The FSFD sometimes tries to flush a zero-length range of a helper stream file object’s cache using CcFlushCache routine. So the CcFlushCache routine is called with the Length parameter set to zero and FileOffset parameter specified (i.e. the FileOffset pointer passed to the function is not NULL).
Being called in this way, the CcFlushCache routine first increments WritesInProgress member of the shared cache map associated with the stream file object, then it checks some flags of the shared cache map (the flags are 0x200205 in this case) and finally it checks the FileOffset and Length parameters and it finds out there is actually nothing to be flushed and it returns (without decrementing WritesInProgress).
So after returning from CcFlushCache the WritesInProgress member of the shared cache map stays incremented until the next reboot.
This causes problems when the cache map is uninitialized (using CcUninitializeCacheMap). As part of the cache’s uninitialization the corresponding shared cache map is deleted by the lazy write thread. The lazy write thread cannot delete the shared cache map until the shared cache map’s WritesInProgress member is set to zero. Because this never happens, the lazy write thread is periodically checking the shared cache map’s WritesInProgress member and keeps postponing the shared cache map’s deletion until the system is restarted.

As the WDK documentation for the CcFlushCache does not state that the zero-length flushes are illegal, I guess this might be a bug. What do
you think about it?

Best regards

Lenka

>As the WDK documentation for the CcFlushCache does not state that the

zero-length flushes are illegal, I guess this might be a bug. >What do you
think about it?

Looks like a bug to me. Note that this is new behavior to Win7, so unless
we’re missing something and that field is decremented elsewhere it’s a
breaking change to anyone with this code pattern.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com