sosex.mbp 或 sosex.mbm 设置的断点不起作用答案

【问题标题】：Breakpoint set by sosex.mbp or sosex.mbm not workingsosex.mbp 或 sosex.mbm 设置的断点不起作用
【发布时间】：2012-08-01 23:15:41
【问题描述】：

我正在使用 VS.NET 2010。我编译了一个非常简单的 .NET 4.0 应用程序。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestWindbg
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.ReadLine();
            Func1();
        }

        static void Func1()
        {
            int i = 0;
            int j = i + 2;
            Console.WriteLine(j);
        }
    }
}

我打开windbg 6.12.0002.633编译的可执行文件。键入以下命令以加载 sosex

.loadby sosex clr

然后，输入以下命令设置断点

!mbm TestWindbg.Program.Func1
!mbp Program.cs 16

然后运行程序。没有一个断点被击中。

有什么想法吗？

* 编辑 *

根据 Marc 的要求，我在此处粘贴有关我的环境的更多详细信息

0:004> !mbl
1 eu: disable *!TESTWINDBG.PROGRAM.FUNC1 ILOffset=0: pass=1 oneshot=false thread=ANY
2 eu: disable Program.cs, line 16: pass=1 oneshot=false thread=ANY
0:004> .chain
Extension DLL search Path:
    C:\Program Files\Debugging Tools for Windows (x64)\WINXP;C:\Program Files\Debugging Tools for Windows (x64)\winext;C:\Program Files\Debugging Tools for Windows (x64)\winext\arcade;C:\Program Files\Debugging Tools for Windows (x64)\pri;C:\Program Files\Debugging Tools for Windows (x64);C:\Program Files\Debugging Tools for Windows (x64)\winext\arcade;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\;C:\Program Files (x86)\Shoreline Communications\ShoreWare Client\;C:\Program Files (x86)\Perforce;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\
Extension DLL chain:
    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sosex: image 4.5.0.0, API 1.0.0, built Mon May 21 11:39:36 2012
        [path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sosex.dll]
    dbghelp: image 6.11.0001.404, API 6.1.6, built Wed Feb 25 18:10:27 2009
        [path: C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll]
    ext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 18:10:26 2009
        [path: C:\Program Files\Debugging Tools for Windows (x64)\winext\ext.dll]
    exts: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 18:10:17 2009
        [path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\exts.dll]
    uext: image 6.11.0001.404, API 1.0.0, built Wed Feb 25 18:10:20 2009
        [path: C:\Program Files\Debugging Tools for Windows (x64)\winext\uext.dll]
    ntsdexts: image 6.1.7015.0, API 1.0.0, built Wed Feb 25 18:09:22 2009
        [path: C:\Program Files\Debugging Tools for Windows (x64)\WINXP\ntsdexts.dll]
0:004> sx
  ct - Create thread - ignore
  et - Exit thread - ignore
 cpr - Create process - ignore
 epr - Exit process - break
  ld - Load module - output
  ud - Unload module - ignore
 ser - System error - ignore
 ibp - Initial breakpoint - break
 iml - Initial module load - ignore
 out - Debuggee output - output

  av - Access violation - break - not handled
asrt - Assertion failure - break - not handled
 aph - Application hang - break - not handled
 bpe - Break instruction exception - break
bpec - Break instruction exception continue - handled
  eh - C++ EH exception - second-chance break - not handled
 clr - CLR exception - second-chance break - not handled
clrn - CLR notification exception - second-chance break - handled
 cce - Control-Break exception - break
  cc - Control-Break exception continue - handled
 cce - Control-C exception - break
  cc - Control-C exception continue - handled
  dm - Data misaligned - break - not handled
dbce - Debugger command exception - ignore - handled
  gp - Guard page violation - break - not handled
  ii - Illegal instruction - second-chance break - not handled
  ip - In-page I/O error - break - not handled
  dz - Integer divide-by-zero - break - not handled
 iov - Integer overflow - break - not handled
  ch - Invalid handle - break
  hc - Invalid handle continue - not handled
 lsq - Invalid lock sequence - break - not handled
 isc - Invalid system call - break - not handled
  3c - Port disconnected - second-chance break - not handled
 svh - Service hang - break - not handled
 sse - Single step exception - break
ssec - Single step exception continue - handled
 sbo - Stack buffer overflow - break - not handled
 sov - Stack overflow - break - not handled
  vs - Verifier stop - break - not handled
vcpp - Visual C++ exception - ignore - handled
 wkd - Wake debugger - break - not handled
 wob - WOW64 breakpoint - break - handled
 wos - WOW64 single step exception - break - handled

   * - Other exception - second-chance break - not handled

* 编辑 2012 年 8 月 17 日 *

感谢科林史密斯，我认为您得到了最接近的答案。我将我的程序编译为 32 位程序。切换到使用 32 位 Windbg 和 32 位 sosex。按照相同的步骤设置断点。现在，如果我这样做!mbl。断点列表的显示方式不同。

0 e : disable *!TESTWINDBG.PROGRAM.FUNC1 ILOffset=0: pass=1 oneshot=false thread=ANY
    TestWindbg!TestWindbg.Program.Func1() (PENDING JIT)

以前，我没有看到(PENDING JIT) 这一行。继续程序，Windbg 成功停在断点处。

我不知道为什么 64 位程序不起作用。我仔细检查了我的 64 位 sosex.dll 和我的 64 位程序符号路径。一切看起来都是正确的。也许，这是 sosex.dll 中的错误？

我使用的是 .NET 4.0，而我的 windbg 运行在 Windows 2008 R2 64 位。

【问题讨论】：

被调试者、调试器和 sosex.dll 的位数是否都匹配（例如，全部 32 位或全部 64 位）？对于 .NET 4.0，sosex.dll 至少应该是版本 4。
@Marc 我只是仔细检查了一遍。该程序被编译为 64 位。我也刚刚尝试编译到 AnyCPU。我的 WinDbg 是 AMD64。我下载的 sosex.dll 是 64 位的，它是我从 stevetechspot.com 获得的最新版本。顺便说一句，它说它支持.NET 4.5。我应该改用 .NET 4.5 吗？
设置断点后，!mbl 显示什么？ .chain 显示什么？ sx 对 clrn 异常显示什么？
@MarcSherman 很抱歉这么晚才回复您。我现在的项目太忙了。我刚刚更新了问题以包含您提出的信息。
运行程序后，!mbl 会显示什么？您所显示的是在 CLR 解决断点之前。运行程序后，断点是否仍然显示为未解决？ 0:000> !mbl 0 e : 禁用 *!CONSOLEAPPLICATION3.PROGRAM.FUNC1 ILOffset=0: pass=1 oneshot=false thread=ANY ConsoleApplication3!ConsoleApplication3.Program.Func1() 1 e 000007ff001601a9 1 e : 禁用 Program.cs,第 16 行：pass=1 oneshot=false thread=ANY ConsoleApplication3!ConsoleApplication3.Program.Func1() 1 e 000007ff001601a9

标签： c# .net debugging windbg sosex

【解决方案1】：

这里有一些建议，需要检查：

在设置断点之前等待模块加载

您可以尝试等到运行时/JITter/模块加载/初始化之后再设置断点。

用途：

sxe ld:mscorlib （加载运行时后中断）...或
sxe ld:clrjit （加载 JITter 后中断）... 或
sxe ld:MyModuleAssemblyName （加载特定模块后中断）

这将导致调试器在它们发生后中断......然后你可以做你的!mbm，等等。

检查您的程序私有符号（来自它的 .pdb）是否已正确加载

用途：

lml （显示已加载和加载失败的符号）
lme （仅显示加载符号失败）。

您也可以使用!sym noisy 获取符号加载活动的详细跟踪，例如帮助发现您何时损坏了 .pdb 等。

有关一些 PDB 相关错误代码的有用参考：

http://www.codeproject.com/script/Content/ViewAssociatedFile.aspx?rzp=%2FKB%2FDLL%2FSymbols_File_Locator%2FSources.zip&zep=SymbolsParser%2FDiaErrorTranslator.cpp&obid=37883&obtid=2&ovid=3

有关验证符号是否正确加载的一般性讨论，请参阅：

http://msdn.microsoft.com/en-us/library/windows/hardware/ff560260(v=vs.85).aspx

使用 32 位或 64 位 WinDBG

此外，您能否尝试在 32 位调试器而不是 64 位调试器下运行您的程序（当然还要使用 32 位 SOSEX 插件...并编译为 x86）...看看您是否得到相同的结果.

使用最新版本的 SOSEX

在 Steves Techspot 中，他说他破坏了 XP 中的兼容性（您似乎正在使用它）......也许这就是问题所在。（2012 年 6 月 8 日）

http://www.stevestechspot.com/FixForXPIncompatibility.aspx

【讨论】：

再次感谢您的帮助

【解决方案2】：

作为替代方案，只要您可以控制源代码，就可以尝试在 C# 代码中添加 DebugBreak 语句。编译成二进制文件后，Windbg 会崩溃

C# 中 DebugBreak 的良好参考 How can I use DebugBreak() in C#?

【讨论】：