How can I make you learn and benefit from my Blog? and how can I learn from you?

Summer is almost over and a new season of heavy work is beginning. I wanted to take this opportunity to start on a new page and make sure that I’m spending my cycles doing the right things.

I’ve been blogging for almost 3 years now and throughout the blogs life I’ve been blogging pretty much the same way, trying to show examples of where me and fellow developers have gotten into situations that have caused crashes, memory leaks, exceptions, hangs etc., so that we can all learn from the situations and avoid them.

Throughout the 3 years I have gotten a lot of comments saying that posts have helped developers, but I have also gotten more private comments saying that what I am talking about lies so far out of their realms that they don’t understand half of what I am saying. Some of these comments have come from people that I know and respect and that I know are extremely proficient developers, which makes me think that maybe I am not explaining things in a very understandable or approachable way.

I have also noticed that people tend to send me private emails rather than comment on the blog, maybe because people feel a bit too intimidated by post-mortem debugging to comment directly on the blog since the topic is a bit low-level. Maybe I am all wrong and that is not at all why people email me rather than comment :)

Either way, since this has been bugging me for a while, I wanted to let you know how I look at my blog and what I want it to be, and I also wanted to solicit your ideas on how to make it more that way.

My philosophy with the blog

I work as an ASP.NET Support Escalation Engineer which means that my job is to help developers solve these types of issues. When I can help them resolve their issues that makes both me and them happy. In reality though they would probably be a lot happier if they could resolve their own issues and didn’t have to call, or even more happy if they didn’t have these issues in the first place.

With all that, my goal has always been to try to avoid that people need to call support, so effectively my goal is to make my job obsolete :). I realize that people will always run into pitfalls so I set up this blog to teach people debugging and make people more aware about the internals of asp.net and the CLR, and to learn from each other.

I want people to be less intimidated by debugging and see that it is in fact something that we can all do, something that is useful to all developers and something that is not as difficult or far out there as it may seem at first look.

I want people to ask lots of questions, or comment on things that they want to know more about, don’t understand or don’t agree with. The more such comments and questions there are, the more I and others can learn from them. In a perfect world, this would be a nice debugging community where we all learn from each other.

My ask from you

I would like to learn from you what ideas you have around how I can accomplish this goal better.

• How many of you just glance at the posts and think “hmm, probably interesting for someone who is deep down into debugging but I’ll never use this”?
• How many of you really read them and learn something from them?
• Are the posts too long, too short, too deep, not deep enough, too boring, too many stupid jokes?
• What makes you shy away from a post and what makes you want to learn more?
• How can I make things more applicable to the world you live in?
• What do you want to see more or less of?
• How can I help you so that you can apply more of what I am talking about to your day to day job?
• Do you want me to mix up the debugging posts more with some lighter posts about other topics? If so, what would you be interested in?

Feel free to be as candid as you can :)

Have fun, Tess

EDIT 2021: I haven’t replicated the comments as I have been restoring my blog posts - but I have been re-reading them, and I have always been so happy with my blog community. The comments were always nice and respectful, and there was a real sense of poeple in the comment section trying to help each other. So for this particular post, (since it was a request for interaction) I decided to replicate the comments as well - to save them as a nice memento.

---

Comments from readers

nitesh1981 17 Aug 2009 7:33 AM

debugging and see that it is in fact something that we can all do

jsmano 17 Aug 2009 9:32 AM

Just keep on debugging! From the very beginning this blog has seemed to concern the debugging internals and this is its value. Please do not post about any lighter topics and dig deeper and deeper…

Rob Ringham 17 Aug 2009 10:19 AM

I never really spent much time learning to debug outside of the basics - until I started running into some very difficult bugs at work. Before, I may have thought to myself that your posts would be of more interest to someone who is deep into debugging, but once you’re there and you are out of ideas on how to proceed, your posts are lifesavers.

A few of those types of bugs, and you learn that you really need to educate yourself on debugging, and that’s why your blog is so great. I’ve learned a ton from it, thank you. And I happen to like the jokes :-)

Stephen Saar 17 Aug 2009 12:32 PM

I like the depth of your blog. There aren’t many blogs around that go in to in depth debugging techniques, so I find it pretty useful. I do mostly C++ debugging, but a number of techniques you list on this site are very useful even when not dealing with .NET code. I’m hope you don’t change anything major on the site. I like it as is. I’ve been browsing your, Raymond Chen’s, Marks Russinovich’s,and the NTDebugging blogs for a little while and they’ve been a big help in my understanding of windows and windbg.

AlexP77 17 Aug 2009 1:26 PM

Hi Tess,

I’ve been reading your posts for too long and they are always brilliant. I’ve learnt a lot from them. Please keep posts as is :)

SeanM 17 Aug 2009 2:24 PM

I enjoy that at times your posts push me to the edge of confusion. If they didn’t then I wouldn’t be learning too much. :)

I’ve found your posts very valuable. There have been a few (OK, a lot) that were situations that I’m sure I’ll probably never be in. But reading them and seeing the logic behind how you figured them out was useful and definitely is something that I can apply to my own scenarios. That’s the key part about these posts that I like. There are books about how to debug in Visual Studio and limited info about how to use Windbg. But these usually just explain how the tool works. The posts on this blog show how to go beyond just using the tool in to how to actually use it to problem solve.

I wouldn’t change a thing.

Stephen Cleary 17 Aug 2009 2:26 PM

I always make it a point to at least read over your blog entries. To date I have not used ASP.NET, but I have a great interest in debugging, so I always find your blog very informative.

I do view your blog as more of a “reference” rather than “training”. It’s too deep for me to retain everything, but that’s good because when I need a reference I want it to be deep.

So I briefly read every entry, building an index of sorts so that if I do come up against a similar problem, I can remember “Tess did it!”, and then turn to your blog as a reference.

In short: I like your blog just the way it is. :)

Brian 17 Aug 2009 2:28 PM

Tess, I find this to be a phenomenal resource. I have found a post or two of yours that helped me solve a specific problem - that’s how I found you. Now I read every post. Quite often it is over my head but I’ve found I learn so much more by reading a bit over my head.

Keep it up and thanks again!

Thomas Danecker 17 Aug 2009 2:36 PM

There are two motivations for me reading blogs: Learning something new that I can use in the future and finding solutions to concrete problems I’m encountering.

Please keep showing us a lot of details, so we have somewhere to look for solutions to tricky problems but also keep teaching us how to use the tools. We’re always interested in learning from you!

Itay Maman 17 Aug 2009 2:40 PM

I think programming is all about the low level. Most difficulties stem from low level issues.

Keep it up.

Jason Evans 17 Aug 2009 2:50 PM

I’ve always found your technical post very informative and have been able to follow them without too much trouble. Though I sometimes see references to things like ‘the loader’ or the ‘the loader heap’ (I forget exactly) which leads me to think it would be nice to have posts, or links, about the CLR internals.

I think it would be beneficial for those who want to go a bit deeper behind the scenes to get some info on those parts of the CLR which aren’t openly discussed.

codepoke 17 Aug 2009 2:54 PM

Hello Tess,

I’m new to WinDBG-style debugging and entirely self-taught at everything. I was a coder 5 years ago, but now I’m an IIS Admin with no access to the source at all. I have no clue how you’re supposed to learn this stuff, but I’ve been learning it by brute-forcing my way through various problems.

70% of what I’ve picked up about WinDBG has been at your site, but there are huge holes of ignorance between every couple things I grasp. It’s often little things, like why commands from your blogs don’t work, and it seems to be something about SOS as often as not. It appears there are 2-3 versions of SOS I can load, and some of the commands are simply not there depending on which flavor I call.

And every problem’s bizarre. I have a couple right now.

• An IIS App Pool recycles normally most of the time, but every now and again it comes up in zombie mode. Mscorsvr is not loaded by the time the pool quits booting, so SOS won’t load/work on the dump. And there I am, clueless. I can look at threads, and try to see what’s loaded, but I have no idea what to look for or how to look at much of anything without SOS. I still have no idea why that load hangs.

• Using Oracle Client 10g an IIS process takes 150 seconds to return data, but using 9i it only takes 30 seconds. I have dumps of the system running well and poorly, but can’t tell how to see what’s spinning with the 10g client. Lmm tells me what’s installed, but it’s a hard sell that downgrading is the performance answer.

• A DMZ server makes a DNS call, and experiences a first time exception and crashes. I can see in the DebugDiag-triggered stack trace where the call is that’s killing me, but it’s not a managed thread and I have no idea how to find my way into any of the parameters to see what we’re doing that’s killing us.

It’s frustrating, but I live for this stuff. It’s as exciting as anything I’ve ever done as a developer, because I’ve had some rip-roaring successes, too. You taught me how to identify the 100 Oracle connection objects attached to zombie threads and I was able to teach the developer to dispose of them more effectively. You taught me to parse through to all the leftover HttpWebRequest objects and find that they all have the same uri and failure mode. It’s been an exciting 2 months.

When I first came to your site, 6 months ago, I was overwhelmed and backed away. It wasn’t until I was 100% certain I had a problem that only WinDBG could unravel that I finally took the plunge. Since then, I’ve found a use for this little tool almost daily, and probably have 10 solved cases under my belt. It’s not much, and there’s a lot more to go, but there you have it.

I’ve taken to googling problem words plus the word, “Tess.” When some other admin has found a solution, they will frequently reference you by name, and that can be the easiest way to find the page on your site that holds the best clues.

Today I’m here because we have a web farm experiencing viewstate corruption even though the machine keys are synched. I tried to !DumpConfig, but cannot seem to find the right combination of SOS version to make that work. It’s a curious problem, because I have client traces of the system carrying state across the servers, but vastly more examples of state being rejected on the second server. As is usually the case, the first problem is figuring out where to start, and Google is unhelpful on this because everybody and their brother has solved the problem by synching machine keys.

I’m about as ignorant as a man can be and still garner useful information from your brilliant site. Hopefully, though, my rambling will give you some insight what’s happening in one losers brain.

RM 17 Aug 2009 3:03 PM

Hi Tess,

I feel that for those who, like me, never touched most of the tools you use to diagnose problems (windbg and so on), having a few screen casts or videos of some kind of some of your examples would be a great introduction to your material.

The internet now has a lot more than text to present your stuff, might as well use it to get it easier to get into. :)

Also, I wanted to thank you for having this blog and sharing some impressive knowledge on it. I have to say that when I’m debugging a weird memory behavior on a production server in the middle of the night and google gets me to some helpful article on your blog, I feel a little bit less alone with my problem. Keep up the great work ! :D

Renaud

codepoke 17 Aug 2009 3:12 PM

Oh, and I did find your viewstate post from a little bit back on .NET 3.5 sp1, and I suspect you hit the nail on the head. Thank you. Yours was result #6 on Google, and I skipped 4 of the first 5 without a glance. “If broken it is,…” had the answer again.

You never cease to amaze. Thank you.

Rubio 17 Aug 2009 3:30 PM

I’m one of those who browses through your blog but rarely stops to really investigate the issue at hand. This is partly because I don’t do ASP.NET and partly because the issue often is far beyond my debugging skills. But occasionally I find a pearl from your blog. The reason I’ve never gotten deeper into debugging is simply because I don’t have time. I’d like to, but whenever I’ve tried to learn more about debugging and post-mortem debugging in particular (like recently when my home Vista started to BSOD every time it shuts down), I find that there’s quite a stride from basic to advanced level. My point is that you can’t please everyone, so maybe it would be better if you target your blog to devs who already possess the advanced level skills. If, however, you feel that the blog would serve a larger audience by not being so advanced, then you would have to help people take their debugging skills to the advanced level. That, I think, requires more than a few blog posts. Ingo Rammer made a web cast that’s a good start, I think. (I’ve even been thinking of asking him if I could publish a transcript.) If this is something you’d be willing to do, then I think I could give more feedback than you’d ever want to receive. ;-)

Richard 17 Aug 2009 4:08 PM

If I describe my situation maybe it will make things clearer. I’m a C# developer using ASP.NET/ASP.NET MVC/SQL Server 2005/Oracle. In the last 5 years of being a programmer, I’ve had to use WinDBG exactly once. It was a problem somewhere between Delphi, COM-Interop and .NET. I found the problem with WinDBG but I had no idea why it was happening or how to fix it. I just didn’t have enough knowledge of the underlying platforms/libraries. Eventually I sent a dump to Microsoft and they were able to diagnose and solve the problem. To solve my problem I would have had to learn both how Delphi works and COM.

So my question is, why should I invest time and effort in learning WinDBG when I am going to use it so seldom? I can’t know everything, I have to choose what to spend my time on. I’m much better off hitting a problem and page faulting in information to solve the problem. Some days that’s all I do. I don’t have the luxury of understanding ASP.NET from the top to bottom and being able to recite the unabbreviated page-lifecycle. If things are behaving weirdly and a method doesn’t return out of a call to COM, that’s when I’ll pull out WinDBG. Until then, almost 99% of the code we have is written in C# and the development experience is so good I don’t need to drop to a lower level. (Incidentally, I would probably put SysInternals’ tools in the same category as WinDBG).

Essentially the way I use your blog is to try and be aware of options I have if I hit a certain class of problem. I read most of the articles and I try and understand the methodology behind the troubleshooting process. I think the real value in what you are doing lies in the teach-a-man-to-fish mentality. If anything I would like to see more posts on the “art of solving problems” if you will because it doesn’t seem like an exact science.

The other thing about your blog is that it is an awesome reference site that is designed for “snowflake queries” i.e. search terms that are unique to a specific problem that will help people solve the specific problems they are experiencing. What would be useful is putting out information about the top 10 problems you have every month that are potentially searchable. I think this would ultimately lead to less support calls because people could potentially find the answers online. (I’m guessing you’re already doing this but I just thought it was worth reiterating)

Having said all of that I’ve been subscribed to your blog for a year and enjoy most of the in-depth articles and I know exactly where to go if I hit a snag with WinDBG. You do a great job and I find it awesome that you’re trying to improve yourself even more. Keep it up :).

Richard 17 Aug 2009 6:12 PM

Hi Tess,

I’m another lurker. I subscribe and I skim every post. I’m a C# dev and, to date, I’ve not needed WinDbg and I’ve never used it. However - I’m always interested in how stuff works, because I don’t believe you can form a credible hypothesis about what may be causing the observed facts, unless you have a reasonable clue about how it works. So - I’m mighty glad that this resource is there and I fully expect to use it one day. Just not yet!

I don’t think you should be concerned that some readers find what you work on is far outside their realm. Intel makes the chip in the computer I work on. Some intel guy blogging on how the electrons move round the chip would be interesting - but it’s way outside my realm.

Do NOT feel you have to write stuff “for everyone”. We are not REQUIRED to read it, we CHOOSE to read it. Another Microsoftie wrote recently about the “Law of Two Feet” “If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute. (I’ve always been a fan of this one!)” From http://geekswithblogs.net/iupdateable/archive/2009/08/05/altnetuk-conference-was-a-great-way-to-spend-a-weekend.aspx.

Jonathan Perret 17 Aug 2009 6:23 PM

Tess, I just wanted to say thank you for the unique resource that your blog is. I could begin to tell of what you taught me but the comments above do it better justice than I could hope to.

Cheers,

–jonathan

Jeff Handley 17 Aug 2009 7:05 PM

When I first started reading your blog, it seemed as though you took many of your “tools of the trade” for granted, assuming we knew how to use them and how to get the types of output you were illustrating. For the occasional reader, or someone who finds you blog while searching for solutions to specific problems, then can cause them to be overwhelmed and not understand how you did what you did.

However, the depth you go into is perfect for the task at hand, and I wouldn’t change that.

As far as whether or not you blog about other types of issues or topics–I wouldn’t let anyone tell you what to write on your blog–it is in fact your blog, and not theirs. :-)

Thanks,

Jeff Handley

Luis Guerrero (DPE) 17 Aug 2009 7:08 PM

Hi Tess

I’m Reading your blog since 2 years, I have to say that its best’s blog I’ve seen before. I love debugging, I love WinDBG and I absolutely love goes deeper and deeper in every issue. As a part of my job, I’m doing some Debugging and Optimization issue with clients, that mean that like you I’m a Support Escalation Engineer, but my job’s name isn’t so cool.

Also I’m doing some training, talks about advanced Debugging talking about WinDBG, sos, Internals, CLR and so on, and in every talk I’ve made all people are getting more confused. This passion is not for everyone that’s what you need to know, so please stay as you are. You’re not going to change because a few (or a lot of) say to you that your job is so complicated and doesn’t unrestraint anything. I know exactly who this feeling is, when you finish some talk and, with lucky, one or two people know or learned anything.

Luis Guerrero.

DontAskMeIJustWorkHere 17 Aug 2009 8:49 PM

Another lurker here…

Your blog is pretty much awesome, doubly -no, triply- so because of the lack of similar resources which offer practical help when the memory gets leaky and the debugging gets serious, and not just for the ASP.NET guys.

Something which would be great to see more… more posts? :P

Thanks for all your great posts, keep up the good stuff!

David Douglass 17 Aug 2009 8:54 PM

Let me start by saying I think you have one of the best blogs. Please keep up the great work!

How many of you just glance at the posts and think “hmm, probably interesting for someone who is deep down into debugging but I’ll never use this”? How many of you really read them and learn something from them? I’ll admit I don’t read each post in detail, but that’s because the problem isn’t (at the moment) plaguing me. Your collection of posts is an invaluable reference for when you really need it.

Are the posts too long, too short, too deep, not deep enough, too boring, too many stupid jokes? They should be as long as they need be but not any longer. I wouldn’t be concerned about too deep.

What makes you shy away from a post and what makes you want to learn more? If I’m troubleshooting a problem and the post looks relevant, I’ll spend whatever time I need with it.

How can I make things more applicable to the world you live in? My world involves the interactions (or lack of) between custom code (managed and unmanaged), purchased components (managed and unmanaged), Windows, servers such as SQL, and the network. A lot can go wrong (and does).

What do you want to see more or less of? I always want to know how to understand what is going on. Knowing how to fix something is good, but knowing how to figure out what is actually happening is better.

How can I help you so that you can apply more of what I am talking about to your day to day job? Preventive steps would help. What can be done to software prior to handing off to QA to prevent the bugs from leaving development.

Do you want me to mix up the debugging posts more with some lighter posts about other topics? If so, what would you be interested in? I leave that up to your imagination.

Michael G 17 Aug 2009 9:43 PM

Put me down as another C++ developer reading your blog to pick up the techniques that cross over into my world.

I say keep on keepin’ on–deep articles may not be light daily reading for most people, but you’re one of the few people writing at this level.

Do you want me to mix up the debugging posts more with some lighter posts about other topics?

God I hope this doesn’t mean cat blogging. :)

another developer 17 Aug 2009 11:26 PM

I enjoy the detail in your blog - its mostly a “file away for future reference” type of thing, I have only once needed to go back and actually use something.

Its more like, if I can follow what you’re saying, then I know that I have some feel of the system, and that gives me a good feeling.

Please keep the detail going.

Lack of comments probably indicates that your readers are not having that particular problem at that point in time; however, they will likely be able to avoid them in the future.

vikram 18 Aug 2009 1:06 AM

I think you are doing a great job with the blog, So I would just suggest you to keep doing what you already have been doing…. :)

Brian 18 Aug 2009 1:30 AM

I find your blog very interesting. I’m a .NET developer, but I do a lot of debugging using WinDbg, so obviously your blog is very relevant to me.

I’ve been doing debugging talks and classes for a while and I get the “why is this arcane stuff even relevant to me?!” question on a regular basis, so I can certainly relate to what you’re saying here.

I have come to the conclusion that it is okay that most people are not WinDbg experts. As long as they know it is available and know how to pick up more information / help when they need it. To that end your blog is a boon, so keep up the good work!

Another happy reader

Brian

Rasetti 18 Aug 2009 2:15 AM

Hi Tess,

I’ve been following your blog for a long time and I think that the particularity with it is that, as the situations described are not at the level of “how can I bind a gridview row”, it’s useless most of my days, but a real lifesaver in that day, when things don’t work and the reason seems to be nowhere.

In a way, I have it more as a collection of white papers.

So, I think you have to keep doing exactly what you do, the way you do it.: your blog is probably the only resource on the web about low level, core NET debugging, so I would just recommend you to carry on :)

Just one thing that you may want to write about, from time to time, is .NET source debugging. Since it’s available, I’ve discovered a whole new world about .NET, and I think that there are a number of common mistakes, performance issues, etc., that one can stop doing by simply knowing how things work under the hood.

I guess you should be able to present us cases where you solved a customer issue that she could have solved herself just by having a look at the source.

Anyway, good work!

Juan

Tess 18 Aug 2009 2:36 AM

To be honest I wrote this post to get the scoop on what is not going well, hoping to get some “this sucks, I would learn much more if you did it this way instead” but now I am truly overwhelmed by all the nice comments :) Really appreciate them :)

In fact I am very surprised that so many have a genuine interest in this stuff, I thought I was just one of a few looney bins :) and I am super happy that at least the people who commented seem to be learning something, so it looks like I’m at least partially on the right track.

If you do have some “this sucks, do it this way instead” comments, feel free to be anonymous, or email me privately with them, i’m still interested to hear them.

Rubio, thanks for the web cast idea. I might try to get together with Ingo to see if we can do something together even. and Rasetti, I’ll think about the source code debugging one… to be frank there, I rarely use the source when I debug, and the few times I do it is mostly through reflector, but i can probably think of a few cases.

Michael G, about the lighter posts, hadn’t really thought of cat blogging, but now that you mention it, maybe my non-existant cat needs some more internet exposure:) just kidding…

Also, I wanted to mention that it is totally ok to comment on my blog with links to your own posts where you have solved issues etc. I know that most people don’t have the luxury of having the time to put that kind of stuff in print, but if you do, share it.

Thanks again all, you make my day…

JM 18 Aug 2009 8:43 AM

I’m writing this as a knee-jerk reaction before reading any other comments, because the tone of the post worries me.

Tess, you’re one of my top resources when it comes to hardcore debugging, of the kind that involves windbg and crash dumps. I can safely say that I don’t need any information in your blog for my day-to-day business, because debugging hard-to-find stuff isn’t my day-to-day business… but when it is time for a hardcore debugging session, I use all the things I learned surreptitiously from various blogs, including yours. This is primo “file at the back of my mind for future reference” stuff. Do not dumb it down or remove the nitty-gritty because this blog doesn’t have the 90% prime-time demographic, or something. In my experience, programmers always blog best when they write from the heart, and from their daily experience, not when they write what they think people want to hear. So I hope you’ve been doing that, and by all means keep doing it. The reason you never hear from people like me is because I have nothing to say at the time of your post, other than maybe “thanks for posting”, which would get old real soon. But if you need that to keep on posting, I’ll be more than happy to oblige. :-)

Now I’ve read the rest of the comments, and I’m not surprised to find that most people have basically the same opinion. :-)

Francois Ward 18 Aug 2009 9:06 AM

I’ll reflect what others have said: don’t change your focus, you’re filling in a niche.

If I want to know how to use F5 in Visual Studio and set breakpoints, there’s 3 billion other blogs I can go to. Yours fill in a niche that almost no other can. It introduced me to “Debugging beyond breakpoints”, and is now part of my daily tool set. Many people here rave about your blog. DO NOT change a working recipe!

Looking through my own blog’s usage analytics, I noticed that when you google for stuff like “set breakpoint windbg assembly” will pop up MY blog within the first 2-3 pages (which may seem awful, but my point is: I only have ONE debugging post on it, and no one links to my blog…so it just goes to show there is almost NO good resources for this)

Going back in time, some things I had to debug years ago that took weeks or months, could have been done in 5 -minutes- with the stuff that I learnt from here.

Its true many people will not understand when this stuff is useful. “Why use WinDBG when you can use Visual Studio?”, I get a lot of time. Its a shame, but turning THE source about the “how” into a source about the “why” would leave us with nothing for the former :) Just keep up on what you do best!

Brenda 18 Aug 2009 9:13 AM

I can certainly understand how most developers might be “overwhelmed” by your posts. I myself have often had to read a single paragraph several times.

But at the end of the day, I would not want you to leave out a single detail. Not only is this hard stuff, I’ve not been able to find another source of documentation that includes real world examples or explains things in such detail. If you dumb it down, your posts simply won’t be as useful to me.

That said… when I come to this blog, I fully expect to have to use other resources in order to completely consume what you’ve said – because when it comes to solving tough problems, there is no silver bullet. Any one who’s not willing to work at it probably shouldn’t be debugging in the first place.

My preferred environment is Java/LAMP so the only “this sucks” you’ll hear from me has to do with the problem that brought me to your blog in the first place. I always leave feeling like I’ve armed myself with what I need to make the issue go away.

Rick 18 Aug 2009 11:20 AM

I hope that you can tell from the comments that everyone loves your blog. I’ve learned so much about debugging in the last year of reading your blog…your goal is almost complete from my point of view…my team almost never opens cases with Microsoft because I’m able to figure out 99% of the issues we run into thanks to your teachings :) Your posts are always excellent, I really appreciate the depth you go into…it either hurts my head, or solves my issue…both are good :)

The only thing that I would request, which is not even directly related to your blog, is that some of the extra cool goodies that Microsoft has be made public. I’ve had a few issues where I spent days looking at a dump, and the support guys at Microsoft were able to figure it out in less than an hour, because of the extra tools you have available (i.e. psscor). Your post about StackViewer was great, and have you seen SOSAssist - http://www.thinktecture.com/sosassist ? I think Microsoft needs to create something like SOSAssist and throw it out on codeplex, along with psscor & the internal versions of sos.

chakrit 18 Aug 2009 12:48 PM

First time commenting :-)

Haven’t read what everyone already said but just wanna add my 2cents:

• Concise-ify your posts but no need to drop the technical level!!
• Do show up on other communities outside of M$!!

I think you need to make your posts more concise, but no need to drop the low-level stuffs, that is the reason I’m still reading your blog, to learn some low-level debugging stuffs in order to improve my skills as a developer.

And if you had an account on stackoverflow.com I’d definitely subscribed to your answers there :-)

Anyway, you’re one ninja debugger! keep up with the blog posts :-)

Colin Newell 18 Aug 2009 3:27 PM

I like your blog just the way it is!

I’d suggest you have an eclectic selection so that you have something for everyone and people can ignore the articles they don’t have time for until they really need them. The trouble is you’re already doing that!

Justin James 18 Aug 2009 10:45 PM

I’ve learned a lot from this blog, and I link to it over at TechRepublic regularly. I like that you cover things from a completely different angle than I am used to reading.

One thing I’ve learned in the last nearly 4 years of writing, is that the critics write and the fans don’t. I’ll get a few emails a month telling me that I need to change something about my writing, but so few commenters actually say, “gee, you are really wrong” or “wow, you are such a jerk!” that I feel confident that I’m doing something right.

I think that if you keep doing what you are doing, which you clearly must because you keep doing it, you’ll be fine. Unless you are getting paid to write this, no one is your master but you!

J.Ja

BEERLESS In Seattle 19 Aug 2009 2:24 AM

I love your blog and subscribe to it in some kind of an ‘RSS’ feed. (What ever that is?)

Anyhow, just keep on doing what you are doing. Do not dumb it down. Who cares if it is ‘so far out of their realms’ of some peoples understanding. They need to dig deeper too!

Now read the first 10 chars of this reply (including spaces) and add an exclamation point after the ‘u’ :-)

–Pope Titus

Marc Shermaan 19 Aug 2009 10:18 AM

Tess,

IMO this is the BEST blog about .NET debugging! I have learned a LOT from it and it has made me a much better .NET debugger. Deeper is always better and please do not make the posts lighter.

thanks for your hard work,

Marc

Eber Irigoyen 19 Aug 2009 11:50 AM

for me your blog has been a source of great knowledge, the topics you talk about here are not simple, are not for the average developer, that’s for sure; but anyone wanting to learn more about advanced debugging can come to your blog and learn tons

I like the way you present your work, you have answered my questions when I’ve had issues here, so, for me, you don’t need to change anything

I really appreciate all the work you have put into all these fantastic tutorials, I have no problem admitting that you are one of my heroes

thank you Tess

Angel 19 Aug 2009 5:05 PM

I am not a developer but have had the need on several occasions to delve deep into some dumps. Your blog has helped me immensely. I read every one of your posts. I won’t say I necessarily understand everything but they have definitely helped get me to the solution or at least determine “why.” In some cases, it’s just nice to just get a deeper understanding of what is going on and why - for no reason at all.

I’m sure there have been some posts where you presume some knowledge of your audience but I think that’s okay. Those times have just forced me to learn on my own and I have no problems with that.

You can’t please all of the people all of the time!

Konstantin 19 Aug 2009 7:27 PM

It is 21st century, please post code samples in color, not in as plain black and white text.

I’m not into deep debugging, but I’m trying to look through your new posts so I can learn something or at learn that there is a way to solve some problem.

PS

you are one of my 2 homepages at work :)

Tom 20 Aug 2009 4:59 PM

My suggestion would be to provide a few “Getting Started” posts that explain your background and introduce your debugging philosophy, methods and tools. Put a link to this post at the top of your blog.

Thanks for your hard work and commitment!

Marvin 21 Aug 2009 10:20 AM

Hey, Tess.

I’m an ASP.NET developer and brand new to your blog. Scott Walker presented on debugging at DevLink 2009 and highly recommended it, so I am going to start reading. I don’t know anything about it, but it sounds like a topic that will be useful to me.

I guess it was fortunate that I had a production problem that was difficult to track down the week prior to DevLink. Put me in the right frame of mind to hear about this stuff.

Just looking at the front page of your blog, it would be nice to find a “If you are a total new to debugging, start here” link. I see the links for post index and top 21 posts, so I’ll start there, but it would be great if I could go straight to the beginner level posts as a point of entry to get comfortable.

Looking forward to learning about it.

John 21 Aug 2009 10:24 AM

Tess you are my last and often sole resort, there are too many “Getting Started” blogs around. Keep up the brilliant work and dig as deep as you can go.

If there where more deep down blogs like yours inside MS, explaining who things are really working down under the hood, my work would be a lot easier.

Thanks a lot and keep up the good work.

Sorry for my english, that might be the reason why many people prefer private messages ;-)

Best regards

John

Erick 21 Aug 2009 7:03 PM

I love the information on your blog, and think that it is one of the few treasures in the .net community.

With that said I think one of the problems is most of your readers rarely (if ever) run into a problem that needs windbg to solve. Or rather I think most of us don’t know what symptoms to look for.

Obviously if your event log starts showing a bunch of oom exceptions or you get true application crashes, or the server stops responding you know you have a problem. But it has been my experience that this is rare. Servers and applications restart on their own to often for these types of problems to manifest in an obvious way. (I’m talking about windows update restarts, low activity process recycling, and general low traffic web sites).

So I think some posts on looking for less obvious symptoms of problems would be great. I would cover things like how to get a baseline performance profile of your app using tools like perfmon would be a good way to show people how to detect problems. I know you have done lots of posts about using perfmon but it is always in the context of using the tool after you know a problem is occurring because your app crashed or something like that.

Avivg 23 Aug 2009 9:10 AM

I love your blog! I’m a kernel developer, so ASP.NET is not directly related to what i do day to day, but i like to read it because there is a lot in common. Working the debugging tools, and the general technique and mind attitude is similar. I also like to learn new stuff about windows internal workings through the problems you present and solve.

Of course that there are developers who don’t know what are you talking about. Let’s be frank, many developers (and people in general) are stupid, lazy and narrow minded - many productive developers couldn’t debug a complex on-site problem if their life depended on it. Advanced debugging, working with windbg, post mortem debugging - is complex. What can you do?

You can! You can widen the “simple use cases” section of your blog to educate those developers with enough will-power to learn something new, and ease their way in.

Advanced debugging is not main stream - so are you - just learn to accept it :)

Samuel 25 Aug 2009 5:17 PM

Tess,

I think so far you’re spot on. For everyday debugging you don’t really need to use many of the things you talk about here. For the worst scenarios where critical issues hit production servers, your blog is invaluable. I think you need to keep with your target demographic which is more of the after the fact debuggers. I do appreciate your articles. Keep up the good work.

Randy 28 Aug 2009 11:28 AM

You asked for “This really sucks…do it this way” comments, so hear you go…

Love the blog, but for someone that does not live debugging, I don’t know what I don’t know. Meaning sometimes I don’t know what to look for.

It would be very helpful to have a one-stop guide to how you approach a debug scenario. For instance, given a crash scenario, what commands do I use? How do I know to run !pe ? How do I walk the stack to find root cause.

What I do find on your site rocks, but there are often times I just don’t know how to find it and the search functionality of the site sucks.

Ed Zielinski 31 Aug 2009 11:08 PM

Please keep posting your detailed explanations and examples. Your debugging labs got me the hands on start that I needed to understand debugging in IIS and .NET. Your clear, logical writing style is a joy to read, despite the subject matter often involving advanced topics. One of your examples reproduced a problem that I observed in a customer’s application, and others have provided hints in the right direction. Thanks!

P.S. - I also thought your webcast presentation was very insightful also.

Kellen Sunderland 8 Sep 2009 3:54 PM

I’ve used your site many, many times for quick reference. Additionally it was your labs in the first place that got me into debugging via windbg.

Now in my organization I’ve fixed a bunch of production issues with WinDBG. I happen to love working on these, and I’ve been sure to mention your posts to the people I work with.

I’ve found that you can generally follow a debugging flow chart for most common problems (as you explain in your labs). Maybe outlining these methods in a summarized flow chart would be useful for people’s reference?

Wade Mascia 9 Sep 2009 2:46 AM

Tess, your humility and your desire to reach the masses is refreshing. You know it takes us 4 full days of classroom-style instruction just to introduce folks to the debugging tools/techniques. After that, it takes how many years of troubleshooting issues full time for a living to get really good at it? And how many engineers who do it for a living really get good at it, vs. those that are content to hand the work to your team? So please don’t feel bad if most developers can’t digest most blog posts on most issues. It’s hard.

If you’re really interested in taking all that knowledge/experience (aka. lessons from war) and feeding them out to the developer world with maximum impact, then one thing you might want to consider is helping to automate the process in some way, to make it more consumable/useful for everyone. You can execute debugger extensions within VS. You could do it from a plugin w/ a UI. For a pro like you, the possibilities are endless. OK I may be biased after working on DebugDiag :), but that may be a good way to help spread the love, if that’s your goal.

btw any time you want a pool lesson just let me know :)

hth!

Tess 10 Sep 2009 3:13 AM

Randy, Kellen,

I’ve been trying, for many years in fact, to come up with a flow-chart that works well. My problem is that while it starts out pretty nicely it ends up getting very big, very fast :) I will continue trying though because that is something I want to do.

Also, on the one-stop for crashes for example, I have done some similar posts on hangs and memory (on this blog) but they don’t cover everything, thanks much for the tip.

I have an idea that I’m thinking about, approaching the blog as a book, trying to sort things into chapters, and I noticed while doing that, that I do have a lot of case studies, but I am missing a lot of the more “general” info on things like crashes, debugging, etc.

Wade :) I’ll definitely have to take you up on that pool lesson next time I’m in CLT.

Been talking a little bit to Brett about debug diag stuff and I think he was looking at what we could do based on the memory debug diag script I posted here earlier. Automation is something i am definitely interested in but it is a really tough topic to tackle for a lot of issues.

Thank you all for the masses of feedback, love it

Miguel Ventura 18 Sep 2009 7:08 AM

Hi Tess,

I think that your blog is very useful, well organized and I love those initiatives like putting up those labs as they’re really helpful.

However I do think that WinDbg has an edgy learning curve and most people I know learn how to debug using GDB (or other tools with similar syntax) or Visual Studio, but never get to WinDBG. For those people (me included), seeing all this information is awesome but it’s like seeing hundreds of different commands falling from the sky. It’s really hard to see a good tutorial or other resources on learning WinDBG starting from zero, which makes most people flee to easier albeit less powerful alternatives, which is a shame. I mean… how do you support escalation engineers get started with this tool?

On another issue: I do product maintenance where I work (I probably could call myself a support escalation engineer but I think “maintenance guy” is more cosy :)) and we sometimes have issues with our product that only happen on a particular customer’s machine which makes it rather difficult to identify and replicate (and therefore fix) the problem. When these problems are crashes, crash dumps may help a lot. However sometimes it’s a performance problem or some component giving timeouts… so, do you know of any tools that help with this kind of issues and that don’t require the installation of a full-featured heavy weight profiler application and attaching it to our application while it’s running and etc?

best regards,

Miguel

Tess 21 Sep 2009 2:53 AM

Thanks for the input Miguel,

Perf issues are tough, if the perf issues are bad enough you can troubleshoot it with dumps but if not unfortunately you will need a profiler of some kind. I usually at least gather some perfmon logs to get a picture of the problem before going to a profiler since that is pretty invasive.

David 28 Sep 2009 12:23 PM

The biggest suggestion that I would make is search. I realize your on the MSDN blogs site, but SO MANY times I have come across a blog posting of yours in the past that was from 2006 or 2007 time frame. When I do a search on the blog it doesn’t return anything. I typically have to find obscure references to your blog from other people’s blogs, which is a bit frustrating.

Erich Eichinger 28 Sep 2009 6:04 PM

Hi Tess,

you already got so much love from your reader-community, I thought I’ll add mine as well ;-). Yes your blogs are sometimes hard reading and yes, most of the issues I will (hopefully) never run into. Ntl your blog saved my life for a couple of times already. I guess the point is, that most people don’t do this sort of debugging every day, thus they need some refresh once they get into the situation and that is one of the major pluses of your blog. It always helped me get up&running within a short time to be able to tackle my issue at hand.

Even when I am not currently debugging a serious issue, I love reading your posts. I always learn something from them and your war stories are thrilling. It is like reading a whodunit.

Keep up the great work!

Ed Zielinski 26 Oct 2009 7:06 PM

Tess - Since 64 bit computing is becoming more prevalent and each day sees more IIS and .NET applications using it as a platform, can you include more details about debugging x64 applications and also include any caveats for x64 for various debugging scenarios.

Great stuff!

Lee 28 Oct 2009 9:06 PM

Tess,

Your blog is just fantastic and I only stop by rarely too keep in touch with the debugging world… however a couple of years ago I found a great article you wrote and realized you were talking about just the issue we were having with IIS. I called MS support and mentioned “Tess knows what this issue is”. Within 20 minutes I had a call from you… I nearly fell off my chair!

Anyway, you resolved our problem and I have always kept my eye out over here. I do less development now but still enjoy straining my brain trying to figure out some of the stuff you talk about. It’s worth it though, as someone said above, if it doesn’t tax you, you don’t learn… when you do finally get it - its like a lightbulb turning on in your head.

Keep up the wonderful stuff!

Tess 29 Oct 2009 3:11 AM

Thanks Lee,

Good to hear from you again :)