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()

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.

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.