我的 Windows 7 包含的 .NET 安装（3.5 到 2.0）出现了轻微且特别严重的损坏，我正在尝试修复它，而无需重新安装 Windows 或尝试恢复到备份。
一切正常，然后我的硬盘开始损坏一些文件，checkdisk 发现了坏簇，所以我将硬盘镜像到新硬盘上。我一启动新硬盘，一切就都正常了除了在 .NET 3.5 到 2.0 中调用 System.Net.NetworkInformation 方法的程序（例如 Ping() 和 IsNetworkAvailable()），这些程序会立即导致调用这些方法的应用程序崩溃（在 .NET 4.0 中，这些调用可以正常工作）。这些方法位于 System.dll 中，我假设调用本机方法，我相信这些方法位于 winnsi.dll 或 iphlpapi.dll 或其他程序中（我还没有找到这些程序）；我假设它调用本机方法，因为导致崩溃的异常是致命执行引擎错误，人们提到它通常与调用本机方法和在它们之间封送数据有关。
关于罪魁祸首的一个重要线索可能是，当我通过代码分析器（执行 exe 并捕获哪些方法耗时最长的统计数据）启动完全相同的崩溃应用程序时，应用程序运行良好，根本没有崩溃！为什么在分析器内运行它可以，而在外部运行它却不行？这似乎是谜团的关键。
- 我使用 procmon 捕获崩溃执行和分析器成功执行中的所有注册表、文件系统和网络事件，并比较了两个输出，但并没有学到太多东西（我看到了未分析的应用程序崩溃的时刻，但在此之前它们的行为相同，加载了相同的模块）。唯一的大区别似乎是，在应用程序崩溃之前，分析器执行的代码会创建 4-6 个新线程，而直接执行的代码只会创建 1-2 个。
- 我对磁盘故障前后看起来最相关的文件/目录 (Windows 和 Program Files 下的 .NET 内容) 进行了差异处理，没有看到任何我意想不到的变化 (没有明显的文件损坏)。
- 我对磁盘故障前后的软件和系统注册表配置单元进行了比较，并没有发现任何相关的变化。
- 我已经创建了一个新的用户帐户，并清理了所有与环境相关的环境变量。没有变化。
- 我执行了“sfc /scannow”，没有发现完整性问题。
- 我尝试使用“ngen update”来重新生成预编译的代码，以防我错过了一些可能被损坏并且没有任何改变的东西。
我认为我需要修复我的 .NET 安装，但由于 Windows 7 包含 .NET 3.5 - 2.0，您不能直接重新运行 .NET 安装程序来重做它。我无法访问 Windows 磁盘来尝试重新安装 Windows（计算机有一个恢复分区，但无法使用）；此外，该驱动器使用全盘加密解决方案，重新安装会很困难。
我绝对不想从头开始安装全新的 Windows，重新安装几十个软件包，尝试记住几十个与开发相关的定制/等等。
考虑到所有这些...有人有什么有用的建议吗？我需要 .NET 3.5 - 2.0 工作，因为我是一名开发人员，需要针对它进行构建和测试。
谢谢！
昆西
答案1
简短的回答是我的 System.ni.dll 文件损坏了，我替换了它，一切正常。
我记得我应该重新检查 chkdsk 日志，我一直在列出因驱动器故障而损坏的文件。故障发生后，我已将所有列出的文件 ID 转换为文件路径/名称，并已从备份中替换了所有 100 多个文件，但当我现在回去查看时，我发现一条注释，虽然我已成功替换了 4 或 5 个 .NET 相关文件，但有一个文件我无法替换，因为它当时“正在使用中”。那个文件？System.ni.dll！！！我现在能够从备份中替换此文件，瞧，我的 .NET 安装恢复正常，无论是否进行了配置，应用程序都可以正常工作。
令人沮丧的是，当此事件首次发生时，我完全预料到问题与损坏的文件有关，特别是与包含失败方法的 System.dll 文件有关。因此，我对所有名为 System.dll 的文件进行了差异比较和重新差异比较。但我当时没有意识到 System.ni.dll 是 System.dll 的本机编译表现形式（或类似内容）。而且由于我已对 .NET 相关目录进行了差异比较和重新差异比较，但没有注意到这一点（不知道我怎么会错过它），所以我放弃了这种方法。
无论如何......长话短说，是损坏的 System.ni.dll 导致了我的问题，其中一个或多个集群的内容被 0x0 替换，而它恰好表现为我观察到的奇怪问题。