Comments
4 comments
-
This will be due to the optimization that the runtime is doing, either at JIT time or ahead of time by the ngen compiler.
Our tool provides a pdb containing mappings between IL instructions and lines of source, and scoping information for local variables. Depending on optimizations that are happening, the debugger cannot always use this information to get all of the information you may like to see.
It's possible to make the optimizations less aggressive by having a debugger attached from the start of the session and by ngening assemblies to make them debuggable.
Do you have a particular example we can look at? -
It is the Microsoft.IdentitModel.dll.
In the meantime I managed to get it working by using the .ini file approach mentioned below:
[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0
http://msdn.microsoft.com/en-us/library/9dd8z24x.aspx
Thanks. -
Thanks - that's something I've done before to get less optimization.
-
I should also point to the following post
http://blogs.msdn.com/b/kirillosenkov/archive/2009/01/27/how-to-disable-optimizations-during-debugging.aspx which shows how setting the COMPLUS_ZapDisable environment variable can turn off some of the optimisation.
Add comment
Please sign in to leave a comment.
what could be the problem that I can step into decompiled code, but cannot actually see the values of the locals and variables?
E.g.
Cannot obtain value of local or argument as it is not available at this instruction pointer, possibly because it has been optimized away
I mean, not seeing the values makes the debugging into third party code pretty much useless
Thanks!