In general, we try to write software that doesn't throw a lot of exceptions. We recently noticed a very odd set of exceptions in our CSLA.NET based app. We're making requests from Silverlight. In our server-side code we recently started getting a ton of exceptions:
XmlException:
Name cannot begin with the '<' character, hexadecimal value 0x3C.
This is being thrown from within WcfProxy.Fetch:
ChannelFactory<IWcfPortal> cf = GetChannelFactory(); IWcfPortal svr = GetProxy(cf); WcfResponse response = null; try { // Error is thrown here....
response = svr.Fetch(new FetchRequest(objectType, criteria, context));
Execution continues on just fine, and we haven't seen any side effects of this error, but we'd rather not
get it. Any thoughts on how to remove this exception? We get around two dozen of these each time our
application starts-up.
I haven't seen that exception. Do you have the full stack trace? With any luck that'll reveal some more useful information.
In the actual exception, the stack trace only contains:
at System.Xml.XmlConvert.VerifyNCName(String name, ExceptionType exceptionType)
And there is no inner exception.
However, the full Call stack from the debugger looks like this:
> Csla.dll!Csla.DataPortalClient.WcfProxy.Fetch(System.Type objectType, object criteria, Csla.Server.DataPortalContext context) Line 148 + 0x2b bytes C#
Csla.dll!Csla.DataPortal.Fetch(System.Type objectType, object criteria) Line 215 + 0x12 bytes C#
Csla.dll!Csla.Server.Hosts.Silverlight.SilverlightRequestProcessor.Fetch(Csla.Server.Hosts.Silverlight.SilverlightCriteriaRequest request) Line 146 + 0xc bytes C#
Csla.dll!Csla.Server.Hosts.Silverlight.WcfPortal.Fetch(Csla.Server.Hosts.Silverlight.CriteriaRequest request) Line 102 + 0xe bytes C#
[Lightweight Function]
System.ServiceModel.dll!System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(object instance, object[] inputs, out object[] outputs) + 0x2f5 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x137 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x5e bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x6c bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x89 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x59 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x3b bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x4e bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x125 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(ref System.ServiceModel.Dispatcher.MessageRpc rpc) + 0x34 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.MessageRpc.Process(bool isOperationContextSet) + 0xff bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(System.ServiceModel.Channels.RequestContext request, bool cleanThread, System.ServiceModel.OperationContext currentOperationContext) + 0x44b bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(System.ServiceModel.Channels.RequestContext request, System.ServiceModel.OperationContext currentOperationContext) + 0x127 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(System.IAsyncResult result) + 0x43 bytes
System.ServiceModel.dll!System.ServiceModel.Dispatcher.ChannelHandler.OnContinueAsyncReceive(object state) + 0x45 bytes
System.Runtime.DurableInstancing.dll!System.Runtime.IOThreadScheduler.ScheduledOverlapped.IOCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* nativeOverlapped) + 0x78 bytes
System.Runtime.DurableInstancing.dll!System.Runtime.Fx.IOCompletionThunk.UnhandledExceptionFrame(uint error, uint bytesRead, System.Threading.NativeOverlapped* nativeOverlapped) + 0x39 bytes
mscorlib.dll!System.Threading._IOCompletionCallback.PerformIOCompletionCallback(uint errorCode, uint numBytes, System.Threading.NativeOverlapped* pOVERLAP) + 0x74 bytes
[Native to Managed Transition]
[Appdomain Transition]
[Native to Managed Transition]
Not super helpful :)
But it does indicate that the origination of the exception if from WCF (System.ServiceModel) during the completion callback (if I read it correctly).
So it is quite possible that something is wrong with the byte stream coming back from the server.
Are you using compression? Have you maxed the various size limits for WCF on client and server? These are important, and are discussed in the FAQ (http://www.lhotka.net/cslanet/faq/DataPortalFaq.ashx) and in the Using CSLA 4: Data Portal Configuration ebook.
If you've done those things, the next step is probably to put fiddler on the wire so you can see what is going over the network.
I ran into something very similar when I was sending business objects across the wire thru the remote data portal. These objects had several automatic properties. For various reasons, these properties were not in the standard "registered CSLA properties format. The problem was that the names generated by the C# compiler for the internal field that supports each of the properties has a name that contains the "<" character that confuses serialization. I agree that exceptions should be addressed, if possible. I got around these exceptions by switching back to the "old style" properties with an explicit internal field. Not fun, but I did feel more righteous.
Jon Stonecash
I also recognized this "first chance exception" and narrowed the reason down to some auto property in our classes and ObservableBindingList AllowEdit, AllowNew and AllowRemove. Although this exception is caught be the .NET Framework itself, there are messages in VisualStudio's Output.
I also was unsure why an XML problem, because we use TCP binding. I analyzed the stack a bit in the debugger, and although im not a WCF expert, I got to the conculsion that some validation is made on XML base before or after the actual encoding (that I guessed from method names on the stack indicating something like "validate").
So, me too, back to the "old style" properties with an explicit internal field. That reduces the chatty messages a lot.
Stefan
See this post: http://forums.lhotka.net/forums/p/10511/50274.aspx#50274
Copyright (c) Marimer LLC