System.ServiceModel.CommunicationObjectFaultedException - c#

I am facing the following problem on one server only on another server or locally it is working properly.
I am using IIS6 Windows 2003. Is there any setting related problem?
System.ServiceModel.CommunicationObjectFaultedException: The
communication object, System.ServiceModel.Channels.ServiceChannel,
cannot be used for communication because it is in the Faulted state.
Server stack trace: at
System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan
timeout) Exception rethrown at [0]: at
System.Runtime.Remoting.Proxies.RealProxy.

You cannot use a channel that has been faulted. You will need to recreate a new channel.
My toolkit has inbuilt support for this so that you can seamlessly make another call to the channel. It handles this scenario internally.
See http://neovolve.codeplex.com/releases/view/53499.

First, we need to find out what the real problem or issue is. For this set includeExceptionDetailInFaults to true as below in you service App.Config file:
serviceDebug includeExceptionDetailInFaults="true"
Then you will get the real exception detail when you catch an exception. I was getting AccessDeniedException. So I ran this command from Power Shell:
netsh http add urlacl url=http://+:8080/ user=Domainxxx\UserNamexxx. Problem solved.

Related

WCF client has inconsistent behavior with multiple network interfaces

I have the WCF client shown below:
public static string Execute(string a)
{
WebHttpBinding b = new WebHttpBinding();
b.Security.Mode = WebHttpSecurityMode.Transport;
WebChannelFactory<IAnimalService> f = new WebChannelFactory<IAnimalService>(b, new Uri(a));
f.Endpoint.Behaviors.Add(new WebHttpBehavior());
IWebService client = f.CreateChannel();
return client.SayHello("moo");
}
I am testing the client (in a console host) against its counterpart service from 2 different computers (A, B) and and i get different outcome. Here are the similarities and differences between A and B:
Both A and B are Windows Server 2012 R2 have multiple network interfaces. And each of them have one interface connected to the Internet (so as to reach the service in question).
When running on machine A, everything works as expected i get expected response ("cow says 'moo'") in the client.
When running on machine B, i get different behaviours:
Via the web-browser (firefox), i can get to the service by constructing a request in the address bar. I can see the request going on the external network interface. And everything works as in 2 above.
Via the app (i.e. code above), i get the exception below and more over, when looking at the request in wireshark, it does not go on the external network interface. The exception comes the fact that on that network interface there is a proxy and the proxy is rejecting the request (X-Squid-Error -> ERR_ACCESS_DENIED 0).
Exception:
Unhandled Exception: System.ServiceModel.Security.MessageSecurityException: The HTTP request was forbidden with client authentication scheme
'Anonymous'. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden.
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
--- End of inner exception stack trace ---
I also consulted the routing table on machine B and it shows that request should have gone on the external network interface. I have assumed that the internal routing table would be consulted by the lower layer of the TCP-IP stack in order to forward the packet to the correct (network) medium.
So, I am wondering if someone would have an idea how i could get my client to pick the correct interface on machine B. I am not sure how to go about to troubleshoot the problem further. So any kind of advice/tips on how to get to the bottom of this situation on machine B would be most welcomed.
Try to use this snippet in you config file, so you will be able to use your default credentials to autenticate in the proxy server.
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
It would appear that by default, the binding seeks to look for the default proxy setting on machine B. Adding the following binding configuration solved the problem:
b.UseDefaultWebProxy = false;

In UWP applications, can I get the list of SSL certificate errors after establishing connection?

In a UWP application, I can set something like this to enable self-signed certificates when connecting StreamSocket to an SSL-enabled host:
streamSocket.Control.IgnorableServerCertificateErrors.Add(ChainValidationResult.InvalidName);
streamSocket.Control.IgnorableServerCertificateErrors.Add(ChainValidationResult.Untrusted);
await streamSocket.ConnectAsync(new HostName("localhost"), "993", SocketProtectionLevel.Tls12);
However, I would like to make it possible for the application to examine which errors actually occurred during the connection. I thought I'd use this:
streamSocket.Information.ServerCertificateErrors
However, this collection is empty in my tests. It only gets populated in case when streamSocket.Control.IgnorableServerCertificateErrors is empty and thus the connection is aborted with an exception. I would like to have the connection established (i.e. SSL errors ignored) but still have these errors recorded and available for the application (like I did before with SslStream and .NET Framework). Is it possible?
In my opinion, if we add ChainValidationResult.InvalidName and ChainValidationResult.Untrusted to the StreamSocketControl.IgnorableServerCertificateErrors before we run the StreamSocket.ConnectAsync method, it will ignore the SSL server errors. That we can not get any ChainValidationResult in StreamSocketInformation.ServerCertificateErrors.
We should be able to use the StreamSocket.ConnectAsync method without adding the ChainValidationResult.InvalidName and ChainValidationResult.Untrusted.
There is an official sample about StreamSocket, please refer the Certificates in Scenario5.
We should be able to use try-catch to catch the exception of the StreamSocket.ConnectAsync method. Then we can get the ChainValidationResult in StreamSocketInformation.ServerCertificateErrors and we can add the ChainValidationResult to the StreamSocketControl.IgnorableServerCertificateErrors. Also we should be able to use the StreamSocket.ConnectAsync again.

Windows Server can not use WCF Server

I can use this program on my own computer, but I can not use on the server.
Server use supreme authority Administrator to open the program.
Server WCF HTTP Activation Feature with .NET4.5 is opening.
Server endpoint address use "http://localhost" like following
endpoint address="http://localhost" binding="basicHttpBinding" bindingConfiguration="NewBinding0" name="ProductService" contract="ProductService.IWCFProductService"
Wrong Message:
The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.
Stack trace at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.System.IDisposable.Dispose()
at FileUtilityHelperService.Program.Main(String[] args)
This simply means that there has been an unexpected exception somewhere in your code. The error message "...because it is in the Faulted state" means that communication between the server and the client is unusable.
What you need is better error handeling.
Use try/catch around your code that can potentially generate an exception
Always order exeptions from the most specific to the least specific
You would probably like to log your errors to a file or database, log4net is great for this (and comes as a nuget package)

WCF service client application getting "Object not set to an instance of an object"

just deployed my WCF service on a server here at my company using IIS 7.5 and everything seems to work fine. But when i set up my client application and add a server reference to the server and then use this code .
ServerReference.ServiceClient client = new ServerReference.ServiceClient();
var s = client.GetBrand("Audi", false);
I get an exception that says "object reference not set to an instance of a object".
the s object should not b null (we tried the service on localhost where the we had it all in the same project where it worked).
You looked at the stackstrace and it looks like this.
21.6.2012 16:16:29
Object reference not set to an instance of an object.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Any suggestions ??
P.S The CPU where the WCF Service is hosted doesnt have visual studios so i cant debug through it
As I suggested in a comment, make sure you can get the data using WcfTestClient. This both confirms the service is working, and almost unit-tests the method call ensuring it's working from a client perspective.
Second, (unless you watered it down to post on SO) use the correct WCF call method as to avoid these kinds of problems. Once you introduce a dependency it's always a good idea to anticipate for failures (albeit your service, the client's internet connection, or otherwise).
Without knowing anything else about your project it's tough to describe how to fix it. Factors like old WSDL, misconfigured *.config, unexposed endpoint on server, and other issues could be the root of the problem but given what you've shown I have no idea which it could be.
If you can provide more information I'll be glad to update my answer with any more advice I may have. For now, have a look at enabling WCF tracing on the server so you can look back through the log(s) and see if anything is afoul on the server's end (in addition to stepping through your client's call and checking).
You don't have to debug thru it. Just add WCF tracing setup in the web.config and you can get information about the originating error. See http://msdn.microsoft.com/en-us/library/ms733025.aspx
I have the same problem in my project, in my case I found that the exception occurred in the service constructor but it's only triggered when I call any method.
Configure trace sources to emit traces and set trace levels, set activity tracing and propagation to support end-to-end trace correlation, and set trace listeners to access traces.
Windows Communication Foundation (WCF) outputs the following data for diagnostic tracing:
Traces for process milestones across all components of the applications, such as operation calls, code exceptions, warnings and other significant processing events.
Windows error events when the tracing feature malfunctions. See Event Logging in WCF.

CommunicationException with 'not recognized sequence' message in WCF

I get a CommunicationException while using WCF service. The message is:
The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted.
The exception is thrown in a moment after a contract method was called. Before calling contract method the channel state is Opened. I restore my service client after catching this exception and for some time it works fine. But then this error occures again. It seems like some timeout is exceeded, but I can't understand which one exactly.
I use wsHttpBinding with reliableSession enabled. The InactivityTimeout is set to half an hour and I'm sure it's not exceeded, because exception is thrown earlier.
I solved the problem. The reason was RecieveTimeout on a server side. It was set to 1 minute, so after having no requests during 1 minute server used to close a channel, and when client tried to call a contract, channel was already crashed due to the timeout.
I found the solution after reading this article:
http://msdn.microsoft.com/en-us/library/system.servicemodel.reliablesession.inactivitytimeout.aspx
I received this error while setting up a new WCF service which returned a list of objects.
My understanding is that WCF services can only pass very simple objects back n forth.
So objects with anything other than public properties will not be transferable.
The object had a read only property doing a bit of logic.
Once I got rid of this, rebuilt, and updated the web references, the error went away.
Tip:
If you're returning a object and it has properties check the gets and sets of each one.
We had a problem around it.
I have seen this happen when an application pool gets recycled.
Look at the very last section of this blog about service recycling .

Categories

Resources