Troubleshooting WCF In Production Environments


WCF is such a nice framework, and its diagnostics capabilities are really comprehensive. Really, I only have two (pseudo-)issues with diagnostics so far:



  • Configuring diagnostics is pretty difficult to do (lots of XML editing involved)

  • Reading trace and message logs is hard. By default, it’s in XML, so it’s ‘human-readable’, but there’s just so much of it that it becomes nigh-unreadable in reality

In both cases, the answer is a tool, and such tools actually exist: The Service Configuration Editor (SvcConfigEditor.exe) addresses the first point, and the Service Trace Viewer (SvcTraceViewer.exe) the second. Both are part of the SDK and can be found in “C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin” (or whereever your SDK is installed).


The only problem with this is that in production (or staging or test) environments, the SDK isn’t typically installed, and nor should it be. Alas, this also means that those two very useful tools aren’t available either, which makes troubleshooting on a production client or server much harder.


After a couple of days of manually copying configuration and trace files back and forth between my laptop and the test server I was troubleshooting, the obvious solution hit me. It’s so simple that you probably already know this trick, and if that’s the case, I apologize for having made you read this far.


Both the Service Configuration Editor and Service Trace Viewer tools are .NET applications, and since they don’t have any fancy dependencies (apart from .NET 3.0), you can deploy them via xcopy. While I don’t particularly recommend that you copy them to your production servers or random clients, you can copy them to a USB stick that you can carry around.


Whenever you need to use these tools, but don’t have the SDK installed on a machine, you can just plug the USB drive in the machine and run the tools from there.


There you have it: You may have figured this out long ago, but for those of you who are as slow as me, I hope this little trick can save you some time.

Comments (11)

  1. rprimrose says:

    If you have read access for logs and (heaven forbid) write access to the config file on your server, both applications will happily read the files off the network location.

  2. ploeh says:

    Good point. In the case I just experienced, however, I didn’t have network access from my developer machine to the server in question, so that wasn’t an option. In my experience, that’s not too uncommon a case, so it’s nice to know that if you can’t bring the log files to you, you can bring the tools to the log files 🙂

  3. kost says:

    Good hint/idea. An alternative to a USB stick is of course a net drive. Many server configurations (e.g. blade servers) does not have a USB interface.

  4. ploeh says:

    Another good point. You can also burn the tools on a CD or DVD. The Service Configuration Editor is too large (1960 kB), but the Service Trace Viewer even fits nicely on a 1.44 MB floppy disk 🙂

    You could even carry it around on your phone and transfer the files via BlueTooth, but I guess blade servers don’t have BlueTooth either 🙂

    The main point here is that these tools are very portable, so you don’t need to install anything to use them.

  5. ploeh says:

    Oh, BTW, I forgot to mention this: Both Service Configuration Editor and Service Trace Viewer are .NET applications, so because of Code Access Security it matters from where you execute them. If you run them from a network drive, they are likely to not run under Full Trust, and I don’t know how they are going to behave under those circumstances (I haven’t tested it).

    That’s the nice thing about USB drives: When you plug them in, they act as just another local disk, which means that .NET applications will run from them with Full Trust.

  6. ploeh blog says:

    It must be my week of discovering the obvious . The other day I was troubleshooting a race condition

  7. alik levin's says:

    This is a digest of WCF Security resources I was collecting for some time. Drop me a comment in case

  8. Pingala says:

    I copies the files to USB stick and tried to execute on the windows 2003 server having .net framework 3.0. I am getting error in application event log. what is the problem?

  9. ploeh says:

    Hi Pingala

    Which error are you getting?

  10. Pingala says:

    I have .NET framework 3.0 & the following error occurs:

    EventType clr20r3, P1 svcconfigeditor.exe, P2 3.5.0.0, P3 4715d092, P4 svcconfigeditor, P5 3.5.0.0, P6 4715d092, P7 a32, P8 0, P9 system.typeinitialization, P10 NIL.

  11. ploeh says:

    If you perform a Live search after ‘EventType clr20r3’ you will see there’s a lot of grief about that message. I’ve never seen it before, but it seems to be related to attempts at using CLR types that are not available on the installed framework.

    Could you, perchance, be trying to use a 3.5 SvcConfigEditor.exe on 3.0?