Planning a new .net debugging lab set – What do you want to see?

There’s been close to 25 000 downloads of the buggy bits lab set, YAY!!! 🙂  but now I think it’s time to expand it a bit with some new labs. 

I have a few different issues in mind but I wanted to check in and see if there is something specific you want to see in the new lab set. 

I know that the first request I’ll probably get is to include something about COM debugging or debugging RCW/CCW leaks and I might do that, but I just want to say that I am struggling a bit with this.  Just for fun I installed VB 6.0 the other day to create some nasty COM component, but it has just been so long that I’ve forgotten how to write code without the VS.NET intellisense 🙂 you don’t really realize how good it is to have something until you don’t have it anymore…

Looking at the old labs, my main goal there was to include the basic scenarios and to make sure that the labs could be installed in a few short steps without having to register this and that.  They do require IIS though, but I wanted to see what your thoughts are on some items before I start planning the new lab set

1. Are you interested in Winforms debugging, Silverlight debugging, WPF debugging?  It’s all essentially the same since the techniques are the same no matter what “shell” you use, but still…

2. Does it matter if you need IIS installed on the machine?

3. Do you want to see debug diag examples?



Comments (25)

  1. jk says:

    Debug diag would be interesting, particularly since I can’t get it to play nice w/ Win 2k3 x64 (seems to require a reboot every time I change rules).

  2. Russ says:

    I would like to see the ability to specify the number of cores my application can take advantage of. It would be nice to see how my multi-core changes affect a single core, ( or any number less than what my dev machine has ), users.

  3. Ed Fancher says:

    It would be interesting to see some really tough problems. For example, we’re seeing a problem recently where our production site shows a high amount of memory fragmentation and this prevents some 3rd party unmanaged components from loading (They need a certain amount of contigous memory to load). It would be nice to see how you would go about troubleshooting and reproducing a problem like that.

  4. GS says:

    Yes, please focus on ASP.NET stuff since it’s probably most researched area of debugging

  5. .NET Redirecting without the exceptions So, what’s new in the CLR 4.0 GC? Source Control for Visual

  6. PK says:

    .NET debugging only.

    Would love to see some of these labs turn into Video sessions.

    I have no problems requiring IIS to be installed. Anything ASP.NET, WCF or WF related i’d love to see.

  7. hehe, you nailed with COM RCW/CCW bugs, but I have written those in .NET, overall I don’t think there are a lot of people using (having issues debugging) these technologies

    I would like to see more focus maybe on web technologies like Silverlight/ajax, etc

  8. JD says:

    Silverlight debugging would be a godsend

  9. puru says:

    about locks,deadlocks and  load of examples

  10. yk says:

    I would love to see how to monitor handle leaks in .NET process (not necessarily ASP.NET). and also, Advanced use of windbg.

  11. Tess says:

    Great ideas, I like all of them.

    Russ, about your comment "I would like to see the ability to specify the number of cores my application can take advantage of. It would be nice to see how my multi-core changes affect a single core, ( or any number less than what my dev machine has ), users."  can you expand on this a little bit…  

    You can set processor affinity (through a windows API, i believe it is called something like SetProcessorAffinitiyMask but you will want to be very careful with that since it can get you into deep trouble if you run with the server version of the GC)   Why do you want to specify the number of cores?  is it just to test your application on a single core box, or for some other reason?

  12. ThomasD says:

    Hi Tess, 90% of our apps are desktop apps (native C++ mixed with .Net Winforms). So I’d like to see samples without the IIS. We also have often a lot of trouble with COM DLLs and mixed DLLs written in C++ or C#, but not in VB6 anymore 🙂 . So any sample in this area would be welcome.

  13. Lucian Bargaoanu says:

    1. Don’t care much about UI-s.

    2. No.

    3. Yes, please :).

  14. Bruno Aleixo says:


    com interaction would be very interesting, mixed mode, and also cases where we would make more debugging in native stacks , get to frames, unassembly to get values, understanding FPO and different call conventions….

    not asking to much am i ? 🙂

  15. says:

    It will including the multithreading?

  16. Tess says:

    technically all .net applications are multithreaded, but I am considering adding some threadsafety issues.  I am assuming that that might be what you are looking for, if not, please expand.



  17. Nitin says:

    1. Sure why not?

    2. Does not matter whether there is a need to install IIS or not.

    3. Including Debugdiag would be great.

    Also if you post your personal practical expirience examples that will also help.

  18. Jeremy Sage says:

    1. Winforms – yes please

    2. IIS install – no problem

    3. Debug diag examples – yes please

  19. Michelle Rutherford says:

    I would like to see debugging performance issues with SharePoint

  20. Bruno Aleixo says:

    Usually we are post mortem debugging. Is it possible to get a case around live debugging. For example around statics, finding variables addresses and setting breakpoints there to understand flow (e.g) ?

  21. AtulGupta says:

    Would like to see some WPF and SL specific labs. In WPF, something that helps with the load times, graphics and rich animations and performance issues due to them.

    We also had a case of multi appdomains in WPF, so something on that scenario as well.

    finally, SL with specifically package load issues. We know that we can create multiple xap files, but is that all to it?

  22. Bruno Aleixo says:

    As time goes by i keep remembering stuff. What about some heap corruption ?

  23. Jp says:

    How about some really simple stuff

    1) Learn how to use Windbg to go to the first chance exception of a .net program.

    2) Dump the exception code and get the exception message.

    3) Learn how to set a break point at the entry point of that method

    4) Learn how to single step and display local Vars up to the point of the exception.

    IIS is not needed, this can be a native debug session.

    PDB files should be available

    Source code can be available to…

    Then explain why using WINDBG might be better than attempting to use CORDBG or the .NET Framework SDK in production mode…

  24. Al says:

    As your after .NET debugging I’d like to see some more .NET specific analysis.

    – Memory leaks – going from !gcroot or !refs (explain each of the root types – I know you’ve touched on these but others are mysterious) e.g Some don’t "end" in the object that you’ve requested. i.e the last object in the chain is not the object you passed the address of to gcroot.

    – Delegates – getting from what’s in the intPtr to a method – this would be great for tracking Winforms based memory leaks.

    – Any tips you have for combining reflector, ildasm, and bpmo for better managed breakpoints

    I’ve "lurked" for years on your blog and finally a post – so a big thank you for all the great info.

  25. Joseph Laccone says:

    Hi Tess,

    I’d like to see everything (including the kitchen sink, and maybe the dishwasher as well) on debugging threads. How to make them safely, how to view them while they are executing, tips tricks and sneaky plans to terminate them individually in a debug environment.

Skip to main content