SQL Server Trace Files and StorPort vs KMDF

I have a storage driver which exists in 2 variants: StorPort and KMDF.

I am running SQL Server (2008 and 2012 on different machines) and I’ve moved the DATA files and Log files from the default C: drive onto our storage device using drive letter D: .

If I use the KMDF driver, everything works great and everyone is happy.

However, if I use the StorPort variant, everything works EXCEPT one small thing: a query using fn_trace_gettable() fails. For example:

select *
FROM sys.fn_trace_gettable(‘D:\SQLSERVER\Log\log_111.trc’, DEFAULT)T

This query returns error message “File ‘D:\SQLSERVER\Log\log_111.trc’ either does not exist or is not a recognizable trace file. Or there was an error opening the file.”

Using SysInternals ProcMon, I see the file open succeeds, but then it is immediately closed without reading the file:

Time of Day Process Name PID Operation Path Result Detail

10:45.3 sqlservr.exe 6904 CreateFile D:\SQLSERVER\Log\log_111.trc SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Write Through, No Buffering, Non-Directory File, Open No Recall, Attributes: N, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened

10:45.3 sqlservr.exe 6904 CloseFile D:\SQLSERVER\Log\log_111.trc SUCCESS

In contrast, with the KMDF driver loaded, I see the open succeeds, the file is read and then closed.

My suspicion is that there is a device characteristic required by SQL Server with fn_trace_gettable() which is present with the KMDF driver, but is missing in the StorPort variant.

I put a conditional breakpoint on NtCreateFile() for when log_111.trc is opened, but the call stack is so convoluted that it is like looking for a needle in a haystack.

Any ideas on this?