如何解决 ntdll.dll 中的冻结（或死锁）？
我有一个在 .Net Framework 4 上运行的应用程序，并且我的应用程序运行托管和非托管代码。在非托管代码中，使用 UDP 套接字。当应用程序从 Visual Studio 运行时，一切都很好，但当它单独运行时，它经常冻结。我在 Windows XP SP3 和 Windows 7 SP1 上都看到过这种行为。当我将调试器附加到应用程序并暂停它时，我可以看到许多线程卡在 ntdll.dll 中的同一内存地址处。反汇编后，执行的netdll.dll命令是“ret”。
这对任何人来说都敲响了警钟吗？
之前好像也有过类似的问题，比如这里报道的，和UDP有关： http://social.msdn .microsoft.com/Forums/en-US/netfxnetcom/thread/1b54b2f2-6e7c-405b-bdda-62197ac8a287 没有给出任何答案。
我还找到了针对类似问题的旧修补程序，但根据 Microsoft 的说法，它仅适用于 Windows NT 4。
任何帮助将不胜感激。
I have an application running on the .Net framework 4 and my application runs managed AND unmanaged code. In the unmanaged code, UDP sockets are used. When the application is run from Visual Studio, all is fine, but when it is run on its own, it often freezes. I have seen the behavior on both Windows XP SP3 and Windows 7 SP1. When I attach the debugger to the application and pause it, I can see that many MANY threads are stuck at the same memory address in ntdll.dll. When disassembled, the netdll.dll command executing is "ret".
Does that ring a bell for anyone ?
It seems there has previously been similar issues, such as reported here, and it was related to UDP:
http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/1b54b2f2-6e7c-405b-bdda-62197ac8a287
No answers were ever given.
I have also found an old hotfix for a similar issue, but according to Microsoft it only applies to Windows NT 4.
Any help would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
造成死锁的不是操作系统。是的，您的堆栈跟踪将显示它在 ntdll.dll 内的 KiFastSystemCallRet() 上阻塞。堆栈跟踪指向 SYSENTER 之后的 RET 指令。但它只是做你要求它做的事情。
使用“调试”+“Windows”+“线程”窗口查看线程正在做什么。经典的死锁场景是其中一个线程已获取同步对象并处于阻塞状态。另一个线程正在尝试获取的同步对象。这是最常见的线程问题之一。
It is not the operating system that is causing the deadlock. Yes, your stack trace will show it blocking on KiFastSystemCallRet() inside ntdll.dll. With the stack trace pointing to the RET instruction after SYSENTER. But it merely is doing what you asked it to do.
Use the Debug + Windows + Threads window to see what your threads are doing. The classic deadlock scenario is that one of the threads has acquired the synchronization object and is blocking. The synchronization object that another thread is trying to acquire. This is one of the most common threading headaches.