Why does my attempt to acquire an SRW lock block even though !locks report no locks held?

A customer asked for some help debugging a problem with their application:

We have an application that synchronizes access to resources by using SRW locks rather than critical sections. We have traced execution in the debugger up to the point at which we're about to call Acquire­SRWLock­Shared. Trying to step over the call in WinDbg sends the program into Running mode. Breaking back into the debugger and using the !locks command reports "no locks", confirming that that there are no deadlocks on the lock. But why is Acquire­SRWLock­Shared not returning?

The debugger's !locks command reports on critical section objects. Says so right on the tin:

The !locks extension in Ntsdexts.dll displays a list of critical sections associated with the current process.

It does not have any insight into SRW locks or any other synchronization objects.

The program is entering Running mode when you try to step over the call to Acquire­SRWLock­Shared because the call is blocking, presumably because another thread has acquired the SRW lock in exclusive mode and has yet to release that lock. (Other possibilities are that the acquirer of the exclusive SRW lock released it incorrectly, or that the SRW lock is corrupted.)

There are no built-in diagnostics for SRW locks. These locks retain no diagnostic information; that's what makes them slim. If you need to debug your program's use of SRW locks, you can wrap the SRW lock functions inside your own helper functions that record additional diagnostic information. Or you can use Application Verifier, which is basically the same thing, just that the diagnostic information is recorded by Application Verifier. Or you can add additional logging to your program to try to reconstruct the history of the SRW lock to find out who acquired it exclusively and failed to release it properly.

Comments (7)
  1. Medinoc says:

    Does Windows have any non-slim, waitable reader/writer locks? I remember years ago looking for one fruitlessly…

  2. DWalker07 says:

    Naming is so important. It doesn’t say that it reports on critical section objects “on the tin”, but on the instruction leaflet that’s packed inside the tin. The tin is labeled “!locks”.

    Hindsight says that the name should not have been !locks, but !critical or !critsections, or something. Where’s that time machine?

    1. xcomcmdr says:

      Why was it named locks anyway ?

      1. Medinoc says:

        Because it’s shorter maybe?

      2. Andrew says:

        Did SRW locks exist when windbg was first written? MSDN has the minimum supported client for InitializeSRWLock listed as Vista, but that might not be accurate (since everything before Vista is not supported).

        1. cheong00 says:

          I’ve checked the Windows SDK v5.0 WinBase.h does not have InitializeSRWLock() defined. The first existence is on v6.0A.

        2. Klimax says:

          Note: MSDN still lists XP as minimum version where applicable.

Comments are closed.

Skip to main content