Debugging WCF

I like Stack Overflow and the other StackExchange sites. They’re very clever: you go there in response to a Google search, and find yourself trapped into answering questions about all sorts of things.

I mean, Joel and Jeff even sent me a hat, and a couple of pens, and a T-shirt, for answering a question about… worktop surfaces. And if that doesn’t count a sign I get easily distracted from the day job, nothing will.

One thing I’ve started to notice is that plenty of people end up asking questions that can be answered by themselves by understanding a little more about the tools they already have. A good example is the WCF Service Trace Viewer.

Windows Communication Foundation is great, but it can be insanely tricky to configure, especially when it comes to the various combinations of transport security, message security and what-have-you. And while the exception messages try hard to be specific the flexibility of WCF means there are just too many places where the thing can break, leaving nothing but “The remote connection was terminated” or something similar.

Enter the Service Trace Viewer.

OK, there’s more configuration to add… but this tells WCF to spit out great hunks of detail on what it is doing. Better still, if there’s an exception, the complete stack trace appears together with detail on what WCF decided to do.

    <trace autoflush="true" />
            <source name="System.ServiceModel"
                    switchValue="Information, ActivityTracing"
               <add name="sdt"
                   initializeData= "c:\temp\ServerTrace.svclog" />

Put this into the configuration file on the server and the client.

Be careful that you create the service trace file where you can read it: it’ll be created and written using the account your service runs under, which generally isn’t particularly privileged.

Also be careful that the place you choose for the file is big enough. Busy services will spit out megabytes of data, especially if you (like me) forget you’ve left it configured. (You really don’t want to do this for your production instances: here, Web config transforms are your friend.)

All this is wrapped up in what personally I reckon is one of the best bits of UI visualisation I’ve seen. Yes, it’s a bit long-in-the tooth (hey, love the retro toolbar) but: can you spot where the exception is thrown here?

Yes, thought so. Double-click on the angry red link and you get all kinds of detail:

This is the Service Trace Viewer. You’ll find it in C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\ or thereabouts, or just press Start and type ‘service trace viewer’ — as you can see you’ll need the Windows SDK installed.

There’s all sorts of doo-hickeys on the tool bar and menu to help you filter down the trace information. That graphical display on the left of the information flow between client and server is awesome, but it’s the way you can see the exception trace in all its gory detail that I like.

But that’s not all. I was figuring out a really horrid issue the other day and found…serialization also works in the same way! So, if something is deserialized as null when you’re not expecting it, the Service Trace Viewer may well tell you why.

All we need next is a nice context-sensitive button that appears next to an exception in the trace labelled “Find on StackOverflow” – so we can go directly to the relevant answer…