Feb
3
2009
I spend the last four days on solving a problem I had with a WCF service. The message I got was really clear; the client authenticates anonymously while the server expected Windows authentication.
[MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'.]
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
+7594687System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
+275RssService.IRssService.GetChannels()
+0RssService.RssServiceClient.GetChannels()
+15RSS.ShowChannels()
+63RSS.Page_Load(Object sender, EventArgs e)
+48System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
+14System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
+35System.Web.UI.Control.OnLoad(EventArgs e)
+99System.Web.UI.Control.LoadRecursive()
+50System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
+627
The weird part is that the client, the web site is was working on is set up to use Windows authentication and the WCF service is running under Anonymous authentication. So how is it possible that I get an error message that seems to say the opposite.
Searching the net only gave me similar messages but all of them were in the "correct" order. The books and articles gave me a better understanding about how bindings work and so on but none of the changes I made to the configuration files.
Then I ran into a book which talked about two tools; SvcConfigEditor.exe and SvcTraceViewer.exe both are typically located in C:\Program Files\Microsoft SDKs\Windows\V6.0A\bin. How could I forget about those tools as I had seen them before, just never used it…
The SvcConfigEditor.exe
This tool allows you to edit configuration files which contain the end-points and bindings used either by the client connecting to the service or the WCF service itself.
The tool allows a more controlled way of adding endpoints, choose the bindings, and binding configuration. Not only that, the tool can also be used to setup message and transport level tracing while diagnosing a problem. You can read more about it @ http://msdn.microsoft.com/en-us/library/ms732009.aspx
The SvcTraceViewer.exe
The SvcTraceViewer.exe tool allows you to view the message and transport level log files generated after activating the tracing with the SvcConfigEditor tool. The viewer provides a great deal of information about what happened during the Service request, if you configure tracing on both the client and service side you can get a pretty good understanding of what your problem might be... at least better than the cryptic error messages presented on a web page. You can read more about the trace viewer @ http://msdn.microsoft.com/en-us/library/ms732023.aspx
Solving the problem
In my case after learning about these tools I was able to solve my problem in just about 10 minutes. After turning on the transport and message tracing on both the client and the service, I noticed that the service log files were never created, thus the client never reached the service even though the error message seemed to indicated that there is some connection established. Looking closer at the info in the transport log files of the client...duh... it said, "server doesn't exist or server not available".... copied the URL from the endpoint in a browser and..... "file not found".... a good old typo.
Lesson learned
Had I known more about WCF and the tools that come with it, I might have had it solved right away. So if you are working with WCF and you didn't know about these tools, please take a look it might just save you a lot of diagnostic time.