XmlSchema.Read gives COMException "Catastrophic failure"

StackOverflow https://stackoverflow.com/questions/23603701

  •  20-07-2023
  •  | 
  •  

Question

I've got a utility class with a few method relating to XML schemas. Without any code changes nor any know changes to the environment, it has suddenly started to fail systematically.

The method that fails:

public static XmlSchema GetSchema(string xsdFileName)
{
    string path = MyConfiguration.XmlSchemaLocation;
    if (!path.EndsWith(@"\"))
    {
        path += @"\";
    }

    path += xsdFileName;
    return XmlSchema.Read(File.OpenRead(path), null);
}

The stack trace shows XmlSchema.Read is internally attempting to construct a Parser object, and the constructor of this attempts to read some configuration, and this in turn leads to some policy evidence being examined, and then it blows up with a COMException with an error code which, if I understand this correctly, provides no more information than the error being unexpected!

Here's the exception:

System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))
   at System.Security.Policy.PEFileEvidenceFactory.GetLocationEvidence(SafePEFileHandle peFile, SecurityZone& zone, StringHandleOnStack retUrl)
   at System.Security.Policy.PEFileEvidenceFactory.GenerateLocationEvidence()
   at System.Security.Policy.PEFileEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.AssemblyEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   at System.Security.Policy.Evidence.GetHostEvidence(Type type, Boolean markDelayEvaluatedEvidenceUsed)
   at System.Security.Policy.AppDomainEvidenceFactory.GenerateEvidence(Type evidenceType)
   at System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   at System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext()
   at System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext()
   at System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String& typeName)
   at System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath)
   at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
   at System.Configuration.ClientConfigurationHost.RequireCompleteInit(IInternalConfigRecord record)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Configuration.ConfigurationManager.GetSection(String sectionName)
   at System.Xml.Schema.Parser..ctor(SchemaType schemaType, XmlNameTable nameTable, SchemaNames schemaNames, ValidationEventHandler eventHandler)
   at System.Xml.Schema.XmlSchema.Read(XmlReader reader, ValidationEventHandler validationEventHandler)
   at MyProj.Common.XSDValidator.GetSchema(String xsdFileName)
   at ...

Any idea how to investigate this further? Does anyone know what kind of thing may have caused this to start happening (e.g. a corrupt user profile for the identity under which the process is executing)?

This has happened in a production envioronment and I really have no idea how to proceed to figure out what has caused it, or to fix it.

In case it's relevant: The code is hosted in a console application. Note that the code has successfully accessed configuration shortly before it blows up. (The "MyConfiguration" class is another utility class that is basically a thin layer encapsulating a bunch of appSettings keys that uses the ordinary System.Configuration.ConfigurationManager class.)

Windows version:

OS Name:                   Microsoft® Windows Server® 2008 Datacenter
OS Version:                6.0.6002 Service Pack 2 Build 6002
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Member Server
OS Build Type:             Multiprocessor Free
Was it helpful?

Solution

The program was being executed via Task Scheduler. The instances that failed were running under minimum priveliges.

I reckon a SecurityException with a sensible description would have made more sense, but once the scheduled task was configured to run as a more priveliged process, the problem disappeared.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top