Paul mentioned madExcept. If you're not using this, you should really consider it. It's invaluable for tracking down in-the-field problems. Here's part of an exception report from one of our apps (names changed to protect the innocent!): date/time : 2007-05-01, 15:12:32, 557ms computer name : APCSomewhere user name : Some User <admin> registered owner : some-user operating system : Windows XP Service Pack 2 build 2600 system language : English system up time : 42 minutes 10 seconds program up time : 31 minutes 11 seconds processors : 2x Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz physical memory : 1301/2046 MB (free/total) free disk space : (C:) 23.36 GB display mode : 1280x800, 32 bit process id : $c40 allocated memory : 48.41 MB command line : "SomeExe.exe" "SomeParam=SomeValue" executable : SomeExe.exe exec. date/time : 2007-05-01 09:37 version : 7.0.0.132 madExcept version : 3.0c callstack crc : $26cb1e41, $e28343ad, $925632c2 exception number : 1 exception class : EInvalidOp exception message : Invalid floating point operation. main thread ($ad8): 00412e84 SomeExe.exe SysUtils 11505 DateTimeToTimeStamp 00413115 SomeExe.exe SysUtils 11674 DecodeDateFully 00413257 SomeExe.exe SysUtils 11734 DecodeDate 00413404 SomeExe.exe SysUtils 11843 IncMonth 007f8f10 SomeExe.exe SomeForm 963 GetNextDateTime ...
You can build in your own little bits of code to add extra pertinent information to the collection of information above (so I presume you could add some code to check for your potential GDI/resource leaks), plus you get stack traces for all your threads at the moment of the crash. HTH, Conor ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trevor Jones Good point Rohit, I hadn't even thought of resource leaks. That might explain a lot. Trouble is, the OS is so locked down that Task manager is not available. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rohit Gupta 1. We have something similar right now to do with Crystal Reports. I fairly sure that I have found the two problems in it. One is that callback from a dll is into a nested procedure with local variables and could be called after the object has been destroyed. The other is to do with strings. The more strings we pass to the dll the faster the crash. Basically memory/stack/registers are getting trashed leading to nonsense errors and even the app just disappearing. 2. Running out of resources. Open the task manager and keep an eye on GDI objects (the worst), User Obects, Handles etc GDI is the worst. Windows goes crazy, you cant even shut down. Old version of Nero used to do this. And ODBC driver for MSSQL did/does it too. Trevor Jones wrote: Hello, Just wondering if any of you have encountered really weird bugs and support issues on machines that have been running for a long time (without a reboot).
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
