Name cannot begin with the '<' character, hexadecimal value 0x3C

Name cannot begin with the '<' character, hexadecimal value 0x3C

Old forum URL:

tbaldridge posted on Wednesday, June 01, 2011

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:


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;
        // 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.

RockfordLhotka replied on Wednesday, June 01, 2011

I haven't seen that exception. Do you have the full stack trace? With any luck that'll reveal some more useful information.

tbaldridge replied on Wednesday, June 01, 2011

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] 


RockfordLhotka replied on Wednesday, June 01, 2011

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 ( 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.

JonStonecash replied on Thursday, June 02, 2011

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

StefanCop replied on Monday, October 17, 2011

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. 


StefanCop replied on Monday, October 17, 2011

See this post:

Copyright (c) Marimer LLC