.NET 3.5程序迁移后PresentationFramework.ni.dll致CPU占用过高求解

我之前也碰到过类似的WPF应用在.NET 3.5环境下迁移后，PresentationFramework.ni.dll异常占用CPU的情况，给你几个经过实际验证的解决方案：

• 安装.NET 3.5的最新补丁
  PresentationFramework的native image（.ni.dll）存在过多个已知的性能bug，微软针对.NET 3.5 SP1发布过不少累积修复补丁，比如KB976038、KB2468871等。确保目标机器已经安装了.NET 3.5 SP1以及后续的所有相关更新，这是最基础也最有效的步骤之一。

• 重新生成Native Image缓存
  迁移后的应用可能在目标机器上的ngen缓存不兼容，或者原有native image是针对开发机硬件生成的。可以通过以下步骤重新生成：

  1. 打开管理员权限的命令提示符；
  2. 定位到.NET 3.5对应的ngen.exe路径（通常是C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe，因为.NET 3.5基于CLR 2.0）；
  3. 先卸载旧的缓存：

     ngen uninstall "你的应用程序完整路径.exe"
     

  4. 再重新生成适配目标机器的缓存：

     ngen install "你的应用程序完整路径.exe"
     

  这个操作能让系统重新编译优化应用的native image，大概率能解决ni.dll的CPU异常问题。

• 禁用WPF硬件加速
  有时候目标机器的显卡驱动兼容性差，或者硬件加速触发了PresentationFramework的渲染bug。可以强制让应用使用软件渲染：

  • 代码方式（在App.xaml.cs的OnStartup方法中添加）：

    protected override void OnStartup(StartupEventArgs e)
    {
        RenderOptions.ProcessRenderMode = RenderMode.SoftwareOnly;
        base.OnStartup(e);
    }
    

  • 配置文件方式（在app.config中添加）：

    <configuration>
        <appSettings>
            <add key="RenderMode" value="SoftwareOnly"/>
        </appSettings>
    </configuration>
    

  切换到软件渲染后，能绕过硬件加速相关的问题路径，降低ni.dll的CPU占用。

• 排查应用内的WPF性能瓶颈
  某些不合理的WPF写法也会触发这类问题，比如：

  • 频繁更新的绑定未设置合适的UpdateSourceTrigger；
  • 无限循环或未正确停止的动画；
  • 过度的布局重绘（比如没有使用VirtualizingStackPanel的长列表）。
    可以用Visual Studio的Performance Profiler（针对WPF的UI分析模块）或者旧版的WPF Performance Suite来排查这些问题，优化后也能缓解CPU占用。

• 检查目标机器的系统环境
  确保目标机器的系统版本符合要求，比如Windows XP的部分版本对.NET 3.5的WPF支持存在局限性，尽量使用Windows 7及以上系统。另外，检查系统虚拟内存是否充足，内存不足也可能导致CPU异常负载。

这些方法里，重新生成ngen缓存和安装补丁是我当时解决问题的关键，你可以按顺序尝试。

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