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 'f:\'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 bigintselect @WaitTime = wait_time_ms from sys.dm_os_wait_stats where wait_type = 'MSQL_XP'select @WaitTime - wait_time_ms from sys.dm_os_wait_stats where wait_type = 'PREEMPTIVE_OS_GETPROCADDRESS'
Bob Dorr - Principal SQL Server Escalation Engineer
Hi,
Is there a fix for this problem ?
Thank you,
Victor S.
DBA
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.
Thanks,
Charley
I am seeing this wait in relation to the Quest LiteSpeed extended procedures. Is there a fix for this yet or plans for one?