SQL DBA Blog: Home

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,…

read more

PREEMPTIVE_OS_FILEOPS is a generic wait covering a family of Windows file system functions that do not have their own dedicated preemptive wait type. When a thread calls one of them, it switches from SQL Server’s cooperative scheduling to Windows control (showing state RUNNING throughout) and banks the time here. It is a catch-all: file attribute…

read more

PREEMPTIVE_OS_FLUSHFILEBUFFERS is recorded while a thread calls the Windows FlushFileBuffers function (or its equivalent on Linux), which forces everything buffered for a file down to durable media. Like all preemptive waits, the thread runs outside SQL Server’s scheduler until the OS call returns. Its claim to fame is SQL Server on Linux: from SQL Server…

read more

PREEMPTIVE_OS_GETDISKFREESPACE is recorded when a thread calls the Windows GetDiskFreeSpace function to check a volume’s free space. Callers include the engine (before file growth, during certain file operations) and, prominently, monitoring queries: sys.dm_os_volume_stats, xp_fixeddrives, and the tooling built on them, our disk space scripts included. Every “how full are the drives” check passes through here.…

read more

PREEMPTIVE_OS_GETPROCADDRESS is recorded while a thread calls the Windows GetProcAddress function to resolve an extended stored procedure’s entry point inside its DLL. Every XP call needs this lookup, so instances that use extended stored procedures (their own, a vendor’s, or built-ins like xp_cmdshell) generate this wait as part of the XP call path. One quirk…

read more

Three preemptive waits track Windows DLL handling, and this page covers them together: PREEMPTIVE_OS_LOADLIBRARY (loading a DLL into the process), PREEMPTIVE_OS_FREELIBRARY (unloading one), and PREEMPTIVE_OS_LIBRARYOPS (the generic bucket for other library operations). Their callers are the components that bring foreign code into the SQL Server process: extended stored procedure DLLs on first call, diagnostic and…

read more

PREEMPTIVE_OS_LOOKUPACCOUNTSID is recorded while a thread calls the Windows LookupAccountSid function, which translates a security identifier (SID) into an account name. For domain accounts that translation can leave the server entirely and query a domain controller, so each call inherits your AD infrastructure’s latency. The classic T-SQL trigger is SUSER_SNAME() with an explicit SID argument,…

read more

The remaining one-API preemptive waits do not warrant a page each, so this reference covers them together. All share the standard mechanics: the thread runs under Windows control (state RUNNING) until the call returns, and the wait measures that external time. Are They a Problem? None has been a noticeable contention point. They exist so…

read more

Four preemptive waits track Windows networking APIs, and this page covers them together: Together they are the OS-call basement under SQL Server’s outbound and transport networking. Are They a Problem? At trace levels, no. The member with the sharpest teeth is GETADDRINFO: slow or flaky DNS makes every outbound name resolution stall, which surfaces as…

read more

PREEMPTIVE_OS_PIPEOPS is recorded when a thread calls out to Windows functions that work with pipes, and in DBA reality that means one thing almost every time: xp_cmdshell. SQL Server launches the external command and reads its output through a pipe; the entire runtime of that command accumulates under this wait. The PREEMPTIVE_ prefix means the…

read more