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

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

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

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

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

这是在没有断点的情况下抛出错误的代码片段：

// 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,Boolean useSidHistory)
   bei System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRef(Type principalType,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,IdentityType identityType,String identityValue)
   bei System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context,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."

解决方法

所以我自己弄明白了。

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

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

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

看起来模拟和PrincipalContext不能同时正常运行。

解决方案：

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

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