Visual Studio 调试器的奇怪行为; "The network location cannot be reached" (ERROR_NETWORK_UNREACHABLE)

Bizarre behavior with Visual Studio's debugger; "The network location cannot be reached" (ERROR_NETWORK_UNREACHABLE)

本文关键字：reached cannot be ERROR UNREACHABLE NETWORK location The 调试器 Studio Visual      更新时间：2023-10-16

从 2012 年开始，在多台计算机和多个项目上，我在 Visual Studio 的每个版本中都经历过这种情况，但我还没有弄清楚如何解决它：

每当我调试 64 位（？C++控制台程序，几分钟后，似乎完全随机（当我没有单击或键入任何内容时），程序的控制台窗口会自发关闭，我无法再使用 Visual Studio 调试或单步执行程序。当我按停止并尝试重新启动调试时，我通常会得到ERROR_NETWORK_UNREACHABLE：

// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE        1231L

如果我尝试手动附加到进程，则会出现错误：

Unable to attach to the process.

我为此找到的唯一解决方法是重新启动Visual Studio。我找不到任何其他方法来修复它，并且我尝试运行进程监视器，但没有找到任何东西。

导致此问题的原因是什么，我该如何解决？

（？经过进一步检查，这似乎只发生在 64 位模式下，但我不是 100% 确定。

好吧，这太错误了

我也遇到了这个错误的问题，就我而言，它每隔一个调试会话就会发生一次。这意味着调试 -> 停止 -> 调试 -> 错误 ->重新启动 Visual Studio -> 转到开始（全天每分钟重复一次）。

不用说，我被驱使去寻找解决方案。所以昨天我尝试了procmon，花了几个小时查看API监视器的差异，查看插件，netstat等，等等。什么也没发现。我放弃了。

今天

直到今天。

为了追踪我程序中的一个愚蠢的错误，我启动了appverifier。对于我的应用程序，我运行了"基础知识"测试并单击保存。几个小时后，这导致我发现了程序中的错误，它是这样的（极其简化的版本）：

void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
显然

这是一个错误，显然需要修复。在memcpy行上放置断点后，我注意到了错误，该断点未执行。

在停止并再次"调试"后，我惊讶地发现我实际上可以第二次调试程序。现在，几个小时后，这里的这个烦人的错误并没有再次出现。

那么似乎发生了什么

所以......显然，来自我的程序的数据正在渗入调试器的数据或执行空间，这反过来又似乎产生了错误。

我看到你在想：不，这不应该发生...你是对的;但显然确实如此。

那么如何解决呢？基本上修复您的程序（更具体地说：堆损坏问题）似乎使VS调试器错误消失。使用appverifier.exe（它在Windows的调试工具中）将给你一个良好的开端。

为什么有效

从VS2012开始，VC++使用不同的方法来管理堆。Hans Passant 在这里解释道：msvcrt 是否自 （vs2012/2010/2013） 以来使用不同的堆进行分配。

基本上发生的情况是堆损坏会破坏调试器。AppVerifier 基本设置将确保在应用程序执行某些操作以损坏堆之前触发断点。

因此，现在发生的情况是，在进程中断堆之前，将触发断点，这通常意味着您将终止进程。实际效果是，在终止程序之前，堆仍将处于状态，这意味着调试器仍将正常运行。

"测试"

  • 使用应用程序之前 -- 每 2 分钟触发一次错误
  • 使用appverifier时 - VS调试器已经稳定了5天（并且还在增加）

这当然是一个环境问题。 总是很难排除故障，SysInternals的实用程序，如进程监视器和进程资源管理器，是你选择的主要武器。 调试时可能生成网络错误的一些非直观方式：

  • 从VS2012开始，C运行时库进行了非常激烈的修改，如果您的程序损坏了堆，则可能导致很难诊断错误行为。 就像@atlaste描述的那样。 自古以来，CRT 总是创建自己的堆，底层调用是 HeapCreate（）。 不再使用，它现在使用 GetProcessHeap（）。 这非常方便，现在处理使用/MT 构建的 DLL 要容易得多。 但是有了相当锋利的边缘，您现在可以轻松损坏Microsoft代码拥有的内存。 如果您无法重新连接 64 位程序，则不会强烈指出，您必须杀死 msvsmon.exe以清除损坏。

  • Microsoft符号服务器为Microsoft可执行文件提供 PDB。 他们通常会剥离其源+行号信息，但不是全部。 例如，CRT尤其不然。 这些 PDB 是在雷德蒙德的 DevDiv 拥有的构建服务器上构建的，该服务器在 F： 驱动器上具有源代码。 一些是从E：驱动器构建的，Patterns+Practices使用它（在C++程序中不太可能）。 调试器将查找那里以尝试查找源代码。 这通常结束得很好，它很快就会放弃，但如果你的机器也使用这些驱动器号，那就不行了。 通过清除符号缓存并使用"工具 + 选项"、"调试"、"符号"禁用符号服务器进行诊断。

  • winapi遭受了两种令人讨厌的病毒感染，它从另一个操作系统继承而来，这些操作系统将全局状态添加到任何进程。 PATH 环境变量和默认工作目录。 使用控制面板+系统+高级+环境查看PATH，将故意小文本框的内容复制/粘贴到文本编辑器中。 确保它是吱吱作响的干净，顺便说一句，通常的混乱中的一些瘫痪是正常的。 不要俘虏。 使用默认目录时遇到问题要困难得多。 使用进程监视器时，两者都应该弹出。

没有灌篮解释，这是一个棘手的问题，但你可以看看黑暗的角落。

我有同样的问题。认为它与 64 位控制台应用程序有关，几乎任何调试会话都很容易触发它。但是，它也发生在64位Windows应用程序上。现在我在 32 位 Windows 应用程序上看到它。我在单个桌面上运行 Windows 8.1 专业版，最新版本为 vs 2013，并且没有远程调试。我的（添加的）扩展是Visual Assist，Advanced Installer，ClangFormat，Code Alignment，Code Compare，Duplicate Selection，Productivity Power Tools 2013和Visual SVN。

我发现"Visual Studio 2013\Settings\CurrentSettings.vssettings"文件已损坏。您可以删除此文件并通过重新启动 VS 重新创建它，也可以尝试编辑 XML。然后，我保留一个好的设置文件的副本，当它再次损坏时，我用它来替换它。

就我而言，损坏的行以

</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"

。而且它非常长（我认为这就是为什么它容易腐败）。

>我刚刚在菜单中禁用

工具>选项

调试>编辑并继续

仅限本机的选项>启用本机编辑并继续

现在它不会给出阻止启动调试对象应用程序的愚蠢错误。

>我在VS2015上也遇到了同样的问题。令人沮丧的是，当我第二次运行调试器时，一个简单的 Hello World 程序给出了此错误。已尝试卸载并重新安装，但不起作用。

最后，https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug 中提到的解决方案

工作。使用"工具"->导入和导出"设置重置所有视觉工作室设置。现在问题没有发生。

相关文章：