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

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

  • Comments 58

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 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,

Leave a Comment
  • Please add 6 and 3 and type the answer here:
  • Post
  • debugging and see that it is in fact something that we can all do

  • 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...

  • 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 :-)

  • 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.

  • 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 :)

  • 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.

  • 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. :)

  • Tes, I find this to be a phenominal 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!

  • 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!

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

    Keep it up.

  • 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.

  • 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 webfarm experiencing viewstate corruption even though the machinekeys 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 machinekeys.

    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 luser's brain.

  • 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 screencasts 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


  • 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.

  • 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. ;-)

Page 1 of 4 (58 items) 1234