Litespeed backup stuck with wait type ‘preemptive_os_getprocaddress'



We have an issue with T-Log backups being executed by Litespeed. Here is a sequence of events:

  1. There are 56 databases on a SQL Instance.
  2. We started receiving alerts from Spotlight that the databases are missing T-Log backups for more than 45 minutes (alert thresholds we setup). Upon further examination we noticed that T-Log backup job started execution at 12:00 AM and got stuck in ‘Running’ state for the next 70 minutes.
  3. After analyzing the SQL logs and the backup files generated on the disk, I observed that the T-Log backups were generated successfully for 50 of the 56 databases, but the job never proceeded to the 51st database.
  4. Looking at the active processes, there were 2 spids numbered 115 & 116 related to Litespeed processes and one of the spids had a ‘Last Batch’ time of 12:02 AM (matches the backup time for the 50th database).
  5. SQL activity in Spotlight Playback option indicates that the spid got stuck in the wait type of ‘preemptive_os_getprocaddress’.
  6. Around 1:10 AM, I had to kill the T-Log backup job and re-run the job. This time it ran successfully.

This error happened once a couple of months ago and Litespeed support has asked us to enable the logging and reproduce the issue. The challenge here is that we are unable to reproduce the issue. The occurrence is so random that it requires us to enable logging on all our 100 Production servers continuously and wait for few months to capture the issue. The challenge with doing that is the amount of logs that are generated. We tried doing that once in the past and blew out the C drive on many servers within 1 day. I observed that the amount of logging is proportional to the number of dbs and we have servers that have hundreds of databases.


Before we go thru the process of enabling logging again, I wanted to find out if you have any idea about why a Litespeed spid would get stuck with a wait type ‘preemptive_os_getprocaddress’.

Below url indicates that the wait type is observed when SQL tries to invoke some DLLs. I suspect that this is an issue when SQL tried to invoke the Litespeed dll. Can someone let us know their thoughts on this issue and the associated wait type?


Looks like there is a similar issue on the forums logged in the past, but I do not see a definitive solution in that case. I appreciate a solution for this issue as this causing us some grief by throwing alerts at all kinds of random times (ex: 12:00 AM in the night)

No Data
Reply Children
No Data