我们有一个.NET应用程序，可以将文件从客户端工作站传输到LAN中央服务器上的数据库。我们的一些客户在使用商业第三方WiFi加密机制的无线Windows XP工作站上运行此操作（出于各种原因，他们不使用标准的WiFi加密，如WPA）。相当一致，当我们的应用程序运行时，这些工作站会蓝屏。
我们的应用程序不直接调用任何非托管代码，但显然我们程序正在做的是间接导致底层网络堆栈出现问题。我从一台受影响的计算机上获得了一个迷你内核转储文件并将其加载到WinDbg中，它告诉我崩溃可能是由.sys文件引起的，该文件是加密软件的驱动程序文件之一（我已经怀疑过） ）。但是，调试器没有告诉我其他有用的内容。
我的问题是：有没有办法让我从崩溃的角度一直到我们的.NET应用程序获得堆栈跟踪？我是否需要完整的内存转储？我有我们的应用程序的来源，但我受到以下事实的阻碍：a）我没有相关驱动程序的源或符号; b）我对低级Windows调试没有经验。如果有必要，我不介意修改我们的应用程序以避免有问题的调用，但我需要知道要避免的调用。
答案 0 :(得分：3)
正如评论所指出的，用户模式程序不能导致蓝屏。只有内核级组件才能导致BSOD。最可能发生的事情是您的程序碰巧以某种方式发送数据，网络驱动程序无法处理并导致BSOD。这不是你的程序错误。所有内核驱动程序都应该使用防御性编程技术。因此，如果BSOD正在发生，则是驱动程序故障。这是kerenel / usermode分离的主要特征之一。用户模式不应该能够做任何可以BSO框的东西。
我意识到，当您尝试修复问题时，上述建议并不总是有用。所以最好的办法是在windbg中打开转储，然后运行！analyze -v。这将为您提供合理的堆栈跟踪（对于非托管代码），您可以看到导致问题的驱动程序。
如果你想看看哪个线程引起了这个问题，我恐怕你的SOL。基本上不可能知道哪个线程导致了问题，因为很可能数据包被卡在队列中然后再处理。当BSOD的时候，将数据包放入队列的线程已经关闭并完成其他事情。
但是，如果你是超级幸运并且星星都对齐了，那么也许你可能仍然将线程放在队列的同一个地方，你可以看看是否使用了带有SOS dll的windbg。 / p>
开始使用windbg进行托管调试的合理帮助是： http://blogs.msdn.com/b/alejacma/archive/2009/07/07/managed-debugging-with-windbg-introduction-and-index.aspx
这不会回答你所有的问题，但这是一个不错的开始，谷歌搜索将让你完成大部分剩余的工作。
答案 1 :(得分：-1)
通常这会导致创建转储文件。在windbg中加载转储文件并运行“analyze -v”并上传相应的输出以供进一步分析。