22

Here's what I've tried:

Made a new Console App (.NET Framework) in Visual Studio 2017.

Added the following code:

static void Main(string[] args)
{
    new Dictionary<int, int>().TryGetValue(3, out int x); //I want to step into TryGetValue() (this is just an example)
}

Configured the settings listed here: https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/

Confirmed symbols are loaded in the Modules window:

mscorlib.dll Symbols loaded. 4.6.1586.0 built by: NETFXREL2

Tried: "Step Into (F11)"

Tried: "Step into Specific" | "System.Collections.Generic.Dictionary.TryGetValue"

Both just step over the line.

I've tried configuring VS using the details here: http://www.symbolsource.org/Public/Home/VisualStudio

Same result, the debugger steps over the line.

I've looked at the answer here: https://stackoverflow.com/a/12432029/297451

But this version doesn't seem to be a security update, and a search for "site:support.microsoft.com/kb 4.6.1586.0" yields nothing.

What am I doing wrong?

Community
  • 1
  • 1
Jon
  • 5,275
  • 5
  • 39
  • 51
  • Works just fine, looks like the reference source symbol server was in fact updated to 4.6.2. The hash code I get for mscorlib.dll is BEC17127F5324AE795428E84A11901182. Use the troubleshooting procedure I documented [here](http://stackoverflow.com/a/27655501/17034). Empty the cache if necessary. – Hans Passant Mar 09 '17 at 12:36
  • 1
    @HansPassant Deleting the cached PDB solved the first issue, thanks (did I have a stripped PDB? How to tell?) I can now step into the function, but it's "Dictionary [from metadata]" and not source code. I have the same hash BEC17127F5324AE795428E84A11901182. – Jon Mar 09 '17 at 12:52
  • @HansPassant I still have a problem because it's not stepping through source code. "Dictionary [from metadata]" is just the interface, not the implementation. It's supposed to fetch the code on demand from source server. – Jon Mar 09 '17 at 13:03
  • Hmm, at this point you should of course show us the symbol trace you got. – Hans Passant Mar 09 '17 at 13:05
  • @HansPassant (removed a bunch of "Cannot find or open..."): SYMSRV: C:\symbols\mscorlib.pdb\BEC17127F5324AE795428E84A11901182\mscorlib.pdb - file not found SYMSRV: mscorlib.pdb from http://referencesource.microsoft.com/symbols: 11490816 bytes http://referencesource.microsoft.com/symbols: Symbols downloaded from symbol server. C:\symbols\mscorlib.pdb\BEC17127F5324AE795428E84A11901182\mscorlib.pdb: Symbols loaded. – Jon Mar 09 '17 at 13:09
  • 1
    Yes, that is the correct one. I can only assume your Tools > Options settings are not correct. You have not linked the correct docs, navigate to referencesource.microsoft.com and click the "How to configure ..." link. – Hans Passant Mar 09 '17 at 13:22
  • 1
    That did the trick - for reference it was "Require source files to exactly match the original version" which I'd incorrectly ticked. Note that I'd tried all combinations of these settings, but the stripped PDB prevented anything from working. Seems like a UX regression - I'm sure I've seen "Symbols loaded (stripped)" in the Modules window before, as well as a prompt when source file does not match the original version. Maybe both those features are C++ only. – Jon Mar 09 '17 at 13:32

2 Answers2

16

Here is the answer, thanks to Hans Passant. Note that this solution raises additional questions.

  1. Ensure https://referencesource.microsoft.com/ contains the exact version you're debugging.

  2. Configure Visual Studio as specified here: https://referencesource.microsoft.com/setup.html

    • Untick "Enable Just My Code"
    • Tick "Enable .NET Framework source stepping" (this should have been the only step needed)
    • Tick "Enable source server support"
    • Untick "Require source files to exactly match the original version"

  3. Confirm symbols are loaded in the Modules window, with source indexing included.

    • How can you tell if source indexing is included? The modules window doesn't specify if a PDB has stripped source information.

Microsoft could make this process a lot more robust by giving helpful error messages instead of silently failing.

Community
  • 1
  • 1
Jon
  • 5,275
  • 5
  • 39
  • 51
  • thanks for sharing your solution here, you could mark it as the answer, so it could help other community members who meet the same issue. Of course, if you have any good suggestions for the VS products, you could submit a feature request(http://visualstudio.uservoice.com/forums/121579-visual-studio) or reports feedback through the report tool under Help menu of VS IDE. – Jack Zhai Mar 13 '17 at 02:56
  • 2
    I've just installed .NET 4.7 Developer Pack and put together a solution in VS2017 on Windows 10. I've tried all of these instructions and cannot step into a List Sort. I cannot really see security updates surrounding this. Fair to say I am a bit stuck! – Andez Sep 15 '17 at 11:03
  • 1
    This works for me https://hmemcpy.com/2014/07/how-to-debug-anything-with-visual-studio-and-jetbrains-dotpeek-v1-2/ Basically use JetBrains dotPeek as a symbol server. – Andez Sep 15 '17 at 12:43
12

Use the Symbol Server feature in JetBrains dotPeek. Worked like a charm for me after struggling to get the standard functionality to work:

  1. Run dotPeek and go to Tools > Options... > Symbol Server.
  2. Ensure that "All assemblies" is selected and copy the local symbol server URL to the clipboard. Start the dotPeek symbol server by clicking it in the Tools menu.
  3. In Visual Studio, go to Tools > Options... > Debugging > Symbols and add the dotPeek server URL to the list. Move the dotPeek symbol server as high up the list as possible, and uncheck all other symbol servers in the list (in particular, the "Microsoft Symbol Servers" and "NuGet.org Symbol Server" must not be selected).
  4. Start debugging - when you attempt to step into Framework source code, you will see dotPeek doing some work decompiling the assembly for you, and then you will be into its source.

If this doesn't work, it's probably because Visual Studio has previously downloaded the "wrong" symbols for the assembly in question from Microsoft/NuGet, and is using them instead of asking dotPeek. To check this, start debugging and find the relevant assembly in the modules list (Debug > Windows > Modules) - delete the PDB file at the path displayed under "Symbol File" for that assembly, then restart debugging, and dotPeek should kick into action.

Ian Kemp
  • 28,293
  • 19
  • 112
  • 138
Phil Haselden
  • 2,876
  • 3
  • 30
  • 25
  • Can you please explain how to connect this to vs2017 ? – Ini Dec 10 '17 at 20:35
  • @Invader Sorry for the delay and this answer. I did it in VS2015. I briefly tried it briefly in VS2017, but didn't get it working. From memory, following their doco got it working. – Phil Haselden Feb 21 '18 at 01:14
  • 1
    This should be the accepted answer, dotPeek Just Works™ without having to bugger around with all of the pain detailed in the other answer. – Ian Kemp Apr 18 '19 at 09:22
  • THANK YOU! this works even in 2022. (4.6.2 framework) – diox8tony Sep 15 '22 at 21:41