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 available to process this command.".
From the stacktrace it looks like it is always during CreateWnd call
Main ($1edc): 004146cc +070 app.exe SysUtils RaiseLastOSError 00414655 +005 app.exe SysUtils RaiseLastOSError 004ce44c +130 app.exe Controls TWinControl.CreateWnd 00535a72 +022 app.exe cxControls TcxControl.CreateWnd 004ce82a +016 app.exe Controls TWinControl.CreateHandle 00553d21 +005 app.exe cxContainer TcxContainer.CreateHandle 00586ef1 +005 app.exe cxEdit TcxCustomEdit.CreateHandle 005c331d +005 app.exe cxDropDownEdit TcxCustomDropDownEdit.CreateHandle 004ceaf0 +074 app.exe Controls TWinControl.UpdateShowing 004ceb1e +0a2 app.exe Controls TWinControl.UpdateShowing 004cebdc +03c app.exe Controls TWinControl.UpdateControlState 004d118a +026 app.exe Controls TWinControl.CMVisibleChanged 004cb713 +2bb app.exe Controls TControl.WndProc 004cf569 +499 app.exe Controls TWinControl.WndProc 004b727d +4c1 app.exe Forms TCustomForm.WndProc 004cb3a0 +024 app.exe Controls TControl.Perform 004c9f6a +026 app.exe Controls TControl.SetVisible 004b6c46 +03a app.exe Forms TCustomForm.SetVisible 004baf1b +007 app.exe Forms TCustomForm.Show 004bb151 +14d app.exe Forms TCustomForm.ShowModal 007869c7 +0d3 app.exe UfrmPrice 770 +19 TfrmPrice.EditPrice 0078655d +009 app.exe UfrmPrice 628 +0 TfrmPrice.actNewBidExecute 00431ce7 +00f app.exe Classes TBasicAction.Execute 004c2cb5 +031 app.exe ActnList TContainedAction.Execute 004c397c +050 app.exe ActnList TCustomAction.Execute 00431bb3 +013 app.exe Classes TBasicActionLink.Execute 004af384 +090 app.exe Menus TMenuItem.Click 004b059f +013 app.exe Menus TMenu.DispatchCommand 004b16fe +082 app.exe Menus TPopupList.WndProc 004b164d +01d app.exe Menus TPopupList.MainWndProc 004329a8 +014 app.exe Classes StdWndProc 7e4196b2 +00a USER32.dll DispatchMessageA 004bea60 +0fc app.exe Forms TApplication.ProcessMessage 004bea9a +00a app.exe Forms TApplication.HandleMessage 004becba +096 app.exe Forms TApplication.Run 008482c5 +215 app.exe AppName 129 +42 initialization
I've never been able to get to the bottom of what causes this and as it happens fairly seldom I haven't been to concerned, but I would like to find out what causes it and hopefully rectify it...
EDIT: Full Stacktrace
EDIT 2: More info... The client who experienced this today has had my app installed for about 4 months and it is running on his PC 8 hours a day. The problem only appeared today and kept reappearing even though he killed my app and restarted it. None of the other apps on his system behaved strangely. After a reboot the problem goes away completely. Does this point towards the heap shortage that Steve mentions?
EDIT 3: Interesting msdn blog post here and here on the topic of the desktop heap. Though I'm not sure whether this is the cause of the problem it certainly looks likely.
Not enough storage is available to process the command is a common issue in Windows. It usually occurs when the system encounters registry errors, or a driver malfunctions or when it runs out of memory. The easiest fix is to restart the PC and start over again.
Actually this is a problem with ATOM table. I reported this issue to Embarcadero (saved in Wayback Machine) 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 (saved in Wayback Machine) 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, or download ControlsAtomFix1.7z from www.idefixpack.de/blog/downloads.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With