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 matters for reading it: a long-standing SQL Server bug (documented in 2008, with anecdotal reports on later versions) counted the entire XP execution time under this wait, not just the address lookup. So a big number here often really means “extended stored procedures ran for a long time”.
Is It a Problem?
The lookup itself, never; it is a fast in-process call. When this wait carries serious time, treat it exactly like MSQL_XP: an inventory flag that significant work is happening inside extended stored procedure code, which SQL Server cannot see into or schedule around. The concerns are the XPs themselves: what they do, how long they run, and whether a hung external dependency could pin a worker thread.
Common Causes
- Regular XP usage, with the wait inflated by the execution-time counting quirk.
- Third-party backup or monitoring products implemented as XPs.
- Legacy application code calling custom XP DLLs.
What To Do
- Inventory the XPs in use: catch callers via
sys.dm_exec_requestsduring the wait, and list registered XPs in the master database. - Time-box and monitor what the XP code does externally; hangs trace to hung dependencies.
- Migrate away where practical: CLR, Agent job steps, or application services replace most legacy XP patterns without foreign DLLs inside the engine process.
How To See It
Rank it against everything else with Get-WaitStatistics, and read it together with MSQL_XP; they describe the same XP story from two angles.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply