Develop Reference

Getting IIS HTTPERR Request_Cancelled errors for ASP.Net Web API

This is happening very randomly and very sporadically. The only thing that we can find is that IIS HttpErr is giving a Request_Cancelled error.
We are using ASP.Net Web API and nothing is writing to the error logs and no methods are getting any exceptions.
The client connects to our web api using a post call. Is there any way to capture or at least get in more detail this "Request_Cancelled" error?
I read something about a TraceListener but I cannot get this to work. NOthing writes to the log file on IIS.
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
// etc.
config.EnableSystemDiagnosticsTracing();
// etc.
}
}
<configuration>
<system.diagnostics>
<trace autoflush="false" indentsize="4">
<listeners>
<add name="myListener"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="E:\CompressedLogs\Service1-WebApi-TraceOutput.log" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
</configuration>

Casting to an invalid enum value results in unspecified exception on clientside

I know that casting an integer to an invalid enum value does not result in an exception in C# due to Flags. Here I was, specifying a table in a DB table and getting its values 1-3 with EntityFramework. On my serverside I cast the values into an enum XyzType ranging from 0-2, which obviously generates the invalid value (XyzType)3. Now i put this value in a XyzDTO and send it to a WCF client. Which upon deserialization fails with this very vague description:
Now i've read some other posts discussing exceptions caused by deserializing invalid XML and it all makes sense.
My question is, how come I did not get any useful information as to what the cause was at all? I spent the last 1.5 hours with this bug, until i figured the difference between the enum and the DB values. Is it considered a flaw in the WCF error handling that no useful info was given? If so, should MS be notified? Do you have any good practices as to how to avoid scenarios like this in the future?
EDIT: Please note i do not have a web.config. My serverside is a WCF service within a windows service, ie. i have app.config.
EDIT2: There seems to me some misunderstanding regarding this issue and what ive tried. Inspecting the InnerExceptions of the CommunicationException in the debugger provides no useful information at all. Also i already have "includeExceptionDetailsInFaults" = true on serverside, but the exception is not thrown by the serverside! It is caused during deserialization on clientside.
EDIT3: Some answers have suggested activating tracing on clientside. I have now attempted this, but apparantly for this issue it does not provide any useful information either. Here is a link to the output.

When discussing enums and WCF, ensure the values are serialized/deserialized by marking up the enum with the DataContract and EnumMember attributes as follows:
[DataContract(Namespace = Namespaces.V1)]
public enum AreaType : int
{
[EnumMember]
Unknown = 0,
[EnumMember]
Urban = 1,
[EnumMember]
Suburban = 2,
[EnumMember]
Rural = 3
}
It seems obvious, but also be aware that the default value is 0. As khlr mentioned, you can activate tracing. You will want to set the customErrors mode to "Off" and compilation for debug to "true" in your web.config while in Development.
<system.web>
<compilation debug="true" />
<customErrors mode="Off" />
</system.web>
Once you've moved off development, you'll want to provide a custom error page and set debug="false".
<system.web>
<compilation debug="false" />
<customErrors mode="RemoteOnly" defaultRedirect="ErrorRedirectPage.html" />
</system.web>
You'll also want to give some thought and design consideration to exception handling. You'll need to ensure you do not lose info. on the exception if you're rethrowing the exceptions. I like to use a simple logging framework, such as NLog, to log the exception, then I'll rethrow the exception back to the original method in the service where I wrap the exception in a FaultException where T is a class that I create for serializing and holding exception information. For example:
[DataContract(Namespace=Namespaces.V1)]
public class MyFaultException
{
[DataMember]
public string Reason { get; set; }
public MyFaultException()
{
this.Reason = "Service encountered an error";
}
public MyFaultException(string reason)
{
this.Reason = reason;
}
}
And in my service method:
try
{
//...
}
catch (Exception ex)
{
// Asynchronously log the error message in a helper class using NLog
LogHelper.LogException(ex, "Error calculating blah.", LogLevel.Error);
throw new FaultException<MyFaultException>(
new MyFaultException(ex.Message), new FaultReason(ex.Message));
}
You might want to define your own classes that derive from Exception to throw your own exceptions.

It's almost always a good idea to activate tracing to get some more detailed informations about the error:
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
You can configure tracing in your server's and client's web- or app.config files to get details from both sides.
Edit:
<serviceDebug includeExceptionDetailInFaults="true" /> makes your service transport an occured exception (see here for more details) to the client. If the client doesn't handle that fault, you might won't notice it.

You're having problems with serialization/deserialization and as others already suggested you need more logging. And you've enabled some of it, but not all and not specific for serialization.
Try to use following config for logging:
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="traceListener" />
</listeners>
</source>
<source name="System.Runtime.Serialization"
switchValue="Information">
<listeners>
<add name="traceListener" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</sharedListeners>
</system.diagnostics>
<system.serviceModel>
<diagnostics>
<messageLogging
logEntireMessage="true"
logMessagesAtServiceLevel="true"
maxSizeOfMessageToLog="16777216"/>
</diagnostics>
</system.serviceModel>
</configuration>
Here I added two additional trace sources (and enabled message logging): System.Runtime.Serialization will produce any errors (if any) regarding serialization/deserialization process. And message logging will help you understand whether you receive anything on client side.
From callstack in the log you've published it's clear to me that exception happens on the server side. But message logging will show this better.

If you want to use Enum in WCF, you need to define 0 value for Enum. It is very important.
public enum MyEnum{
Default = 0,
SomeValue1 = 1,
SomeValue2= 2,
....
}

Saving Trace data to storage not working in Azure after publishing but working in Dev environment

This is the code I use in my WebRole OnStart method:
var config = DiagnosticMonitor.GetDefaultInitialConfiguration();
DiagnosticMonitorTraceListener tmp = new DiagnosticMonitorTraceListener();
System.Diagnostics.Trace.Listeners.Add(tmp);
//config.Logs.BufferQuotaInMB = 200;
config.Logs.ScheduledTransferPeriod = TimeSpan.FromSeconds(30.0);
DiagnosticMonitor.Start("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString", config);
System.Diagnostics.Trace.Write("Test");
0This is my configuration in my web.config:
<trace>
<listeners>
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=2.3.0.0, Culture=neutral, PublicKeyToken=xxxx"
name="AzureDiagnostics">
<filter type="" />
</add>
</listeners>
</trace>
Using Above Code i am able to write trace statements on azure storage table executing from my local envt. but after publishing, trace statements are not written on azure storage table.

This is because your OnStart method runs in WaIISHost.exe, and your web.config is configuring w3wp.exe. This means that your OnStart code has no trace listener defined. You can do a search for 'DiagnosticMonitorTraceListener OnStart' and find several solutions. In general the options are:
Add the following code to your OnStart:
System.Diagnostics.Trace.Listeners.Add(new Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener());
Add the <listeners> element to your app.config in addition to your web.config.

Regarding Enable Tracing in WCF

i go through this msdn link http://msdn.microsoft.com/en-us/library/ms733025%28v=vs.110%29.aspx
here is the full settings
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="CardSpace">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.IO.Log">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.Runtime.Serialization">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.IdentityModel">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\log\Traces.svclog" />
</sharedListeners>
</system.diagnostics>
</configuration>
but do not understand
why so many source & listener tag what is the meaning of having multiple source & listener tag ??
if possible please explain regarding multiple source & listener tag in config setting.
another point is
i enable the tracing but saw no file was created in this folder c:\log\Traces.svclog
so someone advise me that run the apps with admin privileged. when i distribute my apps to anyone then how do i know the person has admin privileged or not?
guide me. thanks

Most of your questions are answered inside the linked article
System.ServiceModel.MessageLogging: Logs all messages that flow through the system.
System.Runtime.Serialization: Logs when objects are read or written.
etc. You can log different information on different trace level (e.g. errors to database, warnings to xml file).
to another point:
You can for example request admin context as asked and answered here How to request administrator permissions when the program starts?

OK, so you have different sources because you may want to log problems/messages in different portions of the program. Most inportant for a WCF web service is the System.ServiceModel since that's going to capture the WCF in/out traffic, but you might also want to log trouble with your serialization, IO or IdentityModel (authentication/Authorization). So based on your config, you've got five sources all of which will be using the shared listener, named XML, which will log your text. That's what's going on here in a nutshell, but there's more.
"Can't see c:\log\Traces.svclog" ... if your WCF service is running and responding to requests, you should see something. If not, make sure you're running your service as "administrator", or the ID underwhich you're running your servce has read/write access to the folder.
"When i distribute my apps to anyone then how do i know the person has admin privileged or not?" OK, yes, I can see this as an issue. Here's a block of code, setting a boolean, you could use to 1) determine if the program is run as "admin", and if not B) instruct the user to re-start the program under the proper "admin" rights:
private void GetServicePermissionLevel()
{
bool bAdmin = false;
try {
SecurityIdentifier sidAdmin = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null);
AppDomain myDomain = Thread.GetDomain();
myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
WindowsPrincipal myPrincipal = (WindowsPrincipal)Thread.CurrentPrincipal;
if (myPrincipal.IsInRole(sidAdmin)) {
bAdmin = true;
} else {
bAdmin = false;
}
} catch (Exception ex) {
throw new Exception("Error in GetServicePermissionlevel(): ");
} finally {
_ServiceRunAsAdmin = bAdmin;
}
}
Also, if you're trying to debug host-side problems in your WCF service, you might want to turn on this parameter for your web host interface: IncludeExceptoinDetailsInFaults = True. It's false by default, but if you set this to true to expose more information about WCF service faults, make sure you turn it off before going to production.
Here's an additional URL to consider for your setup: http: //www.topwcftutorials.net/2012/06/simple-steps-to-enable-tracing-in-wcf.html

Best way to log errors in WCF

What's the best way to catch and log errors when developing a WCF service layer, and why?
I can think of three ways,
1) Manual try/catches around each method.
2) Leave the responsibility to the WCF engine.
3) Use a third party library such as Enterprise Library Policy Injection/Logging.

I would implement custom IErrorHandler and use log4net
[AttributeUsage (AttributeTargets.Interface)]
public class ErrorPolicyBehaviorAttribute : Attribute, IContractBehavior, IErrorHandler
{
private ILog m_logger;
#region IErrorHandler
public void ProvideFault (Exception error, MessageVersion version, ref Message fault)
{
return;
}
public bool HandleError (Exception error)
{
m_logger.Error (error.Message, error);
return true;
}
#endregion
#region IContractBehavior
public void ApplyDispatchBehavior (ContractDescription contractDescription, ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)
{
...init logger
......Add this class to a list of dispatchRuntime.ChannelDispatcher.ErrorHandlers...
}
#endregion
}
This class also implements IContractBehavior, so you can use it as Attribute on your service contracts.
[ErrorPolicyBehavior]
public interface IYourServiceContract
{ }
log4net is quite flexible, so you can log what you need and when you need.

WCF can be configured to output traces for process milestones across all components of the applications, such as operation calls, code exceptions, warnings and other significant processing events.
The following is an app.config example to enable tracing.
<configuration>
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Warning" propagateActivity="true" >
<listeners>
<add name="xml"/>
</listeners>
</source>
<source name="myUserTraceSource" switchValue="Warning, ActivityTracing">
<listeners>
<add name="xml"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="TraceLog.svclog" />
</sharedListeners>
</system.diagnostics>
</configuration>
You can read more about WCF Tracing from MSDN: Configuring Tracing.
Microsoft provides a Service Trace Viewer Tool to read .svclog files.
Apart from tracing, you may also want to consider using log4net for in-application logging.

If you are asking for logging framework ELMAH is also a good option to consider. If you dont like to litter your code with try/catch around each method, you can try using AOP frameworks which would give you the ability to handle exceptions by marking the method with Attributes

It might be worth your while to check out log4net. There is a good tutorial here on CodeProject.

I would go with number 1. Mainly because of reduced overhead over number 3 and number 2 should just be a no-no.
Granted you still want to log to something say like a file or event manager. But I personnally would use log4net for it since it's a bit lighter than all the entlib stuff.