A catastrophic failure when impersonating another user

Question

I am using an Enterprise Health Validator integrated with WCF. It reports System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) when I impersonate another user using the WIN32 API LogonUser and WindowsIdentity.Impersonate. It seems that something is wrong when you need to get security evidence when loading the configuration. If I remove the avatar coding, it works without errors. This is 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() 

Answer 1

It seems to me that the problem is that System.Configuration represents itself when loading app.config. I was able to get around this problem by running

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

until he pretends to be an avatar. This led to the subsequent impersonation succeeding.

EDIT. To clarify things a bit, I suggest that this causes app.config to load and cache into memory, so the code path that causes the problem runs only once with the original credentials.

Answer 2

After a long battle and many ProcMon captures, I found that under certain conditions there is a failure when checking security zones during interaction and when issuing them. This is due to this KB:

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

If you mark where the node registry and key are added, instead of adding w3wp.exe as directed, add the file name of your own executable file. It worked for me - YMMV.

Answer 3

See my answer to this question in this thread on MS forums:

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

This is the thread header: The connection pool randomly throws COM exceptions.

You can search for text on the LogonUser page.