Blocking SPID has Zero Disk IO and Zero CPU Time

Question

Running sp_who2 and following the BlkBy trail up to the root cause of blocking returns a SPID which has CPUTime and DiskIO values of 0; yet it's blocking 4 other SPIDs.

I'm confused by how this is possible; the CPUTime in particular seems odd as in order to obtain a lock you'd have had to have spent some time requesting resources / requesting the lock itself.
CPUTime is in milliseconds, so whilst it's possible that the requesting and locking of resources occurs fast enough to have a rounded down value here, that is a little surprising.

Also, these SPIDS are sometimes a few minutes old; yet appear to have done nothing beyond cause blocking.

Question

How is it possible for a SPID to cause blocking whilst having zero CPU Time?

I'm asking as I suspect something's lacking in my understanding of the CPU Time stat. If anyone can advise on sensible steps to aid in investigating such issues though that would also be useful.

Answer 1

This can sometimes happen when applications are using implicit transactions

It doesn't help that sp_who2 is really confusing -- Aaron is right that you're better off with sp_WhoIsActive or sp_BlitzWho to find running queries.

One dead giveaway of implicit transactions is seeing the query text like begin tran or IF @@TRANCOUNT > 0.

This can also happen when queries are using explicit transactions, of course. It's just far easier to catch those in code.

As to why CPU time is very low -- well it doesn't take much CPU to do an index seek to one row and lock it, then cause problems for any other queries that also want that row.