38

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)

Ghasem
  • 14,455
  • 21
  • 138
  • 171
Bogdan_Ch
  • 3,328
  • 4
  • 23
  • 39
  • 2
    I also may add that from time to time I'm getting OutOfMemory exceptions from time to time in Visual Studio when I working with that project. Usually it happens when I open a form in design view. – Bogdan_Ch Jun 16 '09 at 15:57
  • I suppose that this discussion that I initiated on ServerFault could be also usefull to those who read this discussion http://serverfault.com/questions/27352/are-there-any-drawbacks-of-3gb-switch-in-boot-ini-for-32bit-windows – Bogdan_Ch Jun 18 '09 at 08:56
  • of course this old issue was related only to 32 bit Windows and not a problem on 64bit – Bogdan_Ch Aug 14 '15 at 12:51
  • In my case, it was caused in a batch script, running a 32-bit IIS Express 7.5 on a machine with 16 GB RAM and multiple running "devenv.exe" instances. Solution 1 was to close all other possible applications (including devenv.exe), solution 2 was to use 64-bit IIS Express 8. Both solutions worked independently and, of course, also together. – Uwe Keim Apr 30 '19 at 10:32

10 Answers10

23

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.

AnthonyWJones
  • 187,081
  • 35
  • 232
  • 306
  • 1
    Thanks for your answer, I will tell you why I suppose this is unlikely: Imagine, that VS have to re-load assembly's metadata and requires a significant continuous chunk of memory for this, but it also has to unload the previous version! The size should be the same (referenced assembly is not changed in time, it is an assembly I got from 3rd party vendor). So, it could be very logical to think that when VS unloads previous version of assembly, it deallocates the same amount of continuos memory that required to load the same assembly again. Why it cannot use the same memory address ??? – Bogdan_Ch Jun 15 '09 at 14:01
  • @Bogdan_Ch: I think that's an over simplistic view of what really has to happen. Besides as Jared points out this is likely a combination of things. The reality is this error is nearly always due to address fragmentation. – AnthonyWJones Jun 15 '09 at 14:05
18

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

Daniel
  • 12,982
  • 3
  • 36
  • 60
zuraff
  • 204
  • 2
  • 2
  • cool! can you explain, if that tool has any side effects (like decreasing performance, other bugs etc.?) is it safe for use in everyday intensive development work? thanks in advance! – Bogdan_Ch Nov 09 '09 at 18:49
  • Hi, we're using it for a while on a solution with about 100 C# projects which reference lot of external assemblies. We didn't observe any significant slowdown or bugs which the tool could be blamed of. (VS is already a bit slower than we would like it to be, with that amount of code). – zuraff Nov 26 '09 at 16:05
  • cannot use for vs 2013 ! – Ali Yousefi Jun 02 '15 at 07:59
  • Page was removed. Any summary of what the fix was? – DanM7 Aug 29 '16 at 14:24
10

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.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • Thanks for your time, In fact I had only 2 projects in my solution and they are small or mid size (10-20K lines of code). I have only 1 addon - CodeRush from DevXpress... I will try to switch it off, and see if this helps. May be, this is really a good point to investigate, if CodeRush creates in memory any helper collections that consume memory proportionally to the number of interfaces in referenced assemblies... – Bogdan_Ch Jun 15 '09 at 14:10
  • Why is your assembly so large then? >70Mb seems pretty big for an assembly that is "GUI-less" and only has "10-20K lines of code". – Chris Dunaway Jun 15 '09 at 16:18
  • I meant to ask if there was any way to reduce the size of the assembly and if that would help with your problem? – Chris Dunaway Jun 15 '09 at 16:23
  • 20K lines of code, is the codebase of my own app. I use a 3rd party assembly that is 70Mb. As I wrote it is "C++ CLI library that has other unmanaged libraries statically linked into one DLL" . I suppose the size is so big because it includes a lot of C++ stuff inside. – Bogdan_Ch Jun 16 '09 at 15:52
  • 1
    Anthony, I disabled all add-ins, but I still getting either "Not enough storage..." or "Out of memory" exceptions in Visual Studio. I could also say that I could repeat the bug just in 5 minutes - all I have to do is open each form in my projects (4 forms) change something in layout, save, compile, and repeat this operation 3 or 4 times. I never see such a crazy behavior of VS when I work with previous projects, and I have all latest service packs, so I suppose the assembly size really matters in my case. So I will run now the last experiment - will try to set /3Gb option for WinXP – Bogdan_Ch Jun 16 '09 at 16:11
3

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

Sudheer Kumar
  • 311
  • 4
  • 16
3

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.

adeel41
  • 3,123
  • 1
  • 29
  • 25
2

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.

  • You are close to what I has been investigating recently - sure it is related to VS designer but it is connected not to datasets, rather to User controls and Forms. For sure, I'll post here my answer later, but right now I'm just not sure is this a problem in VS or in 3rd party library. – Bogdan_Ch Jun 19 '09 at 07:38
  • I'm having the same problem under Win7 with 4G Ram, so it is not the OS's fault. The assembly that I was trying to load was only 14M. Also I have 9 projects in my solution. zuraff's solution actually worked for me. – Thea Jun 16 '10 at 07:27
1

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.

Jas
  • 11
  • 1
1

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

Jon
  • 61
  • 3
1

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.

Kiran K Katkar
  • 51
  • 6
  • 1
    thanks for responding this old question :) yes, now 64 windows is not a problem, but this was 6 years ago... – Bogdan_Ch Aug 14 '15 at 12:50
1

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.

Sami Viitala
  • 31
  • 3