CLR SPY: Feature requests for the next version

Now that I'm set up at my new blogging home, I'd like to get some feedback from anyone who has used the CLR SPY tool that I've uploaded to and blogged a lot about in the past.

We're investigating shipping the tool in the .NET Framework SDK, and would like some feedback on what you do/don't find useful about it.  The Whidbey CLR will have a larger set of CLR Debug Probes (CDPs) than what v1.1 has, and these will all be exposed in the updated tool, of course.  But do find the “monitoring“ behavior of the tool useful?  Are the balloon notifications annoying?  etc. etc.

Thank you in advance!

Comments (15)
  1. Keith Hill says:

    How about a CDP for calling code on the wrong thread? This is particularly relevant to Windows Forms code. Would it be possible to do a CDP for not calling EndInvoke on a delegate?

    The ballon notifications but in the end what I really want is a report listing all the problems. The log is OK for that but I’d rather be able to pull up the ClrSpy UI and see a history/log of issues.

  2. Adam Nathan says:

    Thanks, Keith. Ian Griffiths also asked for such a CDP here: We’ll see what can be done. I’ll pass along both of your requests.

    Yes, I’m definitely planning to have a simple table that logs all messages that you can clear, sort, etc.

  3. Keith Hill says:

    OK, just got bit by another stupid mistake that perhaps a CDP can be created for? What’s wrong with this line of code: String.Format("Some nice formatted text {0}", foo1, foo2)? This is probably more of a .NET Framework thing but it would be nice to have some indication that not all of the parameters passed into String.Format were used.

  4. Daniel Bodart says:

    I’d just like to give some feedback on the tool: I have been doing a lot of P/Invoke + COM interop work during the development of a pure C# property page / mmc framework.

    This tool immediately identified 2 premature garbage collection issues where I was not passing a GC handle into the unmanaged world. I had been aware of the issue but this pinpointed it straight away.

    One area where I felt I could have had a bit more of a hand would have been with the Thread switching apartment state message. Naturally I have read your blog but is there a way to stop the CLR from trying to switch to MTA when initialising a managed inproc COM component? Or can I stop this message without loosing all thread state changing messages? (i.e. a sub category)


  5. I’m working on an OPSEC LEA client. Rather stupidly, they need you to reference struct pointers in their DLL’s.

    I’m getting around this at the moment by going

    #pragma unmanaged

    __declspec( dllimport ) extern OpsecEntityType *LEA_CLIENT;

    __declspec( dllimport ) extern OpsecEntityType *LEA_SERVER;

    #pragma managed

    I’d like clearer documentation on

    a) if this is supported

    a2) if not, why it’s a really good idea to refactor your code to use accessor functions

    a3) If yes, how to do this in a supported way, linked off a related links page in MSDN or platform SDK.

    DllImportAttribute and the marshalling area of P/Invoke simply don’t go into it at all, and it’s the sort of gotchya that will make or break some projects.


  6. Whoops – wrong wish list. 🙂

  7. Read Print says:

    Free books for students, teachers, and the classic enthusiast.

  8. IM says:

    [whinge-moan-gripe] doesnt work in Firefox!


  9. Rob says:

    What about support for ASP.NET apps and Serviced Components?? This would be great.

Comments are closed.

Skip to main content