У меня есть приложение, использующее счетчики производительности, которое работает несколько месяцев. Теперь на моей машине разработчика и другой машине разработчика она начала зависать, когда я вызываю PerformanceCounterCategory. Существуют. Насколько я могу судить, зависает бесконечно. Неважно, какую категорию я использую в качестве входных данных, и другие приложения, использующие API, демонстрируют такое же поведение.
Отладка (с использованием серверов символов MS) показала, что зависает вызов Microsoft.Win32.RegistryKey. Дальнейшее исследование показывает, что зависает именно эта строка:
while (Win32Native.ERROR_MORE_DATA == (r = Win32Native.RegQueryValueEx(hkey, name, null, ref type, blob, ref sizeInput))) {
По сути, это цикл, который пытается выделить достаточно памяти для данных счетчика производительности. Он начинается с size = 65000
и выполняет несколько итераций. В 4-м вызове, когда size = 520000
, Win32Native.RegQueryValueEx
зависает.
Более того, что довольно тревожно, я нашел этот комментарий в справочном источнике для PerformanceCounterLib.GetData:
// Win32 RegQueryValueEx for perf data could deadlock (for a Mutex) up to 2mins in some
// scenarios before they detect it and exit gracefully. In the mean time, ERROR_BUSY,
// ERROR_NOT_READY etc can be seen by other concurrent calls (which is the reason for the
// wait loop and switch case below). We want to wait most certainly more than a 2min window.
// The curent wait time of up to 10mins takes care of the known stress deadlock issues. In most
// cases we wouldn't wait for more than 2mins anyways but in worst cases how much ever time
// we wait may not be sufficient if the Win32 code keeps running into this deadlock again
// and again. A condition very rare but possible in theory. We would get back to the user
// in this case with InvalidOperationException after the wait time expires.
Кто-нибудь видел такое поведение раньше? Что я могу сделать, чтобы решить эту проблему?