Not enough storage is available to process this co

问题:

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)

回答1:

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

回答2:

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.

回答3:

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.

回答4:

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..

回答5:

If you are just interested to make it work then restart your computer and it will work like a charm. I Had same kind of error in my application and then after reading all of the answer here at stackoverflow, I decided to first restart my computer before doing any other modifications. And it saved me a lot of time.

回答6:

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.

回答7:

If memory usage and VM size is small for devenv. Explicitly kill "ALL" instances of devenv.exe running.

I had 3 devenv.exe running where as I had two instances of Visual studion opened in front.

That was solution in my case.

回答8:

I know it has been a long time since this was commented on but I ran into this exact issue today with a telerik dll in VS2010. I had never seen this issue before until today when I was making some setting changes in IE.

There is a setting in Tools/Folder Option/View in the Files and Folders section called "Launch folder windows in a separate process".

I am not sure the amount of memory used for each window when using this setting but until today I have never had this checked. After checking this option for misc reasons I started getting the "not enough storage is available to process this command". The telerik dll is an 18mb dll that we are using located in our library folder as a reference in our project.

Unchecking this resolved the problem.

Just passing along as another possible solution

回答9:

I also faced the same problem. Make sure that the windows os is with 64bit. I switched to windows 64bit from windows 32bit. I problem got solved.

回答10:

I had this same issue and in my case, the exception name was very misleading. The actual problem was that the DLL couldn't be loaded at all due to invalid path. The exception i was getting said "

I used DllImport attribute in C#, ASP.NET application with declaration like below and it was causing the exception:

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

Below is working code snippet:

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

The actual problem was using forward slashes in path, instead of back slashes. This cost me way too much to figure out, hope this will help others.