none
Setting a breakpoint on Main using WinDbg/SOS

    Question

  • Hi,

    I'm tr
    ying to debug a third-party app, and I need to place a breakpoint on Main(). I've found many techniques on the web to do so; apparently SOS is smart enough to defer the breakpoint until the module has been loaded.The thing is, it doesn't work for me. It goes past Main and executes everything. I've built a sample app to try and isolate the problem:

    Code Snippet (teste.exe)
    namespace teste
    {
    class Program
    {
    static void Main(string[] args)
    {
    Console.Beep();
    }
    }
    }

    I open it in WinDbg:

    CommandLine: "C:\Documents and Settings\Pedro\Desktop\teste\bin\Release\teste.exe"
    Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
    Executable search path is:
    ModLoad: 00400000 00408000   teste.exe
    ModLoad: 7c900000 7c9b4000   ntdll.dll
    ModLoad: 79000000 79046000   C:\WINDOWS\system32\mscoree.dll
    ModLoad: 7c800000 7c8ff000   C:\WINDOWS\system32\KERNEL32.dll
    (df0.388): Break instruction exception - code 80000003 (first chance)
    eax=00251eb4 ebx=7ffd5000 ecx=00000000 edx=00000001 esi=00251f48 edi=00251eb4
    eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
    ntdll!DbgBreakPoint:
    7c901230 cc              int     3
    0:000> bu mscorwks!EEStartup

    When it breaks on EEStartup:

    0:000> .loadby sos mscorwks
    0:000> !bpmd teste.exe teste.Program.Main
    Adding pending breakpoints...
    0:000> g


    ...And it just flies past my breakpoint.

    I've tried setting a breakpoint on kernel32!Beep and checking !clrstack to see if the method name is correct:

    0:000> !clrstack
    OS Thread Id: 0x924 (0)
    ESP       EIP    
    0012f454 7c837a77 [NDirectMethodFrameStandalone: 0012f454] Microsoft.Win32.Win32Native.Beep(Int32, Int32)
    0012f464 793e7b2e System.Console.Beep(Int32, Int32)
    0012f484 00c500a6 teste.Program.Main(System.String[])
    0012f69c 79e7c74b [GCFrame: 0012f69c]


    I suspect something is wrong with my debugger, because entering sxe clr (or sxe clrn, I've seen both of them on the internet) before the CLR is loaded doesn't get me anything (it still runs nonstop, when it should break when the CLR loads).

    Here is the .chain output:

    0:000> .chain
    (...)
    Extension DLL chain:
        C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.1433, API 1.0.0, built Wed Oct 24 01:41:30 2007
            [path: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll]
        dbghelp: image 6.8.0004.0, API 7.0.6, built Thu Sep 27 18:27:05 2007
            [path: C:\Arquivos de programas\Debugging Tools for Windows\dbghelp.dll]
        ext: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:59 2007
            [path: C:\Arquivos de programas\Debugging Tools for Windows\winext\ext.dll]
        exts: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:28 2007
            [path: C:\Arquivos de programas\Debugging Tools for Windows\WINXP\exts.dll]
        uext: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:45 2007
            [path: C:\Arquivos de programas\Debugging Tools for Windows\winext\uext.dll]
        ntsdexts: image 7.0.6440.1, API 1.0.0, built Thu Sep 27 18:45:23 2007
            [path: C:\Arquivos de programas\Debugging Tools for Windows\WINXP\ntsdexts.dll]

    I've built the program on VS08 targeting .NET 3.5, but using clr10\sos.dll yields me "Doesn't work with 2.x".

    Any help on this would be greatly, greatly appreciated.

    -Pedro

    Friday, April 18, 2008 6:52 PM

Answers

  • There is no problem with your setup.  Just omit the namespace when you're setting the breakpoint, i.e.:

     

    !bpmd teste.exe Program.Main

    Saturday, April 19, 2008 10:40 AM
  •  Sasha Goldshtein wrote:
    I know this doesn't sound helpful, but did you try it on a completely clean machine?  This sounds environmental (I could be wrong of course...)

     



    Yes, I did. I tried it on 4 different machines, one of them a clean VM, and on all of them I had the same result.

    I was able, however, to set the breakpoint, by stopping WinDbg after mscorjit.dll is loaded:

    0:000> sxe ld mscorjit.dll; g
    (...)
    0:000> !bpmd teste.exe teste.Program.Main; g
    Found 1 methods...
    MethodDesc = 00923078
    Adding pending breakpoints...
    (f3c.d48): CLR notification exception - code e0444143 (first chance)
    JITTED teste!teste.Program.Main(System.String[])
    Setting breakpoint: bp 00D200D0 [
    teste.Program.Main(System.String[])]
    Breakpoint 0 hit
    (...)

    This is different from everything I have ever read on the internet about setting managed bps on Main, including a very detailed post by Thottam R. Sriram
    . Could this be a bug?
    Wednesday, April 23, 2008 10:08 PM

All replies

  • There is no problem with your setup.  Just omit the namespace when you're setting the breakpoint, i.e.:

     

    !bpmd teste.exe Program.Main

    Saturday, April 19, 2008 10:40 AM
  •  Sasha Goldshtein wrote:

    There is no problem with your setup.  Just omit the namespace when you're setting the breakpoint, i.e.:

     

    !bpmd teste.exe Program.Main



    That didn't work

    I think it has to do with the fact that the CLR isn't throwing any exceptions when it loads:

    "!bpmd asks the Windows Debugger to receive CLR Notifications, and waits to receive news of module loads and JITs, at which time it will try to resolve the function to a breakpoint" (from !help bpmd)

    I suppose this is the same as "sxe clrn" which, as I've said before, doesn't work for me - and I've tried it on 3 machines, 2 running XP and one running Vista.

    So, if the debugger isn't notified of JITs or loads, it can't resolve the breakpoint. Is there any reason why the CLR wouldn't send out notifications?

    Tuesday, April 22, 2008 2:08 PM
  • I know this doesn't sound helpful, but did you try it on a completely clean machine?  This sounds environmental (I could be wrong of course...)

     

    Wednesday, April 23, 2008 7:26 AM
  •  Sasha Goldshtein wrote:
    I know this doesn't sound helpful, but did you try it on a completely clean machine?  This sounds environmental (I could be wrong of course...)

     



    Yes, I did. I tried it on 4 different machines, one of them a clean VM, and on all of them I had the same result.

    I was able, however, to set the breakpoint, by stopping WinDbg after mscorjit.dll is loaded:

    0:000> sxe ld mscorjit.dll; g
    (...)
    0:000> !bpmd teste.exe teste.Program.Main; g
    Found 1 methods...
    MethodDesc = 00923078
    Adding pending breakpoints...
    (f3c.d48): CLR notification exception - code e0444143 (first chance)
    JITTED teste!teste.Program.Main(System.String[])
    Setting breakpoint: bp 00D200D0 [
    teste.Program.Main(System.String[])]
    Breakpoint 0 hit
    (...)

    This is different from everything I have ever read on the internet about setting managed bps on Main, including a very detailed post by Thottam R. Sriram
    . Could this be a bug?
    Wednesday, April 23, 2008 10:08 PM
  • I find it hard to believe that it's a bug, because when I answered your initial question I did exactly what you did and it worked on my machine (only without the namespace).

    Perhaps there's something wrong with the binary.  I've seen Visual Studio + C# compiler installations producing invalid code once in the past for an unknown reason.  Perhaps you could upload the binary somewhere?

    Thursday, April 24, 2008 9:09 AM
  • Sasha,

    I hadn't considered this. I've uploaded the binary:

    http://rapidshare.com/files/110038390/teste.exe.html

    I've compiled it with the 2008 compiler, using the /debug switch.

    I find it strange that you were able to make it work without the namespace. If I make windbg stop after mscorjit.dll was loaded, I'm only able to set the breakpoint if I include it:

    0:000> !bpmd teste.exe teste.Program.Main
    Found 1 methods...
    MethodDesc = 00863020
    Adding pending breakpoints.

    0:000> !bpmd teste.exe Program.Main
    Found 0 methods...

    I really appreciate your help on this! Thanks :-)
    Thursday, April 24, 2008 12:37 PM