Process Will Not Quit - Help

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a Windows executable written in C#. It is run by our customer in
three ways: from Windows Explorer, as a scheduled task, or kicked off by
another process.
When the exe is started by the other process, it completes its work but
then remiains resident in memory forever. When it is run as a task or by the
user, it completes and exits memory just fine.
Does anyone have an idea of what may be going on here?
 
You should trust the Garbage Collector. It will release the memory when the
object is no longer referenced by the calling process, meaning when it goes
out-of-scope.

Gabriel Lozano-Morán
 
Are you saying that you still see the process running in the Task
Manager, and you have to kill the process manually?
 
There is something in the program that is preventing it from terminating.
Is there any difference in your code as to how the program behaves when its
started by the user or started by another program? Are the exit paths
different for these two types of users?
 
Hi,

Did you did the calling process? Post the code used to execute it.

The only reason I can think of is it;s waiting for some input. Are you sure
it does finish executing? why don't you put a log as the last instruction of
the program.


cheers,
 
Gabriel Lozano-Morán said:
You should trust the Garbage Collector. It will release the memory when
the object is no longer referenced by the calling process, meaning when it
goes out-of-scope.

Gabriel Lozano-Morán
Click to expand...

The GC has absolutely nothing to do with this.

Willy.
 
I am not saying that the GC is the cause of the problem. But if we are
talking
about managed code here and the process does not get garbage collected then
there must be a reference in the calling process to the child process. I
have seen this a million times that people use global variables where they
store objects.

Chris Jones doesn't say wether the child process gets terminated once the
calling process is terminated. I am assuming that we are talking about a
long-living process.

Gabriel Lozano-Morán
 
Gabriel Lozano-Morán said:
I am not saying that the GC is the cause of the problem. But if we are
talking
about managed code here and the process does not get garbage collected
then
there must be a reference in the calling process to the child process. I
have seen this a million times that people use global variables where they
store objects.

Chris Jones doesn't say wether the child process gets terminated once the
calling process is terminated. I am assuming that we are talking about a
long-living process.

Gabriel Lozano-Morán
Click to expand...

Processes don't get garbage collected and processes don't hold references to
objects in other processes. Processes terminate when some codepath in that
process calls Environment.Exit or returns from the main entry routine, the
GC cannot prevent the process from terminating.The parent process cannot
prevent the termination of a child process either.
One reason why a process could remain in memory (non run-able however), is
when a managed foreground thread other than the main UI thread doesn't
terminate when asked to do so.

Willy.
 
Thanks for the replies. The C# exe is being kicked off from a Delphi app,
and I am including the relevant code below. The process stays resident in
memory (visible in the task manager) even after the parent process has exited.

Any thoughts?

if FileExists( PM_LOAD_PATH ) = True then
begin
ShellWait( PM_LOAD_PATH, '/l' );
sleep(1000);
end
 
Here's a thought... Put a return statement as the very first line in
you C# app, then have the Delphi app call it. That way you will know
whether it is something in the C# app, or in the ShellWait() call. If
the C# app does terminate, then you will know the Dephi app is probably
creating some condition (i.e. file lock) that is causing the C# app to
hang up.
 
Back
Top