Debugging requires symbol files to present within a bin directory along. You have Sitecore libraries, and they are not obfuscated, so you may decompile and inspect the original code using various tools like Reflector. But you need PDBs to be able to to debug those libraries, for example perform step Into, watch and modify locals, set breakpoints and similar actions.
How to generate PDB files from assembly? There is a great (and free!) tool from JetBrains called dotPeek. As soon as you download and install it, you will be able to generate PDB from any non-obfuscated assembly with it. To do that, first specify the location where PDB are kept:
Also allow to debug "not just my" code -this will allow debugger to step into methods that are stored in other referenced libraries, of course of you have their PDBs in symbols folder, as set on previous step.
Now with dotPeek we'll generate PDB under the same path previously set in Visual Studio where it will seek for symbols. Open library in dotPeek, right click its context menu and select Generate PDB, as on a screenshot below:
Remember path should be the same:
Congratulations! Now you can debug that DLL and get more understanding of how Sitecore works internally especially when sometimes you may need to override its functionally and implement your custom logic based on that.
Important! On the recent versions of Sitecore, especially Sitecore 9 or newer you may experience troubles with stepping in withing Sitecore.Kernel library. That happens due to that with time it has been more and more rewritten to rely on
Sitecore.Abstractions so you will need to generate PDBs and de-optimize that one as well.
You are now able to debug the code, step into the functions and investigate the logic as the code runs. But you may not still get the entire experience as if you were debugging your own code - due to optimization. To overcome optimization you need to start Visual Studio as Administrator with setting a specific environment variable:
cd /d "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE"
Next, for each DLL you are about to explicitly disable optimisation, you need to accompany with a *.ini file having the same name and the following instructions (example for Sitecore.Kernel.ini):
[.NET Framework Debugging Control]
Finally, as ReSharper is your permanent friend, you'll find the most convenient way to inspect the code by using its Assembly Explorer:
Hope this helps!