Why does PREEMPTIVE_OS_GETPROCADDRESS Show a Large Accumulation?

There is a bug in SQL Server 2008 that causes PREEMPTIVE_OS_GETPROCADDRESS to include and accumulate the execution time of the extended stored procedure (XPROC). The following is an example showing the increase in the GetProcAddress wait time.

select * from sys.dm_os_wait_stats where wait_type = 'PREEMPTIVE_OS_GETPROCADDRESS' or wait_type = 'MSQL_XP'
exec master..xp_dirtree
select * from sys.dm_os_wait_stats where wait_type = 'PREEMPTIVE_OS_GETPROCADDRESS' or wait_type = 'MSQL_XP'

GetProcAddress is used to load the entrypoint in the DLL (XPROC) and should complete quickly but due to the accumulation bug the wait time is inflated.   To get a better idea (ballpark) of how long GetProcAddress really takes you can using the following query.

declare @WaitTime bigint
select @WaitTime = wait_time_ms from sys.dm_os_wait_stats where wait_type =
select @WaitTime - wait_time_ms from sys.dm_os_wait_stats where wait_type = 'PREEMPTIVE_OS_GETPROCADDRESS'

Bob Dorr - Principal SQL Server Escalation Engineer

Comments (8)
  1. Victor Shahar says:


    Is there a fix for this problem ?

    Thank you,

    Victor S.


  2. Charley Evans says:

    Hi Bob,

    Do you know of any documentation on what PREEMPTIVE_OS_GETPROCADDRESS is and what it means?  I have an SQL Server backup through a third party tool that uses extended procs to do the backup.  The backups was killed, however it has been in a killed/rollback state for 3 hours and lists it's wait type as PREEMPTIVE_OS_GETPROCADDRESS.



  3. Darcy Dupuis says:

    I am seeing this wait in relation to the Quest LiteSpeed extended procedures. Is there a fix for this yet or plans for one?

  4. Naveen says:

    Hi… Even we got the wait types PREEMPTIVE_OS_GETPROCADDRESS and PREEMPTIVE_OS_REPORTEVENT for quest litespeed backup thread. SPID was in hung state and we were not able to run the backup on database. We could not kill the process, server reboot was required.  

  5. John J Serna says:

    I have a process with a long waittime (around 4 days) of PREEMPTIVE_OS_GETPROCADDRESS, I am running SQL Server 2008 R2 SP1, the only solution is to restart the sql server service?

    Microsoft: We need urgent and update of this bug.

  6. Brian Baker says:

    Would be nice to know if this is documented in a KB article and/or has been fixed in subsequent service packs or releases.

  7. Mike King Mike.King@gov.ab.ca says:

    We are experiencing issues repeatedly with xp_sysmail_format_query waiting on preemptive_os_getprocaddress. The process has to be killed and it is an important production procedure.


    Any updates ?

  8. Martin Henriksen says:

    I saw this error on one of my SQL boxes today, where multiple xp_sysmail_format_query was blocking other queries, exaclty one blocked query per head blocker. I killed both head blockers and blocked queries and this solved the issue.
    I also found this related MSDN question with a possible reason for the blocking:

    Quote from the link:
    This will happen if you use user transaction when calling sp_send_dbmail. Do not call sp_send_dbmail with in user transaction.

    If you open a transaction and send a mail with some attachment in first connection and dont commit . Open a second connection and send a mail using sp_send_dbmail it will not be queued and wait till the first connection commits.

    You will also see preemptive_os_getprocaddress wait for second connection

    Hope this helps someone else in this situation .
    I avoided restarting the SQL box, so taht was awesome 🙂

Comments are closed.

Skip to main content