BorlandTalk.com

Dodgy · Guest

This is the problem:

Delphi and some Delphi applications are hanging when closed under
Windows XP. They disappear from the taskbar and from the Applications
list, but the main VCL thread remains occupying 100% CPU in the
Process list.

Compatibility Mode magically works around the issue, but I've found
that it causes the software to misbehave elsewhere and so isn't an
answer :(

The machines at the centre of this are all one model of Dell Xeon
running XP Corporate. On brand new machines with clean XP installs,
everything is fine. But after a few months operation, with updated
drivers, critical updates, and so on and so forth, the problem appears
and won't go away.

A search at Google Groups reveals an unhealthy number of other people
with this exact same problem, but nobody seems to know what's going
on. It's clear that a utility, patch, update, or particular
application, is causing Delphi to act odd and not quit gracefully.

But does anyone know which one?

Dodgy.
--
MUSHROOMS ARE THE OPIATE OF THE MOOSES

Jamie · Guest

i have always found starting with W2k if you were not carefull with the
use of free'd objects you can cause problems like you desribe.
because it may seem appearent that its ok on a fresh PC does not mean
there is something wrong with some installs of Apps and windows updates.
the fact that running your app in a compat mode reduces the effects
tell me that you are using objects from the OS that are no longer what
they were before. i know this because i too also had an that acted fine
on 9x boxes and ok on some XP's and bad on others but would change when
changing the COmpat mode.
in my case it was an app that uses the Audio API's , i closed down an
input wave stream then in my code still made a Media access using that
handle which was still set to the same value but not really valid.. in
9x boxes the memory manager places returned memory at the bottom of the
pile and thus new request of memory are taken from the top, so in many
cases some API functions would just work before the data it was looking
at was still valid..
starting with W2k, memory release is place at the top of the pile for
imediate re'use. this makes memory management more efficient because
page swaping is reduced..
if there is alot of activity in the Pc its very possible that return
ed memory and freed handles and memory that served them get reused else
where rite away! in my case i was getting some strange effects with the
GDI and sometimes the app would hang up on exit.
TO fix the problem was a simple matter of properly not using
un-unitiated objects and memory.
check your code to make sure you are not freeing objects more than
once and accessing closed handles etc..

Dodgy wrote:

Dodgy · Guest

On Mon, 26 Jan 2004 14:30:39 -0800, Jamie
<jamie_5_not_valid_after_5 (AT) charter (DOT) net> waffled on about something:

<snip>

I've tracked down the problem with the 100% CPU on application quit.

It's a bizarre conflict with a WISE library file that hooks each
application you run. The following HKEY_LOCAL_MACHINE string

SOFTWAREMicrosoftWindows NTCurrentVersionWindowsAppInit_DLLs

if renamed from "SetupHook.dll" to "Bananas and Custard" (or whatever,
just not "SetupHook.dll") will cause the mysterious hangs to stop.

Googling reveals links to more information:

http://techsupt.winbatch.com/TS/T000001056F40.html

It's funny. Even WISE don't know what it's for, which of course is yet
another good reason to use InnoSetup instead :D

Anyway, may the Prince of Darkness claw at the souls of WISE coders
for all time they've wasted, and may this message help some other poor
soul out of a hole at some future time...

D0d6y.
--
MUSHROOMS ARE THE OPIATE OF THE MOOSES