Verifier deadlock detection

When verifier detects a deadlock, is it finding that there actually WAS a deadlock or that there potentially COULD be one?

I had one between two threads that I was able to resolve but then I got one that was between 5 threads and it got me thinking.

The driver is using a circular ring buffer so when threads traverse it they are locking the current and next elements so you wind up seeing a mutex acquisition loop like a->b b->c c->d d->a.

Thing is, all the threads but one are labeled as terminated so obviously no deadlock occurred. Is verifier just keeping track of recent locks of various mutexes so that it can predict whether a deadlock MIGHT have happened?

We’ve never observed an actual deadlock in the wild so I’m wondering if it’s coming up because verifier slows things down or just because of the proximity of the lock/unlock calls.

xxxxx@pleora.com wrote:

When verifier detects a deadlock, is it finding that there actually WAS a deadlock or that there potentially COULD be one?

Potential.  This is described in the documentation:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/debugging-deadlocks---driver-verifier-detected-violation--c4---0x1001

It tracks the order of acquisition.  The BSOD means that, at one point
you grabbed A and then B, and at another point you grabbed B and then
A.  That means a deadlock potential exists.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Ah thanks. I needed to follow this page one link deeper.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/-deadlock