0

Is it possible to debug System.Threading library?

I have a stack trace that looks somewhat like this:

enter image description here

I have followed all the steps I could see on how to debug .NET libraries.

  • Uncheck 'Enable Just My Code'
  • Check 'Enable .NET Framework source stepping'
  • Check 'Enable Source Sever Support'
  • Check 'Microsoft Symbol Servers' under Symbol file (.pdb) locations

And yet when I try to debug a System.threadin call, I get a file not found page that asks me to Browse and Find the .cs file.

Something like this. enter image description here

Is it possible to debug System.Threading library? Am I missing any steps?

Edit: I am not sure its a duplicate. For example, the top solution on the other thread asks me to go to referencesource.microsoft.com which does not even contain System.Threading. This is a question specifically for that library. If nothing else, a valid answer for this might be 'It is not possible to debug System.Threadin' or it is possible but use some other method to do so

Paagalpan
  • 1,261
  • 2
  • 16
  • 25
  • I am not sure its a duplicate. For example, the top solution on the other thread asks me to go to https://referencesource.microsoft.com/ which does not even contain System.Threading. This is a question specifically for that library. If nothing else, a valid answer for this might be 'It is not possible to debug System.Threadin' or it is possible but use some other method to do so. – Paagalpan Jul 23 '19 at 15:57
  • Follow the parts of the duplicate about using symbol server support, not reference source. `Microsoft Symbol Servers` are all that is needed. If you still have trouble, I will remove the duplicate. –  Jul 23 '19 at 16:51
  • Btw, it does contain `System.Threading`. https://referencesource.microsoft.com/#mscorlib/system/threading/thread.cs,3980e012bae82e96 –  Jul 23 '19 at 16:54
  • I reviewed your edits since we last spoke and have reopened the question. I apologize for the inconvenience. –  Jul 23 '19 at 19:12
  • Hi. I do not have access to the resources to get back to it this week. I will get back with an update on this on Monday and accept the provider answer if this works. Thanks! :) – Paagalpan Jul 25 '19 at 13:23

1 Answers1

2

Normal scenario:

We can try upgrading to newest .net 4.8 framework, it works for some situations like these two similar issues How to debug System.Web.dll? and Unable to step into PresentationFramework.

Cause we should ensure https://referencesource.microsoft.com/ contains the exact version we're debugging, most of the time it's better to choose the latest version.

But for this one:

Since upgrading to .net 4.8 seems to not resolve this issue(Maybe something I did wrong in the process?).I choose another direction(using local source) but it works in my side.

When we're debugging the .net framework source code, apart from the source server, it will also try to find the source in local directory. So we can download the source code .zip file in our machine and configure the Source File settings for solution.

1.Go https://referencesource.microsoft.com/ and click the Download button in the upper right corner

2.Download the entire source code of .NET Framework as a .zip file. Since my project targets .net framework 4.8, so I download the .net 4.8 package.

(We only need to download the appropriate package corresponding to our project, no need to download all of them)

3.Unzip the .zip file which contains source code and move it to an Location I decide to keep the source code, then in VS IDE=>Right-click solution => Properties => Common Properties => Debug Source Files => New Line(Ctrl-Insert) and enter the path of the Source folder(The Source folder in unzipped folder)=>Apply=>OK.

For me, I put the unzipped DotNet48RTM folder in Documents folder, so the path I enter in the Debug Source Files setting is C:\Users\xxx\Documents\DotNet48RTM\Source

Then I can step into the System.Threading library after I run a rebuild.

In addition: Make sure you've met all requirements mentioned here. You should disable require source files to exactly match the original version option and Empty the symbol cache in Debug=>Options=>Symbols.

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • Thanks for the response. I do not have access to the resources to get back to it this week. I will get back with an update on this on Monday and accept the answer if this works. Thanks again! :) – Paagalpan Jul 25 '19 at 13:23
  • @Paagalpan Hi friend, any update for this issue? Can you now debug into System.Threading now:) – LoLance Jul 30 '19 at 03:04
  • I just tried it. Thanks, it did work! It wasn't able to automatically find the file but once I pointed it to the right path, it was able to reach there. The problem now is that since the source doesnt match, the breakpoints are hitting random lines(comments in most cases) making it impossible to debug :/ – Paagalpan Jul 30 '19 at 16:14
  • 1
    If what you mean `wasn't able to automatically find the file` is that we have to point the debugger to right path where the xx.cs exists, and we have to point it many times since we will debug into many xx.cs files, I think we should set the solution's debug source path as the `source` folder, then it can automatically find the file in my machine. For the issue `the source doesnt match`, I haven't reproduced this issue in my machine. Make sure you're in debug mode, and check if it helps when you enable the `Suppress JIT optimization` option in `Debug menu=>Options`. – LoLance Jul 30 '19 at 16:28
  • 1
    @Paagalpan I will try to confirm with someone in debug product team if `the source doesnt match and has the possibility that cause wrong breakpoint lines` has a workaround. But it may take some time:) – LoLance Jul 30 '19 at 16:30
  • Accepting the answer since it resolved the main query I had. Thanks :) – Paagalpan Jul 31 '19 at 14:13
  • @Paagalpan After contact with one friend, `the source we download has to match the bits that the .NET framework was built with. If they don’t, the breakpoints will never line up.` , so this issue do exist. We have to install a specific version of .NET that the reference source actually matches to resolve this issue.(But I fail to find it) . – LoLance Aug 01 '19 at 07:47
  • And an alternative might be to disassemble System.Threading.dll and just look at the class that’s referenced in the callstack. We can use [ilspy](https://github.com/icsharpcode/ILSpy#ilspy-------) for this sort of thing. If all these can't really meet your requirement, you can report this issue to Product Team by Send feedback button in VS :) – LoLance Aug 01 '19 at 07:49