-
Notifications
You must be signed in to change notification settings - Fork 2
Debugging framework internals without source code
Getting unexpected results produced by frameworks (f.e. parsing data and getting null
) is a common thing nowadays.
From a developer perspective it looks like:
I'm doing everything right.
From framework development team it looks like:
No, you do not do it right. Your data hits this sanity check in 67th line and returns Null as incorrect input.
If only a developer that ran into a problem could debug framework code execution step-by-step as if it was his own =\
A lack of PDB files that hold debugging information is a main showstopper ( Why PDB and Know PDB to have more information), and runtime optimizations.
PDBs are typically generated on compile time, however they can be re-created/re-generated from assembly itself.
Runtime optimization can be disabled by asking .NET to load assembly with debug data.
You can either use free dotPeek or not free Reflector. Lets take a closer look on a free tool first.
- Need to load exact assembly as referenced in project via
File -> Open:
Picking a different version than referenced in VS project will not allow re-generated PDB to be loaded during debugging.
- Select Generate PDB on loaded assembly. Use a cache folder (f.e.
c:\symbols
) rather than solutionbin
to reuse PDB across multiple solutions:
- Setup dotPeek to act as Symbol Server to generate PDBs on fly per debugger request ( killer feature ):
- Let Visual Studio know about PDB cache folder, and Symbol Server:
- Disable runtime optimizations by putting a
*.ini
file with same name as assembly ( in our caseSitecore.Kernel.ini
) with following content:
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
It will allow to disable a part of code translation optimizations thereby enable watching values of local variables.
- Attach to running process, and load assembly symbols via
Debug -> Windows -> Modules -> Right click on correct assembly -> load symbols
. You can ask VS to load symbols automatically each time:
If assembly is shown as optimized, create ini
file in the folder where assembly was loaded from, and restart application.
NOTES I have disabled shadowCopyBinAssemblies in a local solution to speedup application start a bit.
Your assembly would be loaded from a %windows%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\
folder, thus ini
file ought be added there.
Having PDBs loaded, and optimization disabled allows debugger to inspect framework internal code flow, thereby understanding the output produced:
The only difference is that Reflector has VS plugin that allows to generate PDB from VS interface:
And will automatically put PDBs into %app_data%\Local\Red Gate\.NET Reflector 9\Cache\
folder.
Thereby you need to put this folder as PDB source for VS.