We have a few Win32 applications (coded in Delphi 2006) where sometimes the user gets an error message saying \"System Error. Code: 8. Not enough storage is availabl
To me it was just a bunch of TJPEGImages decompressing in a slide-show manner that eventually ran out of memory.
If your program uses a lot of windows resources it could be a Resource Heap shortage.
There is a registry entry that can be increased to raise the heap size for XP. For Vista Microsoft already sets the default value higher. I recommend changing the default 3072 to at least 8192.
This information is documented in the MS Knowledge Base (or search for "Out of Memory"). Additional details concerning the parameter values may be found in article KB184802.
I suggest you read the knowledgebase article but the basic info on the change is:
Run Registry Editor (REGEDT32.EXE).
From the HKEY_ LOCAL_MACHINE subtree, go to the following key:
\System\CurrentControlSet\Control\Session Manager\SubSystem
On the right hand side of the screen double-click on the key:
windows
On the pop-up window you will see a very long field selected. Move the cursor near the beginning of the string looking for this (values may vary):
SharedSection=1024,3072,512
SharedSection specifies the System and desktop heaps using the following format: SharedSection=xxxx,yyyy,zzz
where xxxx
defines the maximum size of the system-wide heap (in kilobytes), yyyy
defines the size of the per desktop heap, and zzz
defines the size of the desktop heap for a "non-interactive" window station.
Change ONLY the yyyy
value to 8192 (or larger) and press OK.
Exit the Registry Editor and reboot the PC for the change to take effect.
Good luck.
You can use Desktop Heap Monitor from Microsoft to view heap statistics (use % etc.) and is available at:
http://www.microsoft.com/downloads/details.aspx?familyid=5cfc9b74-97aa-4510-b4b9-b2dc98c8ed8b&displaylang=en
Actually this is a problem with ATOM table. I reported this issue to Embarcadero as it is causing me a lot of grieves.
If you monitor global atom table you will see that Delphi apps are leaking atoms, leaving the id of your app without dropping it off from memory:
You will see loads of following items:
**Delphi000003B4*
*Controlofs0040000000009C0**
Basically, since you can't register more than 0xFFFF different windows messages ID as soon as you ask for another one, the system will return "System Error. Code: 8. Not enough storage is available to process this command". Then you will not be able to start any app that creates a window.
Another issue was reported in Embarcadero QC Central.
This issue presents itself under Windows 7 / Windows Server 2008. The fact that on Windows Server 2003 and before it used to run is because of a wrong implementation, which recycles ATOMs once their index wrapped around the maximum of 16384 units.
Feel free to use my Global Atom Monitor to check whether your Delphi apps are leaking atoms or not.
To fix this you'll need a patch from Embarcadero.
I noticed this error (System Error. Code: 8. Not enough storage...) recently when using some Twain code, it was happening on my computer and not my coworker's, and the only real difference between our machines is that I use the laptop screen as a second monitor, so my total desktop dimensions are larger.
I found documentation of the problem pointed to above by Steve Black, but I found a way (that fixed the error on my machine, at least) that does not require editing the registry:
The old code was using
DC := GetDC(Owner.VirtualWindow);
// ...
ReleaseDC(Owner.VirtualWindow, DC);
and I found that replacing it with this got rid of my errors
DC := CreateCompatibleDC(Owner.VirtualWindow);
// ...
DeleteDC(DC);
I don't know if this has relevance to your problem, but it may be helpful for others in the future.
There could be bugs in the compiler, it's a fair bet it's something in your app that is causing the problem. Could it be that your app is leaking window handles or some other GUI object like pens/brushes? This could be a cause.