Not enough storage is available to process this command in VisualStudio 2008

Question

Hello!

When I try to compile an assembly in VS 2008, I got (occasionally, usually after 2-3 hours of work with the project) the following error

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

Usually to get rid of that I need to restart Visual Studio

The assembly I need to use in my project is BIG enough (> 70 Mb) and probably this is the reason of that bug, I've never seen some thing like this in my previous projects. Ok, if this is the reason my question is why this happens and what I need to do to stop it.

I have enough of free memory on my drives and 2Gb RAM (only ~1.2 Gb are utilized when exception happens)

I googled for the answers to the questions like this.

Suggestions usually related to: 1) to the number of user handlers that is limited in WinXP... 2) to the physical limit of memory available per process

I don't think either could explain my case

For user handlers and other GUI resources - I don't think this could be a problem. The big 70Mb assembly is actually a GUI-less code that operates with sockets and implements parsers of a proprietary protocols. In my current project I have only 3 GUI forms, with total number of GUI controls < 100.

I suppose my case is closer to the fact that in Windows XP the process address space is limited with 2 GB memory (and, taking into account memory segmentation, it is possible that I don't have a free segment large enough to allocate a memory). However, it is hard to believe that segmentation could be so big after just 2-3 hours of working with the project in Visual Studio. Task Manager shows that VS consumes about 400-500 Mb (OM + VM). During compilation, VS need to load only meta-data. Well, there are a lot of classes and interfaces in that library, but still I would expect that 1-2 Mb is more then enough to allocate metadata that is used by compiler to find all public classes and interfaces (though it is only my suggestion, I don't know what exactly happens inside CLR when it loads assembly metadata).

In addition, I would say that entire assembly size is so big only because it is C++ CLI library that has other um-managed libraries statically linked into one DLL. I estimated (using Reflector) that .NET (managed) code is approx 5-10% of this assembly.

Any ideas how to define the real reason of that bug? Are there any restrictions or recommendations as to .NET assembly size? (Yes I know that it worth thinking of refactoring and splitting a big assembly into several smaller pieces, but it is a 3rd party component, and I can't rebuilt it)

Answer 1

The error is misleading. It really should say "A large enough contiguous space in virtual memory could not be found to perform the operation". Over time allocations and deallocations of virtual memory space leads to it becoming fragmented. This can lead to situations where a large allocation cannot be filled despite there being a plenty total space available.

I think this what your "segmentation" is refering to. Without knowing all the details of everything else that needs to load and other activity which occupies the 2-3 hour period its difficult to say whether this really is the cause. However I would not put it into the category of unlikely, in fact it is the most likely cause.

Answer 2

As Anthony pointed out, the error message is a bit misleading. The issue is less about how big your assembly is and more about how much contiguous memory is available.

The problem is likely not really the size of your assembly. It's much more likely that something inside of Visual Studio is fragmenting memory to the point that a build cannot complete. The usual suspects for this type of problem are

1. Too many projects in the solution.
2. Third party add-ins

If you have more than say 10 projects in the solution. Try breaking up the solution and see if that helps.

If you have any 3rd party addins, try disabling them one at a time and seeing if the problem goes away.

Answer 3

Another cause for this problem can be using too many typed datasets via the designer. or other types that can be instaniated via a designer like lots of databound controls on lots of forms. I imagine your the sort of hardcore programmer though who wouldn't drag n' drop a DS! :D

in relation to your problem, Bogdan, have you tried to reproduce the problem w/o your c++ component loaded? If you can't then maybe its this. How are you loading the component? have you tried other techniques like late binding, etc? any difference?

Additional: Yes you are right, the other culprits are lots of controls on the form. I once saw this same issue with a dev that had imported a very VB6 app over to .net. he had literally 100's of forms. He would get periodic crashing of the IDE after a couple of hours. I'm pretty sure it was thread exhaustion. It might be worth setting up a vanilla box w/ no addins loaded just to rule addins out, but my guess is you are just hitting the wall in terms of a combined limiation of VS and your box specs. Try running Windows Vista 64bit and install some extra RAM modules.

Answer 4

Hi I'm struggling with similar issue.

Error 13 Metadata file '[...]\IKVM.OpenJDK.ClassLibrary.dll' could not be opened -- 'Not enough storage is available to process this command. '

The library has about 30MB, it is a third party. The issue came up when we started using this version library (previous were significantly smaller)

I'm able to work for some time, but then I have to restart IDE. This also happens to my colleagues on the team.

We are using Visual Studio 2005 SP. There are 98 projects in the solution. Windows XP SP3 2GB RAM available

At the time the problem occurs, VS consumes about 450 MB (with a few addins).

Answer 5

Hi,

In my case the following fix helped: http://www.jetbrains.net/confluence/display/ReSharper/OutOfMemoryException+Fix

Answer 6

I am getting this error on one of my machines and surprisingly, this problem is not seen on other dev machines. May be something wrong with VS installation. But I found an easier solution. If I delete the .suo file of teh solution and re-open the solution again, it will start working smoothly. Hope this will be useful for somebody in distress..