다른 사용자로 가장 할 때 치명적인 오류가 발생했습니다.

저는 엔터프라이즈 라이브러리 유효성 검사 블록과 WCF를 통합했습니다. WIN32 API LogonUser 및 WindowsIdentity.Impersonate를 사용하여 다른 사용자를 가장 할 때 System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))이보고됩니다. 로딩 구성에 대한 보안 증거를 얻을 때 뭔가 잘못된 것 같습니다. 가장의 코딩을 제거하면 오류없이 작동합니다. 이것들은 예외 스택 추적의 일부입니다. 여러분이 도움을 줄 수 있기를 바랍니다. 감사.다른 사용자로 가장 할 때 치명적인 오류가 발생했습니다.

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

출처

2012-10-09 Leo Wong

fyi - 유사 항목 : https://stackoverflow.com/a/23650343/717732 – quetzalcoatl

-2

는 MS 포럼에서이 스레드에서이에 대한 내 대답을 참조하십시오

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

이 스레드 제목입니다 : 연결이 COM 예외를 던지는 무작위로 풀링.

LogonUser 페이지에서 텍스트를 검색 할 수 있습니다.

출처

2013-05-27 16:23:45 Brannon

과 관련없는 것처럼 보입니다. 유일한 공통점은 "명의 도용에 대한 문제"입니다. 지적한 스레드는 LogonUser와 핸들을 처리하는 데 중점을 둡니다. 우리는 여기에 아무것도 없습니다. 여기서 우리는 파일을 읽거나 실패 할 때 바로 후드에서 가장을하려고하는 ConfigurationManager에 약간의 문제가 있습니다. 아마도 프로세스에 가장을 수행 할 수있는 권한이 없기 때문일 수 있습니다. -user, non-interactive, etc. – quetzalcoatl

app.config를로드 할 때 System.Configuration 자체가 가장을하는 것 같습니다. 이 문제를 해결하려면 다음을 실행하여 문제를 해결할 수있었습니다. 도용하지 않고

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

이렇게하면 나중에 가장이 성공하게됩니다.

편집 : 조금 명확히하기 위해이 작업을 수행하면 app.config가 메모리에로드되고 캐싱되어 문제가되는 코드 경로가 원래 자격 증명과 한 번만 실행됩니다.

출처

2014-04-03 18:49:00

고마워,이 고정 문제. 적어도 4.5.1에서는 .NET 4.x의 버그 여야합니다. .NET 2.0에서는 발생하지 않습니다. XmlElement 속성 값을 설정하려고 할 때 문제가 발생합니다. 그러나 새 XmlDocument(). CreateElement ("Test")를 만들고 속성을 해당 값으로 설정 한 다음 설정하려는 항목으로 설정하면 작동합니다. 매우 이상합니다. –

오랜 전투와 많은 ProcMon 캡처 후에 일부 조건에서 interop 및 도용 중에 보안 영역을 확인할 때 오류가 있음을 발견했습니다. 그것은이 KB 관련이있다 :

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

당신이 대신 지시에 따라 W3wp.exe를 추가로, 레지스트리 노드와 키가 추가 끝을 확인 자신의 실행 파일의 파일 이름을 추가하는 경우. 이것은 나를 위해 일했습니다 - YMMV.

출처

2015-04-30 14:19:56 Cork

다른 사용자로 가장 할 때 치명적인 오류가 발생했습니다.

답변

관련 문제