PREEMPTIVE_OS_REPORTEVENT is recorded when a thread calls the Windows ReportEvent function, writing an entry to the Windows event log. SQL Server mirrors significant error log messages to the Application event log, and features like RAISERROR ... WITH LOG, failing logins (when auditing is on), and alert-generating errors all route through this call.
Its accumulation is a rough meter of how much the instance is telling Windows about.
Is It a Problem?
The wait mechanics, no; event log writes are quick when the OS is healthy. Its diagnostic angle is volume: growth means something is generating event-log-worthy messages at pace, and the message stream itself is the real finding. Login-failure storms (audit both-on plus a misconfigured app retrying), error floods from a recurring exception, or chatty RAISERROR WITH LOG usage all show up here before anyone reads the logs.
Slow ReportEvent calls themselves would implicate the OS event log service, which is rare and OS-side.
Common Causes
- Login auditing writing failure (or success) events during authentication storms.
- Recurring errors with severity high enough to hit the event log.
- Application code using
RAISERROR ... WITH LOGliberally.
What To Do
- Read the messages: the error log and Application event log around the accumulation window name the source.
- Fix the generator: the retrying app, the recurring error, or the over-chatty logging pattern.
- Keep login auditing at “failed only” unless a policy requires more; success auditing multiplies event volume for little insight.
How To See It
Rank it against everything else with Get-WaitStatistics; its spikes will correlate with visible bursts in the logs themselves.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply