使用WinDbg从minidump确定InnerException的行号 [英] Determine line number of InnerException from minidump using WinDbg
问题描述
我正在尝试从转储中跟踪NullReferenceException。 NullReferenceException不是崩溃异常，而是崩溃异常是TargetInvocationException，而InnerException是NullReferenceException。
I'm trying to track down a NullReferenceException from a dump. The NullReferenceException is not the crashing exception, rather the crashing exception is a TargetInvocationException with an InnerException which is the NullReferenceException.
我正在将Windbg与SOS一起使用，我使用了命令 analyze -v ，这给了我打电话NullReferenceException的堆栈：
I'm using Windbg with SOS, I use the the command analyze -v and this gives me the call stack of the NullReferenceException:
EXCEPTION_OBJECT: !pe f6cb150
Exception object: 000000000f6cb150
Exception type: System.NullReferenceException
Message: Object reference not set to an instance of an object.
InnerException: <none>
StackTrace (generated):
SP IP Function
000000002CD9D8C0 000007FF01E7C639 MyDll!DoSomething2()+0xe99
000000002CD9DBE0 000007FF01E7B11D MyDll!DoSomething1()+0x43d
000000002CD9DD20 000007FF01E7AB11 MyDll!WorkerDoWork(System.Object, System.ComponentModel.DoWorkEventArgs)+0x51
000000002CD9DD80 000007FEEA68A0F2 System_ni!System.ComponentModel.BackgroundWorker.WorkerThreadStart(System.Object)+0x62
注意，我得到的方法名称带有字节偏移量，但没有行号。 DoSomething2 是一个大函数，因此NullReferenceException发生的位置并不明显。
Notice, that I get the method names with byte offsets, but no line numbers. DoSomething2 is a large function, so it's not obvious where the NullReferenceException occurred.
我尝试遵循Tess Ferrandez的博客：
I attempted to follow the instructions in Tess Ferrandez's blog:
但是我很早就尝试在哪里确定方法 DoSomething2 的方法描述符，使用！ip2md和DoSomething2的IP：7FF01E7C639：
But I got stuck early on where I attempt to determine the method descriptor for the method DoSomething2 using !ip2md with the IP of DoSomething2: 7FF01E7C639:
> !ip2md 7FF01E7C639
Failed to request MethodData, not in JIT code range
请注意！ ip2md命令在发生TargetInvocationException的方法的IP上成功。
Note that the !ip2md command succeeds on the IP of the method where the TargetInvocationException occurred.
问题 ：
Question:
从哪里可以缩小DoSomething2中崩溃的行？
请注意，我无法重现崩溃，所以我只有这个转储（和几个重复的转储）。
Where can I go from here to narrow down what line in DoSomething2 is crashing? Note that I cannot reproduce the crash, so all I have this (and several duplicate) dumps.
其他说明：
- .NET 4.0
- Windbg版本：6.12.0002.633 AMD64
- 我是Windbg的新手，所以信息越多
编辑1
当我没有正确设置符号时，得到以下信息：
When I don't have symbols set up properly, I get the following:
STACK_TEXT:
00000000`2cd9d8c0 00000000`ffffffff MyDll!Unknown_0xe99+0xe99
00000000`2cd9dbe0 00000000`ffffffff MyDll!Unknown_0x43d+0x43d
00000000`2cd9dd20 00000000`ffffffff MyDll!Unknown_0x51+0x51
00000000`2cd9dd80 00000000`ffffffff system_ni! System.ComponentModel.BackgroundWorker.WorkerThreadStart+0x62
当我将其设置为指向我的符号服务器时，开启！sym嘈杂，似乎可以正确加载符号：
When I set it up to point to my symbol server and turn on !sym noisy, it appears to load symbols properly:
0:000> ld MyDll
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\MyDll.dll - file not found
SYMSRV: c:\symbols\MyDll.dll\4F3D6F4B154000\MyDll.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/MyDll.dll/4F3D6F4B154000/MyDll.dll not found
SYMSRV: \\mysymbolserver\store\Mydll.dll\4F3D6F4B154000\file.ptr
SYMSRV: MyDll.dl_ from \\mysymbolserver\store: uncompressed
DBGHELP: c:\symbols\MyDll.dll\4F3D6F4B154000\MyDll.dll - OK
DBGENG: c:\symbols\MyDll.dll\4F3D6F4B154000\MyDll.dll - Mapped image memory
SYMSRV: c:\symbols\MyDll.pdb\8AFC2BE7529A41289FA9FBCEDB6836161\Mydll.pdb not found
SYMSRV: http://msdl.microsoft.com/download/symbols/Mydll.pdb/8AFC2BE7529A41289FA9FBCEDB6836161/MyDll.pdb not found
SYMSRV: \\mysymbolserver\store\MyDll.pdb\8AFC2BE7529A41289FA9FBCEDB6836161\file.ptr
SYMSRV: MyDll.pd_ from \\mysymbolserver\store: uncompressed
DBGHELP: MyDll - private symbols & lines
c:\symbols\MyDll.pdb\8AFC2BE7529A41289FA9FBCEDB6836161\MyDll.pdb
Symbols loaded for MyDll
编辑2
我尝试使用！name2ee，如下所示：
I tried using !name2ee as follows:
0:000> !name2ee MyDll!MyType.DoSomething2
Module: 000007ff004995b8
Assembly: Autodesk.DataManagement.Client.Framework.Vault.dll
<invalid module token>
所以，那里没有运气。但是后来，我似乎几乎明白了：
So, no luck there. But then I almost seemed to get somewhere with this:
0:000> !name2ee MyDll.dll!MyNamespace.MyType
Module: 000007ff004995b8
Assembly: MyDll.dll
Token: 000000000200008c
MethodTable: 000007ff01b2e258
EEClass: 000007ff01b415e0
Name: MyNamespace.MyType
0:000> !dumpmt -md 7ff01b2e258
EEClass: 000007ff01b415e0
Module: 000007ff004995b8
Name: MyNamspace.MyType
mdToken: 000000000200008c
File: C:\Program Files\MyCompany\MyProduct\Bin\MyDll.dll
BaseSize: 0x30
ComponentSize: 0x0
Slots in VTable: 31
Number of IFaces in IFaceMap: 2
--------------------------------------
MethodDesc Table
Entry MethodDesc JIT Name
000007feeb31a2c0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007feeb3689f0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007feeb3688c0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007feeb353440 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01b01300 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01e89140 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01b9c080 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01f45f40 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01a9b358 000007ff01b2e128 NONE MyType.DoSomething3()
000007ff01a9b360 000007ff01b2e130 NONE MyType.DoSomething4()
000007ff01a9b368 000007ff01b2e138 NONE MyType.DoSomething5()
000007ff01e79800 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff020fea80 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01a9b3b0 000007ff01b2e1b0 NONE MyType.DoSomething6()
000007ff01a9b3b8 000007ff01b2e1b8 NONE MyType.DoSomething7()
000007ff01a9b328 000007ff01b2e0f0 NONE MyType..ctor()
000007ff01b01280 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01e7a810 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01e7aac0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01e83240 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01f19520 000007ff01b2e178 JIT MyType.RunWorkerCompleted(System.Object, System.ComponentModel.RunWorkerCompletedEventArgs)
000007ff01e7ace0 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01e7b7a0 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01e7b710 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01e7d2b0 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01b015f0 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01b88ce0 0000000000000000 JIT 0000000000000000 is not a MethodDesc
000007ff01a9b3e0 000007ff01b2e200 NONE MyType.DoSomething8()
000007ff01b921e0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01b933b0 0000000000000000 NONE 0000000000000000 is not a MethodDesc
000007ff01b93870 0000000000000000 NONE 0000000000000000 is not a MethodDesc
我正在猜测所有缺少的条目（那些带有而不是MethodDesc）是由于这不是完整的小型转储。
I'm guessing all the missing entries (those listed with "is not a MethodDesc") are due to this not being a full mini-dump. Is that right?
推荐答案
在上面的评论中，您提到了||。命令产生用户迷你转储。为了正确调试.NET代码，您需要一个完整的转储，该转储将在||中指示全内存用户小型转储。命令。我认为这是您的问题。如果无法访问完整的加载程序堆，则无法将代码地址映射回.NET方法，因此无法获得堆栈跟踪。如果可以重现此问题，请捕获完整的转储。您可以使用ADPlus，ProcDump或DebugDiag在崩溃时捕获转储。
In a comment above, you mention that the || command yields "User mini dump". In order to properly debug .NET code, you need a full dump, which would indicate "Full memory user mini dump" from the || command. I think this is your problem. Without access to the full loader heaps, it's not possible to map a code address back to a .NET method, so you can't get a stack trace. If you can reproduce this problem, capture a full dump. You can use ADPlus, ProcDump or DebugDiag to capture a dump on crash.
这篇关于使用WinDbg从minidump确定InnerException的行号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
