我试图了解代码探查器（在本例中为Drone profiler）是如何运行的。NET应用程序不同于直接运行它。我需要知道这一点的原因是，我的开发计算机出现了一个非常奇怪的问题/损坏。NET安装，它在探查器之外表现出来，但奇怪的是，它不在探查器内部，如果我能理解为什么我可能会修复我的计算机的问题。
该问题似乎只影响对系统的调用。网NetworkInformation的方法（并且仅在.NET 3.5到2.0中，如果我针对4构建一些东西，那么一切都很好）。我做了一个小测试应用程序，它只做一件事，叫做System。网网络信息。IsNetworkAvailable（）。在探查器之外，我得到了System.dll中发生的"致命执行引擎错误"，这就是它提供的所有信息。据我所知，错误通常是由本机方法调用引起的，这种调用可能发生在System.dll让一些本机dll执行IsNetworkAvailable（）逻辑时。
- 我试图使用Process Monitor来找出探查器内部和外部的差异，记录两种情况下的事件并进行比较。两个日志都是相同的，直到调用iphlpapi.dll和winnsi.dll后不久，探查器运行代码dnsapi.dll和非探查器代码开始加载崩溃报告相关内容之前。在出现问题的那一刻，探查器运行代码创建了4-6个新线程，而非探查器（崩溃）代码只创建了1或2个。我不知道这意味着什么
可以说是不必要的背景
包括我的Windows7。NET安装（3.5到2.0）一直运行良好，直到我的硬盘出现一些损坏，检查磁盘开始发现坏集群。我将驱动器映像为一个新驱动器，除此问题外，其他一切都很好。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工作，因为我是一名开发人员，需要针对它进行构建和测试
谢谢！
Quinxy
简单的答案是我的System.ni.dll文件已损坏，我已将其替换，一切正常。
长篇大论的答案可能会通过其解决方案的方法帮助其他人。。。
我的问题与.Net被破坏有关，除非通过探查器，否则应用程序无法运行。我下载了SlimTune开源探查器的源代码，在本地构建它，并在调用Process.Start（）之前设置了一个断点。然后，我比较了通过探查器成功启动应用程序与手动启动应用程序所涉及的所有参数。我发现的唯一有意义的区别是添加了添加到环境变量中的.NET配置文件参数：
- cor_enable_profile=1
- cor_profiler=｛38A7EA35-B221-425a-AD07-D058C581611D｝
然后我试着在我自己的用户环境中设置这些，瞧！现在，我手动运行的任何应用程序都可以工作。（事实上，我在几个小时前也尝试过做同样的事情，但我使用了一个包含在示例中的GUID，它没有指向真正的探查器，而且显然.NET知道我给了它一个伪造的GUID，并且没有在探查模式下运行。）
我现在回过头来，开始阅读CLR是如何执行PE文件的，希望弄清楚为什么我的应用程序在启用评测的情况下运行很重要。我学到了很多，但似乎什么都没有学到。
然而，我确实记得我应该重新检查chkdsk日志，我一直在列出因驱动器故障而损坏的文件。失败后，我将所有列出的文件ID转换为文件路径/名称，并从备份中替换了所有100多个文件，但当我现在回去查看时，我发现了一条注释，虽然我成功地替换了4或5个与.NET相关的文件，但有一个文件我无法替换，因为它"正在使用中"。那个文件？System.ni.dll！！！我现在可以从备份中替换这个文件了，瞧，我的.NET安装恢复正常了，无论是否有配置文件，应用程序都可以工作。
令人沮丧的是，当这起事件第一次发生时，我完全预料到问题与一个损坏的文件有关，特别是与一个名为System.dll的文件有关。该文件包含失败的方法。因此，我对所有名为System.dll的文件进行了区分和重写。但当时我没有意识到System.ni.dll是System.dll（或类似的）的本地编译表现形式。因为我对.NET相关的目录进行了区分和重编，但没有注意到这一点（不知道我是怎么错过的），所以我放弃了这种方法。
不管怎样。。。长话短说，是一个损坏的System.ni.dll导致了我的问题，其中的一个或多个集群的内容被0x0替换，它恰好表现为我观察到的奇怪问题。
这听起来像是一个时间问题，探查器通过使其稍微慢一点来"修复"了这个问题。
许多评测器使用检测（此处提供更多信息），这会略微降低应用程序的速度。显然，它降低了一个线程的速度，使得另一个线程可以做更多的工作，从而防止崩溃。像这样的错误通常不会直接在开发人员的机器上表现出来，但一旦它们在具有更多内核或超线程的处理器上运行，就会出现。有时它们只出现在发布版本中（反之亦然，在调试版本中）。时间问题可能很难追踪，因为相同的代码在不同的条件下（在探查器或调试器中）可能会给出不同的结果。
根据你的描述，我将尝试对如何修复它进行疯狂的猜测：
尝试在源中查找新线程的启动位置。然后，在它们被派生后，在那里添加一行System.Threading.Thread.Sleep(500);以暂停主线程，并给新线程一些时间来启动。
如果没有源代码和一些崩溃的堆栈跟踪，这就相当于一种猜测。