调试已编译的 .NET 2.0 应用程序
我不知道我是否会在这里传递所有必要的信息，但我只是被要求在这里发布这个问题，而我并不完全关注此事。
有一个 .NET Framework 2.0 应用程序在调试模式下编译，参数 jitDebugging 在 app.config 中设置为 true。
<system.windows.forms jitDebugging="true" />
发生任何崩溃后，我们都会看到一个对话框，允许我们发送报告或调试程序。当我们选择调试并选择合适的 VS 时，IDE 会启动，但会显示以下消息：
没有为任何调用堆栈帧加载任何符号。无法显示源代码。
和
运行模式下无法显示反汇编代码。
是否有可能看到代码或发生崩溃的位置？
//编辑：
Tarscher 的建议很好，但最终的解决方案是...添加一个带有 Main() 方法的模块并强制项目使用它 - 不知何故感谢 VS 能够显示代码并找到异常的源。
I don't know if I'll pass all the necessary information here, but I've only been asked to post this question here and I'm not entirely onto the matter.
There is a .NET Framework 2.0 application compiled in the Debug mode with the parameter jitDebugging set to true in app.config
<system.windows.forms jitDebugging="true" />
After any crash we get the dialog box allowing us to send a report or to debug the program. When we choose to debug and select proper VS, the IDE starts but with the announcement:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
and
Disassembly cannot be displayed in run mode.
Is there any possiblity to see the code or the spot where the crash has occured?
//edit:
Tarscher's advice was fine, but the final solution was to... add a module with the Main() method and force project to use it - somehow thanks to that VS was able to display code and locate exception's source.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
确保应用程序中包含 .pdb 文件和 .dll 文件。
make sure you have .pdb files along with your .dll files in your application.
您的 .net 应用程序将在崩溃后创建一个转储文件。您需要将此转储文件与应用程序 pdb 文件一起加载才能查看源代码。该 pdb 文件是在编译时创建的，并存储有关程序的调试信息。
在您的情况下，Visual Studio 可能无法找到 pdb 文件并加载它们。
Your .net application will create a dump file after the crash. You need to load this dump file together with the application pdb file to see your source code. This pdb files are created when compiling and store debugging information about a program.
In your case Visual Studio might not be able to locate the pdb files and load them.
不确定您的部署场景是什么样的，但在客户或生产计算机上运行调试器通常不太实用。为 AppDomain.UnhandledException 事件编写一个事件处理程序并显示 e.ExceptionObject.ToString() 的值。您的客户至少可以向您发送屏幕截图。您将收到异常消息和一个不错的堆栈跟踪，显示您的程序是如何遇到麻烦的。通常 95% 就足以看出哪里出了问题。
Not sure what your deployment scenario looks like, but running a debugger on a customer or production machine isn't typically very practical. Write an event handler for the AppDomain.UnhandledException event and display the value of e.ExceptionObject.ToString(). At a minimum, your customer can send you a screen shot. You'll get the exception message and a nice stack trace, showing how your program got in trouble. Usually 95% good enough to see what went wrong.