Process won't die when form is closed.

[Edwin Smith]

I have a form which displays a DataGridView table generated with the VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or may
not be related.

My next step is to start over from scratch since it's fairly easy to rebuild
once I have screenshots of my queries etc...

Edwin

[Lau Lei Cheong]

Try call Application.Exit() instead.

If it works, check the line Application.Run() whether it is the form your
DataGridView is running on.

If not, run it in Debug mode. Try closing the application and click Pause
after the screen goes off to see where your code stuck at.

"Edwin Smith" <sm**********@aol.com¼¶¼g©ó¶l¥ó·s»D:uG************ **@TK2MSFTNGP05.phx.gbl...

>I have a form which displays a DataGridView table generated with the VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to
close the form the .exe refuses to die and has to be killed in Task
manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or
may not be related.

My next step is to start over from scratch since it's fairly easy to
rebuild once I have screenshots of my queries etc...

Edwin

[Bruce Wood]

On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:

I have a form which displays a DataGridView table generated with the VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or may
not be related.

My next step is to start over from scratch since it's fairly easy to rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.

[Edwin Smith]

When I run it in debug mode it works fine and exits properly. Of course the
app doesn't run in it's own executable then, it's running in the debugger so
the debugger doesn't tell me anything.

If I run it in it's own executable then when I click the X on the form or
click the close button I added, the form closes but the app is still running
in memory and is "orpahned".

I'll look for the "background thread" problem suggested in the other reply
to my post.

Thanks

Edwin

"Lau Lei Cheong" <le****@yehoo.com.hkwrote in message
news:OP**************@TK2MSFTNGP04.phx.gbl...

Try call Application.Exit() instead.

If it works, check the line Application.Run() whether it is the form your
DataGridView is running on.

If not, run it in Debug mode. Try closing the application and click Pause
after the screen goes off to see where your code stuck at.

"Edwin Smith" <sm**********@aol.com>
¼¶¼g©ó¶l¥ó·s»D:uG**************@TK2MSFTNGP05.phx.g bl...

>>I have a form which displays a DataGridView table generated with the
VS2005 tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to
close the form the .exe refuses to die and has to be killed in Task
manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto the form and put "this.Close();" in for it's event but I get the
same result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes
properly but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or
may not be related.

My next step is to start over from scratch since it's fairly easy to
rebuild once I have screenshots of my queries etc...

Edwin

[Edwin Smith]

"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:

>I have a form which displays a DataGridView table generated with the
VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to
close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes
properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or
may
not be related.

My next step is to start over from scratch since it's fairly easy to
rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.

I never know whether it's proper to reply before or after the quoted text.

The database code is generated by VS2005 code behind the TableAdapter. I can
trace through it with the debugger so I'll see if there's any IsBackground
properties. Or do you mean there is an IsBackground property that can be set
in the visual designer? I'll check those.

Thanks

Edwin

[Edwin Smith]

"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:

>I have a form which displays a DataGridView table generated with the
VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to
close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes
properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or
may
not be related.

My next step is to start over from scratch since it's fairly easy to
rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.

Does the code generator for the TableAdapter.Fill generate background
threads for ODBC connections? Since this is filling a DataGridView table it
DOES get the entire table in memory before it displays the form. Then it
disconnects from the database. ( I think)

Or is the background thread just an automagic thing and I have to insert the
IsBackground property somewhere in order for the code to shutdown properly?

I searched the entire project and the text "IsBackground" does not appear
anywhere.

AFAIK this project runs in a single thread since I have not explicetly set
anything for multithreaded operation. I'm not that sophisticated a
programmer yet so multithreading is way over my head.

Thanks

Edwin

[Bruce Wood]

On Feb 26, 12:02 pm, "Edwin Smith" <[e-mail]:

AFAIK this project runs in a single thread since I have not explicetly set
anything for multithreaded operation. I'm not that sophisticated a
programmer yet so multithreading is way over my head.

Well, the way to tell is to watch and see whether the user interface
freezes while the application is fetching data from the database. If,
during the data fetch, the application is still responsive, then it's
multi-threading. If it freezes, then the DB fetch is being done on the
UI thread and locking it up.

Try searching your app for "Thread" and see what you find.

[Willy Denoyette [MVP]]

"Edwin Smith" <sm**********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>
"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

>On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:

>>I have a form which displays a DataGridView table generated with the VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the generated
code behind the TableAdapter. If I comment it out the form closes properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may or may
not be related.

My next step is to start over from scratch since it's fairly easy to rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.

Does the code generator for the TableAdapter.Fill generate background threads for ODBC
connections? Since this is filling a DataGridView table it DOES get the entire table in
memory before it displays the form. Then it disconnects from the database. ( I think)

Or is the background thread just an automagic thing and I have to insert the IsBackground
property somewhere in order for the code to shutdown properly?

I searched the entire project and the text "IsBackground" does not appear anywhere.

AFAIK this project runs in a single thread since I have not explicetly set anything for
multithreaded operation. I'm not that sophisticated a programmer yet so multithreading is
way over my head.

Thanks

Edwin

In this case it means that the code is stucked (or deadlocked) in the main thread (are you
sure your Main is marked STAThread ?), probably in the Pervasive ODBC driver.
To be sure you'll have to attach a debugger to the process and check which thread is waiting
and what he is waiting for.
Another option is to get a copy of process explorer (procexp.exe) from www.syinternals.com
(now on msdn) and watch the offending process threads and their stacks.

Willy.

[Edwin Smith]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OL**************@TK2MSFTNGP05.phx.gbl...

"Edwin Smith" <sm**********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>>
"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.googlegr oups.com...

>>On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:
I have a form which displays a DataGridView table generated with the
VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.

The DataGridView works great except when I'm done and I click the X to
close
the form the .exe refuses to die and has to be killed in Task manager.

I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto
the form and put "this.Close();" in for it's event but I get the same
result.

Using trial/error troubleshooting seems to point to some of the
generated
code behind the TableAdapter. If I comment it out the form closes
properly
but then of course my DataGridView doesn't work.

Anyone have a similar problem?

I'm also having a VS2005 lockup problem (on another thread) which may
or may
not be related.

My next step is to start over from scratch since it's fairly easy to
rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.

Does the code generator for the TableAdapter.Fill generate background
threads for ODBC
connections? Since this is filling a DataGridView table it DOES get the
entire table in
memory before it displays the form. Then it disconnects from the
database. ( I think)

Or is the background thread just an automagic thing and I have to insert
the IsBackground
property somewhere in order for the code to shutdown properly?

I searched the entire project and the text "IsBackground" does not
appear anywhere.

AFAIK this project runs in a single thread since I have not explicetly
set anything for
multithreaded operation. I'm not that sophisticated a programmer yet so
multithreading is
way over my head.

Thanks

Edwin

In this case it means that the code is stucked (or deadlocked) in the main
thread (are you
sure your Main is marked STAThread ?), probably in the Pervasive ODBC
driver.
To be sure you'll have to attach a debugger to the process and check which
thread is waiting
and what he is waiting for.
Another option is to get a copy of process explorer (procexp.exe) from
www.syinternals.com
(now on msdn) and watch the offending process threads and their stacks.

Willy.

Thanks for the reply;

I downloaded Process Explorer and This is what it shows for the program.

There are 3 threads of note: I have a BMP screen shot if you need to see
what else is there. It's to large to post however.

!GetMetaDataPublicInterfaceFromInternal+0xd30 --Wait:DelayExecution

Two others:

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

All the rest say Wait: UserRequest

I haven't a clue what all this means but hopefully you or somebody else
does.

Thanks

Edwin

[Willy Denoyette [MVP]]

"Edwin Smith" <sm**********@aol.comwrote in message
news:u5**************@TK2MSFTNGP06.phx.gbl...

>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OL**************@TK2MSFTNGP05.phx.gbl...

>"Edwin Smith" <sm**********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>>>
"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.googleg roups.com...
On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:
I have a form which displays a DataGridView table generated with the
VS2005
tools. The database is a Pervasive v.9 with an ODBC driver.
>
The DataGridView works great except when I'm done and I click the X to
close
the form the .exe refuses to die and has to be killed in Task manager.
>
I ran a debug trace and it seems to work fine. I dropped a CLOSE button
onto
the form and put "this.Close();" in for it's event but I get the same
result.
>
Using trial/error troubleshooting seems to point to some of the
generated
code behind the TableAdapter. If I comment it out the form closes
properly
but then of course my DataGridView doesn't work.
>
Anyone have a similar problem?
>
I'm also having a VS2005 lockup problem (on another thread) which may
or may
not be related.
>
My next step is to start over from scratch since it's fairly easy to
rebuild
once I have screenshots of my queries etc...

This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.

You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.
Does the code generator for the TableAdapter.Fill generate background
threads for ODBC
connections? Since this is filling a DataGridView table it DOES get the
entire table in
memory before it displays the form. Then it disconnects from the
database. ( I think)

Or is the background thread just an automagic thing and I have to insert
the IsBackground
property somewhere in order for the code to shutdown properly?

I searched the entire project and the text "IsBackground" does not
appear anywhere.

AFAIK this project runs in a single thread since I have not explicetly
set anything for
multithreaded operation. I'm not that sophisticated a programmer yet so
multithreading is
way over my head.

Thanks

Edwin

In this case it means that the code is stucked (or deadlocked) in the main
thread (are you
sure your Main is marked STAThread ?), probably in the Pervasive ODBC
driver.
To be sure you'll have to attach a debugger to the process and check which
thread is waiting
and what he is waiting for.
Another option is to get a copy of process explorer (procexp.exe) from
www.syinternals.com
(now on msdn) and watch the offending process threads and their stacks.

Willy.

Thanks for the reply;

I downloaded Process Explorer and This is what it shows for the program.

There are 3 threads of note: I have a BMP screen shot if you need to see what else is
there. It's to large to post however.

!GetMetaDataPublicInterfaceFromInternal+0xd30 --Wait:DelayExecution

Two others:

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

All the rest say Wait: UserRequest

I haven't a clue what all this means but hopefully you or somebody else
does.

Thanks

Edwin

Hard to tell where these threads come from, all I can say is:
- the first thread is waiting for a timer interrupt.
- the next two threads are waiting on a synchronization object, if both are waiting on the
same object, they could be deadlocked.
None of these threads are the application's UI thread, nor are they CLR threads, so my guess
is that they come from a buggy ODBC driver.

Q. Are you running this in the VS debugger? If yes, what happens when you run stand-alone?
Q. Are you sure the process don't go away after a time-out?

Willy.

[Edwin Smith]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OI**************@TK2MSFTNGP02.phx.gbl...

"Edwin Smith" <sm**********@aol.comwrote in message
news:u5**************@TK2MSFTNGP06.phx.gbl...

>>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:OL**************@TK2MSFTNGP05.phx.gbl...

>>"Edwin Smith" <sm**********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl.. .

"Bruce Wood" <br*******@canada.comwrote in message
news:11**********************@q2g2000cwa.google groups.com...
On Feb 25, 9:15 pm, "Edwin Smith" <[e-mail]:
>I have a form which displays a DataGridView table generated with the
>VS2005
>tools. The database is a Pervasive v.9 with an ODBC driver.
>>
>The DataGridView works great except when I'm done and I click the X
>to
>close
>the form the .exe refuses to die and has to be killed in Task
>manager.
>>
>I ran a debug trace and it seems to work fine. I dropped a CLOSE
>button
>onto
>the form and put "this.Close();" in for it's event but I get the same
>result.
>>
>Using trial/error troubleshooting seems to point to some of the
>generated
>code behind the TableAdapter. If I comment it out the form closes
>properly
>but then of course my DataGridView doesn't work.
>>
>Anyone have a similar problem?
>>
>I'm also having a VS2005 lockup problem (on another thread) which may
>or may
>not be related.
>>
>My next step is to start over from scratch since it's fairly easy to
>rebuild
>once I have screenshots of my queries etc...
>
This sounds like a background thread that isn't marked "background".
The application shuts down only when all foreground threads have
stopped executing. If your code starts a background thread to do some
long-running task (like fetching data from a database) and doesn't
mark the thread "IsBackground", then the thread will keep your
application alive.
>
You'll have to find the code that starts the background thread and
ensure that the thread's IsBackground property is set to true.
>

Does the code generator for the TableAdapter.Fill generate background
threads for ODBC
connections? Since this is filling a DataGridView table it DOES get the
entire table in
memory before it displays the form. Then it disconnects from the
database. ( I think)

Or is the background thread just an automagic thing and I have to
insert
the IsBackground
property somewhere in order for the code to shutdown properly?

I searched the entire project and the text "IsBackground" does not
appear anywhere.

AFAIK this project runs in a single thread since I have not explicetly
set anything for
multithreaded operation. I'm not that sophisticated a programmer yet so
multithreading is
way over my head.

Thanks

Edwin

In this case it means that the code is stucked (or deadlocked) in the
main
thread (are you
sure your Main is marked STAThread ?), probably in the Pervasive ODBC
driver.
To be sure you'll have to attach a debugger to the process and check
which
thread is waiting
and what he is waiting for.
Another option is to get a copy of process explorer (procexp.exe) from
www.syinternals.com
(now on msdn) and watch the offending process threads and their stacks.

Willy.

Thanks for the reply;

I downloaded Process Explorer and This is what it shows for the program.

There are 3 threads of note: I have a BMP screen shot if you need to see
what else is there. It's to large to post however.

!GetMetaDataPublicInterfaceFromInternal+0xd30 --Wait:DelayExecution

Two others:

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

!l_RpcBCacheFree+0x5b8 --Wait: WrLpcReceive

All the rest say Wait: UserRequest

I haven't a clue what all this means but hopefully you or somebody else
does.

Thanks

Edwin

Hard to tell where these threads come from, all I can say is:
- the first thread is waiting for a timer interrupt.
- the next two threads are waiting on a synchronization object, if both
are waiting on the same object, they could be deadlocked.
None of these threads are the application's UI thread, nor are they CLR
threads, so my guess is that they come from a buggy ODBC driver.

Q. Are you running this in the VS debugger? If yes, what happens when you
run stand-alone?
Q. Are you sure the process don't go away after a time-out?

Willy.

This is from running the Debug version of the code stand alone. When I run
it from within VS debugger (F5) it runs and terminates fine. It's only if I
run it stand alone or with Ctrl-F5 that it hangs on exit.

I'll try the Pervasive message board and see if anyone there has a clue.

Thanks.

Edwin

[Peter Duniho]

On Tue, 27 Feb 2007 03:42:37 +0800, Edwin Smith <sm**********@aol.com>
wrote:

I never know whether it's proper to reply before or after the quoted
text.

It is proper to reply after a quote, in-line so that people reading can
understand what the text you write refers to. Of course, it is also
proper to trim the quote so that all that remains is the text to which you
refer. Otherwise, the quote has no real value (other than to clutter up
the newsgroup with duplicates of previous articles).

The database code is generated by VS2005 code behind the TableAdapter. I
can trace through it with the debugger so I'll see if there's any
IsBackground properties. Or do you mean there is an IsBackground property
that can be set in the visual designer? I'll check those.

A Thread instance has a IsBackground property. Of course, this is for
things that use the .NET Thread class. Something called by .NET but
implemented without .NET may call it something else. If you are not
creating the thread yourself, you probably don't have control over its
background status. From your other post about the threads shown in
Process Explorer, it does sound as though somehow your ODBC use is
creating a thread that's not a background thread and which is waiting on
something that apparently never happens. Which of the many threads PE
showed you is the culprit, I don't know.

Have you tried simply calling Application.Exit? That *should* force the
application to quit, as far as I can recall.

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Tue, 27 Feb 2007 03:42:37 +0800, Edwin Smith <sm**********@aol.com wrote:

>I never know whether it's proper to reply before or after the quoted text.

It is proper to reply after a quote, in-line so that people reading can understand what
the text you write refers to. Of course, it is also proper to trim the quote so that all
that remains is the text to which you refer. Otherwise, the quote has no real value
(other than to clutter up the newsgroup with duplicates of previous articles).

>The database code is generated by VS2005 code behind the TableAdapter. I can trace
through it with the debugger so I'll see if there's any IsBackground properties. Or do
you mean there is an IsBackground property
that can be set in the visual designer? I'll check those.

A Thread instance has a IsBackground property. Of course, this is for things that use
the .NET Thread class. Something called by .NET but implemented without .NET may call it
something else. If you are not creating the thread yourself, you probably don't have
control over its background status. From your other post about the threads shown in
Process Explorer, it does sound as though somehow your ODBC use is creating a thread
that's not a background thread and which is waiting on something that apparently never
happens. Which of the many threads PE showed you is the culprit, I don't know.

IsBackground is a CLR thread attribute, not a OS thread attribute, native OS threads have
no back/foreground notion, the ODBC driver is unmanaged code, so the threads created by this
driver are not CLR managed threads.

Have you tried simply calling Application.Exit? That *should* force the application to
quit, as far as I can recall.

Application.Exit is no solution when a thread gets stucked in the kernel, the clr cannot
stop and these threads don't go away after the CLR unloads.

Willy.

[Lau Lei Cheong]

If it runs fine when you start it in IDE, probably you could also try to
start the application(compiled with DEBUG settings), then start the IDE, and
then use the IDE to attach to the process and see if there any difference.

"Edwin Smith" <sm**********@aol.com¼¶¼g©ó¶l¥ó·s»D:OP************ **@TK2MSFTNGP02.phx.gbl...

When I run it in debug mode it works fine and exits properly. Of course
the app doesn't run in it's own executable then, it's running in the
debugger so the debugger doesn't tell me anything.

If I run it in it's own executable then when I click the X on the form or
click the close button I added, the form closes but the app is still
running in memory and is "orpahned".

I'll look for the "background thread" problem suggested in the other reply
to my post.

Thanks

Edwin