C#控制台应用程序调试时抛出错误-在正确位置使用断点时，不会抛出错误

Question

我目前正在 Visual Studio 2019 中的 C# 上编辑控制台应用程序。 这是一个在数据库上同步一些数据的应用程序。 上次我编辑代码时一切正常，代码运行通过。

目前我有一个问题，应用程序在一段中引发了灾难性错误，我没有对之前的工作代码进行任何更改。

但是，如果我在调试模式下的错误抛出行上设置一个断点，它就可以正常工作。 我在互联网上搜索了很多，但似乎没有其他人有类似的问题。

这是在没有断点的情况下抛出错误的代码 sn-p：

// GetADContext just creates a new PrincipalContext with specific user and password
PrincipalContext pc = SomeDllClass.GetADContext();
// The line below throws an error - but only if there is no breakpoint
UserPrincipal adUser = UserPrincipal.FindByIdentity(pc, IdentityType.Sid, myClass.SID);

我尝试清理并重建解决方案。还删除了 .vs、obj 和 bin 文件夹。到目前为止没有任何效果。

我不知道为什么会这样。 我希望你们中的任何人都可以帮助我解决这种奇怪的行为。

*编辑

这是抛出的完整异常：

"System.DirectoryServices.AccountManagement.PrincipalOperationException: Schwerwiegender Fehler (Ausnahme von HRESULT: 0x8000FFFF (E_UNEXPECTED)) ---> System.Runtime.InteropServices.COMException: Schwerwiegender Fehler (Ausnahme von HRESULT: 0x8000FFFF (E_UNEXPECTED))
   bei System.Security.Policy.PEFileEvidenceFactory.GetLocationEvidence(SafePEFileHandle peFile, SecurityZone& zone, StringHandleOnStack retUrl)
   bei System.Security.Policy.PEFileEvidenceFactory.GenerateLocationEvidence()
   bei System.Security.Policy.PEFileEvidenceFactory.GenerateEvidence(Type evidenceType)
   bei System.Security.Policy.AssemblyEvidenceFactory.GenerateEvidence(Type evidenceType)
   bei System.Security.Policy.Evidence.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   bei System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   bei System.Security.Policy.Evidence.GetHostEvidence(Type type, Boolean markDelayEvaluatedEvidenceUsed)
   bei System.Security.Policy.AppDomainEvidenceFactory.GenerateEvidence(Type evidenceType)
   bei System.Security.Policy.Evidence.GenerateHostEvidence(Type type, Boolean hostCanGenerate)
   bei System.Security.Policy.Evidence.GetHostEvidenceNoLock(Type type)
   bei System.Security.Policy.Evidence.RawEvidenceEnumerator.MoveNext()
   bei System.Security.Policy.Evidence.EvidenceEnumerator.MoveNext()
   bei System.Configuration.ClientConfigPaths.GetEvidenceInfo(AppDomain appDomain, String exePath, String& typeName)
   bei System.Configuration.ClientConfigPaths.GetTypeAndHashSuffix(AppDomain appDomain, String exePath)
   bei System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig)
   bei System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig)
   bei System.Configuration.ClientConfigurationHost.RequireCompleteInit(IInternalConfigRecord record)
   bei System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   bei System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   bei System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
   bei System.Configuration.ConfigurationManager.GetSection(String sectionName)
   bei System.Configuration.PrivilegedConfigurationManager.GetSection(String sectionName)
   bei System.DirectoryServices.SearchResultCollection.ResultsEnumerator..ctor(SearchResultCollection results, String parentUserName, String parentPassword, AuthenticationTypes parentAuthenticationType)
   bei System.DirectoryServices.SearchResultCollection.get_InnerList()
   bei System.DirectoryServices.SearchResultCollection.get_Count()
   bei System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRefHelper(Type principalType, String urnScheme, String urnValue, DateTime referenceDate, Boolean useSidHistory)
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRefHelper(Type principalType, String urnScheme, String urnValue, DateTime referenceDate, Boolean useSidHistory)
   bei System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRef(Type principalType, String urnScheme, String urnValue, DateTime referenceDate)
   bei System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate)
   bei System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, IdentityType identityType, String identityValue)
   bei System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, IdentityType identityType, String identityValue)
   bei IMSTools.Base.IMSStd.GetUserPrincipal(PrincipalContext context, IdentityType type, String value)
   bei IMSMitarbeiterSynch.Program.SynchADS(List`1 mitarbeiter) in D:\\Git\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\Program.cs:Zeile 240.
   bei IMSMitarbeiterSynch.Program.SynchronizeData() in D:\\Git\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\Program.cs:Zeile 88.
   bei IMSMitarbeiterSynch.Program.Main(String[] args) in D:\\Git\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\IMSMitarbeiterSynch\\Program.cs:Zeile 53."

Answer 1

所以我自己想通了。

起初我使用 模拟 来获得对我需要一些文件的目录的管理员权限：

if (Environment.UserName.ToLower().Trim() != "adminuser")
{
    if (loggedOn = LogonUser("adminuser", "domainName", "password", 2, 0, ref token))
    {
        WindowsIdentity newId = new WindowsIdentity(token);
        wic = newId.Impersonate();
    }
}

我在程序开始时就这样做了。 对于PrincipalContext 中的活动目录，我必须使用另一个用户来阅读。

模拟和PrincipalContext好像不能同时正常操作。

解决方案：

解决方案是仅当我需要访问目录并在之后撤消它时才模拟，这样模拟 和`PrincipalContext` 永远不会同时处于活动状态。

也许有人有同样的问题，可以用这个解决方案解决它