Breakpoint set by sosex.mbp or sosex.mbm not working

Question

I am using VS.NET 2010. I compiled a very simple .NET 4.0 application.

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);
        }
    }
}

I open the compiled executable by windbg 6.12.0002.633. Typed in the following commands to load sosex

.loadby sosex clr

Then, type in the following command to set the break points

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

and then run the program. None of the break points got hit.

Any idea?

* EDIT *

Here I paste more details about my environment per Marc's request

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

* EDIT 8/17/2012 *

Thanks to colinsmith, I think you got the closest answer. I compiled my program as a 32-bit program. Switch to use 32-bit Windbg and 32-bit sosex. Follow the same steps to set the break points. Now, if I do !mbl. The break point list is shown differently.

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

Previously, I didn't see the line (PENDING JIT). Continue the program and Windbg successfully stops at the breakpoint.

I have no idea why 64-bit program doesn't work. I double checked my 64-bit sosex.dll and my 64-bit program symbol paths. Everything looks correct. Perhaps, it's a bug in sosex.dll?

I am using .NET 4.0 and my windbg is running in Windows 2008 R2 64-bit.

Answer 1

Here are some suggestions, things to check:

Wait for Modules to be Loaded Before Setting Breakpoints

You could try waiting till after the runtime/JITter/module is loaded/initialised before setting the breakpoint.

Use:

• sxe ld:mscorlib       (break after runtime is loaded)... or
• sxe ld:clrjit           (break after JITter is loaded) ... or
• sxe ld:MyModuleAssemblyName       (break after your particular module is loaded)

This will cause a break into the debugger after they have occurred....you can then do your !mbm, etc.

Check if your programs private symbols (from it's .pdb) have been loaded properly

Use:

• lml    (show loaded and failed to load symbols)
• lme    (show only failed to load symbols).

You could alternatively use !sym noisy for a detailed trace of symbol loading activity e.g. helps discover when you have corrupted .pdbs, etc.

For a useful reference to some PDB related error codes:

• 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

For a general discussion on verifying that symbols are loaded properly see:

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

Use 32bit or 64bit WinDBG

In addition could you try running your program under the 32bit Debugger instead of the 64bit one (and use the 32bit SOSEX plugin of course...and compile as x86)...and seeing if you get the same result or not.

Use the latest version of SOSEX

In Steves Techspot he says he broke compatibility in XP (which you appear to be using)...maybe that's the problem. (dated June 8 2012)

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

Answer 2

As an alternative, so long as you have control of the source code, you could try adding a DebugBreak statement in your C# code. Windbg will break after this is compiled into the binary

A good reference with the DebugBreak in C# How can I use DebugBreak() in C#?