Re: Process won't die when form is closed.



"Edwin Smith" <smithgoldbug@xxxxxxx> wrote in message news:u5ENj$iWHHA.4132@xxxxxxxxxxxxxxxxxxxxxxx

"Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx> wrote in message
news:OLweVQeWHHA.1396@xxxxxxxxxxxxxxxxxxxxxxx
"Edwin Smith" <smithgoldbug@xxxxxxx> wrote in message
news:%238mW9DeWHHA.4832@xxxxxxxxxxxxxxxxxxxxxxx

"Bruce Wood" <brucewood@xxxxxxxxxx> wrote in message
news:1172475109.448421.221030@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 25, 9:15 pm, "Edwin Smith" <smithgold...@xxxxxxx> wrote:
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.


.