问在代码分析器中运行C#应用程序与运行外部代码分析器有什么不同？

EN

简单地说，我的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日志，我一直在列出由于驱动器故障而损坏的文件。在失败之后，我将列出的所有文件in转换为文件路径/名称，并且我从备份中替换了所有的100+文件，但当我现在回去查看时，我发现了一个注释，虽然我成功地替换了4或5个.NET相关文件，但是有一个这样的文件我无法替换，因为它“正在使用”。那份文件？System.ni.dll！现在我可以从备份中替换这个文件了，瞧，我的.NET安装已经恢复正常，应用程序可以正常工作，不管是否配置。

令人沮丧的是，当这一事件第一次发生时，我完全希望问题与一个损坏的文件有关，特别是一个名为System.dll的文件，该文件保存了失败的方法。因此，我对所有名为System.dll的文件进行了修改和修改。但当时我没有意识到，System.ni.dll是System.dll (或somesuch)的本地编译形式。因为我已经对.NET相关的目录进行了区分和重新修改，而没有注意到这一点(不知道我是如何错过的)，所以我放弃了这种方法。

不管怎样..。长话短说，是一个损坏的System.ni.dll导致了我的问题，其中的一个或多个集群的内容被0x0所取代，而它恰好表现为我观察到的奇怪问题。

这听起来像是一个时间问题，分析器通过稍微慢一点“修正”了这个问题。

许多分析器使用插装(这里有更多的信息)，这会稍微减慢应用程序的速度。显然，它使一个线程的速度足够慢，使得另一个线程可以做一些更多的工作，从而防止崩溃。这样的错误通常不会直接出现在开发人员机器上，而是在具有更多内核或超线程的处理器上运行时立即出现。有时它们只发生在版本构建中(或者在调试版本中相反)。时间问题可能很难跟踪，因为相同的代码可能在不同的条件下给出不同的结果(在分析器或调试器中)。

根据您的描述，我将尝试对如何修复它做一个粗略的猜测：

尝试在启动新线程的源代码中找到。然后，在生成它们之后，在那里添加一个System.Threading.Thread.Sleep(500);行，以暂停主线程，并给新线程一些启动的时间。

如果没有源代码和一些崩溃的堆栈跟踪，这是相当多的猜测。