在 Visual Studio 2008 中没有足够的存储空间来处理此命令

Posted 2023-02-16

【中文标题】在 Visual Studio 2008 中没有足够的存储空间来处理此命令

【英文标题】：Not enough storage is available to process this command in VisualStudio 2008

【发布时间】：2010-11-03 00:18:48

【问题描述】：

当我尝试在 VS 2008 中编译程序集时，我得到了（偶尔，通常在项目工作 2-3 小时后）以下错误

Metadata file '[name].dll' could not be opened -- 
       'Not enough storage is available to process this command.

通常要摆脱这种情况，我需要重新启动 Visual Studio

我需要在我的项目中使用的程序集足够大（> 70 Mb），这可能是那个错误的原因，我在以前的项目中从未见过这样的东西。好的，如果这就是我的问题的原因是为什么会发生这种情况以及我需要做些什么来阻止它。

我的驱动器上有足够的可用内存和 2Gb RAM（发生异常时仅使用 ~1.2Gb）

我在谷歌上搜索了此类问题的答案。

建议通常与：

限制在 WinXP 中的用户处理程序的数量... 达到每个进程可用内存的物理限制

我认为两者都无法解释我的情况

对于用户处理程序和其他 GUI 资源 - 我不认为这可能是一个问题。 70Mb 的大程序集实际上是一个无 GUI 的代码，它使用套接字操作并实现专有协议的解析器。在我当前的项目中，我只有 3 个 GUI 表单，GUI 控件的总数

我想我的情况更接近于这样一个事实，即在 Windows XP 中，进程地址空间受限于 2 GB 内存（并且，考虑到内存分段，我可能没有足够大的空闲段来分配内存）。

但是，在 Visual Studio 中处理项目仅 2-3 小时后，很难相信细分会如此之大。任务管理器显示 VS 消耗大约 400-500 Mb (OM + VM)。在编译期间，VS 只需要加载元数据。

好吧，那个库中有很多类和接口，但我仍然希望 1-2 Mb 足以分配编译器用来查找所有公共的 元数据类和接口（虽然这只是我的建议，但我不知道CLR 在加载程序集元数据时到底发生了什么）。

此外，我会说整个程序集的大小之所以如此之大，仅仅是因为它是 C++ CLI 库，它具有其他 um 管理的库静态链接到一个 DLL 中。我估计（使用 Reflector）.NET（托管）代码约占该程序集的 5-10%。

任何想法如何定义该错误的真正原因？ .NET 程序集大小是否有任何限制或建议？ （是的，我知道值得考虑重构一个大组件并将其拆分为几个较小的部分，但它是第 3 方组件，我无法重建它）

【问题讨论】：

我还可以补充一点，当我使用该项目时，我会不时在 Visual Studio 中遇到 OutOfMemory 异常。通常当我在设计视图中打开表单时会发生这种情况。

我想我在 ServerFault 上发起的这个讨论对阅读这个讨论的人也很有用serverfault.com/questions/27352/…

当然这个老问题只与 32 位 Windows 相关，与 64 位无关

在我的例子中，它是由批处理脚本引起的，在具有 16 GB RAM 和多个运行“devenv.exe”实例的机器上运行 32 位 IIS Express 7.5。解决方案 1 是关闭所有其他可能的应用程序（包括 devenv.exe），解决方案 2 是使用 64 位 IIS Express 8。这两个解决方案独立工作，当然也可以一起工作。

【参考方案1】：

该错误具有误导性。它确实应该说“在虚拟内存中找不到足够大的连续空间来执行操作”。随着时间的推移，虚拟内存空间的分配和释放会导致它变得碎片化。这可能会导致尽管有足够的总空间可用，但无法填充大量分配。

我认为这就是您的“细分”所指的。在不了解需要加载的所有其他内容以及占用 2-3 小时时间的其他活动的所有细节的情况下，很难说这是否真的是原因。不过我不会把它归入不太可能的范畴，实际上这是最可能的原因。

【讨论】：

感谢您的回答，我会告诉您为什么我认为这不太可能：想象一下，VS 必须重新加载程序集的元数据并为此需要大量连续的内存，但它也有卸载以前的版本！大小应该相同（引用的组件没有及时更改，它是我从第 3 方供应商处获得的组件）。因此，认为当 VS 卸载以前版本的程序集时，它会释放与再次加载相同程序集所需的相同数量的连续内存，这可能是非常合乎逻辑的。为什么它不能使用相同的内存地址？？？

@Bogdan_Ch：我认为这对真正必须发生的事情过于简单化了。此外，正如 Jared 指出的那样，这可能是多种因素的结合。现实情况是，这个错误几乎总是由于地址碎片造成的。

【参考方案2】：

在我的情况下，以下修复有所帮助： http://confluence.jetbrains.net/display/ReSharper/OutOfMemoryException+Fix

【讨论】：

酷！您能否解释一下，如果该工具有任何副作用（如降低性能、其他错误等？）在日常密集的开发工作中使用是否安全？提前致谢！

嗨，我们在一个包含大约 100 个 C# 项目的解决方案中使用了一段时间，这些项目引用了很多外部程序集。我们没有观察到该工具可能被归咎于任何明显的减速或错误。 （使用这么多代码，VS 已经比我们希望的慢了一点）。

不能用于 vs 2013 ！

页面已被删除。有什么修复的总结吗？

【参考方案3】：

正如 Anthony 指出的那样，错误消息有点误导。问题不在于您的程序集有多大，而在于有多少连续内存可用。

问题可能不是您的程序集的大小。 Visual Studio 内部的某些东西更有可能将内存碎片化到构建无法完成的程度。这类问题的常见嫌疑人是

解决方案中的项目太多。 第三方插件

如果您的解决方案中有超过 10 个项目。尝试分解解决方案，看看是否有帮助。

如果您有任何第 3 方插件，请尝试一次禁用它们并查看问题是否消失。

【讨论】：

感谢您的宝贵时间，事实上，我的解决方案中只有 2 个项目，它们是中小型项目（10-20K 行代码）。我只有 1 个插件 - DevXpress 的 CodeRush ......我会尝试将其关闭，看看是否有帮助。可能，这确实是一个很好的调查点，如果 CodeRush 在内存中创建任何辅助集合，这些集合消耗的内存与引用的程序集中的接口数量成正比......

为什么你的程序集那么大？ >70Mb 对于“无 GUI”且只有“10-20K 行代码”的程序集来说似乎相当大。

我的意思是问是否有任何方法可以减小程序集的大小，这是否有助于解决您的问题？

20K 行代码，是我自己的应用程序的代码库。我使用 70Mb 的第 3 方程序集。正如我所写的那样，它是“C++ CLI 库，它具有静态链接到一个 DLL 中的其他非托管库”。我想它的大小是如此之大，因为它里面包含了很多 C++ 的东西。

Anthony，我禁用了所有加载项，但在 Visual Studio 中仍然出现“存储空间不足...”或“内存不足”异常。我也可以说我可以在 5 分钟内重复该错误 - 我所要做的就是打开项目中的每个表单（4 个表单）更改布局、保存、编译并重复此操作 3 或 4 次。当我处理以前的项目时，我从未见过 VS 如此疯狂的行为，而且我拥有所有最新的服务包，所以我认为程序集大小对我来说真的很重要。所以我现在将运行最后一个实验 - 将尝试为 WinXP 设置 /3Gb 选项

【参考方案4】：

我在我的一台机器上遇到此错误，令人惊讶的是，在其他开发机器上未发现此问题。 VS安装可能有问题。 但我找到了一个更简单的解决方案。 如果我删除解决方案的 .suo 文件并再次重新打开解决方案，它将开始顺利运行。 希望这对处于困境的人有用..

【参考方案5】：

如果您只是想让它工作，然后重新启动您的计算机，它就会像魅力一样工作。我在我的应用程序中遇到了同样的错误，然后在 *** 上阅读了所有答案后，我决定先重新启动计算机，然后再进行任何其他修改。它为我节省了很多时间。

【讨论】：

重启对我有用，我认为这是因为我的电脑连续睡眠太多次而没有重启。

【参考方案6】：

导致此问题的另一个原因可能是通过设计器使用了过多的类型化数据集。或其他可以通过设计器实例化的类型，例如大量表单上的大量数据绑定控件。 我想你是那种不会拖放 DS 的铁杆程序员！ :D

关于您的问题，Bogdan，您是否尝试过在不加载 c++ 组件的情况下重现该问题？如果你不能那么也许它的这个。你是如何加载组件的？您是否尝试过其他技术，例如后期绑定等？有什么区别吗？

补充： 是的，你是对的，其他罪魁祸首是表单上有很多控件。我曾经在将一个非常 VB6 应用程序导入到 .net 的开发人员身上看到同样的问题。他实际上有 100 种表格。几个小时后，他会定期崩溃 IDE。我很确定这是线程耗尽。设置一个没有加载插件的香草盒子可能是值得的，只是为了排除插件，但我的猜测是，就 VS 和盒子规格的组合限制而言，你只是碰壁了。尝试运行 Windows Vista 64 位并安装一些额外的 RAM 模块。

【讨论】：

您与我最近调查的内容很接近——确定它与 VS 设计器有关，但它未连接到数据集，而是连接到用户控件和表单。当然，我稍后会在这里发布我的答案，但现在我不确定这是 VS 还是 3rd 方库中的问题。

我在 Win7 下使用 4G Ram 也遇到了同样的问题，所以这不是操作系统的错。我试图加载的程序集只有 14M。我的解决方案中还有 9 个项目。 zuraff 的解决方案实际上对我有用。

【参考方案7】：

如果内存使用量和 VM 大小对于 devenv 来说很小。 明确杀死正在运行的 devenv.exe 的“所有”实例。

我运行了 3 个 devenv.exe，因为我在前面打开了两个 Visual studion 实例。

这就是我的解决方案。

【参考方案8】：

我知道这已经很久没有评论了，但是我今天在 VS2010 中遇到了一个 Telerik dll 的确切问题。直到今天我在 IE 中进行一些设置更改时，我才发现这个问题。

在“文件和文件夹”部分的“工具/文件夹选项/视图”中有一个设置，称为“在单独的进程中启动文件夹窗口”。

我不确定使用此设置时每个窗口使用的内存量，但直到今天我从未检查过此设置。出于其他原因检查此选项后，我开始收到“没有足够的存储空间来处理此命令”。 Telerik dll 是一个 18mb 的 dll，我们使用它位于我们的库文件夹中，作为我们项目中的参考。

取消选中此项可解决问题。

只是作为另一种可能的解决方案传递

【参考方案9】：

我也遇到了同样的问题。 确保 Windows 操作系统是 64 位的。 我从 windows 32bit 切换到 windows 64bit。我的问题已经解决了。

【讨论】：

感谢您回答这个老问题 :) 是的，现在 64 个窗口不是问题，但这是 6 年前...

【参考方案10】：

我遇到了同样的问题，就我而言，异常名称非常具有误导性。实际问题是由于路径无效，DLL 根本无法加载。我被说的例外“

我在 C#、ASP.NET 应用程序中使用了 DllImport 属性，声明如下，它导致了异常：

   [DllImport(@"Calculation/lib/supplier/SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]

下面是工作代码sn-p：

[DllImport(@"Calculation\lib\supplier\SupplierModule.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, EntryPoint = "FunctionName")]

实际的问题是在路径中使用正斜杠，而不是反斜杠。这花费了我太多的时间来弄清楚，希望这对其他人有帮助。