System.Design - Not enough memory resources
-
Possible? Sure. Common? ??? Ordinarily, dotNet objects are managed. Is is possible, through System.Runtime.InteropServices to call unmanaged code, and obtain pointers to unmanaged data objects. I don't think very many dotNet programmers will do that in cases where there is a managed alternative. Re. Dispose: Sure, you do not know exactly when GC will come in and release the memory / handles occupied. But if resources run low, the GC will attempt to release non-referable resources; it will not just sit down and wait for the system to crash, the way you seem to suggest.
A trick that I use is to wrap the objects I use into common classes so that I use them and free them up as soon as possible. The classes all have a Draw method and, in the Draw, I acquire the resource, paint it to the screen, and then release the resource immediately. The code I use to draw the objects doesn't need a Dispose method because the underlying object is disposed as soon as it is finished with. I find that this really helps me keep track of my allocations.
-
Possible? Sure. Common? ??? Ordinarily, dotNet objects are managed. Is is possible, through System.Runtime.InteropServices to call unmanaged code, and obtain pointers to unmanaged data objects. I don't think very many dotNet programmers will do that in cases where there is a managed alternative. Re. Dispose: Sure, you do not know exactly when GC will come in and release the memory / handles occupied. But if resources run low, the GC will attempt to release non-referable resources; it will not just sit down and wait for the system to crash, the way you seem to suggest.
trønderen wrote:
Possible? Sure. Common? ???
You'd be amazed at how many people don't know this stuff.
trønderen wrote:
Re. Dispose: Sure, you do not know exactly when GC will come in and release the memory / handles occupied. But if resources run low, the GC will attempt to release non-referable resources;
If memory runs low, the GC will jump in and execute a collect. The GC doesn't look at the handle pool at all to determine if it should run or not. If your code is leaking handles like crazy, but memory is not being stressed at all, the GC will not collect. Yes, I've seen it happen myself, with a service that Dell wrote, back in the day.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
It may not be a memory issue, but it certainly could be a handle leak issue. It sounds like you're running the handle pool dry because you're not freeing resources properly, like Bitmaps, Pens, or other drawing objects. Open Task Manager, Details tab, right-click the column header row and pick "Select columns". Turn on Handles and GDI Objects. Then go look at you app in the list. If the handles count just keeps climbing over time, you're not releasing objects properly.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Dave Kreskowiak wrote:
freeing resources properly, like Bitmaps, Pens, or other drawing objects.
The originating error is "Could not load file or assembly" How would graphic resources cause that?
Keep reading the error message:
Not enough memory resources are available to process this command
That can be memory limited, handle limited, or other resources or issues, like memory fragmentation.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
I have recently starting getting a memory resources error with System.Design. The application has been running fine for years and this just started popping up without any code changes. This has been encountered on multiple PCs.
Could not load file or assembly 'System.Design, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Not enough memory resources are available to process this command. (Exception from HRESULT: 0x80070008)
The application is running on .NET 4.6.1. The app is taking up around 400 MB of memory and I have over 10 GB RAM free on my PC. So I don't think it is a PC resource issue. After the error occurs I start seeing issues in the OpenFileDialog. The icons are black squares and parts of the UI of the form don't show up. The file name and file type drop down will be missing. Here is the stack trace:
at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.PopulateNestedClasses(Filter filter)
at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.GetListByName(Char* pName, Int32 cNameLen, Byte* pUtf8Name, Int32 cUtf8Name, MemberListType listType, CacheType cacheType)
at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.Populate(String name, MemberListType listType, CacheType cacheType)
at System.RuntimeType.RuntimeTypeCache.MemberInfoCache`1.GetMemberList(MemberListType listType, String name, CacheType cacheType)
at System.RuntimeType.GetNestedTypeCandidates(String fullname, BindingFlags bindingAttr, Boolean allowPrefixLookup)
at System.RuntimeType.GetMember(String name, MemberTypes type, BindingFlags bindingAttr)
at System.Type.GetMember(String name, BindingFlags bindingAttr)
at Microsoft.VisualBasic.CompilerServices.Symbols.Container.LookupNamedMembers(String MemberName)
at Microsoft.VisualBasic.CompilerServices.Symbols.Container.GetMembers(String& MemberName, Boolean ReportErrors)
at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateSet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean OptimisticSet, Boolean RValueBase, CallTypJoshWilliams wrote:
The application has been running fine for years...taking up around 400 MB of memory and I have over 10 GB RAM...VisualBasic
First noting of course that a 32 bit application is not going to use 10 GB of memory even if it exists. Last time I looked into this (last year) the apps that had been built years ago required setting a flag explicitly to make them into 64 bit apps. There it a attribute somewhere that you can read (and log) to see exactly whether it is 32/64 bit. I suggest using that explicitly to check. Second what is missing in your description is whether you have also been modifying that same application for years. If you haven't then the problem is with the environment or due to load. If you have been modifying then the problem could either be due to the modifications or to load. You can test for load problems at least for memory by starting the application up with a reduced memory space. That artificially forces memory problems to show up. Of course you must still exercise the application after that.
JoshWilliams wrote:
Here is the stack trace:
The stack trace for a resource exhaustion is generally almost worthless because the exhaustion is just telling you where it ran out. It does NOT tell you, most of the time, where the code exists that is using it all up. The entire application is responsible for the resources. So code completely un-associated with the code that you are looking at could be doing something that uses it up. I will mention the following because the error occurs when loading an assembly. This unfortunately is very esoteric and not easy to follow (even when someone already knows something about memory handling.) But it is something that developers should be aware of. Large object heap (LOH) on Windows | Microsoft Learn[^] I think there might be a way to increase this. If you do change it and the error goes away you must keep in mind that you have put a bandaid on a gushing wound and you still need to find the actual problem.
-
Keep reading the error message:
Not enough memory resources are available to process this command
That can be memory limited, handle limited, or other resources or issues, like memory fragmentation.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakDave Kreskowiak wrote:
That can be memory limited, handle limited, or other resources or issues, like memory fragmentation.
However I was asking about the following specifically which is why I referenced it:
"Bitmaps, Pens, or other drawing objects."
So you are suggesting that they could have loaded so many graphic objects that it is those that caused the memory to fill up and that it did so without running into a graphic resource error which I believe is a different error?
-
Dave Kreskowiak wrote:
That can be memory limited, handle limited, or other resources or issues, like memory fragmentation.
However I was asking about the following specifically which is why I referenced it:
"Bitmaps, Pens, or other drawing objects."
So you are suggesting that they could have loaded so many graphic objects that it is those that caused the memory to fill up and that it did so without running into a graphic resource error which I believe is a different error?
Yes! Creating such objects and not properly freeing them CAN and DOES trigger out of memory exceptions, not resource exceptions. I don't have to time to write up a test app right now, but there's nothing stopping you from trying it. Oh, and exhausting the Windows handle table can crash various things in Windows, like an OpenFileDialog or MessageBox, and even crash Windows itself. Every object type in Windows has a handle assigned to it. A handle is just a void pointer to a data structure in memory. Windows, buttons, menus, icons, bitmaps, pens, mutexes, threads, a structure, opening a file, basically, anything in Win32 that has a pointer or handle type that begins with "h", all of these objects end up in the handle (or object) table in Windows. Pretty much ... EVER-Y-THANG. Read up on the Object Manager here[^].
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Yes! Creating such objects and not properly freeing them CAN and DOES trigger out of memory exceptions, not resource exceptions. I don't have to time to write up a test app right now, but there's nothing stopping you from trying it. Oh, and exhausting the Windows handle table can crash various things in Windows, like an OpenFileDialog or MessageBox, and even crash Windows itself. Every object type in Windows has a handle assigned to it. A handle is just a void pointer to a data structure in memory. Windows, buttons, menus, icons, bitmaps, pens, mutexes, threads, a structure, opening a file, basically, anything in Win32 that has a pointer or handle type that begins with "h", all of these objects end up in the handle (or object) table in Windows. Pretty much ... EVER-Y-THANG. Read up on the Object Manager here[^].
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakCan dotNet run out of memory if the computer has plenty? If you run e.g. Task Manager | Performance | Memory, or Resource Monitor | Memory (I guess there are similar tools from 3rd parties as well), and they tell you that you've got lots of free memory, could dotNet still report that you are out of memory? Can it decide not to use what is available? If any free (that includes 'Standby' in Resource Monitor terms) memory can be used by dotNet, keeping a window open with Resource Monitor or Task manager would be a very simple way to see if your problem is with memory or with, say, handles.
-
Can dotNet run out of memory if the computer has plenty? If you run e.g. Task Manager | Performance | Memory, or Resource Monitor | Memory (I guess there are similar tools from 3rd parties as well), and they tell you that you've got lots of free memory, could dotNet still report that you are out of memory? Can it decide not to use what is available? If any free (that includes 'Standby' in Resource Monitor terms) memory can be used by dotNet, keeping a window open with Resource Monitor or Task manager would be a very simple way to see if your problem is with memory or with, say, handles.
trønderen wrote:
Can dotNet run out of memory if the computer has plenty?
Yes, for a variety of reasons. For example, large heap fragmentation. You try to allocate a large object, but there is not a "hole" in the Large Object heap big enough to allocate the object, even though there is technically enough memory to hold it if you add up all the "holes" to get the size of "available" memory.
Quote:
If any free (that includes 'Standby' in Resource Monitor terms) memory can be used by dotNet, keeping a window open with Resource Monitor or Task manager would be a very simple way to see if your problem is with memory or with, say, handles.
If you're running into a handle exhaustion problem, if you try to even launch Task Manager, you can end up with it crashing just trying to create its own window. You are thinking in simple terms of everything. "Free memory" is treated as a single contiguous block in Task Manager, but that's not how memory is really represented. What you're not seeing is "largest available block" of memory. You also seem to think Windows can track an unlimited number of objects in the Object Manager handle table. It can't. Read up on it here[^].
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
JoshWilliams wrote:
The application has been running fine for years...taking up around 400 MB of memory and I have over 10 GB RAM...VisualBasic
First noting of course that a 32 bit application is not going to use 10 GB of memory even if it exists. Last time I looked into this (last year) the apps that had been built years ago required setting a flag explicitly to make them into 64 bit apps. There it a attribute somewhere that you can read (and log) to see exactly whether it is 32/64 bit. I suggest using that explicitly to check. Second what is missing in your description is whether you have also been modifying that same application for years. If you haven't then the problem is with the environment or due to load. If you have been modifying then the problem could either be due to the modifications or to load. You can test for load problems at least for memory by starting the application up with a reduced memory space. That artificially forces memory problems to show up. Of course you must still exercise the application after that.
JoshWilliams wrote:
Here is the stack trace:
The stack trace for a resource exhaustion is generally almost worthless because the exhaustion is just telling you where it ran out. It does NOT tell you, most of the time, where the code exists that is using it all up. The entire application is responsible for the resources. So code completely un-associated with the code that you are looking at could be doing something that uses it up. I will mention the following because the error occurs when loading an assembly. This unfortunately is very esoteric and not easy to follow (even when someone already knows something about memory handling.) But it is something that developers should be aware of. Large object heap (LOH) on Windows | Microsoft Learn[^] I think there might be a way to increase this. If you do change it and the error goes away you must keep in mind that you have put a bandaid on a gushing wound and you still need to find the actual problem.
This here is what I would guess is the most likely answer. Look at the build configuration and explicitly make everything build x64. There may exist scenarios where you would have to explicitly build x86, but explicit x64 is what's generally been the golden hammer for these things in my life. It's not truly "out of memory". It's just confused. Would lean toward this being near certainty if you hit it right upon app start or possibly the first shot at some specific app action.