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

时间:2009-06-15 12:44:56

标签: c# visual-studio visual-studio-2008 memory-leaks metadata

当我尝试在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),可能这就是这个bug的原因,我以前的项目中从未见过这样的事情。好吧,如果这就是我的问题是为什么会发生这种情况以及我需要做些什么来阻止它的原因。

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

我用Google搜索了这样的问题的答案。

建议通常与:

有关
  
      
  1. 指向WinXP中限制的用户处理程序数...
  2.   
  3. 到每个进程可用内存的物理限制
  4.   

我认为不能解释我的案例

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

我认为我的情况更接近这样一个事实:在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程序集大小是否有任何限制或建议? (是的,我知道重构并将大型程序集拆分成几个较小的部分,但它是第三方组件,我无法重建它

10 个答案:

答案 0 :(得分:19)

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

我认为这是你的“细分”所指的。如果不知道所有其他需要加载的细节以及其他占用2-3小时的活动,很难说这是否真的是原因。但是我不会把它放到不太可能的类别中,事实上它是最可能的原因。

答案 1 :(得分:16)

答案 2 :(得分:10)

正如安东尼指出的那样,错误信息有点误导。问题不在于你的程序集有多大,而是关于可用内存的连续性。

问题可能不是你装配的大小。 Visual Studio内部的某些内容更可能是将内存分段到构建无法完成的程度。这类问题的常见嫌疑人是

  1. 解决方案中的项目太多。
  2. 第三方插件
  3. 如果您在解决方案中有超过10个项目。尝试分解解决方案,看看是否有帮助。

    如果您有任何第三方插件,请尝试一次禁用一个,并查看问题是否消失。

答案 3 :(得分:3)

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

答案 4 :(得分:3)

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

答案 5 :(得分:2)

此问题的另一个原因可能是设计人员使用了太多类型的数据集。或者可以通过设计者实现的其他类型,例如许多表单上的许多数据绑定控件。 我想你的那种铁杆程序员虽然不会拖拽DS! :d

关于你的问题,Bogdan,你有没有尝试重现你的c ++组件加载的问题?如果你不能那么也许它。你是如何加载组件的?你尝试过其他技术,如后期绑定等吗?有什么不同吗?

其他: 是的你是对的,其他罪魁祸首是表格上有很多控件。我曾经在开发人员看到同样的问题,将一个非常VB6的应用程序导入.net。他有100个表格。几个小时后他会定期崩溃IDE。我很确定这是线程耗尽。可能值得设置一个香草盒,没有加载只是为了规则插件加载,但我猜你只是在VS和你的盒子规格的组合限制方面击中了墙。尝试运行Windows Vista 64bit并安装一些额外的RAM模块。

答案 6 :(得分:1)

如果devenv的内存使用量和VM大小很小。 显式杀死运行devenv.exe的“ALL”实例。

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

在我的案例中,这是解决方案。

答案 7 :(得分:1)

我知道这已经很长时间了,但是我今天在VS2010中遇到了一个telerik dll而遇到了这个问题。我之前从未见过这个问题,直到今天我在IE中进行了一些设置更改。

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

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

取消选中此解决了问题。

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

答案 8 :(得分:1)

我也遇到了同样的问题。 确保windows os是64位。 我从Windows 32bit切换到Windows 64位。我的问题解决了。

答案 9 :(得分:1)

我有同样的问题,在我的情况下,异常名称非常具有误导性。实际问题是由于路径无效而无法加载DLL。我正在说“

我在C#,ASP.NET应用程序中使用了DllImport属性,声明如下,它引起了异常:

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

以下是工作代码段:

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

实际问题是在路径中使用正斜杠而不是反斜杠。这让我付出太多代价,希望这会有助于其他人。