2

I have a strange problem: My Delphi application raises an EOutOfRessources exception just after starting up on a Application.CreateForm call. Is somebody out there, who solved such a problem?

The strange things are

  • that this happens on a single machine only. I do not have this problem on other computers
  • that the application runs properly, if a teleservice is active (we use Danware NetOP). If teleservice is not running (Netop waits for a guest log in), the application fails.

The application was developed under D7; OS is WinXP SP3.

Thanks for your help

--- Update 1 ---

Application uses EurekaLog to catch exceptions and to store error information. It says, the EOutOfRessources happens on Application.CreateForm (some 50 forms already created, a few other forms pending to create), the message is "out of system ressources". Exception address is 7C81EB2E.

The EurekaLog also provides the call stack :

|*Exception Thread: ID=2088; Priority=0; Class=; [Main]                 |
|-----------------------------------------------------------------------|
|7C81EB2E|kernel32.dll|           |     |                       |       |
|77D56C4F|user32.dll  |           |     |CreateIcon             |       |
|7C9205D4|ntdll.dll   |           |     |RtlAllocateHeap        |       |
|7C9110ED|ntdll.dll   |           |     |RtlLeaveCriticalSection|       |
|77D2058E|user32.dll  |           |     |SystemParametersInfoA  |       |
|77D205A3|user32.dll  |           |     |SystemParametersInfoA  |       |
|7C809AE4|kernel32.dll|           |     |VirtualAllocEx         |       |
|7C809AA2|kernel32.dll|           |     |VirtualAllocEx         |       |
|7C809A94|kernel32.dll|           |     |VirtualAlloc           |       |
|0060E359|_765013.exe |_765013.dpr|     |                       |235[58]|
|7C91E64C|ntdll.dll   |           |     |NtSetInformationThread |       |
-------------------------------------------------------------------------

Total memory use is about 60 MB; the application has some 20 MB in use.

I do not know the used number of handles; EurekaLog does not provide this.

--- Update 2 ---

Now we exchanged the PC by another one of same type. The exception did not raise again. However, we had a similar effect on another machine, now not being able to open a file during Application.CreateForm. The file name string was empty ... After a number of poor people resets (power shut down) the problem disappeared.

We suspect, that the exceptions are caused by a network problem. At this customer, we have four applications running (per two identical projects). They share data over a company network; for that there is a NAS. Network login is done with Windows start up, about 2 minutes before starting the applications. Teleservice runs over company network too.

The question is now, if Application.CreateForm is trying to get connected to network. Our OnCreate event handlers do not require an open network. The applications' source code is on the NAS too (encrypted by TrueCrypt). After compilation we copy the EXE and all other needed files to a local hard drive and run the application from that place. Normally, the TrueCrypt container is closed. Could it happen, that the EXE is searching for some files on NAS resp. the TrueCrypt container?

Maybe, somebody is familiar with such issues. Thanks for your help.

BughunterRZ
  • 21
  • 2
  • 2
    Similar question, [`Hunting down EOutOfResources`](http://stackoverflow.com/q/2180345/576719). – LU RD Sep 24 '13 at 07:50
  • It's probably either a memory leak or a handle leak in whatever code is doing the waiting around looking for the NetOP service. Without code what can we say? – J... Sep 24 '13 at 10:39
  • @BughunterRZ: please, edit the question to provide the complete exception message. – AlexSC Sep 24 '13 at 10:48
  • Do you really need to create 50+ forms at startup? That could kill available system resources. Try to create/destroy those forms dynamically instead. – LU RD Sep 25 '13 at 08:17
  • Thank you, I will try that. However, it will take some time, since this application is used by a customer some 300 miles away. We will have to test this on site; in a teleservice session all workes properly. On the other hand: we shipped more than 100 similar projects over the last 10 years. None of them has such a problem ... – BughunterRZ Sep 25 '13 at 10:19
  • If you manage to solve this problem with resources, I would suggest that you rearrange your code to separate the GUI from business logic. Put the logic in datamodules and let the real-time task be controlled from other datamodules or be driven by threads. – LU RD Sep 26 '13 at 06:28
  • @LU RD That's right, the IDE automatically creates all forms at startup of the application. Until now, that was not so bad for us, since our application runs a realtime communication to embedded controls. Since the number of included modules varies from application to application, communication is done by a special refresh method of the forms themselves - they **must** be alive all time the application is open. This approach is working for many years now; I would not like to change it 'on the fly'. Let me try another attempt to catch the bug. There is a exception logging tool "MadExcept", whic – BughunterRZ Sep 26 '13 at 06:19
  • @LU RD Thank you, I will try that. However, it will take some time, since this application is used by a customer some 300 miles away. We will have to test this on site; in a teleservice session all workes properly. On the other hand: we shipped more than 100 similar projects over the last 10 years. None of them has such a problem ... – BughunterRZ Sep 25 '13 at 10:26
  • The only resources I allow to be created at startup is the main form and datamodules that must run throughout the application lifetime. I know the IDE automatically adds all new forms to be autocreated at startup, which is bad in my opinion. – LU RD Sep 25 '13 at 10:59
  • That's right, the IDE automatically creates all forms at startup of the application. Until now, that was not so bad for us, since our application runs a realtime communication to embedded controls. This communication is done by a special refresh method of the forms - they **must** be alive all time the application is open. – BughunterRZ Sep 26 '13 at 06:10
  • You are right, on the long term we should do that. Maybe even for this project in a quick and dirty manner ... Prior to deciding, let's wait for results with an other exception logging tool on an other machine. My collegues just prepare this test. I'll post the results here in a few days – BughunterRZ Sep 26 '13 at 06:32

0 Answers0