Comments
1 comment
-
Hi.
This is probably due to the optimisations that the CLR is performing. We provide a pdb which maps the IL instructions to the regenerated source code, but the CLR doesn't always record enough data about the mapping between the IL instructions and the generated code to allow full debugging. Additionally, there can be attributes in the assemblies that tell the debugger to use heuristic breakpoints, stopping only when the evaluation stack is empty rather than at points where the source line changes, which means that stepping isn't always as you might expect.
There is some discussion in this thread on rebuilding assemblies using ngen with less optimization to allow better debugging.
http://www.red-gate.com/messageboard/vi ... hp?t=10540
Add comment
Please sign in to leave a comment.
1) While debugging into System libraries (e.g. PresentationFramework.dll, .NET 4.0) I see odd behaviour were stepping through the code jumps over certain lines
2) Setting breakpoints often results in a popup dialog that reads:
"The following breakpoint cannot be set" ... "The Common Language Runtime was unable to set the breakpoint"
3) In the locals window, many local variables display the message "Cannot obtain value of local or argument ... as it is not available at this instruction pointer, possibly because it has been optimized away."
It seems like there is a problem with the PDB mapping of optimized code?