Feedback on debugging optimized (managed) code?
We're looking at ways to improve debugging managed-optimized code (eg, compiled with /o+), and would love any feedback. Some specific questions:
1) What's you're biggest pain-point for debugging optimized code?
2) How often do you have to do this?
3) Do you use Visual Studio or Windbg/SOS?
4) is your optimized code ngenned or jitted?
5) have you noticed a difference in debuggability of optimized code between managed and native?
6) what does your scenario look like here?
7) anything else?
I appreciate any feeback you have.
Comments
- Anonymous
March 01, 2006
The comment has been removed - Anonymous
March 01, 2006
Dan - thanks for your feedback. This is exactly the sort of thing I'm looking for.
"Why doesn't the Jit emit PDBs"... Sounds like a great blog idea. Stay tuned... - Anonymous
March 01, 2006
I would encounter optimized code if there were tools to support post-morted debugging of managed code. Alas, there's no post-mortem story for managed code. Since I'm in the desktop software business I rarely encounter a scenario where I must debug production code short of post-mortem. - Anonymous
March 02, 2006
Albert - I admit our post-mortem managed debugging story is weak. I wouldn't say there's "no story" - windbg / SOS can still provide key functionality (callstacks, object inspection, heap traversal), but I recognize that's definitely much harder to use than Visual Studio. - Anonymous
March 02, 2006
Yes, of course, you are right. If I capture a "maxidump" (entire virtual address space) from the dying process then I can use windbg/SOS. In fact, I have no problem with windbg/SOS in terms of user experience. The problem is that "maxidump" isn't really viable. I guess I'd like CLR to create a minidump with relevant stuff. Or better yet, provide a range of options how much I'd like to capture. - Anonymous
March 02, 2006
Albert - you're in luck. V2 CLR support managed minidumps for Windbg / Sos. A managed minidump is a little larger than a native minidump, but it's still much smaller than a "maxidump" (what we affectionately call "full dumps"). - Anonymous
March 02, 2006
I have made an experimental tool/library that can produce small minidumps also for CLR 1.1:
http://www.debuginfo.com/tools/clrdump.html
It seems to work fine for my apps, though I haven't yet done enough testing on various kinds of apps to be completely sure. - Anonymous
March 05, 2006
I happen to debug optimized code in the context of performance investigations and experimentations. Then it's also NGENed. The issue that bothers me most is that I can't Set Next Statement in VS. I'd also like tooltips for variables to work more often, but I do realize a lot of things get enregistered or optimized away. Other than that, compared to debugging optimized C++, the experience is quite decent. - Anonymous
March 13, 2006
In the debugging area, I would love to read more about debugging .NET Compact Framework 2.0. This is an area where VS2005 works quite well, but I recently encountered a few cases where it was impossible to find out what was going on when using a debugger. Namely, the application I'm working on crashes in certain cases when the device goes to sleep then wakes up (a native exception occurs somewhere in my native code after wakeup).
It's very hard to follow such issues as the debugger disconnects when the device goes to sleep. I don't have the time to reattach it on wakeup before it crashes.
One area where I'd like to see good information is how to correlate a native exception address with the actual location in a unmanaged DLL. I generate map files and I try to locate the offending function by computing the delta between the module base and the actual crash address, but results are usually off by an unknown amount of bytes.
I would very much appreciate seeing in-depth information about this. - Anonymous
March 14, 2006
Florent - you may be in luck! Check out David Kline's blog at: http://blogs.msdn.com/davidklinems
He has a debugger-specific category at:
http://blogs.msdn.com/davidklinems/archive/category/5792.aspx - Anonymous
March 14, 2006
Thanks Mike,
Actually I went through David's blog entries thoroughly before posting here. Thinking twice about it, I'll go check on the WinMob team blogs to see who is the debugger expert there. I understand (quite a bit actually) that on-device native debugging is a different beast. Especially when you need to deal with Idle states ;-)