我有一个使用性能计数器的应用程序,它已经运行了几个月。现在,在我的开发机器和另一台开发机器上,当我调用 PerformanceCounterCategory.Exists 时它已经开始挂起。据我所知,它无限期地挂起。无论我使用哪个类别作为输入,使用 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.
有没有人见过这种行为?我该怎么做才能解决这个问题?
最佳答案
这个问题现在已经解决了,由于这里没有答案,所以我会在这里添加一个答案,以防将来搜索时发现问题。
我最终通过停止打印后台处理程序服务(作为临时措施)修复了这个错误。
看起来性能计数器的读取实际上需要枚举系统上的打印机(由挂起进程的 WinDbg 转储确认,我可以在堆栈跟踪中看到 winspool 正在枚举打印机,并且卡在网络通话)。这实际上是系统失败的原因(果然,打开“设备和打印机”窗口也挂起)。令我困惑的是,打印机/网络问题实际上会使性能计数器下降。人们会认为在这种情况下内置了某种故障保护装置。
我猜测这是由网络上的打印机/驱动程序错误引起的。我还没有在受影响的系统上重新启用打印,因为我们正在寻找坏打印机。
关于c# - 什么会使 PerformanceCounterCategory.Exists 无限期挂起?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4209366/