KB5011564 causing XSD validation error

Question

We've started getting errors with our .NET service from 2 different systems owned by different clients. The error started after these clients installed this KB5011564 https://support.microsoft.com/en-us/topic/march-8-2022-kb5011564-monthly-rollup-11b5486b-9c6a-4a83-97b1-5d697e014a6d

The stack trace for both systems are identical:

Client 1

System.Xml.Schema.XmlSchemaException: Type 'http://schemas.microsoft.com/sqlserver/2004/sqltypes:bigint' is not declared.
at System.Xml.Schema.XmlSchemaSet.InternalValidationCallback(Object sender, ValidationEventArgs e)
at System.Xml.Schema.BaseProcessor.SendValidationEvent(XmlSchemaException e, XmlSeverityType severity)
at System.Xml.Schema.Compiler.CompileElement(XmlSchemaElement xe)
at System.Xml.Schema.Compiler.CompileParticleElements(XmlSchemaComplexType complexType, XmlSchemaParticle particle)
at System.Xml.Schema.Compiler.CompileParticleElements(XmlSchemaComplexType complexType, XmlSchemaParticle particle)
at System.Xml.Schema.Compiler.CompileComplexTypeElements(XmlSchemaComplexType complexType)
at System.Xml.Schema.Compiler.Compile()
at System.Xml.Schema.Compiler.Execute(XmlSchemaSet schemaSet, SchemaInfo schemaCompiledInfo)
at System.Xml.Schema.XmlSchemaSet.Compile()
at XXX.Integration.Services.RequestMessageParser.ParseXmlString(String xml) in C:\Source\XXX.Integration.Services\RequestMessageParser.cs:line 57
--- End of inner exception stack trace ---

Client 2

System.Xml.Schema.XmlSchemaException: Type 'http://schemas.microsoft.com/sqlserver/2004/sqltypes:varchar' is not declared, or is not a simple type.
at System.Xml.Schema.XmlSchemaSet.InternalValidationCallback(Object sender, ValidationEventArgs e)
at System.Xml.Schema.BaseProcessor.SendValidationEvent(XmlSchemaException e, XmlSeverityType severity)
at System.Xml.Schema.Compiler.CompileElement(XmlSchemaElement xe)
at System.Xml.Schema.Compiler.CompileParticleElements(XmlSchemaComplexType complexType, XmlSchemaParticle particle)
at System.Xml.Schema.Compiler.CompileParticleElements(XmlSchemaComplexType complexType, XmlSchemaParticle particle)
at System.Xml.Schema.Compiler.CompileComplexTypeElements(XmlSchemaComplexType complexType)
at System.Xml.Schema.Compiler.Compile()
at System.Xml.Schema.Compiler.Execute(XmlSchemaSet schemaSet, SchemaInfo schemaCompiledInfo)
at System.Xml.Schema.XmlSchemaSet.Compile()
at XXX.Integration.Services.RequestMessageParser.ParseXmlString(String xml) in C:\Source\XXX.Integration.Services\RequestMessageParser.cs:line 57
--- End of inner exception stack trace ---

The only difference is the specific data type that "is not declared". In this case, that is only important because each client has a slightly different data format, and the error is on the first element. Client 1's first element is a bigint, and client 2's is a varchar.

Here is the top portion of the schema for one of the clients:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sqltypes="http://schemas.microsoft.com/sqlserver/2004/sqltypes" targetNamespace="urn:xx.xxx.com" elementFormDefault="qualified" xmlns="">
  <xsd:import namespace="http://schemas.microsoft.com/sqlserver/2004/sqltypes" schemaLocation="http://schemas.microsoft.com/sqlserver/2004/sqltypes/sqltypes.xsd"/>
  <xsd:element name="r">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="entity_id" nillable="1">
          <xsd:simpleType>
            <xsd:restriction base="sqltypes:varchar" sqltypes:localeId="1033" sqltypes:sqlCompareOptions="IgnoreCase IgnoreKanaType IgnoreWidth" sqltypes:sqlSortId="52">
              <xsd:maxLength value="10"/>
            </xsd:restriction>
          </xsd:simpleType>
        </xsd:element>

In our application, SQL Server is creating queue message conversations which our Windows service is reading, parsing, and syncing with an outside service. The structure of the SQL Server messages has not changed. It is identical to the messages created by SQL Server for years.

Both of these clients are on Windows Server 2012 which is what this KB applies to.
Both clients are currently on the same version of .NET Framework - 4.8.03761

I have not been able to find any specific problems related to this listed in the KB description. But it seems like a awful coincidence that both clients began presenting the error at the same time shortly after this .NET Framework update. We have had no code changes, or patches, or updates to our Windows service for these clients in over a year. There have been no other configuration or application changes that should have caused this error.

As far as our code, this is how we're loading the schema:

XElement schemaParse = getTheSchemaDefinition();
var schemaSet = new XmlSchemaSet();
var schema = XmlSchema.Read(new StringReader(schemaParse.ToString()), (sender, args) => { throw new InvalidOperationException("Unable to validate the schema", args.Exception); });
schemaSet.Add(schema);
schemaSet.Compile();

This piece of the code has been unchanged in our product for over 5 years. We also have about 2 dozen clients with other versions of Windows and Windows Server running the service without any issues right now.

Right now, we're trying to figure out a work around. The closest thing I've been able to find is some .NET Core conversations around how it is possible for the "schemaSet.Add(schema);" to succeed but only because it's just structurally validates the schema. It doesn't try to validate it against the XSD until the "Compile()" step. I found that discussion here: https://github.com/dotnet/runtime/issues/48005#issuecomment-879421329

But I haven't found a way for this information to be useful for us yet.

Is this a problem with the KB update? Has some kind of security requirement changed how the schemas are validated? What code or configuration do we need to add to prevent this error?

Thank you.

Answer 1

Here is the shortest code which mimics our system and produces the error:

string xml = @"
    <RequestMessage>
        <meta id=""1"" name=""data0""/>
        <query>
            <xsd:schema xmlns:xsd=""http://www.w3.org/2001/XMLSchema"" xmlns:sqltypes=""http://schemas.microsoft.com/sqlserver/2004/sqltypes"" targetNamespace=""urn:xx.xxx.com"" elementFormDefault=""qualified"" xmlns="""">
                <xsd:import namespace=""http://schemas.microsoft.com/sqlserver/2004/sqltypes"" schemaLocation=""http://schemas.microsoft.com/sqlserver/2004/sqltypes/sqltypes.xsd""/>
                <xsd:element name=""r"">
                    <xsd:complexType>
                        <xsd:sequence>
                            <xsd:element name=""id"" type=""sqltypes:bigint"" nillable=""1""/>
                        </xsd:sequence>
                    </xsd:complexType>
                </xsd:element>
            </xsd:schema>
        </query>
        <r xmlns=""urn:xx.xxx.com"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"">
            <id>438547</id>
        </r>
    </RequestMessage>";

string elementToFind = "xsd:schema";
List<XElement> schemaElements = new List<XElement>();

var settings = new XmlReaderSettings();
settings.IgnoreWhitespace = true;
using (var reader = XmlReader.Create(new StringReader(xml), settings))
{
    while (reader.Name.Equals(elementToFind, StringComparison.InvariantCultureIgnoreCase) || reader.ReadToFollowing(elementToFind))
    {
        schemaElements.Add((XElement)XNode.ReadFrom(reader));
    }
}

//Build and validate the schema set
string schemaXml = schemaElements.First().ToString();
XmlSchemaSet schemaSet = new XmlSchemaSet();
XmlSchema schema = XmlSchema.Read(
    new StringReader(schemaXml),
    (sender, args) =>
    {
        throw new XmlSchemaException("Unable to validate the schema", args.Exception);
    }
);
schemaSet.Add(schema);
schemaSet.Compile();

We've figured out that this has to do with TLS security for some reason. Adding the following line to the top of the code caused it to work in our tests:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

However, this did not work on our client's Windows Server 2012 R2 server. We had to create a workaround where we added the sqltypes.xsd to the local service directory then "hacked" the incoming XML text and replaced

schemaLocation="http://schemas.microsoft.com/sqlserver/2004/sqltypes/sqltypes.xsd"

with

schemaLocation="file:///c:/path/to/service/directory/sqltypes.xsd"

While I initially believed that it was the KB since both affected servers both stopped working shortly after it was installed, I'm now wondering if Microsoft recently updated the servers for schemas.microsoft.com to longer accept connections from older versions of TLS.