|
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.
|
|
|
|
|
You may be right, but how common is it is to address "bitmaps, pens or other drawing objects" directly when you are running dotNet? Usually, that means C# or -as it looks like here - VB, with its GC. Usually it also means UI tools at a higher level, such as WPF.
It is still possible you have (functionally obsolete, but still valid) pointers to a large number of objects so that they can't be GCed, and these objects hold handles so that they can't be GCed. It could still be a handle leak issue, but the fundamental problem may lie in (say) C# objects not being made GCable - which is generally done by removing the last reference (i.e. pointer) to them, not by any explicit freeing operation.
In C#, you can use 'using' to hint the GC that it may free an object, but this is just a hint to reduce memory load. The GC should be running a GC cycle when memory gets low without such hints. I never worked in VB, and don't know if it has anything similar to 'using'.
|
|
|
|
|
It's actual quite easy. For example, if you create a Bitmap object, you're just creating a wrapper around an unmanaged GDI object with a handle associated with it. Failing to Dispose the Bitmap properly and letting the Bitmap go out of scope will allow the GC to collect the wrapper object, and call the Dispose method on it, but not in a deterministic manner, meaning you have no idea when the handle will be released. This can result in you piling up handles waiting to be released and exhausting the handle pool before the GC can get around to freeing the Bitmap objects.
The same goes for all GDI related objects, files, and anything else being backed by unmanaged Windows 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.
|
|
|
|
|
trønderen wrote: Ordinarily, dotNet objects are managed
Yup. The reference is, but things like handles aren't. A lot of the runtime is a wrapper around the existing libraries.
Means one cannot rely on the GC to close those neatly if there's no dispose called.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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[^].
|
|
|
|
|
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[^].
|
|
|
|
|
You should be able to track it down with GFlags
Don't let the documentation scare you, it's not only for device driver developers.
How to use Gflags
|
|
|
|
|
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.
|
|
|
|
|
I'm trying to paste a sub routine into an existing windows form project
|
|
|
|
|
What is your question?
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
|
|
|
|
|
|
If you want an answer that makes any sense at all, you're going to have to add a whole lot more detail to your "question."
|
|
|
|
|
If I want to publish an app for public consumption (in the Microsoft Store), in the past I just compiled it to AnyCpu, and targeted a low enough .NET Framework to not worry about the prerequisite runtime (that was probably wrong). But now I'm updating my app to .NET 7, and I have to assume most users won't already have it. Do I need to compile 3 separate packages, one each listing a prerequisite for the .NET 7 runtime for x64, x86, and ARM, or will it install only the correct version if I mark them all as prerequisites, or is there some way to set prerequisites conditionally? What is the right use and purpose of AnyCpu if you always need to confirm that the right, specific runtime is installed? I'm a self-taught, very amateur programmer, so I think I need to stick to the simple installers Visual Studio creates rather than some self-assembled command-line system that might be able to manually figure out what needs to be installed on every computer.
|
|
|
|
|
|
Yuppers wrote: Do I need to compile 3 separate packages,...
What you actually need to do specifically is test it in all of the environments you are going to claim to support. If it works (when tested) then you do not need to do anything differently. If it fails testing then you will need to decide what changes are needed.
|
|
|
|
|
You might consider whether .NET 7 is appropriate versus .NET 6. The pattern has generally been for every other .NET release to be an LTS (long-term service~3yrs) release versus an STS (~1.5yrs) release.
.NET 7 will hit end of support May 14, 2024.
.NET 6 will hit end of support November 12, 2024.
Meanwhile, we should see an LTS of .NET 8 in November.
|
|
|
|
|
Free code for Convert image pdf to text in c#
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
