When debugging, some of you may have noticed that looking at a managed callstack looks a little different then a native one. One of the big differences is that you don’t see the parameters that are passed to the function. So what can we do about that?
Option 1 – Looking on the stack
So the first choice that we have is to try looking at the output from !dumpstackobjects and seeing if we got lucky and the parameter that we are interested in was pushed onto the stack. One thing that helps with this is if you are using the clr10\sos.dll that ships with the debugger package (which only works against .NET 1.0 and 1.1), you can run !clrstack -a and it will combine the output of these two commands and sort them so you can see what stack objects are associated with which frame on the callstack.
Option 2 – Make the image easier to debug
If that doesn’t work, then we need to try to look at making a change and having the problem happen again. .NET checks for two things before removing this information to save on space and performance. So we can change either of them in order to get the parameters to show up with !clrstack. Our choices are:
- Recompile the assembly as a debug build.
- Place an ini file in the same folder as the assembly to tell .NET to not optimize this assembly
The first option is pretty straight forward. For the second one, you can get more information here. But basically you just create a text file in the same directory where your assembly is located that has the same name as your assembly but .ini instead of .exe or .dll. Then in the file, you just put these lines:
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
Then to see this additional information in a debugger, you can run !clrstack -p to see parameters, -l to see locals, -a to see everything, etc.