c# - 在代码分析器中运行 C# 应用程序与在外部代码分析器中运行有何不同？

Question

我试图了解代码探查器(在本例中为 Drone Profiler)运行 .NET 应用程序与直接运行它的方式不同。我需要知道这一点的原因是因为我的开发计算机的 .NET 安装有一个非常奇怪的问题/损坏，它在探查器外部出现，但很奇怪不在内部，如果我能理解为什么我可以解决我的计算机问题。

这个问题似乎只影响对 System.Net.NetworkInformation 方法的调用(并且只在 .NET 3.5 到 2.0 中，如果我针对 4 构建一些东西，一切都很好)。我构建了一个只做一件事的小测试应用程序，它调用 System.Net.NetworkInformation.IsNetworkAvailable()。在探查器之外，我在 System.dll 中收到“致命执行引擎错误”，这就是它提供的所有信息。据我了解，错误通常是由 native 方法调用引起的，这可能是在 System.dll 让某些 native DLL 执行 IsNetworkAvailable() 逻辑时发生的。

• 我尝试使用 Process Monitor 找出探查器内部和外部的差异，记录两种情况下的事件并进行比较。两个日志都是相同的，直到调用 iphlpapi.dll 和 winnsi.dll 之后的片刻，就在名为 dnsapi.dll 的探查器运行代码和非探查器代码开始加载崩溃报告相关内容之前。在那一刻，当它似乎出错时，探查器运行代码创建了 4-6 个新线程，而非探查器(崩溃)代码只创建了 1 或 2 个。我不知道那是什么意思，如果有的话。

---

可以说是不必要的背景

我的 Windows 7 包括 .NET 安装(3.5 到 2.0)工作正常，直到我的硬盘驱动器出现一些损坏并且 checkdisk 开始发现坏簇。我将驱动器成像到一个新的驱动器上，除了 .NET 的这个问题外，一切正常。

我需要通过重新安装 Windows 或恢复到镜像备份来解决此问题。

以下是我调查过的一些事情:

• 我比较了似乎最相关的文件/目录(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，因为我是一名开发人员，需要针对它进行构建和测试。

谢谢!

昆西

Answer 1

简短的回答是我的 System.ni.dll 文件损坏了，我替换了它，一切都很好。

长答案可能会通过其解决方案的方法帮助其他人...

我的问题与 .Net 相关，其损坏方式导致应用程序无法运行，除非通过分析器。我下载了 SlimTune open source profiler 的源代码，在本地构建它，并在调用 Process.Start() 之前设置一个断点。然后，我比较了通过探查器与手动成功启动应用程序所涉及的所有参数。我发现唯一有意义的区别是将 .NET 配置文件参数添加到环境变量中:

• cor_enable_profiling=1
• cor_profiler={38A7EA35-B221-425a-AD07-D058C581611D}

然后我尝试在我自己的用户环境中设置这些，瞧!现在我手动运行的任何应用程序都可以运行。 (我实际上在几个小时前尝试过做同样的事情，但我使用了一个示例中包含的 GUID，它没有指向真正的分析器，显然 .NET 知道我给了它一个伪造的 GUID 但没有在分析模式下运行。)

现在我回头开始阅读有关 CLR 如何执行 PE 文件的内容，希望弄清楚为什么我的应用程序在启用分析的情况下运行很重要。我学到了很多东西，但没有任何东西似乎适用。

不过我确实记得我应该重新检查 chkdsk 日志，我一直在列出因驱动器故障而损坏的文件。失败后，我将所有列出的文件 ID 转换为文件路径/名称，并且我已经从备份中替换了所有 100 多个文件，但当我现在回去查看时，我确实发现了一个注释，虽然我已经替换了 4 个或5 .NET 相关文件成功 有一个这样的文件我无法替换，因为它“正在使用”。那个文件？系统.ni.dll!!!我现在可以从备份中替换此文件，瞧，我的 .NET 安装恢复正常，无论是否配置文件，应用程序都可以正常工作。

令人沮丧的是，当这个事件第一次发生时，我完全预料到问题与损坏的文件有关，特别是与一个名为 System.dll 的文件有关，该文件包含失败的方法。因此，我比较并重新比较了所有名为 System.dll 的文件。但当时我并没有意识到 System.ni.dll 是 System.dll(或类似的)的 native 编译表现形式。因为我已经 diff 和 rediff 了 .NET 相关目录而没有注意到这一点(不知道我是怎么错过的)我放弃了这种方法。

总之...长话短说，是一个损坏的 System.ni.dll 导致了我的问题，其中一个或多个集群的内容被 0x0 替换，它恰好表现为我观察到的奇怪问题.