none
Out Of Memory during build in Visual Studio

    Question

  • Hi All,

    I have Visual Studio 2005 SP1, Win XP SP 2 on a machine with 2GB physical memory and over 200 GB free hard disk.

    I am getting out of memory exceptions from visual studio while building. It used to happen once a week or so, but now the frequency is up to 3-8 per day. It is getting insanely painful. The only way that I can seem to fix it is by restarting visual studio - which ends up being 5-15minutes of waiting. So as you can imagine - being forced to restart visual studio every couple of hours really sucks. The other people in my team get the same thing so it is not something specific to this machine.

    I am working on a fairly big solution - it has 102 projects including libraries, wcf services, some asp.net web services and a few client executables. Every time I get out of memory, there is always heaps of free memory reported by the task manager. Visual studio itself is using between 400-700 mb of memory and there is always 700-1.2 GB free physical memory.

    So, it manifests as a build error most frequently (occasionally it happens in the designer and other places - but I'll forget that for now since it is only once or twice a week) - randomly with no warning I get the build error:
    The "ResolveManifestFiles" task failed unexpectedly.
    System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.NativeMethods.GetAssemblyIdentityFromFile(String filePath, Guid& riid)
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.ImportAttributes()
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.get_Attributes()
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.AssemblyIdentity.FromManagedAssembly(String path)
       at Microsoft.Build.Tasks.ResolveManifestFiles.IsFiltered(ITaskItem item)
       at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssemblies(PublishInfo[] publishInfos, List`1& assemblyList)
       at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssembliesAndSatellites(PublishInfo[] assemblyPublishInfos, PublishInfo[] satellitePublishInfos)
       at Microsoft.Build.Tasks.ResolveManifestFiles.Execute()
       at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)

    It is always exactly the same build error (when the out of memory happens during a build). After it has happened, no amount of anything will get rid of it - the only solution I've found is to restart visual studio. The most bizzare part is that, there is always plenty of memory, and running a manual build with msbuild at the command line always works. The only thing I can think it could be is that visual studio has some internal memory limits, that it thinks it cannot use more than - then slowly leaks memory (or fragments the heap or whatever) up to this imaginary limit.

    So, hopefully someone can help in anyway. I am getting to the end of my rope with this situation, and unfortunately we have put loads of work and resources into this project - so I can't just go ditching it and/or switching to something else.

    So, any ideas at all?
    Monday, May 28, 2007 3:33 AM

Answers

  •  Maxpenguin wrote:
    I am working on a fairly big solution - it has 102 projects including libraries, wcf services, some asp.net web services and a few client executables. Every time I get out of memory, there is always heaps of free memory reported by the task manager. Visual studio itself is using between 400-700 mb of memory and there is always 700-1.2 GB free physical memory.

    The thing about .NET's OutOfMemoryException is the Garbage Collector (GC) throws it when the Generation 0 heap space runs out and it has not been able to steadily push older objects to Generation 1 and 2 zones. Generation 0 heap != actual free RAM. I do not know the exact specifics why the GC cannot keep up in such scenarios, but it is not just Visual Studio that can encounter this problem; any .NET program creating objects in an undesirable pace may induce it too.

     

    The unfortunate state of VS is it is a bus not a train (30+ passengers vs hundreds); it does not perform well (or stable) when given the job of dynamically handling such a large number of uncompiled projects. My advice is break that 102-project solution in multiple smaller solutions - they have been layered and modularised, so that isolated development can take place, no?

    Tuesday, May 29, 2007 3:43 AM
  • I suggest you contact customer support: http://support.microsoft.com/contactus/?ws=support

     

    Wednesday, May 30, 2007 2:00 PM

All replies

  • If you minimize/restore Visual Studio does the problem go away for a while?
    Monday, May 28, 2007 5:03 PM
  • Hi There,


    No, minimizing visual studio doesn't seem to help. It does drop like 400 mb of ram usage when minimized - then restoring and building it gets back up to about 160 mb. But still gives the same build error:

    The "ResolveManifestFiles" task failed unexpectedly.
    System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.NativeMethods.GetAssemblyIdentityFromFile(String filePath, Guid& riid)
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.ImportAttributes()
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.get_Attributes()
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.AssemblyIdentity.FromManagedAssembly(String path)
    at Microsoft.Build.Tasks.ResolveManifestFiles.IsFiltered(ITaskItem item)
    at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssemblies(PublishInfo[] publishInfos, List`1& assemblyList)
    at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssembliesAndSatellites(PublishInfo[] assemblyPublishInfos, PublishInfo[] satellitePublishInfos)
    at Microsoft.Build.Tasks.ResolveManifestFiles.Execute()
    at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)


    Any other ideas? Anything would be appreciated!

    By the way, if your interested - the one that just happened was #2 for today, and its not even lunch time yet...
    Tuesday, May 29, 2007 12:45 AM
  •  Maxpenguin wrote:
    I am working on a fairly big solution - it has 102 projects including libraries, wcf services, some asp.net web services and a few client executables. Every time I get out of memory, there is always heaps of free memory reported by the task manager. Visual studio itself is using between 400-700 mb of memory and there is always 700-1.2 GB free physical memory.

    The thing about .NET's OutOfMemoryException is the Garbage Collector (GC) throws it when the Generation 0 heap space runs out and it has not been able to steadily push older objects to Generation 1 and 2 zones. Generation 0 heap != actual free RAM. I do not know the exact specifics why the GC cannot keep up in such scenarios, but it is not just Visual Studio that can encounter this problem; any .NET program creating objects in an undesirable pace may induce it too.

     

    The unfortunate state of VS is it is a bus not a train (30+ passengers vs hundreds); it does not perform well (or stable) when given the job of dynamically handling such a large number of uncompiled projects. My advice is break that 102-project solution in multiple smaller solutions - they have been layered and modularised, so that isolated development can take place, no?

    Tuesday, May 29, 2007 3:43 AM
  • Hi,


    Thanks for your help. The solution is pretty heavily layered and modularized (which is some of the reason for the large number of projects), so it could be broken down without too much trouble. Still annoying, but I'd have to agree - better than having to restart the ide constantly. So thats what we will have to do.

    Is anybody else horrified at this? I mean, I know nothing is perfect, I don't know any of the specifics of how the gc handles memory and visual studio is huge and does do some really great things - but this is scary. I mean, at the moment our team is working on a large not-quite-enterprise level solution, and even the ide which itself is a large portion of .net code stresses it to the point where it can't keep up. I'm worried how its going to deal with the large workloads that it will get in production (certainly more work than a single human could stress visual studio) (yes, we have load balancing / distribution / fault tolerance / etc. but still).

    I guess that is why we have things like asp.net worker processors that automatically 'recycle' themselves frequently. Am I being unnecessarily paranoid (tinfoil hat style), or is this shocking to anybody else?

    This project isn't finished yet, and already it looks like we'll have to be migrating away from .NET very soon. I'd love to hear from Microsoft on this - how can .NET be anywhere near anything useful for decent sized business, if Visual Studio puts too much stress on the GC/.NET? Shouldn't we be telling people about this, to get the word out - so more people don't get caught up writing solutions with the fundamentally broken .NET? Am I taking it way too far to say fundamentally broken, probably. Sorry - I am getting rant-ish.

    Thanks for your help anyway,
    (and yes I will be expecting my local Microsoft hit man any minute now... hehe...)
    Tuesday, May 29, 2007 4:44 AM
  • So, (aside from my rant) this is now a CLR question. Can anybody provide some information on why the CLR wouldn't be able to handle this kind of workload?

    Also, is anybody else having something similar, from Visual Studio or otherwise?



    Thanks,
    Wednesday, May 30, 2007 4:07 AM
  • I would like to hear more about this.  I just recently starting receiving this error (System.OutOfMemory Exception) on builds as well.  It is starting to get worse (slowing) and is very annoying.  The only fix is to restart VS

     

    I am running VS 2005 SP1 on WinXP SP2 (with all the updates)... I also run SQL Server Express 2005 on my local machine.  I have a P4 3.2 Northwood with 2GB of RAM... and my task manager says there is more than 500 MB of RAM available at the time of the build error.

     

    This needs to be looked at!  My solution is a WinForms application with 22 projects in the solution.  I can break it up but would like to keep all projects in the same solution. 

     

    Is there any more information on what is possibly the issue?  Is there anything I can do differently?

     

    ward0093

    Wednesday, May 30, 2007 1:45 PM
  • Forgot to mention... I also get the error (System.OutOfMemory Exception) when trying to open one of our "Larger" WinForms in the designer.  The "InitializeComponent" throws the system.outofmemory exception and we can not work on our form!

     

    ward0093

    Wednesday, May 30, 2007 1:47 PM
  • I suggest you contact customer support: http://support.microsoft.com/contactus/?ws=support

     

    Wednesday, May 30, 2007 2:00 PM
  • Hello,

     

    I'm getting this error several times a day, while devloping an WPF application with VS2005 and WinFX November 2006 CTP tools. Sometimes devenv.exe consumes about 1GB of physical memory (my machine has only 1.5 GB physical RAM).

    For me it seems that the CTP is not very stable, MS should consider to release an update for that until Orcas is not available as stable build.

     

    Sven

    Wednesday, June 13, 2007 11:39 AM
  • I am trying to get MS a user dump right now... hopefully they will have some answers for us soon

     

    ward0093

    Wednesday, June 13, 2007 1:43 PM
  • My team and I are developing in VS 2005 using Workflow Foundation and we are getting out of memory errors all the time. We also have a WWF project that has a number of workflows and activities and it is ridiculously slow. Projects with a few classes seem to behave better but generally, it is becoming a nightmare. Anybody had the same problem, and even better, a solution?

    Thursday, November 29, 2007 7:02 PM
  •  Mr B581599 wrote:

    My team and I are developing in VS 2005 using Workflow Foundation and we are getting out of memory errors all the time. We also have a WWF project that has a number of workflows and activities and it is ridiculously slow. Projects with a few classes seem to behave better but generally, it is becoming a nightmare. Anybody had the same problem, and even better, a solution?

    If you're not specifically getting OOM exceptions during a build, I suggest ask this question over the at the WWF forum. Hijacking this thread is likely not going to get you the answer you desire.
    Thursday, November 29, 2007 8:06 PM
  • Our team has the same problem. We run VS 2005 SP1 on fully patched Windows XP machines with 2 GB internal memory and at least 40GB free harddisk space.

    We have a fairly big solution with several projects and we have to restart VS up to 10 times a day. The problems seem to be less after we changed our build configuration to not automatically build all the projects. We now manually rebuild the biggest project in the solution, but still we experience the OOM exceptions during building.

    Sunday, December 16, 2007 2:16 PM
  • i am having this problem too..
    what to do ?

    Tuesday, July 29, 2008 6:54 PM
  • Anyone solved the problem or have found any home made solution?

    . . .

    I hope.. and I wait..

    Thursday, August 28, 2008 1:08 PM
  • Hi all,

    I don't know if that can be of any help, but I had an Out Of Memory error when opening a Windows Form in Visual Studio 2005 designer. Not a particularly huge form but after adding a custom control, I started having that error.

    I could not figure it out until I hade the "brilliant" idea of looking at compile error and warnings more closely. The Error List did not show anything under the Errors but under Warnings I had a few errors (strangely enough). One of them was the Out of Memory error and an associated line number into the form's generated code. Double-clicking on that brought me to a location where an ImageList was being initialized but failed it seemed. I just removed that image list and the Out Of Memory error disappeared.

    Voilà!
    Friday, September 19, 2008 7:42 PM
  •  We've seen this problem too.

    I think VS2008 is actually missing address space more than actual memory. (You may want to check you have plenty of disk space too)

    You can look at here http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=971785&SiteID=1 and

    here http://social.msdn.microsoft.com/forums/en/vbide/thread/0a452345-a247-4327-abc3-5d85ca0c8216/

    for more information.

    Is your system working better just after a reboot?

    Vincent
    Wednesday, November 05, 2008 8:07 PM
  • Uninstall Resharper then reload the project...

    Same problem for me...I unintalled resharper now its very fine for me


    Regards
    Sai Saitish
    Indian Servers

    Saturday, August 08, 2009 9:18 AM
  • Hello everybody,

    I'd like to reopen this discussion, since it seems that Microsoft is cleary not doing anything in order to fix this. This is quite clear to me, because there is no released patch or service pack, and there are posts regarding this everywhere. This OutOfMemory issue is not something new, since VS2005 had the same problem.

    Unlinke prior posts, I am working in an enterprise level project with VS 2008 Professional, and this error keeps coming over and over again...

    From a developer's point of view, it seems to me that VS is leaking memory!

    I get the same error as my collegues above, but not immediately after loading my solution or building it for the first time. This occurs after several builds... And my solution has only 3 projects.

    I'm working with 4GB memory Core2 processor, plenty of HD space and plenty of free RAM, still I keep getting this freaking message:

     

    Task "GenerateApplicationManifest" c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2341,9): error MSB3171: Problem generating manifest. Insufficient memory to continue the execution of the program. Done executing task "GenerateApplicationManifest" -- FAILED. Done building target "GenerateApplicationManifest" in project "XYZ.vbproj" -- FAILED.

     


    I share Maxpenguin 's opinion, this is terrible! Sorry guys, it is... How's that, that VS is not supposed to support large projects? That can't be true... And to read from the posts above that minimizing and restoring a professional software should free some memory for me is just unbelievable...

    Is this task (manifest generation) too complex or memory intensive anyway? I wonder....

    Process Explorer shows that, at the moment of the error, Private Bytes = 480,064B, Virtual Size = 1,246,732B and Working Set = 529,884B, with available Physical Memory = 1,738,000B.

    If I close VS and reopen it, everything works fine, but only up to a x number of builds.

    I was told to reset my settings (didn't work), to "hack" VS and my boot.ini to use /3GB option... Cmon, it's time to release an update to fix this!

    Well.... Any suggestions? Should we developers file a pettition somewhere to get this working? :)

    Cheers,


    Rodrigo Silva - Systems Engineer
    Monday, March 22, 2010 7:07 PM
  • Hi All,

    I have Visual Studio 2005 SP1, Win XP SP 2 on a machine with 2GB physical memory and over 200 GB free hard disk.

    I am getting out of memory exceptions from visual studio while building. It used to happen once a week or so, but now the frequency is up to 3-8 per day. It is getting insanely painful. The only way that I can seem to fix it is by restarting visual studio - which ends up being 5-15minutes of waiting. So as you can imagine - being forced to restart visual studio every couple of hours really sucks. The other people in my team get the same thing so it is not something specific to this machine.

    I am working on a fairly big solution - it has 102 projects including libraries, wcf services, some asp.net web services and a few client executables. Every time I get out of memory, there is always heaps of free memory reported by the task manager. Visual studio itself is using between 400-700 mb of memory and there is always 700-1.2 GB free physical memory.

    So, it manifests as a build error most frequently (occasionally it happens in the designer and other places - but I'll forget that for now since it is only once or twice a week) - randomly with no warning I get the build error:
    The "ResolveManifestFiles" task failed unexpectedly.
    System.OutOfMemoryException: Insufficient memory to continue the execution of the program.
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.NativeMethods.GetAssemblyIdentityFromFile(String filePath, Guid& riid)
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.ImportAttributes()
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.MetadataReader.get_Attributes()
       at Microsoft.Build.Tasks.Deployment.ManifestUtilities.AssemblyIdentity.FromManagedAssembly(String path)
       at Microsoft.Build.Tasks.ResolveManifestFiles.IsFiltered(ITaskItem item)
       at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssemblies(PublishInfo[] publishInfos, List`1& assemblyList)
       at Microsoft.Build.Tasks.ResolveManifestFiles.GetOutputAssembliesAndSatellites(PublishInfo[] assemblyPublishInfos, PublishInfo[] satellitePublishInfos)
       at Microsoft.Build.Tasks.ResolveManifestFiles.Execute()
       at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)

    It is always exactly the same build error (when the out of memory happens during a build). After it has happened, no amount of anything will get rid of it - the only solution I've found is to restart visual studio. The most bizzare part is that, there is always plenty of memory, and running a manual build with msbuild at the command line always works. The only thing I can think it could be is that visual studio has some internal memory limits, that it thinks it cannot use more than - then slowly leaks memory (or fragments the heap or whatever) up to this imaginary limit.

    So, hopefully someone can help in anyway. I am getting to the end of my rope with this situation, and unfortunately we have put loads of work and resources into this project - so I can't just go ditching it and/or switching to something else.

    So, any ideas at all?


    Hi

    This is not really surprising, I mean there is only about 1.5GB (if that) of available local heap in your user login session/process.

    I bet you, if you were to move everything over to a 64-bit version of the OS the problem would vanish, You say you have over a hundred projects? that really is a lot you know.

    Move to x64 and the problem will vanish, on any MS 64-bit OS the available user mode address space jumps from 2GB to 8,000 GB.

    Cap'n

     

     

     

    Wednesday, March 24, 2010 1:21 AM
  • Hi,


    Thanks for your help. The solution is pretty heavily layered and modularized (which is some of the reason for the large number of projects), so it could be broken down without too much trouble. Still annoying, but I'd have to agree - better than having to restart the ide constantly. So thats what we will have to do.

    Is anybody else horrified at this? I mean, I know nothing is perfect, I don't know any of the specifics of how the gc handles memory and visual studio is huge and does do some really great things - but this is scary. I mean, at the moment our team is working on a large not-quite-enterprise level solution, and even the ide which itself is a large portion of .net code stresses it to the point where it can't keep up. I'm worried how its going to deal with the large workloads that it will get in production (certainly more work than a single human could stress visual studio) (yes, we have load balancing / distribution / fault tolerance / etc. but still).

    I guess that is why we have things like asp.net worker processors that automatically 'recycle' themselves frequently. Am I being unnecessarily paranoid (tinfoil hat style), or is this shocking to anybody else?

    This project isn't finished yet, and already it looks like we'll have to be migrating away from .NET very soon. I'd love to hear from Microsoft on this - how can .NET be anywhere near anything useful for decent sized business, if Visual Studio puts too much stress on the GC/.NET? Shouldn't we be telling people about this, to get the word out - so more people don't get caught up writing solutions with the fundamentally broken .NET? Am I taking it way too far to say fundamentally broken, probably. Sorry - I am getting rant-ish.

    Thanks for your help anyway,
    (and yes I will be expecting my local Microsoft hit man any minute now... hehe...)


    Nope, I'm far from horrified.

    You do realize that your login session (the process that runs Visual Studio) has less than 2GB to hold:

    All code: visual studio .exe, all dlls.

    All static data required by these.

    All stack (used heavily by compilers, which employ a lot of recursion, push-down automatons etc)

    All heap (used for any and ever dynamically created structures, again compilers do this a LOT)

    If the process has multiple threads (I'm sure Visual Studio start a few threads!) then this again adds to the consumption of memory.

    The reason your unhappy is that you can't actually see what is happening, but chances are - 3 or 4 weeks ago or perhaps 2 months ago or so, you weren't seeing this error were you?

    It's crept up on you, slowly, week by week and you had no idea, until WHAM !

    Cap'n

     

     

    Wednesday, March 24, 2010 1:29 AM
  • I tend to disagree with you Captain Kernel.

    Did you notice my post just above yours?

    • Private Bytes = 480,064B
    • Virtual Size = 1,246,732B
    • Working Set = 529,884B
    • Available Physical Memory = 1,738,000B

    It's quite obvious to me that 530MB is far, far below the 2GB session limit you're pointing. And manifest generation if far simpler than compiling a solution (task "GenerateApplicationManifest").

    And again, I must reinforce that this only happens after x times rebuilding of the solution.

    We have just migrated this project from VS2003 to VS2008. I've never had a problem like this while we were compiling using VS2003, which in my humble opinion was a far more robust environment than VS2008 or VS2010 is today.

    MS is shooting everywhere, releasing new frameworks each 6 months, and they're not considering quality as a must.

    Cap'n, you should google for this problem a bit, and see that there are lots, lots of programmers having the same thing happening to them.

    And it's not our problem if VS cannot handle, as you said, all static data, all stack and all heap eficiently.

    Cheers,


    Rodrigo Silva - Systems Engineer
    Wednesday, March 24, 2010 1:09 PM
  • I tend to disagree with you Captain Kernel.

    Did you notice my post just above yours?

    • Private Bytes = 480,064B
    • Virtual Size = 1,246,732B
    • Working Set = 529,884B
    • Available Physical Memory = 1,738,000B

    It's quite obvious to me that 530MB is far, far below the 2GB session limit you're pointing. And manifest generation if far simpler than compiling a solution (task "GenerateApplicationManifest").

    And again, I must reinforce that this only happens after x times rebuilding of the solution.

    We have just migrated this project from VS2003 to VS2008. I've never had a problem like this while we were compiling using VS2003, which in my humble opinion was a far more robust environment than VS2008 or VS2010 is today.

    MS is shooting everywhere, releasing new frameworks each 6 months, and they're not considering quality as a must.

    Cap'n, you should google for this problem a bit, and see that there are lots, lots of programmers having the same thing happening to them.

    And it's not our problem if VS cannot handle, as you said, all static data, all stack and all heap eficiently.

    Cheers,


    Rodrigo Silva - Systems Engineer


    Alright, I may be wrong it's happened before!

    If I were you then I'd try to get an answer to this question "has this memory exhaustion issue ever been reported for an x64 platform"? at least knowing this may help a little. For example you may be right, but the effort to install and run on a x64 OS simply as a test, is surely worth it?

    However I am also a little bothered by my idea too, because I now recall that the VS2008 exe always runs as a 32-bit app, so this may well mean I am off the mark.

    So at least try to rerun the same build test on an x64 version of XP or Vista and then dismiss the idea, one never knows in this business...

    Cap'n

     

     

     

    Thursday, March 25, 2010 2:37 PM
  • Hi, and thanks for your reply Cap'n

    We don't have an available x64 machine to test our solution right now, but I'll give it a try when possible.

    The main thing is that, if it works on x64 systems, x32 versions are still having problems like this and no replies from any MS representative at all.

    I really don't know what to do with this environment anymore. If it was possible, I would return to VS2003. :(

    Cheers,


    Rodrigo Silva - Systems Engineer
    Monday, March 29, 2010 5:22 PM
  • If your virtual memory is going up then it is likely to be heap fragmentation. Do you have any add-in's in your VS.NET? Usually these add-in's tend to cause the memory leak?

    You can also check "free" (sign of heap fragmentation) by attaching the process by attaching to windbg and using sos.

     

     


    Thanks Naveen http://naveensrinivasan.com
    • Proposed as answer by NaveenS Tuesday, April 06, 2010 1:57 PM
    Monday, March 29, 2010 5:48 PM
  • Hi NaveenS, thanks for your reply!

    We don't have any add-in installed.

    I will check the heap fragmentation as you said tomorrow since I'm not at work anymore, and I'll post the results here.

    Any clues about what might be causing this possible heap fragmentation, since no add-ins are installed? The only thing this solution uses is a bunch of Crystal reports, but it seems that this has nothing to do with the problem.

    Cheers,


    Rodrigo Silva - Systems Engineer
    Tuesday, March 30, 2010 10:21 PM
  • The cause of heap fragmentation is primarily pinning of memory by GC. Manoi (GC dev) has some great insights in to this.



    Thanks Naveen http://naveensrinivasan.com
    Wednesday, March 31, 2010 2:34 AM
  • Hi

    I agree that this might be the case indeed. Virtual memory keep raising build after build (but please notice that I'm just building and not running the application).

    But now I think I'm getting somewhere: I opened the manifest file (which is generated by the task I've mentioned above) and I saw that there were a bunch of image files in there, including hashes and other details, but these are files that my application was not deploying so they don't need to be present in there.

    Those entries look like the one below:

      <file name="Images\Logos\SS0088.JPG" size="5314">
        <hash>
          <dsig:Transforms>
            <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
          </dsig:Transforms>
          <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <dsig:DigestValue>1RwsWmYqu4S6TvLqMCBqpRBqqlE=</dsig:DigestValue>
        </hash>
      </file>

    This happened because VS adds images to the project with the 'Build Action' property set as 'Content'. I changed this to 'None' in order to remove those files from the manifest.

    By doing so, I reduced the manifest file size from 84,486 bytes to 13,620 bytes. Not something I would consider relevant, but the fact is that after doing this the error stoped .

    I will continue normal work during the day and let you know if this has really solved the problem. As far as it seems, something is wrong with manifest generation.

    Cheers,


    Rodrigo Silva - Systems Engineer
    Wednesday, March 31, 2010 2:20 PM
  • Hi guys,

    Just posting back to say that I had no more problems after I changed my solution as my post above.

    It really seems that there is something wrong with this specific task, when processing images.

    Anyone else think this is really weird, or is it just me?

    Cheers,


    Rodrigo Silva - Systems Engineer
    Monday, April 05, 2010 4:25 PM
  • Hi

    I agree that this might be the case indeed. Virtual memory keep raising build after build (but please notice that I'm just building and not running the application).

    But now I think I'm getting somewhere: I opened the manifest file (which is generated by the task I've mentioned above) and I saw that there were a bunch of image files in there, including hashes and other details, but these are files that my application was not deploying so they don't need to be present in there.

    Those entries look like the one below:

     

      <file name="Images\Logos\SS0088.JPG" size="5314">
    
        <hash>
    
          <dsig:Transforms>
    
            <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
    
          </dsig:Transforms>
    
          <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    
          <dsig:DigestValue>1RwsWmYqu4S6TvLqMCBqpRBqqlE=</dsig:DigestValue>
    
        </hash>
    
      </file>
    
    

     

    This happened because VS adds images to the project with the 'Build Action' property set as 'Content'. I changed this to 'None' in order to remove those files from the manifest.

    By doing so, I reduced the manifest file size from 84,486 bytes to 13,620 bytes. Not something I would consider relevant, but the fact is that after doing this the error stoped .

    I will continue normal work during the day and let you know if this has really solved the problem. As far as it seems, something is wrong with manifest generation.

    Cheers,


    Rodrigo Silva - Systems Engineer


    Well whatever else one can say, one thing is for sure, this is a very valuable discovery. It might simply be that somewhere deep down these images are not cleaned up by the GC as the build runs.

    Cap'n

    Tuesday, April 06, 2010 2:30 PM
  • Hi, I've been experience same problem here for several weeks

    try build solution first (shift + ctrl + B) before debuging your project (F5)

    it works for me and my team

     

    Hope this helps

    Friday, July 09, 2010 5:17 AM
  • Hi, I've been experience same problem here for several weeks

    try build solution first (shift + ctrl + B) before debuging your project (F5)

    it works for me and my team

     

    Hope this helps


    Hi mate,

    Thanks for the suggestion. But for me, the problem appeared after some builds even when I wasn't runinning the app.

    I've been attending to many MS official trainings in the last 6 months, and I hear a lot of complaints from programers about this issue. Everyone keeps closing and opening the solution at least 5 times a day, and still no official help from any MS engineer. And I've heard that VS2010 is behaving the same way.

    In my point of view, it's dificult to work with top technologies when you need to close the environment every 2 hours (at least!). :(

    After removing the images like I said above, the problem stoped for a while, then it came back to haunt me.

    Cheers,


    Rodrigo Silva - Systems Engineer
    Sunday, July 11, 2010 12:52 AM
  • I've been having the same problem and it is getting worse; today I can't hardly work on anything at all. It now seems to be associated with having a WinForm open in the designer. When I first start VS and open my Solution, devenv.exe is using about 138 MB. If I then open my applications main form in the designer, devenv.exe jumps to anywhere from 450 MB to 650 MB and I can no longer build with out getting OOM exceptions. Just closing the designer does not release the memory and neither does closing the Solution; I have to close the designer and then restart VS to get the memory back down to reasonable levels and then I am able to build.

    Of course, like others on this thread, the actual memory usage is well below the physical limits on my system. And my Solution only has a handful of projects and the form I'm opening is pretty minimal (just a DataGridView, Menu, and a couple Toolstrips).

    Monday, July 26, 2010 4:01 PM
  • Hi all,

    I don't know if that can be of any help, but I had an Out Of Memory error when opening a Windows Form in Visual Studio 2005 designer. Not a particularly huge form but after adding a custom control, I started having that error.

    I could not figure it out until I hade the "brilliant" idea of looking at compile error and warnings more closely. The Error List did not show anything under the Errors but under Warnings I had a few errors (strangely enough). One of them was the Out of Memory error and an associated line number into the form's generated code. Double-clicking on that brought me to a location where an ImageList was being initialized but failed it seemed. I just removed that image list and the Out Of Memory error disappeared.

    Voilà!

    It is exactly what I need, Nice writing, Many thanks to your description!
    Saturday, September 18, 2010 2:09 AM
  • Are you still seeing this? I haven't encountered this issue, but I'm wondering if it's due to an upgrade/patch for the later versions.

    Hi

    I agree that this might be the case indeed. Virtual memory keep raising build after build (but please notice that I'm just building and not running the application).

    But now I think I'm getting somewhere: I opened the manifest file (which is generated by the task I've mentioned above) and I saw that there were a bunch of image files in there, including hashes and other details, but these are files that my application was not deploying so they don't need to be present in there.

    Those entries look like the one below:

    {snip}

    This happened because VS adds images to the project with the 'Build Action' property set as 'Content'. I changed this to 'None' in order to remove those files from the manifest.

    By doing so, I reduced the manifest file size from 84,486 bytes to 13,620 bytes. Not something I would consider relevant, but the fact is that after doing this the error stoped.

    I will continue normal work during the day and let you know if this has really solved the problem. As far as it seems, something is wrong with manifest generation.

    Cheers,


    Rodrigo Silva - Systems Engineer

    Thursday, October 21, 2010 3:43 PM
  • Even I got the same error in my project. Workaround to this problem is to close Visual-Studio. Open project again. Clean solution and Rebuild it. It works for me...!!!
    Tuesday, December 07, 2010 7:34 AM
  • Hi

    I have the same error on VS 2010 on a big project. We are trying to seperate in little projec, but I agree this bug is a shame. Our project is big but far than a lot of project I have seen.

    Clean solution just deletes all the compiled and temporary file.It is not fix the problem for us.

    We have reduce the frequency of the bug by :

    - applying hotfix : https://connect.microsoft.com/VisualStudio/Downloads?wa=wsignin1.0

    - Increase memory 2go to 4.

    - hack" VS and boot.ini to use /3GB option

     

    But we didn't found THE solution...

    Thursday, February 03, 2011 9:59 AM
  • Our team is having the same problem in Visual Studio 2010. The project contains Silverlight applications, workflow projects and several Wcf services.

    Out current work around is to stop all ASP.NET development servers before building the solution.

    I wonder when will Microsoft fix this.

    Wednesday, June 22, 2011 2:28 AM
  • This is a "un - ethical " solution , but very useful work around ..

     

    try this, worked for me

     

     

    http://stevenharman.net/blog

    Thursday, July 07, 2011 12:26 PM
  • You can put FALSE at AutoToolBoxPopulate if you using a lot of Crystal Report.

    Go to Option-WindowsForms

    Sunday, March 11, 2012 11:57 PM
  • In my case the issue seems to be caused by building the workflow projects. It seems that when the solution is built and it contains workflow projects, memory uses for visual studio increases but doesn't go down once the build is completed. Probably the memory is not getting released properly once the build was finished.

    As a work around, we removed the workflow projects from build via configuration manager. We created a batch file to build the workflow projects using msbuild command line. So we build the workflow projects using the batch file, whenever there is a change in workflow, otherwise just use the visual studio build option.

    Thursday, August 23, 2012 7:38 PM