1

I'm a relative newcomer to WinDbg. I'm trying to use it to debug the mscorlib source code in CoreCLR, but I seem to be having some problems getting SOS to highlight the source line for C# code (like WinDbg does for C/C++ code).

Here are the steps I've taken so far (I'm trying to debug the string.IndexOf(char, int, int) function here):

    0. Clone CoreCLR and build the repo, via build skiptests release

  1. Open WinDbg and run corerun MyNetCoreApp.exe

    1. Symbol files will be in coreclr\bin\Product\Windows_NT.x64.Release\PDB

  2. bp /1 coreclr!EEStartup ".loadby sos coreclr" to break at the EEStartup and load the SOS extension

  3. bp /1 @$ra; g to set a breakpoint at the end of the EEStartup method and run, by which everything should be initialized/mscorlib will be loaded and the SOS commands will work

  4. !name2ee System_Private_CoreLib_ni!System.String1 to get the EEClass address, !dumpclass to reveal the MethodTable address, and !dumpmt -md to list all of the methods in String along with their addresses.

  5. !bpmd -md 00007ffd7d039618 (the MethodDesc of the method) to set a breakpoint at the start

Unfortunately, when I hit the managed breakpoint, it looks like WinDbg doesn't immediately open the file for me, or highlight the breakpoint, like it does with C/C++. Even when I open the file in the editor via .open and navigate to it, nothing is highlighted. I think WinDbg should be picking up on the PDB symbols, since when I do a lm, System_Private_CoreLib_ni1 is listed as one of the modules with (pdb symbols) next to it.

Perhaps I gave a bit more info than necessary for the sake of a repro, but is it possible to highlight the breakpoints in the source file with managed code/SOS and WinDbg? Thanks.

1 mscorlib has recently been renamed to System.Private.CoreLib in .NET Core. ni is the pre-jitted native image assembly.

James Ko
  • 32,215
  • 30
  • 128
  • 239
  • 2
    Source debugging for managed code is rudimentary at best in WinDbg. There's an ancient version where this worked, but otherwise it is not really supported as far as I know. – Brian Rasmussen Jul 22 '16 at 05:29
  • @BrianRasmussen: I believe the same, and I wonder why this happens. Basically from the PDB information there is a source file and a line number. What language that is (C++, VB6, C#) should not matter. My gut feeling was that it's related to JITting: the address of the MSIL code where the PDB points to is never executed, thus WinDbg won't jump there. However, as the OP says, the `_ni` module has PDBs - and now my usual explanation does not fit any more. Can you explain why it does not work and would need additional implementation in WinDbg? – Thomas Weller Jul 22 '16 at 06:44
  • [Here's a post](http://www.wintellect.com/devcenter/jrobbins/windbg-starts-to-show-a-little-clr-love-finally) from John Robbin's blog regarding the version of `WinDbg` that was released with .NET support..... but was then removed, never to be seen again :( – Jason Evans Jul 22 '16 at 09:41
  • @Thomas I don't have the details, but my guess would be that it is about officially supporting it or not. If it is supported someone at Microsoft has to own it, it has to be documented, bugs have to be fixed and so on. There's no technical reason why WinDbg cannot support manage code properly. – Brian Rasmussen Jul 22 '16 at 15:38

0 Answers0