debug
I'm done with most of these, but not totally. Tons of great information! Here are some more great articles that I found doing debugging research.
They mostly pertain to debugging and CLR internals type of stuff.
CLR
Inside Out - Investigating Memory IssuesDrill Into
.NET Framework Internals to See How the CLR Creates Runtime ObjectsSo,
what’s new in the CLR 2.0 GC?Windows
Debuggers: Part 1: A WinDbg TutorialDebug
Tutorial Part 1: Beginning Debugging Using CDB and NTSDDebug
Tutorial Part 2: The StackDebug
Tutorial Part 3: The HeapDebug
Tutorial Part 4: Writing WINDBG ExtensionsDebug
Tutorial Part 5: Handle LeaksDebug
Tutorial Part 6: Navigating The Kernel DebuggerDebug
Tutorial Part 7: Locks and Synchronization ObjectsTraversing
the gc heap...
"A debugger attached to a process can receive two types of notifications
for each thrown exception: first and second chance. The debugger gets
the first chance to handle the exception. If the debugger allows the
execution to continue and does not handle the exception, the
application will see the exception as usual. If the application does
not handle the exception, the debugger gets a second chance to see the
exception. In this case the application would normally crash if the
debugger was not present."http://msdn.microsoft.com/msdnmag/issues/05/07/Debugging/
These are the articles (in no particular order) that I felt best showed a thorough use of the WinDbg.exe tool from start to finish. They were absolutely priceless to me. Enjoy!
ASP.NET 2.0 Crash case study: Unhandled exceptions
A word for WinDbg (2)
Some new SOS functions
System.ArgumentException: Illegal characters in path
Tracking down a production bug
.NET Memory Leak: XmlSerializing your way to a Memory Leak
ASP.NET Case Study: High CPU in GC - Large objects and high allocation rates
ASP.NET Case Study: Tracing your way to OOM exceptions
Basic debugging of an application crash
Tracking Down Managed Memory Leaks
+ 1 Troubleshooting ASP.NET using WinDbg and the SOS extension
=)
5 things I wish I had known or done prior to attempting to work with SOS.dll and windbg.exe:
sos.dll needs to be in the path for windbg in order to load it
you can .load %full path to sos.dll% instead of .load sos mscorwks or other statements
SOS for .NET 2.0 does *NOT* have all the commands the .NET 1.x version does (a source)
review http://msdn2.microsoft.com/en-us/library/bb190764(vs.80).aspx and use !help %command% often
where these two articles were: one, two.
I experienced an extreme amount of pain first working with SOS.dll because of some of the problems above. I also found that there were LOTS of articles about using it, but some were more detailed...
Ah. Garbage Collection... how I love and hate thee. =P
I think one sad thing about programming in .net is that it seems many developers don't know or care anything about garbage collection and memory management. You used to *have* to know about it in order to write bug free code. I suppose it is a two edge sword in that developers can develop faster as the intention was to relieve developers of the need to know or care anything about memory management. I personally have always tried to follow best practices for implementation and have tried to stay somewhat cautious...