Dela via

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

  • Artikel

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?

Thanks

Tess

Comments

  • Anonymous
    November 24, 2008
    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).

  • Anonymous
    November 24, 2008
    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.

  • Anonymous
    November 24, 2008
    The comment has been removed

  • Anonymous
    November 24, 2008
    Yes, please focus on ASP.NET stuff since it's probably most researched area of debugging

  • Anonymous
    November 24, 2008
    .NET Redirecting without the exceptions So, what’s new in the CLR 4.0 GC? Source Control for Visual

  • Anonymous
    November 24, 2008
    .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.

  • Anonymous
    November 24, 2008
    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

  • Anonymous
    November 24, 2008
    Silverlight debugging would be a godsend

  • Anonymous
    November 24, 2008
    about locks,deadlocks and  load of examples

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

  • Anonymous
    November 24, 2008
    The comment has been removed

  • Anonymous
    November 25, 2008
    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.

  • Anonymous
    November 25, 2008

  1. Don't care much about UI-s.
  2. No.
  3. Yes, please :).

  • Anonymous
    November 25, 2008
    hello, 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 ? :)

  • Anonymous
    November 26, 2008
    It will including the multithreading?

  • Anonymous
    November 26, 2008
    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. Thanks tess

  • Anonymous
    November 26, 2008

  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.
  • Anonymous
    November 27, 2008
  1. Winforms - yes please
  2. IIS install - no problem
  3. Debug diag examples - yes please

  • Anonymous
    November 28, 2008
    I would like to see debugging performance issues with SharePoint

  • Anonymous
    November 28, 2008
    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) ?

  • Anonymous
    December 01, 2008
    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?

  • Anonymous
    December 04, 2008
    As time goes by i keep remembering stuff. What about some heap corruption ?

  • Anonymous
    December 08, 2008
    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...
  • Anonymous
    January 12, 2009
    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.
  • Anonymous
    February 19, 2009
    The comment has been removed