我们有一个IIS托管的网络方法，大约有10％的时间在我们身上随机死亡。在尝试调试时，我们在每个实际代码行前添加了Log.Debug（）消息，它似乎在随机行上死亡。
有没有人看过这个或者想过如何调试这个？
[其他详细信息]
我们花了很多时间查看它并发现了以下内容......
我们有一个单独的自托管WCF服务，它可以访问同一个数据库，并且位于同一台机器上。当它处于高负荷时，网络方法每次都会呱呱叫。如果它没有负载，那么事情通常可以正常工作（但不是100％）。
高CPU似乎不是问题的一部分。我们运行了一个小应用程序，它创建了一个高CPU负载，并且Web服务没有死。
当我们新建一个XmlSerializer（没有执行sgen precomp）或让NHibernate创建一个SessionFactory时，Web服务就会死掉。这些事情的共同点仅在于它们1）看起来像人们通常做的事情.2）看起来它们会相当密集。
我们添加了一个Global.asax来尝试捕获Application_End和Application_Error但两个事件都没有被触发。这对我来说意味着我们没有处理正常的应用程序池重置？
答案 0 :(得分：0)
听起来这可能是一个线程问题。您正在使用信息性调试消息 - 您应该尝试在运行调试器时重现该问题并打破所有异常。确保检查所有Windows日志，以获取有关应用程序池崩溃原因的信息。
每条评论：这很难说，但很多事情都会导致线程看起来“只是死”。内存问题：你在做什么互操作吗？编组不当：您是否正在接触另一个线程上的数据？但是，我将播放概率并询问您是否确定您处理可能发生的任何异常并记录它。你确定你没有吞噬异常并且没有报告它吗？某处低点？这是权限问题吗？您是在运行部分信任还是在低权限用户帐户上运行？
答案 1 :(得分：0)
想出来......真的有两个问题..
我们添加了Global.asax，但没有被复制，这解释了为什么我们没有看到任何消息。我们解决了这个问题，发现了......
我们的WCF日志正在写入IIS Web服务的bin目录。回想起来，这是一种愚蠢的行为，因为WS是一个古老的学校网络服务。 WCF的东西只是出于我们不知道的某些原因而在同一目录中，因为最初设置的人已经不在了。
经验教训..某处有一条消息可以解释所有事情......你只需要找到它。