私人符号加载但没有行号显示？ [英] private symbol loaded but no line number displayed?

问题描述

我正在使用Windbg从托管代码加载崩溃转储（C＃，为任何CPU构建的控制台应用程序），并在x64平台上创建崩溃转储。我在x64平台上进行调试。

I am using Windbg to load a crash dump from managed code (C#, a console application built for Any CPU), and crash dump is created on x64 platform. I am debugging on x64 platform.

我使用以下命令加载我的应用程序的私人符号。以下是Windbg中使用的命令。

I have using the following command to load private symbol of my application. Here are what the commands I am using in Windbg.

(set symbol path and copy FooService.pdb pdb file to local symbol path D:\Debug)

0:016> .reload /f
.*** WARNING: Unable to verify checksum for FooService.exe
DBGHELP: FooService.pdb- private symbols & lines 
         D:\Debug\FooService.pdb

0:016> lm
start             end                 module name
00000000`00400000 00000000`0041c000   FooService C (private pdb symbols)  D:\Debug\FooService.pdb

我的困惑是，当使用以下命令时，堆栈跟踪中不显示行号信息。任何想法有什么问题？我需要设置源路径吗？

My confusion is, when using the following command, no line number information is showed in stack trace. Any ideas what is wrong? Do I need to set source path?

0:016> ~6 e!clrstack

编辑1：遇到一些问题，使用！pe和！U查找堆栈跟踪，抛出异常。

EDIT 1: I met with some issues with using !pe and !U to find stack trace where the exception is thrown.

这是我的调试过程。起初我使用！pe打印堆栈跟踪的异常对象，当我使用！U来组装代码。我发现的问题是！U将组装FooService.ProcessOrders（）的所有功能代码，我想要找到在函数FooService.ProcessOrders中发生崩溃的确切位置。我还发现，装配的IL代码只包含我所做的函数调用（对于非函数调用C＃代码，例如a = a * 2，仅显示汇编语言），而不是将IL映射到C＃代码的每一行， 1）正确的预期行为？ （2）从我发现的分析中找出确切的失败的C＃代码的解决方案或进一步的建议是什么？

Here is my debug process. At first I use !pe to print stack trace for the exception object, when I use !U to diassemble the code. The issue I find is !U will diassemble all function code of FooService.ProcessOrders(), and I want to find the exact place where in function FooService.ProcessOrders the crash happens. I also find the diassembled annotated IL code only contains function calls I made (for non-function call C# code, for example a=a*2, only assembly language is shown), not exactly IL mapped to each line of C# code, (1) is that the correct expected behavior? (2) what is the solution or further suggestion to find the exact failed C# code from my analysis posted here?

!pe 0000064280155325

StackTrace (generated):
    SP               IP               Function

    000000001A56DA70 00000642B74E3B7A System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(System.Data.Common.DbAsyncResult, System.String, Boolean)
    000000001A56DB10 00000642B74E3FCC System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
    000000001A56DB90 0000064280155325 FooService.ProcessOrders()
    000000001A56F3E0 0000064280153A21 FooService.RountineJob()

!U 0000064280155325 

提前感谢
George

thank in advance, George

推荐答案

WinDbg / SOS不将行号映射到！clrstack 的输出。因此，只要 lm 告诉您，您设置的自己的程序集的私有pdb符号是正确的。当前版本的WinDbg / SOS不支持与本机代码相同的扩展级源调试。

WinDbg/SOS doesn't map line numbers to the output of !clrstack. So as long as lm tells you that you have private pdb symbols for your own assemblies you setup is correct. Unfortuntately the current versions of WinDbg/SOS doesn't support source level debugging to the same extend as for native code.

编辑：关于例外。当您执行！pe ，它会告诉您调用堆栈以及相关方法的偏移量。如果您从！pe 输出的IP列中取得地址，并执行！U ，那么您将请参阅相关方法的JITTED代码。 IP列将是生成异常的代码的最后一个地址（因此，您必须进行一点计数才能找到正确的指令）。

Regarding exceptions. When you do a !pe, it will tell you the call stack as well as offsets into the relevant methods. If you take the address from the IP column of the !pe output and do a !U on that, you will see the JITTED code for the relevant method. The IP column will be the last address of the code that generated the exception (so you have to do a little counting to find the correct instruction).

反汇编的输出用.NET调用进行注释，因此不难将其映射到IL或源代码。这应该可以帮助您准确地确定要查找的哪个throw语句。

The disassembled output is annotated with .NET calls so it is no hard to map this against the IL or source code. That should help you identify exactly which throw statement you're looking for.

据说，如果将方法分成多个较小的方法，您将使调试更容易方法。如果这样做，方法名通常足以确定异常的位置。我意识到并不总是一个选择，但值得考虑。

That being said, you will make debugging a lot easier if you split methods into a number of smaller methods. If you do that, the method name is usually enough to pinpoint the location of the exception. I realize that is not always an option, but it is worth considering.

这篇关于私人符号加载但没有行号显示？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！