I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do with a 
recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.

On Sat, 25 Apr 2009 10:54:36 -0700, Glenn Alcott wrote:

> I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do with 
a 
> recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.

I ran into the same thing, and tracked down the source with some help from
the forums. You'll find all the details here:

http://tinyurl.com/dbhr78

The offending HP app affects about 2% of my users.

HTH, but your problem might have a quite different cause.

-- 
Pete

> {quote:title=Peter Martin wrote:}{quote}
> On Sat, 25 Apr 2009 10:54:36 -0700, Glenn Alcott wrote:
> 
> > I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do wit
h a 
> > recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.
> 
> I ran into the same thing, and tracked down the source with some help from
> the forums. You'll find all the details here:
> 
> http://tinyurl.com/dbhr78
> 
> The offending HP app affects about 2% of my users.
> 
> HTH, but your problem might have a quite different cause.
> 
> -- 
> Pete

Thanks for the tip but I doubt this has anything to do with it, since I don't have any HP app on my system. Also, the fact that it's only happened recently (and I've been working on this app for 8 years) leads me to believe it's something recent in my code.

Are there any debugging tools out there that can solve problems like this (like the old BoundsChecker)?

Glenn

Glenn Alcott wrote:
> I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do with 
a 
> recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.

Most often, this is because a Thread is in "suspended" mode and "Free" 
is being called on it. But Free uses WaitFor which does not yield enough 
time for the thread to start and be terminated.
Or, you have a TThread that does not check its Terminated property often 
enough to stop itself fast when it is being asked to do so.

> {quote:title=Olivier Sannier wrote:}{quote}
> Glenn Alcott wrote:
> > I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do wit
h a 
> > recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.
> 
> Most often, this is because a Thread is in "suspended" mode and "Free" 
> is being called on it. But Free uses WaitFor which does not yield enough 
> time for the thread to start and be terminated.
> Or, you have a TThread that does not check its Terminated property often 
> enough to stop itself fast when it is being asked to do so.

Sorry, but this app does not use any threads.

Glenn Alcott a écrit :
> Also, the fact that it's only happened recently (and I've been working on this app for 8 years) leads me to believe it's something recent in my code.

Not necessary of your code only...
A long time ago, I noticed some changes in the comportment of one of my tools 
that was due from a windows update.
:-(

Pascal

Glenn Alcott wrote:

> > Most often, this is because a Thread is in "suspended" mode and
> > "Free" is being called on it. But Free uses WaitFor which does not
> > yield enough time for the thread to start and be terminated.
> > Or, you have a TThread that does not check its Terminated property
> > often enough to stop itself fast when it is being asked to do so.
> 
> Sorry, but this app does not use any threads.

Oh, that is what you think, but it may not reflect reality <g>.  You
may be using some 3rd-party code that internally uses threads. Did you
move to a new version of one of the 3rd-party things you use?

Unfortunately such problems are very hard to isolate if you cannot
reproduce them at will. Since you say that usually the taskbar button
remains (but I assume the forms are not visible anymore) the problem
seems to strike before the VCL has finished destroying the Application
object. So it may be connected to the destruction of a component you
use on any of the forms or data modules that are still around when the
application is closed.

You have not told us anything about what your application does, so it's
a bit hard to give any recommendations of where to look specifically.
Anyway, if you are using database access, don't rely on the database
connection being closed correctly when the datamodule or form
containing the access components is destroyed. Close the datasets and
connection in code when the app goes down (e.g. from the main forms
OnClose event). This way you can make sure everything is closed in the
correct sequence. The same applies to other connections to the world
outside your app, e.g. any TCP/IP communication channels, connection to
mail servers, open files, and so on. Usually these are all dealt with
OK by the standard cleanup done when the components you use are
destroyed, but sometimes there are interdependencies that require
things to be cleaned up in a particular sequence to avoid problems. So
it's better to be explicit in this area in my experience.


-- 
Peter Below (TeamB)  
Don't be a vampire (http://slash7.com/pages/vampires), 
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

> {quote:title=Peter Below wrote:}{quote}
> Glenn Alcott wrote:
> 
> > > Most often, this is because a Thread is in "suspended" mode and
> > > "Free" is being called on it. But Free uses WaitFor which does not
> > > yield enough time for the thread to start and be terminated.
> > > Or, you have a TThread that does not check its Terminated property
> > > often enough to stop itself fast when it is being asked to do so.
> > 
> > Sorry, but this app does not use any threads.
> 
> Oh, that is what you think, but it may not reflect reality <g>.  You
> may be using some 3rd-party code that internally uses threads. Did you
> move to a new version of one of the 3rd-party things you use?
> 
> Unfortunately such problems are very hard to isolate if you cannot
> reproduce them at will. Since you say that usually the taskbar button
> remains (but I assume the forms are not visible anymore) the problem
> seems to strike before the VCL has finished destroying the Application
> object. So it may be connected to the destruction of a component you
> use on any of the forms or data modules that are still around when the
> application is closed.
> 
> You have not told us anything about what your application does, so it's
> a bit hard to give any recommendations of where to look specifically.
> Anyway, if you are using database access, don't rely on the database
> connection being closed correctly when the datamodule or form
> containing the access components is destroyed. Close the datasets and
> connection in code when the app goes down (e.g. from the main forms
> OnClose event). This way you can make sure everything is closed in the
> correct sequence. The same applies to other connections to the world
> outside your app, e.g. any TCP/IP communication channels, connection to
> mail servers, open files, and so on. Usually these are all dealt with
> OK by the standard cleanup done when the components you use are
> destroyed, but sometimes there are interdependencies that require
> things to be cleaned up in a particular sequence to avoid problems. So
> it's better to be explicit in this area in my experience.
> 
> 
> -- 
> Peter Below (TeamB)  
> Don't be a vampire (http://slash7.com/pages/vampires), 
> use the newsgroup archives :
> http://www.tamaracka.com/search.htm
> http://groups.google.com

Peter,

Thanks for your response and for all your contributions to the Delphi forums over the years, many of which I have found invaluable.

Unfortunately, in this case you are only causing me further frustration <g> by telling me how difficult these things are to debug, which of course I already know!! But I guess I can't expect miracles.

This is a database application using Advantage Database. It doesn't do any TCP/IP, mail server connection, etc. There's been no change in the way it handles the database connection or opening/closing of datasets. I am going to have do a careful inspection of all my recent changes to see if I can find anything; at this point I don't know what else to do. Actually I'm not convinced that it's a serious problem because it's only been reported a few times and I have a very hard time duplicating it, but my clie
nt (the vendor of the app) is the one who gets to hear from the users and it's frustrating him so he wants to pursue it to some extent.

Glenn

> problem because it's only been reported a few times and I have a very
> hard time duplicating it, but my clie nt (the vendor of the app) is
> the one who gets to hear from the users and it's frustrating him so
> he wants to pursue it to some extent.

I can tell you have I found the HP problem with the shell.  

1) I had to duplicate it but since you are seeing it once in a while
you have a chance.
2) Install Process Explorer (now maintained by M$ but still free)
3) When it hangs and won't close run process Explorer
4) Look at all the handles and threads still alive in your app with PE
5) Use some physic debugging and start killing handles that seem like
they may have enough "power" that they may be hanging the app.  Hint:
Things like registry handles would not likely be "powerful" enough to
stop you app from closing.
6) When you hit the right one, i.e. the app suddenly finishes closing
after killing a handle, it will give you a better clue where the issue
may be.

Good luck,
Jim
-- 
www.mustangpeak.net

Glenn Alcott wrote:
> I am the developer of a widely distributed application written in Delphi 5. Recently there have been some reports from users that when closing the app, it remains in the taskbar and can only be terminated using Task Manager. I have occasionally seen this myself and have also seen an instance where it wasn't in the taskbar but the process was still running, but I haven't found any specific action that causes it. This has only been happening for the last few months so I assume it has something to do with 
a 
> recent code change, but I don't know exactly what causes this and have no idea how to search for the possible cause. I would appreciate any hints on what causes this and how to find the part of the code that needs fixing.

I have had this happen because of a deadlock on a TCriticalSection, or a 
background thread that never terminates, and I have also had this happen
when you have a low level USB problem with a device driver such as a 
serial port.  Even some Win32 APIs like CloseHandle could freeze 
forever.  I have also seen problems caused by mapped drives that are not
available on the network and network printers installed that are no 
longer visible on the network. And then there's anti-virus tools,
pre-loaded crapware (like the HP stuff someone mentioned).  You have
no shortage of options.  Pick three. :-)

If I'm in doubt, I would add some OutputDebugString messages, and use an 
ODS viewer to see the shutdown progress, just like you could see them if 
you were running in the debugger.


W