使用 Windows 调试工具调试 .NET 2.0 Winforms 应用程序
我支持一个部署相当广泛的 .NET 2.0 Winforms 应用程序。在极少数情况下，我们会接到客户的支持电话，其中当您尝试启动应用程序时，应用程序立即返回 .NET 运行时异常。
过去，我们帮助客户重新安装 .net 框架，并且经常可以工作......但有时却不能。
在这种情况下，可以使用Windows 调试工具来确定问题的原因。如果是这样，您是否必须将调试符号下载到目标计算机（要避免，因为下载到目标可能需要数百 MB 的内容。）
对于 .net 应用程序来说，这是否太过分了？任何替代方案。你会如何调试这个。非具体的逐步说明将不胜感激。当然，这个应用程序在目标机器上编译为 RELEASE 配置。客户很可能没有安装开发工具或调试工具。我们通常可以远程控制访问计算机。重申一下。当客户尝试运行应用程序并且应用程序立即失败时，就会发生这种情况。
为客户解决此问题的最快途径是什么？
以下是事件日志中最近出现的错误的示例。
事件类型 clr20r3。 .exe P2 2010.1.0.0，p3 4B857AFD P4 巴拉巴拉 系统.无效操作，P10 NIL。
来源：.NET 运行时 2.0 错误。 事件 ID：5000
提前致谢。
赛斯
I support a .NET 2.0 Winforms application that is fairly widely deployed. On rare occasion we get a support call from a customer in which the application returns a .NET runtime exception AS SOON as you attempt to launch the application.
In the past we have helped the customer re-install the .net framework and very often that works...but occasionally not.
In such a situation could the Windows Debugging Tools be used to determine the cause of the problem. If so would you HAVE to download debugging symbols to the target computer (want to avoid since that can be several hundred MBs of stuff to download to the target.)
Is this overkill for a .net app? Any alternatives. How would you go about debugging this. Non-specific step-by-step would be appreciated. Of course, this app is compiled as a RELEASE configuration on the target machine. The customer will very likely NOT have dev tools installed or debugging tools. We DO usually have remote control access to the computer. To re-iterate. This happens AS SOON AS the customer attempts to run the application and it fails immediately.
What is the quickest path to solving this problem for the customer?
Here is an example of a recent error from the Event Log.
EventType clr20r3. .exe P2 2010.1.0.0, p3 4B857AFD P4 BLAH BLAH
system.invalidoperation, P10 NIL.
Source: .NET Runtime 2.0 Error.
EventID: 5000
Thanks in advance.
Seth
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为什么不使用它呢？
对于客户的机器，您将无法进行远程调试。因此，建议捕获崩溃转储以捕获崩溃问题，并捕获挂起转储以捕获挂起问题，WinDbg 或 ADPlus.exe 在这里非常有用。
要求您的最终用户在 WinDbg 中启动您的应用程序，并执行
以保存故障转储，然后您可以请求转储文件并分析故障。
在目标机器上，不需要任何符号。当您在自己的计算机上分析故障转储时，符号非常有用，这就是 SOS 之类的东西有用的地方。
当然，还有其他方法可以获取故障转储，
http://blogs.msdn.com/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx
Why not use that?
For customers' machine, you won't be able to do remote debugging. Therefore, it is recommended to capture crash dump for crashing and hang dumps for hang problems, and WinDbg or ADPlus.exe is very useful here.
Ask your end user to launch your application in WinDbg, and execute
to save a crash dump, then you can ask for the dump file and analyze the crash.
On target machine, no symbol is required. Symbols are useful when you analyze the crash dump on your own machine, and that's where things such as SOS are useful.
Of course there are other ways to get crash dumps,
http://blogs.msdn.com/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx
编辑：刚刚看到“启动时立即发生”。 WinDBG 确实可以提供帮助。
虽然 Windows 调试工具确实主要适用于本机应用程序，但它们对于托管应用程序也很有用。托管应用程序在执行时不仅最终是“本机”的，而且特别是 WinDBG 或 CDB 的 SOS 扩展（如果您更喜欢命令行）。
特别是崩溃应用程序的（小型）转储可以通过 SOS 扩展进行很好的分析。只要您在分析转储时手头有匹配的符号文件 (.PDB)，您的应用程序是否在发布或调试模式下编译并不重要。
那里有很多信息，在这个答案中有很多值得讨论的内容，但最好的选择是搜索“windbg sos”。
关于你给出的例子
它可能是其他东西，但对我来说，它看起来像是 .NET 应用程序中未捕获的异常 - 在本例中是 System.InvalidOperationException。
如果您可以获得崩溃的应用程序的小型转储（请查看 ADPlus 工具，它是调试工具的一部分，用于“按需”或“根据事件”获取转储），然后您可以将其加载到 WinDBG 中并使用 SOS 扩展（命令 !clrstack、!dumpstack、!threads 等）找出未捕获的异常从何而来。
Edit: Just saw the "happens immediately on startup". Indeed WinDBG can help.
While the Debugging Tools for Windows are indeed mainly ment for native applications, they are usefull for managed applications as well. Not only are managed apps "native" in the end, when they execute, but there is also and in particular the SOS extension for WinDBG or CDB (if you prefer the command line).
Especially (mini-)dumps of crashed applications can be analyzed quite nicely with the SOS extension. If your application is complied in release or debug mode does not matter a whole lot, as long as you've got the matching symbol files (.PDB) at hand when analyzing a dump.
There is a whole lot information out there, way to much to talk about in this answer, but your best bet is searching for "windbg sos".
Concerning the example you gave
it could be something else, but to me it looks like an uncaught exception in the .NET application - in this case a System.InvalidOperationException.
If you can get a minidump of the crashed application (look into the ADPlus tool, which is part of debugging tools to get a dump "on demand" or "on event"), then you can load that into WinDBG and use the SOS extensions (commands !clrstack, !dumpstack, !threads, etc.) to figure where that uncaught exception came from.
我认为您不需要“Windows 调试工具”。调试符号适用于操作系统，而不是 .NET Framework。 （提醒一下，您的 Windows.Forms 应用程序位于 .NET Framework 中，而不是操作系统中。）
“远程调试”是否有帮助，请访问 http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx？
我通常包含一个“StopSwitch”，但这不是启用 JIT 的要求。 （请参阅“StopSwitch 停止执行以进行即时调试”，网址为 http ://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!309.entry）这允许我启用开关，然后在遇到调试器停止语句时附加到正在运行的应用程序。
您可以调试“发布”版本。发布 pdb 对于堆栈跟踪很有帮助。
我以前也遇到过这个问题。我启用了 StopSwitch，检查是第一行，但 JIT 未启动，因为问题发生在 .NET Framework 加载我的应用程序之前。
I don't think you want the "Windows Debugging Tools". Debugging symbols are for the OS, not the .NET Framework. (Reminder, your Windows.Forms application lives in the .NET Framework, not in the OS.)
Will "Remote Debugging" help at http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx?
I usually include a "StopSwitch", but this is not a requirement to enable JIT. (See "StopSwitch Stops Execution for Just-In-Time Debugging" at http://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!309.entry) This allows my to enable the switch then attach to the running application when it hits the debugger stop statement.
You can debug the "release" builds. The release pdb are helpful for stack traces.
I had this problem before. I enable the StopSwitch, the check was the first line, but JIT was not launch because the problem occurred before the .NET Framework even loaded my application.
我写了一篇博客文章，其中包含一些分步说明以及有用的 URL。
http://www.spearsofttech.com/2010/03/09/how-to-use-debugging-tools-for-windows-to-debug-a-net-application/
赛斯
I wrote a blog post with some step by step instructions along with helpful URLs.
http://www.spearsofttech.com/2010/03/09/how-to-use-debugging-tools-for-windows-to-debug-a-net-application/
Seth