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.

Plyler

Do the bitness of the debugee, debugger, and sosex.dll all match (eg. all 32 bit or all 64 bit)? And sosex.dll should be at least version 4 for .NET 4.0. – Christhood

@Marc I just double checked. The program was compiled to 64-bit. I also just tried compiling to AnyCPU. My WinDbg is AMD64. The sosex.dll that I download is 64-bit and it's the latest one I got from stevetechspot.com. By the way, it said it supported .NET 4.5. Should I try the .NET 4.5 instead? – Plyler

After setting the breakpoints, what does !mbl show? What does .chain show? What does sx show for the clrn exception? – Christhood

@MarcSherman Sorry to get back you so late. I was too busy with my current project. I just updated the question to include the information you asked. – Plyler

Once you run the program what does !mbl show? What you've shown is before the CLR has resolved the breakpoints. After you run the program do the breakpoints still show as unresolved? 0:000> !mbl 0 e : disable *!CONSOLEAPPLICATION3.PROGRAM.FUNC1 ILOffset=0: pass=1 oneshot=false thread=ANY ConsoleApplication3!ConsoleApplication3.Program.Func1() 1 e 000007ff001601a9 1 e : disable Program.cs, line 16: pass=1 oneshot=false thread=ANY ConsoleApplication3!ConsoleApplication3.Program.Func1() 1 e 000007ff001601a9 – Cincinnati

Looks like you have to wait till the module/runtime is initialised/JITted before setting the breakpoint. Use: sxe ld:mscorlib ....(wait for runtime)... or sxe ld:clrjit ... (wait for JITter) ... or if want to wait for your module to be loaded too...then: sxe ld:MyModuleAssemblyName - this will raise an exception after they have occurred....you can then do your !mbm, etc. – Memory

@Cincinnati How did you tell the CLR didn't resolve the breakpoint? I ran the !mbl after I ran the program. See the Console.ReadLine() statement in the first line of the void Main(). I intentionally put that so that the command prompt is waiting for user input and I could pause the debugger and ran !mbm and !mbp. I ran the !mbl right after I ran the !mbp – Plyler

Can you check if your programs private symbols (from it's .pdb) have been loaded....use command "lml" (show loaded and failed to load symbols)....use "lme" (show only failed to load symbols). – Memory

@colinsmith I just tried it again. I saw my TestWindbg's symbol was not loaded. So, I issue command .reload /f TestWindbg.exe to make sure it's loaded. I double checked it's really loaded by lm command. Then, I set the breakpoints again using the same command. The break point still cannot be hit. :( – Plyler

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 AnyCPU)...and seeing if you get the same result or not. .... Also on the Steves Techspot he says he broke compatibility in XP (which you appear to be using)...maybe that's the problem. stevestechspot.com – Memory

@colinsmith Thanks for all your help. I finally got the breakpoint setup properly although I still don't understand why 64-bit program not working. Please post your comment as answer. I will accept it – Plyler

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

Memory

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#?

Equilateral