Catastrophic failure when Impersonate other user

Question

I'm use Enterprise library Validation block intergrated with WCF. It reports System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) when I impersonate some other user with WIN32 API LogonUser and WindowsIdentity.Impersonate. It seems there is something wrong when to get security evidence on loading configuration. If I remove the coding of impersonation, it works without any errors. These are the part of the exception stack trace, hope you give some helpers. thanks.

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.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   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.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   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.CreateConfigurationContext(String configPath, String locationSubPath)
   at System.Configuration.Internal.DelegatingConfigHost.CreateConfigurationContext(String configPath, String locationSubPath)
   at System.Configuration.BaseConfigurationRecord.get_ConfigContext()

Enthrone

fyi - similar: https://mcmap.net/q/1469061/-xmlschema-read-gives-comexception-quot-catastrophic-failure-quot – Lillis

Answer 1

It looks to me like the problem is that System.Configuration does impersonation itself when loading app.config. I was able to work around this issue by running

ConfigurationManager.GetSection("system.xml/xmlReader");

while not impersonating. Doing so caused the later impersonation to succeed.

EDIT: To clarify slightly, I believe that doing this causes app.config to be loaded and cached into memory, so the code path which causes the problem is executed only once and with the original credentials.

Moderation

Thanks, this fixed things for me. This must be a bug in .NET 4.x ... at least in 4.5.1. It doesn't happen with .NET 2.0. I get the problem when attempting to set an XmlElement property value. However, if I create a new XmlDocument().CreateElement("Test"), set the property to that value, then set it to what I meant to set it to, it works. Very odd. – Nosey

This also fixed this problem for me, using .Net 4.6. I added "System.Configuration.ConfigurationManager.GetSection("dummy");" to the Main method in my console app, before I call LogonUser, WindowsIdentity.Impersonate and the SqlConnection constructor. I do not even have an exe.config file, and the exception was still being raised. The fix works with or without an exe.config. – Donough

@RichardAnthonyFreeman-Hein I'm having the same issue here - #73541168 How this fix works for me? Can you help me in this? – Trask

@Trask Sorry I am not sure, this was so long ago. – Nosey

Answer 2

After a long battle and many ProcMon captures, I have discovered that under some conditions, there is a failure when checking Security Zones during interop and while impersonating. It is related to this KB:

https://support.microsoft.com/en-us/kb/945701?wa=wsignin1.0

If you check the end where a registry node and key are added, instead of adding w3wp.exe as directed, add the filename of your own executable. This worked for me - YMMV.

Gilmer

Answer 3

I am sharing this piece of code in a hope that would help future readers. It letterly helped me to get out of a 3-hour headache :)

        //This is an important line to write while impersonating.
        //It will allow SQL server connections to happen otherwise connection strings will error out.
        ConfigurationManager.GetSection("SqlColumnEncryptionEnclaveProviders");

        //Do the impersonation
        var credentials = new UserCredentials(DomainName, AccountName, Password);
        Impersonation.RunAsUser(credentials, LogonType.Interactive, () =>
        {
            //Your code here inside impersonation . . .
        });

Stenosis

Answer 4

Please see my response to this on this thread in the MS forums:

http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataproviders/thread/b5b7a179-3737-4380-b6cf-843f3e71b317/

This is the thread title: Connection Pooling randomly throwing COM exceptions.

You can search the text on the page for LogonUser.

Allrud

seems unrelated. The only common thing is "some problem with impersonation". The thread you pointed out is focused on handling LogonUser and handles. We have nothing such here. Here we have some problem with ConfigurationManager trying to do the impersonation under the hood just before reading the file and failing at it, probably because the process does not have priviledges to do the impersonation at all due to being ran as, i dont know, limited-user, non-interactive, etc. – Lillis