.Net 4.6 Service Reference call fails with "maximum nametable character count quota" error

Question

I'm getting the error message "The maximum nametable character count quota (16384) has been exceeded while reading XML data.... Line 3, position 435." on a call to a commercial SOAP web service. But the actual data returned is not exceeding any count of any kind -- it is 2k of perfectly valid XML, and there is no character 435 on line 3, or on any other line. The error message makes no sense.

I've seen other questions about this error message on stackoverflow, but they're generally of the kind where the error actually means what it says, and the correct solution is to raise the length limit in question. That is not the case here.

Background: for years, our web app has used a commercial vendor's web service to process payments. And the WSDL/XSD specification we've used to define our interface to it is now many versions out of date, but still works. We are now trying to use their current WSDL and XSD, so that we can take advantage of recent features. But once I regenerate the service interface from the modern layout, it doesn't work anymore -- it produces the "maximum nametable character count" error, wrapped in an XML parsing exception.

After hours of struggle, I managed to attach an IClientMessageInspector class to the service, so I could log the content of the SOAP requests and responses. You might imagine how baffled I was when I saw that the response was not some kind of badly-formed server error message that couldn't be parsed, but a short and simple XML response indicating a successful transaction, much like those we had always been receiving.

My last desperate hope was to use Visual Studio's disassembly debugging to step to the place where the error was being thrown, and try to see what kind of input it was actually failing on, but alas, Visual Studio keeps skipping over that code -- it refuses to step through it even though "own code" is turned off.

The stack trace of the inner exception reads:

at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3)
at System.Xml.XmlExceptionHelper.ThrowMaxNameTableCharCountExceeded(XmlDictionaryReader reader, Int32 maxNameTableCharCount)
at System.Xml.XmlBaseReader.QuotaNameTable.Add(Int32 charCount)
at System.Xml.XmlBaseReader.QuotaNameTable.Add(String value)
at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderITransactionProcessor.InitIDs()
at System.Xml.Serialization.XmlSerializationReader.Init(XmlReader r, XmlDeserializationEvents events, String encodingStyle, TempAssembly tempAssembly)
at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)

This is wrapped in an InvalidOperationException which says "There is an error in XML document (3, 436)" with this trace:

at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
at System.ServiceModel.Dispatcher.XmlSerializerOperationFormatter.DeserializeBody(XmlDictionaryReader reader, MessageVersion version, XmlSerializer serializer, MessagePartDescription returnPart, MessagePartDescriptionCollection bodyParts, Object[] parameters, Boolean isRequest)

and that in turn is wrapped in a CommunicationException saying "Error in deserializing body of reply message for operation 'xxxx'."

I have no idea how to proceed. I cannot connect the error message with anything accessible to analysis. What could cause this?

Answer 1

Increase the maxNameTableCharCount on your client side in the config:

<readerQuotas maxDepth="32" 
              maxStringContentLength="5242880" 
              maxArrayLength="16384" 
              maxBytesPerRead="4096"
              maxNameTableCharCount="5242880"/>

The reader quota settings only apply to the client (or service) - basically whichever side is using that config.

The size of the XSDs may be why the increased size is necessary - MSDN documentation isn't real clear on what that property does, so this is a semi-educated guess :)