System Error. Code: 8. Not enough storage is available to process this command.

Question

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.

Answer 1

Can you post more of the stack trace?

You're actually asking question that can't be answered.

Notwithstanding 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, but it might not be possible to tell from the stack trace alone.

Answer 2

Used up all your Window or GDI Handles?

Answer 3

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 Knowledge Base Article ID 126962 (or search for "Out of Memory"). Additional details concerning the parameter values may be found in the Knowledge Base Article ID 184802.

I suggest you read the knowledgebase article but the basic info on the change is:

1) Run Registry Editor (REGEDT32.EXE).

2) From the HKEY_ LOCAL_MACHINE subtree, go to the following folder:

       \System\CurrentControlSet\Control\Session Manager\SubSystem

3) On the right hand side of the screen double-click on the key:

       windows

4) 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

5) 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 "noninteractive" window station.

6) Change ONLY the yyyy value to 8192 (or larger) and press OK.

7) Exit the Registry Editor and reboot the PC for the change to take effect.

Good luck

Answer 4

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