我们有一个.NET应用程序,它将文件从客户端工作站传输到LAN中央服务器上的数据库.我们的一些客户在使用商业第三方WiFi加密机制的无线
Windows XP工作站上运行此操作(出于各种原因,他们不使用标准的WiFi加密,如WPA).相当一致,当我们的应用程序运行时,这些工作站会蓝屏.

我们的应用程序不直接调用任何非托管代码,但显然我们的程序正在做的是间接导致底层网络堆栈中的问题.我从一台受影响的计算机上获得了一个迷你内核转储文件并将其加载到WinDbg中,它告诉我崩溃可能是由.sys文件引起的,该文件是加密软件的驱动程序文件之一(我已经怀疑过) ).但是,调试器并没有告诉我其他许多有用的信息.

我的问题是：从崩溃的角度到.NET应用程序,我有什么方法可以获得堆栈跟踪吗？我需要完整的内存转储吗？我有我们的应用程序的来源,但我受到以下事实的阻碍：a)我没有相关驱动程序的源或符号; b)我对低级Windows调试没有经验.如果有必要,我不介意修改我们的应用程序以避免有问题的调用,但我需要知道要避免的调用.

最佳答案 正如评论所指出的,用户模式程序不能导致蓝屏.只有内核级组件才能导致BSOD.最可能发生的事情是您的程序碰巧以某种方式发送数据,网络驱动程序无法处理并导致BSOD.这不是你的程序错误.所有内核驱动程序都应该使用防御性编程技术.因此,如果BSOD正在发生,则是驱动程序故障.这是kerenel / usermode分离的主要特征之一.用户模式不应该能够做任何可以BSOD框的东西.

我意识到,当您尝试修复问题时,上述建议并不总是有用.所以最好的办法是在windbg中打开转储,然后运行！analyze -v.这将为您提供合理的堆栈跟踪(对于非托管代码),您可以看到导致问题的驱动程序.

如果你想看看哪个线程导致了这个问题,我恐怕你的SOL.基本上不可能知道哪个线程导致了问题,因为很可能数据包被卡在队列中然后再处理.当BSOD的时候,将数据包放入队列的线程已经关闭并完成其他事情.

但是,如果你是超级幸运的并且星星都对齐了,那么也许你可能仍然在将数据包放入队列的同一个地方仍然存在,你可以看到是否使用带有SOS dll的windbg.

使用windbg进行托管调试的合理帮助是：
http://blogs.msdn.com/b/alejacma/archive/2009/07/07/managed-debugging-with-windbg-introduction-and-index.aspx

这不会回答你所有的问题,但这是一个不错的开始和谷歌搜索将带你到余下的大部分时间.