You are not logged in.
Pages: 1
Some (general-purpose) suggestions are the following:
-If your application is not multi-threaded, do the process in background threads, then leave the main thread ready to process GDI messages;
-If your application is multi-threaded, take care that all VCL access from background threads are made via a Synchronize call;
-If your application is multi-threaded or use timers, take care that no method is re-entrant (in some circonstances, you may come into a race condition;
-Hunt any memory leak;
-Use a detailed logging of the program execution, logging all exceptions risen, to guess the context of the program hang (it may be used on the customer side also to hunt race conditions);
-Download the great free tool named ProcessExplorer (now hosted by Microsoft), and check out the state of your frozen program: you will see detailed information about threads, CPU use, memory, network, libraries, handles - this is a must have for any serious debugging - track especially the GDI handles leaks (number of those should remain stable);
-If you did not check it already, take a look at the global Windows system event log: there may be some information here;
-Perhaps a third party component or library is responsible of the process hang: try to isolate the part of your code which may be responsible of this hang.
I've Delphi application running for months without any problem. Issue is definitively in application code, not in the Delphi architecture (its RTL and VCL are very stable).
Offline
Pages: 1