Windows 10 1803后WindowsIdentity.Impersonate引发SqlConnection初始化失败

我来帮你拆解这个问题的本质，再给你几个比修改那个晦涩注册表项更靠谱的修复方案——毕竟依赖注册表hack确实容易踩坑，谁知道下次系统更新会不会又出问题呢。

Windows 10 1803（2018年4月更新）对服务账户模拟上下文的安全策略做了收紧调整：当你用LOGON32_LOGON_SERVICE方式获取的WindowsIdentity进行模拟时，.NET Framework的System.Data.SqlClient.SqlConnection在执行静态构造函数（类型初始化）时，会调用GetLocationEvidence去获取应用的安全区域信息，但服务账户的模拟上下文没有足够的权限或环境信息完成这个操作，直接抛出了E_UNEXPECTED（灾难性失败）异常。

而你提到的几个正常运行场景也能佐证这个逻辑：

• 注释掉Impersonate时，用的是高权限管理员账户，能正常读取安全区域配置；
• 单步调试时，调试器会给线程注入额外权限/上下文，临时绕过了安全检查；
• KB945701的注册表项本质是让系统跳过对该应用的安全区域验证，相当于直接绕开了这个报错环节，但确实是个不优雅的hack。

方案1：提前在高权限上下文初始化SqlClient静态类 #

因为SqlConnection的类型初始化（静态构造函数）只会执行一次，我们可以在进入模拟上下文之前，先在高权限的管理员上下文里触发一次初始化，后续在模拟服务账户时就不会再执行这个逻辑了。

代码示例：

// 提前在高权限上下文触发SqlClient静态初始化（哪怕创建一个临时连接就行）
try
{
    using (var tempConn = new SqlConnection("Server=(local);Integrated Security=true;"))
    {
        // 不需要打开连接，只要触发类型初始化即可
    }
}
catch { /* 忽略临时连接的错误，我们只需要完成静态初始化 */ }

// 之后再执行模拟逻辑
try
{
    using (svcIdentity.Impersonate())
    {
        using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
        {
            conn.Open();
            // 你的业务逻辑
        }
    }
}
catch (Exception ex)
{
    // 异常处理
}

这个方案简单直接，不需要修改配置或权限，完全通过代码逻辑规避问题。

方案2：迁移到Microsoft.Data.SqlClient（推荐） #

微软现在已经把SqlClient的开发重心转移到Microsoft.Data.SqlClient（原.NET Core SqlClient，也支持.NET Framework 4.6+），这个库的初始化逻辑重新设计过，移除了那些依赖安全区域的旧逻辑，从根源上避免了这个问题。

迁移步骤非常简单：

1. 通过NuGet安装Microsoft.Data.SqlClient包；
2. 把代码里的using System.Data.SqlClient;替换成using Microsoft.Data.SqlClient;；
3. 其他代码几乎不需要修改（API和原SqlClient完全兼容）。

这个方案不仅能解决当前问题，还能获得微软后续的官方支持和bug修复，是长期来看最可靠的选择。

方案3：调整服务账户权限（备选） #

如果上面两个方案都无法实施，可以尝试给服务账户授予读取安全区域配置的权限：

• 打开注册表编辑器，找到HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones路径，给服务账户添加读取权限；
• 确保服务账户对%WINDIR%\Microsoft.NET\Framework\v4.0.30319\Config下的machine.config和security.config有读取权限。

不过这个方案需要调整系统权限，可能存在安全风险，而且后续系统更新可能再次改变权限策略，所以只建议作为最后备选。

内容的提问来源于stack exchange，提问作者flip