PREEMPTIVE_OS_QUERYREGISTRY

The PREEMPTIVE_OS_QUERYREGISTRY wait type in SQL Server occurs when a thread is waiting for an operation that involves querying the Windows operating system registry. This wait type is classified as a preemptive wait, meaning that SQL Server is temporarily giving control to the operating system to complete the task. Normally, SQL Server uses cooperative scheduling, where SQL Server threads manage their own execution times. However, when interacting with external resources like the OS registry, SQL Server switches to preemptive mode, allowing the operating system to take over until the operation is complete.

Key Points about PREEMPTIVE_OS_QUERYREGISTRY:

  1. Preemptive Mode: SQL Server switches to preemptive mode when it needs to call an external API (like the registry) that isn’t governed by SQL Server’s internal scheduler.
  2. Registry Access: This wait type specifically indicates SQL Server is interacting with the Windows registry. This can happen during operations such as reading configuration settings, checking licensing information, or fetching system-level details stored in the registry.
  3. Rare Wait Type: PREEMPTIVE_OS_QUERYREGISTRY is not commonly seen in most workloads. If you observe it frequently, it may indicate that SQL Server is repeatedly accessing the registry, which could signal an issue with a feature or configuration that involves frequent registry queries.
  4. Potential Performance Impact: While this wait type is usually brief, excessive occurrences can indicate a performance bottleneck, often related to:
    • Heavy reliance on SQL Server features that frequently query the registry.
    • Poorly performing registry calls due to a slow operating system response or system resource contention.
    • Issues with the registry itself (such as corruption or excessive size).

Common Scenarios involving PREEMPTIVE_OS_QUERYREGISTRY:

  • SQL Server Configuration: Certain features or operations within SQL Server (like Service Broker, Full-Text Search, or specific trace flags) might involve reading values from the registry.
  • Extended Stored Procedures: Custom extended stored procedures or legacy code could be interacting with the registry, resulting in this wait.
  • Licensing or Activation Checks: SQL Server might query the registry to verify licensing information or during activation checks.

How to Investigate:

  1. Check Wait Statistics: You can monitor PREEMPTIVE_OS_QUERYREGISTRY waits using sys.dm_os_wait_stats to see how often it occurs in your environment:SELECT * FROM sys.dm_os_wait_stats WHERE wait_type = 'PREEMPTIVE_OS_QUERYREGISTRY';
  2. Identify Queries: If you suspect specific queries or procedures are causing this wait, use the sys.dm_exec_requests DMV to identify the session and SQL text associated with the wait:
    SELECT session_id, wait_type, wait_time, blocking_session_id, text FROM sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle) WHERE wait_type = 'PREEMPTIVE_OS_QUERYREGISTRY';
  3. Review Registry Access: If this wait is happening excessively, review whether any extended stored procedures, third-party tools, or SQL Server features are frequently interacting with the registry. Reducing or optimizing these interactions could help.

Mitigation:

  • Review Registry Access Patterns: If the wait is linked to a particular feature or stored procedure, try to minimize registry access or cache values when appropriate.
  • Update SQL Server: Ensure SQL Server is patched and updated, as some registry access issues may have been resolved in newer versions or service packs.
  • Optimize System Resources: If the OS is slow in handling registry requests, investigate underlying OS performance issues (disk I/O, memory, or CPU contention) that may be delaying registry access.

Real-World Example:

At Stedman Solutions, we encountered a client whose system was showing unusually high PREEMPTIVE_OS_QUERYREGISTRY waits, which was traced back to a custom extended stored procedure querying the registry on every execution. By caching the results of the registry query and minimizing the calls, we reduced the wait times, improving overall performance. This is a scenario where our SQL Server Managed Services could help—by identifying unusual waits like these and providing targeted solutions.

Let me know if you’d like assistance with troubleshooting this wait type in your environment or other possible wait types here: Databasehealth.com