在WinDbg中调试.NET字符串值 [英] Debugging .Net String value in windbg

问题描述

我有捕获异常的.NET应用程序转储，我使用的WinDbg和兴趣在一个字符串参数对的方法之一的价值分析。我已经分离出的String对象。我的WinDbg的工作是：

I have a .Net application dump which captured an exception, I'm analysing using windbg and interested in the value of a String parameter on one of the methods. I've isolated the String object. My windbg working is:

0:000> .loadby sos mscorwks
0:000> !dso
OS Thread Id: 0x16f0 (0)
RSP/REG          Object           Name
00000000001fe908 000000000f011440 System.AppDomainSetup
00000000001fe918 000000000f0335f8 System.ArgumentException
00000000001fe920 000000000f011b60 System.String

0:000> !do 000000000f011b60

Name: System.String
MethodTable: 000007feef477a80
EEClass: 000007feef07e530
Size: 538(0x21a) bytes
 (C:\Windows\assembly\GAC_64\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: C:\Windows\Installer\MSI2D87.tmp
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007feef47ecf0  4000096        8         System.Int32  1 instance              257 m_arrayLength
000007feef47ecf0  4000097        c         System.Int32  1 instance              179 m_stringLength
000007feef4794c8  4000098       10          System.Char  1 instance               43 m_firstChar
000007feef477a80  4000099       20        System.String  0   shared           static Empty
                                 >> Domain:Value  00000000029d02d0:000000000f011308 <<
000007feef479378  400009a       28        System.Char[]  0   shared           static WhitespaceChars
                                 >> Domain:Value  00000000029d02d0:000000000f0121f8 <<

在m_stringLength成员变量表示该字符串是179个字符长，但检查它似乎是唯一的32个字符的字符串。看着这个字符串就是内存显示为空值终止。还有空终止字符后多个字符。这可以重复使用的内存或字符串腐败然而由于显示的路径看起来是正确的。 所引发的异常是非法字符路径但在这条道路没有非法字符。 因此，对于这种异常的调用堆栈是：

The m_stringLength member variable indicates that the string is 179 characters long, however inspecting the string it seems to be only 32 characters long. Looking at the memory for this string is appears to be NULL terminated. There are more characters after the NULL terminating character. This may be reused memory or a string corruption however the path looks correct as displayed. The exception being thrown is 'Illegal characters in path' but there are no illegal characters in this path. So the call stack for this exception is:

0:000> !CLRStack
OS Thread Id: 0xbac (0)
Child-SP         RetAddr          Call Site
000000000021e9a0 000007feeea64dec System.IO.Path.CheckInvalidPathChars(System.String)
000000000021e9e0 000007feee9c0e66 System.IO.Path.NormalizePathFast(System.String, Boolean)
000000000021eaa0 000007feee9badf8 System.AppDomainSetup.NormalizePath(System.String, Boolean)
000000000021eb10 000007feeea630ad System.AppDomainSetup.SetupDefaultApplicationBase(System.String)
000000000021eb70 000007feee9bb27b System.AppDomain.SetupFusionStore(System.AppDomainSetup)
000000000021ebc0 000007feef87d4a2 System.AppDomain.SetupDomain(Boolean, System.String, System.String)

是否System.IO.Path.CheckInvalidPathChars方法过程中使用在m_stringLength找到的长度的字符串，或者它考虑到空终止字符串本身中？ 我也开这样的事实，还有别的东西错了，如果你能发现一些东西我没有。

Does the System.IO.Path.CheckInvalidPathChars method process the string using the length found in m_stringLength, or does it take into account the NULL termination in the string itself? I'm also open to the fact that there is something else wrong if you can spot something I haven't.

推荐答案

下面就是System.IO.Path.CheckInvalidPathChars做（至少在.NET 2.0）：

Here's what System.IO.Path.CheckInvalidPathChars is doing (at least in .NET 2.0):

for (int i = 0; i < path.Length; i++)
{
    int num2 = path[i];
    if (((num2 == 0x22) || (num2 == 60)) || (((num2 == 0x3e) || (num2 == 0x7c)) || (num2 < 0x20)))
    {
        throw new ArgumentException(Environment.GetResourceString("Argument_InvalidPathChars"));
    }
}

注意string.length减的有趣的部分，那就是如何字符串实际上暴露了它的长度属性，丢失：

Note that the interesting part of string.Length, that is, how string actually exposes its length property, is missing:

public int Length { [MethodImpl(MethodImplOptions.InternalCall)] get; }

我会尝试，如果可以模拟这个问题，通过检索准确的字符串（最多为长度存储在m_stringLength），并尝试重现该问题。

I would try to simulate the issue if possible, by retrieving the exact string (up to to length stored in m_stringLength) and trying to reproduce the issue.

这篇关于在WinDbg中调试.NET字符串值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！