0

While stepping into .NET 4.7.1 framework source code during a Visual Studio debugging session, I was driven a bit crazy by an error in which Visual Studio reported during debugging that it could not locate certain .NET Framework class library source files, such as hashtable.cs (in my case)--which comes from System.Collections and is in mscorlib.dll. Most odd about this error is that Visual Studio would display a page like this:

enter image description here

This page appeared even if I cleared my local symbols cache and tried again.

Then I noticed in the message that Visual Studio was looking for source files in this path: "f:\dd\ndp\clr\src". It was looking in a non-existent F (F:) drive for source files. F: doesn't exist on my system, so of course it would never find files there.

I then inspected the Solution (not project--Solution) properties. Opening that and accessing the Debug Source Files pane revealed this:

enter image description here

I was able to remove those entries (they're in an editable multi-line textbox), but I still was unable to step into source from mscorlib.dll.

I'm looking for reliable way to step into source for all 4.7.1 framework files, especially mscorlib.dll. I am using the default "Microsoft Symbol Servers" and "http://referencesource.microsoft.com/symbols" as my symbol servers--I even tried clearing my symbol cache and selected only on of those symbol servers (rather than have both checked), to no avail.

Currently I am experimenting with using DotPeek as my local symbol server, but looking for a pure Microsoft solution, if possible.

Jazimov
  • 12,626
  • 9
  • 52
  • 59
  • 2
    The F: drive is where the source code was located when the assembly was built in Redmond. "dd" is short for DevDiv, the group inside Microsoft that is responsible for .NET. Diagnose reference source symbol server issues with hints in [this question](https://stackoverflow.com/a/27655501/17034). The server has been outdated again for several weeks, many recent questions about it. – Hans Passant Jul 08 '18 at 14:48
  • I see, thanks. I think what's actually happening is that my system isn't finding the PDB for mscorelib.dll for a 4.7.1 project... – Jazimov Jul 08 '18 at 14:55
  • 1
    It certainly did find the PDB, or it would not know anything about F:\dd. But it found the one from the MSDL server. That server does not provide source. The diagnostic method I documented shows this. – Hans Passant Jul 08 '18 at 14:58
  • Got it, I see now how this works. I re-read your post and things are making much more sense now. – Jazimov Jul 08 '18 at 16:19
  • 1
    @Jack: Sorry to imply that it was "resolved". All I meant is that Hans explained where the F-drive reference was coming from and that Microsoft isn't keeping its framework source code current or making it easy for developers to debug into ,NET framework code. I ended up using JetBrains DotPeek as wriiten about here: https://stackoverflow.com/questions/27655014/cannot-step-into-net-framework-source-code/28574127#comment89450383_28574127 – Jazimov Jul 12 '18 at 07:03
  • Although that solution is not ideal: DotPeek simplifies the task of stepping into decompiled .NET source code--not original Microsoft source code. So variable names and other code elements won't be as easy to follow as the actual source... I used mostly the decompiled source for debugging then perused the actual source modules for additional help. Those files are here: www.dotnetframework.org. – Jazimov Jul 12 '18 at 07:07
  • @Jazimov, Really thanks for your response, I also get the information from Hans Passant's suggestion from another case before:https://stackoverflow.com/questions/24096274/no-disk-in-the-drive-error-when-debugging-in-visual-studio, but I remember that it doesn't update all source code for the latest .NET Framework, I suggest you report this feedback through the VS report tool. – Jack Zhai Jul 13 '18 at 03:36

0 Answers0