A large family of PREEMPTIVE_OS_* waits each track a single Windows file API call. They share one mechanic, the thread leaves SQL Server’s cooperative scheduler (state shows RUNNING) until Windows returns, and one diagnosis, so this page covers the set:
PREEMPTIVE_OS_CLOSEHANDLE, COPYFILE, CREATEDIRECTORY, DELETEFILE, FINDFILE, GETCOMPRESSEDFILESIZE, GETFILEATTRIBUTES, GETFILESIZE, GETFINALFILEPATHBYHANDLE, GETLONGPATHNAME, GETVOLUMENAMEFORVOLUMEMOUNTPOINT, GETVOLUMEPATHNAME, MOVEFILE, OPENDIRECTORY, REMOVEDIRECTORY, SETENDOFFILE, SETFILEPOINTER, WRITEFILE, plus PREEMPTIVE_FILESIZEGET and PREEMPTIVE_OS_BACKUPREAD.
Two members deserve a named mention. SETFILEVALIDDATA is the instant file initialization call: time here is data files being created or grown without zero-filling, which is IFI working (the call itself is near-instant when healthy). BACKUPREAD appears around backup operations reading through the Windows backup API.
Are They a Problem?
Individually, almost never; none has been a meaningful contention point. Collectively they are a latency meter for your file infrastructure: FILESTREAM workloads, backup file handling, database file lifecycle operations, and xp_-style file access all sprinkle time across the family. When several members grow together, the file system under SQL Server (or a filter driver on top of it) is slow, and testing basic file operations from the OS on the affected volumes reproduces it outside SQL Server.
What To Do
- Map accumulation to the file-touching activity at the time (backups, FILESTREAM, file growth).
- Confirm antivirus exclusions for data, log, backup, and FILESTREAM paths; filter drivers tax every one of these calls.
- If calls are genuinely slow, prove it OS-side and hand it to the platform team.
How To See It
Rank waits with Get-WaitStatistics; read the family as one signal about file-path health rather than chasing members individually.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply