WindowsIdentity.Impersonate throws ''Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))' after April 2018 (1803) update

Our installer app uses the following code to verify service account permissions:

try
{
    using (svcIdentity.Impersonate())
    {
        using (SqlConnection conn = new SqlConnection(builder.ConnectionString))  // <<<
        {
            conn.Open();
            ...

Omitted for brevity:

• The svcIdentity WindowsIdentity is obtained by using the Win32 LSA LogonUser function in advapi32.dll and LOGON32_LOGON_SERVICE.
• builder is a SqlConnectionStringBuilder that builds a connectionstring to a local SQL Server database.

Targeting .Net Framework 4.6.

The app runs elevated (requestedExecutionLevel level='requireAdministrator' in the app.manifest).

This code ran flawless until Windows 10 version 1803 (April 2018 update). Since then, the SqlConnection constructor (marked <<<) throws an exception:

The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.

The inner exception provides more insight:

Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED))

Stack trace:

   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.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.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.RequireCompleteInit(IInternalConfigRecord record)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Configuration.ConfigurationManager.GetSection(String sectionName)
   at System.Data.SqlClient.SqlConnection..cctor()

The stack trace indicates the SqlConnection constructor fails to open a configuration section. Our app.config does not have a connectionstrings section and machine.config and security.config on the tested computers haven't changed since 2017.

The code works when:

• Commenting out using (svcIdentity.Impersonate),

  or

• when setting a breakpoint on the line immediately above the SqlConnection constructor ({) and stepping through the code (???),

  or

• when adding our application to the registry key mentioned at the end of KB945701

That KB article about a fix for Internet Explorer 9 seems unrelated, except that GetLocationEvidence on the first line of the stack trace seems to take a SecurityZone into account, which applications listed in the corresponding registry key seem to ignore.

Now my question:

Can anybody help me understand what exactly is going wrong, and if there is a better way to fix this than with an obscure registry key? It seems a 'coincidence' that this registry change works and I'm afraid our code might break again if we don't understand exactly why it fails.

Thx.