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?
Thanks