我有一个托管的Windows Azure网站。我发现了一种情况，即网站锁定在用户的网络浏览器中（几个月前我问过这个问题——启动SSRS报告会导致浏览器挂起）。
我已经设置了流日志记录，现在可以在VS2015中查看流了。在我的global.asax中，我在每个处理程序的开头和结尾都添加了一条跟踪语句。关于我失败的（挂起的）请求-请参阅链接的帖子了解更多详细信息-我看到"PostMapRequestHandler"事件完全启动。下一个似乎触发的事件（基于监视成功的请求）是AcquireRequestState。
在请求失败的状态下，我从未看到AcquireRequestState完成。如果我输入了一个有目的的错误——抛出新异常（"抛出我"）——应用程序将显示黄色屏幕。然而，如果这里只有我的跟踪语句，我永远看不到这个方法是完整的。
当我处于这种糟糕的状态时，浏览器永远不会从服务器得到响应。等待大约5-10分钟后，页面将显示500。只有完全关闭浏览器并打开一个新窗口，基本上扔掉旧的会话信息，我才能绕过这个问题。
- 我还能在哪里找到这个全局方法处理程序失败的原因
- 它告诉我AcquireRequestState没有完成什么？我的直觉告诉我正在处理一些"糟糕"的会议魔力，但我有点不知所措
有几种可能性：
- 根据您运行网站的方式，您可以将.PDB文件和其他代码放在服务器上，并在问题发生时捕获过程的快照（您需要对服务器进行桌面访问，这取决于您用于托管网站的azure系统）。在任务管理器中，右键单击相应的w3wp进程，然后选择"创建转储文件"
- 它已经被弃用了，但在过去，我使用
Thread.Suspend()、new StackTrace(thread, true)和Thread.Resume()得到了不错（不太好）的结果。请注意，其中一些函数已被弃用，需要非常小心地执行。您需要非常小心地在每个请求进入时创建一个线程列表，并添加一个新类型的请求，该请求遍历列表以获取线程状态并将其转储。（对于诊断像您这样的问题（在大型系统中并不罕见），.NET中缺乏此功能是一个严重的问题 - 在导致问题的执行路径中放入额外的临时日志记录代码，重新创建问题，反复检查日志结果，并添加更多日志记录，直到找到问题为止
对我来说，这听起来像是一个无限循环
您是否尝试将调试器附加到web应用程序？您可以执行以下操作：https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/
附加调试器将允许您查看所有线程和调用堆栈，因此它应该有助于诊断问题。