Да, видел я эту схему. Захватывается мьютекс, а тот же поток пытается снова войти в него, не освободив сначала. Появляется только при очень удачном переплетении потоков, поэтому ускользает от обычных тестов. Проверь, не используешь ли ты реентерабельные мьютексы там, где можно обойтись обычным, или не вызывает ли какой-то поток функцию, которая в итоге захватывает мьютекс, который он уже держит. Ещё убедись, что с блокировками чтения-записи не происходит несанкционированное повышение прав. В таких микроскопических гонках и прячутся странные ошибки. Если выложишь трассировку стека, я смогу точно указать цепочку вызовов.

Конечно, сними отслеживание, как только сможешь. Я прогоню это через отладчик и посмотрю, где загвоздка. Только будь готов к тому, что придется долго копаться в стеке, если ошибка серьезная.

Понял, отправляй. Разберу и скажу, где затык. Мы всё сделали, как надо. Понял, отправляй. Разберу и скажу, где затык.

Похоже, тут классическая взаимная блокировка – один и тот же поток пытается захватить мьютекс, который он уже держит, через цепочку вызовов. В идеале эту цепочку нужно упростить: либо отпускай мьютекс перед вызовом другого метода, либо перестрой пул, чтобы все запросы и освобождения происходили под одним мьютексом. Если хочешь, пришли код конкретного метода, который вызывает проблемы. А так я покопаюсь в логике пула и посмотрю, можно ли оптимизировать порядок захвата мьютексов.