WCF Tracing. How I can get the exact reason for closing connection?

Question

In my WCF service, when trying transfer large data I constantly get an error: The underlying connection was closed: The connection was closed unexpectedly

Answer 1

For anyone still getting this problem - as usual there are a couple absolutely crucial things left out of the above discussion, without which there's no hope of finding an answer. Here's what took me 3 hours of rooting around online to find out.

To recap: First, I got the dreaded Not Found error using WCF from a Silverlight service. No, it's not because the service isn't found. I was able to step thru the called service method clear to the end, including the return. Then the client side got an exception in the async End part of the call. No explanation. It's got NOTHING to do with the bindings etc.

Then I found forum messages like this one about using the trace viewer. Turns out I already had that configured, but was not getting any trace (so I figured my service must be ok, esp. since I could trace thru). Wrong, bongo boy. Then I found another message saying a little known fact is if you set up a trace listener to write to "C:\logs\mylog", you MUST first create C:\logs by hand. It will not do it for you.

Ok, now I get the log and bring it up in TraceViewer. Whereupon I get an "error message" about an unterminated string. Thirty minutes later I find another message saying, oh, everybody knows you must first end your local dev server in order to flush out the last of the messages. You know, the ones that actually tell you what went wrong?

Now I get to the real errors and look at each one of them: Throwing an Exception, RequestContext aborted, and Failed To Send Response message over http. Only the first one matters. Except of course when looking at the lower pane, it gave me no useful information at all except to say there was a Serialization error. Um, "where" would be nice.

At my wit's end, I suddenly notice there's a little XML tab in the lower pane, right next to the "Formatted" tab. When I click on that, for my ThrowingAnException message, there it is - a ginormous dump with a highly specific message that led me right to the problem:

System.ServiceModel.CommunicationException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 There was an error while trying to serialize parameter :GetTimecardsWithAlertsResult. The InnerException message was 'Enum value '0' is invalid for type 'Timeclock.Web.ShiftManager.AlertType' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.'. Please see InnerException for more details.

The problem was I had not initialized an enum-based member of a class, so it was 0, which was NOT one of my allowed enum values. Very simple to fix.

And clearly, very simple for Microsoft to detect, given that large amount of information they successfully hid from prying eyes for 3 hours.

Here's an idea Microsoft - how about you just offer a way to catch these errors and the all-important exception-message server side? Or let them fully pass through to the Silverlight client? You known, to make it easy to see what's going on, so I could fix this simple problem in the 3 seconds it deserves, instead of the 3 hours I have to charge my client for doing nothing useful?

Oh, I know. It's really hard because it's an async call over http, and the mean ol' internet makes it hurt your brain. But guess what? You're Microsoft. You have unlimited time and money. And you impact millions of people. When you screw around with this kind of s**t, like you do with thousands of scenarios where you just couldn't be bothered, you affect hundreds of thousands of developers across the planet.

Look around on StackOverflow. See how many people across the globe, smart people trying to write software to do useful important things, who are just not immersed in the incredible minutia like the above because, you know, they have real work to do.

Multiply my 3 hours on this stupid problem times tens of thousands of developers time 30-40 episodes of this sort of crap in a typical year, and you see what catastrophes you cause. That's fine to say "that's why we get paid the big bucks", but think about what actual good work we could all be accomplishing in the world if every time we turn around we didn't have to dive down a 3-hour s**t-hole you dug for us?

Microsoft, you are bad for programming, bad for business, and bad for humanity. I don't care how many computers run your software. You need to do better. Please start acting like you understand just how much you abuse minions of hard-working people in the world, in every country, every single day. And how much better a place you could make it if you just acted like it mattered to do things right.

Tim Johnson