If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

Request for feedback

Request for feedback

Rate This
  • Comments 34

Not sure if anyone is reading this blog, but if you are and there is something specific you want me to blog about please let me know.

On my TODO list right now i have

  • Debugging managed memory leaks
  • Automating debugging with .shell and .foreach etc.
  • Debugging .net 2.0 applications

but I want this blog to be a useful resource, so rather than just blogging about what interests me, let me know what interests you:).
And I'm also interested in getting feedback on if my blog posts are too long, or too short, or too detailed or not detailed enough...
or if i should just stick to debugging, and stop writing boring blogs:)

Until next time...

  • Hi, I'm not sure if you have already blogged about Remote Debugging or not, but that is always something I hear people having trouble with (Setting up, permissions etc), so an article on that would be great!
  • In Windbg? or are you talking about Visual Studio?
  • Your are doing a great job. Especially Managed debugging using windbg.
  • Tess, Your blog rocks. I don't have any specific areas to suggest, but suggest you keep wrting when you come accross stuff you think should be more widely known because it's REALLY usefull stuff.

    Thanks!

    Colin.
  • I usually don't post comments. I just use the "Rate" feature.

    More windbg tutorials would be great. Especially debugging mixed mode code and pure managed code.

    My knowledge on windbg has been based on what I found on google and on http://blogs.msdn.com/mvstanton/default.aspx.

    Your post on associating windbg files with dumps was excellent because it was a time saver for loading some dumps I was working on.


    Debugging managed memory leaks seems like an interesting topic. For now, I've been using scitech's profiler.

    It would be great if you can stick to just windbg instead of vs.net for debugging articles because windbg is free and is a small install and sometimes, I want to debug the problem in realtime.. Windbg doesn't require a reboot upon installation which allows me to download, install, attach, dump, look at stuff, detach.
    =]
  • 1 more thing.. Is SIEExtPub.dll past of the windbg install yet?

    I remember having to scour the internet for it, as it was a seperate download I got from some obscure website =/

    It had some useful functions like critlist, waitlist, and showstring.

    critlist & showstring = major timersaver.
  • Keep up the good work!

    I too would like to see information about Remote Debugging.

    Also, any tips on remote debugging VB6 applications would help me out right now ;-)
  • A friend recently show me your blog and trust me, every minute reading the posts is worth. I think that the size of the post doesn't matter, if you need 20 or 2000 lines to explaind something, do it. Keep up the good work.
  • wow, thanks a lot for all the comments, i'll keep writing then:) next one comming up will be a case study of a memory leak and should be done within the next few days.

    In regards to the remote debugging topic, I am still curious if it is windbg or visual studio that interests, and also what types of environments (over the internet, or on the same LAN, or through a terminal services session etc. and also if it is debugging a service or a windows application as how you attach depends a little what windows station you started the application in, on second thought, i'll probably add a little of everything once i start writing it:))

    Windbg doesn't allow you to attach to a remote process but i'll be happy to talk about tips and tricks to debug things remotely by starting cdb on the remote machine and then attaching to a remote session. It can be a bit tricky to get it working.

    For the VB6 topic, I'm sorry to say it's not something I generally deal with, but I want to recommend my colleague Mark Long (his blog is in the blogs i read list) he knows a lot more about VB6 than anyone on this earth would ever care to know...
  • Oh, and on sieextpub.dll, it's not a part of the windbg.exe package but i'll try to figure out where to get it and write some posts about it. Some of the functions that Hasani mentioned like !critlist is a must for low CPU hang debugging (gives you all threads waiting for critical sections)
  • One thing I can't ever find is a "managed debugging for noobs" article that covers taking memory dumps of a process on demand and by creating an exception handler of sorts that does it for you, then loading this dump into mdbg or windbg, loading the symbols, and doing a bit of inspection.

    It seems there is plenty of info out there on the power of debugging memory dumps, and plenty about the details of what you can do within the dbg tools, but there's just so little on helping people bridge that gap.
  • I noticed this so I wrote a post called Back to Basics on how to gather dumps, and in the 40.000 exceptions post you can see how you can create a config file for gathering logs/dumps for all your exceptions, but I'll keep doing more of these as ideas come up.
  • Good article! Very useful!
    Remote debugging is something I would be interested in.

    cheers,

    nik
  • Good blog,keep on the good work...

    Please don't neglect the unmanaged world.
    Also I would be happy to read about real cases when GFlags/Verifier helped you troubleshoot strange bugs.
  • I think consensus is that people are reading this "boring blog" and *LOVING* it. I'm a big fan.

    Since I tend to see more apps having memory pressure than high cpu. I'd like to see...

    Difference between pinning and things being rooted and how to solve both.

    How does 64 bit (with 2.0) change the debugging landscape - specifically what new things to look for and the tools to support looking.
Page 1 of 3 (34 items) 123
Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post