如何在代码分析器中运行C#app与运行一个外部代码分析器有什么不同？

Question

我试图理解代码分析器(在这种情况下是Drone Profiler)运行.NET应用程序与直接运行它的方式不同.我需要知道这个的原因是因为我的开发计算机的.NET安装有一个非常奇怪的问题/腐败,它在分析器之外表现出来但很奇怪不在里面,如果我能理解为什么我可以解决我的计算机问题.

这个问题似乎只会影响对System.Net.NetworkInformation方法的调用(并且只在.NET 3.5到2.0中,如果我构建一个针对4的东西,那么很好).我构建了一个小测试应用程序,它只做一件事,它调用System.Net.NetworkInformation.IsNetworkAvailable().在分析器之外,我在System.dll中发生了"致命执行引擎错误",这就是它提供的所有信息.据我所知,错误通常是由本机方法调用引起的,当System.dll允许某些本机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和程序文件下的.NET内容)与磁盘之前和之后的问题区分开来,看不到任何我没想到的变化(没有明显的文件损坏).
• 我已经将软件和系统注册表配置文件分成了磁盘前后的麻烦,并且没有看到任何相似的变化.
• 我创建了一个新的用户帐户,并在环境相关的情况下清理了所有环境变量.没变.
• 我做了"sfc/scannow",发现没有完整性问题.
• 我尝试了"ngen update"来重新生成预编译的代码,以防我错过了可能被损坏且没有任何改变的东西.
• 我删除了我的病毒扫描程序,看它是否干扰,没有区别.
• 我尝试在安全模式下运行测试代码,同样的崩溃问题.

我假设我需要修复我的.NET安装但是因为Windows 7包含.NET 3.5 - 2.0,所以你不能只重新运行.NET安装程序来重做它.我无法访问Windows磁盘以尝试重新安装Windows(计算机有一个恢复分区,但它无法使用); 此外,该驱动器使用整盘加密解决方案,重新安装将很困难.

我绝对不想从头开始安装一个全新的Windows,重新安装几十个软件包,尝试并记住几十个与开发相关的自定义/等.

鉴于这一切......有没有人有任何有用的建议？我需要.NET 3.5 - 2.0,因为我是一名开发人员,需要构建和测试它.

谢谢!

Quinxy

Answer 1

简而言之，我的 System.ni.dll 文件已损坏，我替换了它，一切正常。

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

我的问题与 .Net 被损坏有关，除非通过分析器，否则应用程序无法运行。我下载了SlimTune 开源分析器的源代码，在本地构建它，并在调用 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（或类似的东西）的本机编译表现。因为我已经对 .NET 相关目录进行了比较和重新比较，但没有注意到这一点（不知道我是如何错过的），所以我放弃了这种方法。

无论如何......长话短说，这是一个损坏的System.ni.dll导致了我的问题，其中的一个或多个簇的内容被替换为0x0，而它恰好表现为我观察到的奇怪问题。