Errore irreversibile quando si impersonano altri utenti

Uso la libreria Enterprise Blocco di convalida integrato con WCF. Segnala System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) quando impersono un altro utente con API LogonUser WIN32 e WindowsIdentity.Impersonate. Sembra che ci sia qualcosa di sbagliato quando ottenere prove di sicurezza sul caricamento della configurazione. Se rimuovo la codifica della rappresentazione, funziona senza errori. Queste sono la parte della traccia dello stack di eccezioni, spero che tu dia alcuni aiutanti. Grazie.Errore irreversibile quando si impersonano altri utenti

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

fonte

2012-10-09 Leo Wong

fyi - simile: https://stackoverflow.com/a/23650343/717732 – quetzalcoatl

-2

Si prega di vedere la mia risposta a questo su questo thread nel forum MS:

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

Questo è il titolo del thread: Pool di connessioni in modo casuale generare eccezioni COM.

È possibile cercare il testo nella pagina per LogonUser.

fonte

2013-05-27 16:23:45 Brannon

sembra non correlato. L'unica cosa comune è "qualche problema con la rappresentazione". Il thread che hai indicato è incentrato sulla gestione di LogonUser e maniglie. Non abbiamo nulla di simile qui. Qui abbiamo qualche problema con ConfigurationManager che cerca di eseguire la rappresentazione sotto il cofano appena prima di leggere il file e non ci riesce, probabilmente perché il processo non ha privilegi a fare la rappresentazione a causa di essere eseguito come, non lo so, limitato -utente, non interattivo, ecc. – quetzalcoatl

Mi sembra che il problema sia che System.Configuration esegue la stessa impersonificazione durante il caricamento di app.config. Sono stato in grado di risolvere questo problema eseguendo

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

mentre non si spaccia. Ciò ha causato il successo della successiva imitazione.

EDIT: Per chiarire leggermente, credo che facendo ciò, app.config venga caricato e memorizzato nella cache, quindi il percorso del codice che causa il problema viene eseguito solo una volta e con le credenziali originali.

fonte

2014-04-03 18:49:00

Grazie, questo ha fissato le cose per me. Questo deve essere un bug in .NET 4.x ... almeno in 4.5.1. Non succede con .NET 2.0. Ottengo il problema quando si tenta di impostare un valore di proprietà XmlElement. Tuttavia, se creo un nuovo XmlDocument(). CreateElement ("Test"), imposta la proprietà su quel valore, quindi impostalo su cosa intendevo impostare, funziona. Molto strano. –

Dopo una lunga battaglia e molte acquisizioni di ProcMon, ho scoperto che in alcune condizioni, si verifica un errore durante il controllo delle zone di sicurezza durante l'intervallo e durante la rappresentazione. Esso è legato a questa KB:

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

Se si seleziona la fine dove vengono aggiunti un nodo di registro e chiave, invece di aggiungere w3wp.exe come diretto, aggiungere il nome del file del proprio eseguibile. Questo ha funzionato per me - YMMV.

fonte

2015-04-30 14:19:56 Cork

Errore irreversibile quando si impersonano altri utenti

risposta

Problemi correlati