I've just finished writing up an e-mail for some new people in my team about starting Debugging and the use of the WinDBG tool. So I thought I would share this out here as well. I've got some great colleagues in my extended European team and also my US colleagues and so I'll point you towards some topics they've already written on this subject. (I'd like to thank them for taking the time to write these posts and hope they won't mind me ripping them off!) My colleague Carlo Cardella in Italy has written a series of posts about an introduction to debugging and I think they are a good starting point. New to Debugging Things to Do Before Debugging Why Should we care about symbols Capturing a Dump Taking Control over Windbg Ok, so now that you understand the Debugging Basics here’s some more information about using WinDBG from another colleague Johan Straarup who's in Sweden. Getting Started with WinDbg Part 1 Getting Started with WinDbg Part 2 Tom Christian is a US based engineer who writes a lot about Asp.Net Debugging. He's written a post about Debugging Asp.Net on a Production Environment which is very useful. Tess Ferrandez also works in Sweden and is very well known in the .Net Debugging world. She has created a series of .Net Debugging Demo Labs which you will find here. Then if you have time then also read her 21 most popular blog posts. Doug Stewart is based in the UK and sits next to me so I often talk about IIS\Asp.Net issues with him. His Debugging posts are listed here. Last but not least Nicolas Dietrich has a very good post on dissecting an Asp.Net 2.0 request .
PingBack from http://blog.a-foton.ru/2008/07/new-to-debugging/
Thanks for the information. :-)
Ef þú hefur litla sem enga reynslu af villuleit (e. debugging) þá er þetta færslan sem kemur þér á bragðið.
Debugging is such a core process of development and testing. Even if these are interns still in school, I would be very concerned that they are unfamiliar.
I understand your point. I'm a big advocate of understanding testing and development before debugging. I view the debugger as one of the final tools you need to use and it should come after you understand the issue and have exhausted all other troubleshooting means.
In the IIS\Asp.Net support world unfortunately it's not always our own applications we are troubleshooting and so we do need the Debugger sometimes to understand what is happening.