.Net Windows服务中的StackOverflowException

在某些情况下，我的.Net windows服务可能会生成StackOverflowException。不幸的是，该服务的行为似乎只是死机停止，不向事件日志写入任何内容。我甚至没有收到来自服务控制经理的消息说服务失败

windows服务是否有任何方法可以检测到发生了此类异常

在该异常的文档中，MSDN指出，请注意，承载公共语言运行库CLR的应用程序可以指定CLR卸载发生堆栈溢出异常的应用程序域，并让相应的进程继续。这是我期望windows服务实现能做的事情，但事实并非如此

---

请不要只是回复说我应该确保我的代码永远不会抛出这样的异常-相信我，如果可以的话，我会这样做-我正在尝试以一种合理的方式处理最坏的情况，并使我的服务能够抵御意外错误。

堆栈溢出是线程可能遭受的最坏的心脏病发作。糟糕的是，你甚至没有在事件日志中找到什么。很糟糕，你甚至不能做任何合理的事情来恢复程序的状态。线程已停止，appdomain的状态也已停止。它以完全不可预测的方式变异，你只能扔掉它

你已经知道了。但对此不屑一顾并假装它没有发生会导致另一种失败。系统故障，服务应该做些什么，但没有发生。在很多情况下，这是不可接受的。文件没有得到处理，数据库没有更新，等等。这类事故可能会在以后引发一连串事故。就像首席财务官在年底发现一百万美元失踪一样

---

你不想听这个，但是没有明智的方法来处理这个问题。集中精力寻找bug，而不是创可贴。堆栈溢出总是一个编程错误。

好的，一个实用的答案。您不会被固定大小的堆栈所束缚。您可以使用ThreadStart、int构造函数创建一个具有更大堆栈的构造函数。给它几十兆字节。如果不能完全解决问题，这将大大避免问题的发生

下一步要做的事情是开始筛选要处理的xml文件。不太确定文件的原始大小是否会导致.xml中的数据正确或错误。首先检查文件的大小，如果文件是怪物，则将其放入单独的目录中。手动处理，最好由最初创建此文件的人进行处理。如果你还没有的话，确保你有一些麻烦制造者的文件。试着用一个怪物线程堆栈大小离线处理它们。如果这个问题仍然存在，那么就开始寻找一种可以预先筛选.xml内容的算法来检测问题的根源

---

如果您认为.xml文件内容可能是原因，您需要找出哪些不良内容可能导致此问题，您对xlt了解不多。

您是否尝试将调试器附加到服务？：为了尝试找出到底出了什么问题？您是否发现了错误？是的，Tony，我正在CLR中尽我所能将我们的逻辑放到另一个应用程序域中。不幸的是，本例中的问题是在100页用户提供的word XML文档上运行6000行XSLT翻译造成的。当然，我们会努力找出错误，但由于XSL的复杂性和几乎无限的输入数据范围，即我们试图处理任何word文档，偶尔需要一个backstop机制。感谢增加堆栈大小的想法，我肯定会尝试一下。目前，我设计了一个解决方案，通过该解决方案，我们将服务设置为在出现故障时自动重新启动，它将检测到意外的进程退出，并显式地使该作业失败。不幸的是，word文档和样式表一样复杂，很难想出一些规则来清理输入，而不一定排除一些可以工作的文档，这将更糟糕。