How to know what component sets the dirty bit?

I’m working on a Win2003 NTFS issue with Microsoft support where we’re seeing “The file system structure on the disk is corrupt and unusable.” (NTFS EventID 55) errors occassionally on our systems. The support fellow asserts that error is only logged only if and whenever the dirty bit is set, though I’m not convinced that is true. (In fact, a simple test with “fsutil dirty set” shows that isn’t true.)

We want to find out who is setting the dirty bit, assuming that the NTFS error is a result of the dirty bit getting set. For example, is it NTFS.sys itself setting it, or someone doing “fsutil dirty set”, or something else.

The only possibility that I came up with was to possibly use SysInternals DiskMon, though that seems fairly heavy-weight and I’d want something non-GUI (because I’d have to monitor thousands of machines).

It could surely be done with a file system filter driver, but while I’m a driver developer, I haven’t done file systems, so I suspect that would be too much for me.

The problem is also quite rare, only every 150 machine-years. However, we have a single customer with 7,000 of these machines, so we see it about once a week. Unfortunately, its too rare to try to reproduce in the lab, and we certainly don’t yet know how to reproduce it at will.

So, how could I find out the component (e.g. process) that is setting the NTFS dirty bit? I’m hoping that there’s some utility that FS developers are familiar with that will do what I want.

Thanks in advance for any suggestions of utilities, methods, or even ideas of a different way to approach this problem.

You certainly can *not* do this with a filesystem filter. ODS maintenance
is between the Filesystem and the media. FS Filters sit between the
Filesystem and the application.

Assuming that you know how to find the dirty bits (and I guess some dev
level filtering of fsutil would tell you that), can you not do this with a
device filter? Just look for writes to that (those) particular LBN(s) take
a poke at the buffer and see whether that/those bits are being written.
Then throw a bluescreen or whatever you need to debug it. Obviously you
wouldn’t ship with this …

Rod