tracking SL_WRITE_THROUGH on SATA drives

Hi,

I’m newbie to driver development, I’m coming from the database world. I’m trying to find out whether my SATA II drive is FUA compliant or not (running XP Pro SP3). I’ve written a simple cpp doing sector aligned writes using (FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING) in loops. The way I track Irp addresses in windbg is passing the device object address to !irpfind and calling !irp on the active irp address.

When I am able to look at some file IO Irps, I check the IRP.Flags against SL_WRITE_THROUGH bit pattern (0x04 according to winddk.h). Usually I find this kind of IRP:

Irp is active with 10 stacks 6 is current (= 0x882a312c)
Mdl=88195a60: No System Buffer: Thread 881059e8: Irp stack trace.
Flags = 00000043
ThreadListEntry.Flink = 882a3018
ThreadListEntry.Blink = 882a3018
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = a0e60878
UserEvent = a0e60820
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 88083000
&Tail.Overlay.DeviceQueueEntry = 882a3048
Tail.Overlay.Thread = 881059e8
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = 882a312c
Tail.Overlay.OriginalFileObject = 899ef028
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[4, 0] 0 0 8a483770 00000000 f77077ca-8a483548
\Driver\Disk
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 8a483548 00000000 f7238962-8a4a5ae8
\Driver\PartMgr
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 8a4a5a30 00000000 f74a7680-8a48a7b8
\Driver\Ftdisk
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 8a48a700 00000000 f7063e3f-a0e6045c
\Driver\VolSnap
Args: 00000000 00000000 00000000 00000000
[4, 0] 0 0 8979c020 00000000 00000000-00000000
\FileSystem\Ntfs
Args: 00000000 00000000 00000000 00000000

Flags = 00000043 does not embed (0x04). Does it really mean that SL_WRITE_THROUGH has been dropped ? (when I check the corresponding FileObject.Flags it has FO_WRITE_THROUGH on so I’m sure the file is opened correctly). What is confusing is that the IO_STACK_LOCATION shows drivers up to the Class driver (disk.sys), but not further drivers in the stack like atapi or storport.

I do not have the gear to test this with SCSI drives, so I’m not sure I interpret correctly. In your opinion what would be the most effective method of checking whether the SL_WRITE_THROUGH bit is persisted or not ? Am I completely mistaken ?

Thanks for your help,

David B.