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

[Edwin Smith]

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:OI******** ******@TK2MSFTN GP02.phx.gbl...

"Edwin Smith" <sm**********@a ol.comwrote in message
news:u5******** ******@TK2MSFTN GP06.phx.gbl...

>>
"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:OL******* *******@TK2MSFT NGP05.phx.gbl.. .

>>"Edwin Smith" <sm**********@a ol.comwrote in message
news:%2****** **********@TK2M SFTNGP04.phx.gb l...

"Bruce Wood" <br*******@cana da.comwrote in message
news:11***** *************** **@q2g2000cwa.g ooglegroups.com ...
On Feb 25, 9:15 pm, "Edwin Smith" <smithgold...@a ol.comwrote:
>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
>generate d
>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 "IsBackgrou nd", then the thread will keep your
applicati on 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.Fi ll generate background
threads for ODBC
connection s? 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 "IsBackgrou nd" does not
appear anywhere.

AFAIK this project runs in a single thread since I have not explicetly
set anything for
multithreade d operation. I'm not that sophisticated a programmer yet so
multithreadi ng 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.

!GetMetaDataPu blicInterfaceFr omInternal+0xd3 0 --Wait:DelayExecu tion

Two others:

!l_RpcBCacheFr ee+0x5b8 --Wait: WrLpcReceive

!l_RpcBCacheFr ee+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**********@a ol.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.Exi t? That *should* force the
application to quit, as far as I can recall.

Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@nn owslpianmk.comw rote in message
news:op******** *******@petes-computer.local. ..

On Tue, 27 Feb 2007 03:42:37 +0800, Edwin Smith <sm**********@a ol.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.Exi t? That *should* force the application to
quit, as far as I can recall.

Application.Exi t 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(com piled 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**********@a ol.com¼¶¼g©ó¶l¥ ó·s»D:OP******* *******@TK2MSFT NGP02.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