sqlce resources not released on application.exit()?

[Scott Anderson]

Hi-

When I run my netcf 3.5 app, then click a button that executes
application.exit(), then run the app again, I get an exception when trying to
access the sqlce database. I am making sure that I close the connections and
dispose sqlcecommands after I am done with them. Is there something else I
need to do to make sure the resources are released on application exit? Or
could there be something else that would cause this?

Thanks!

 

[Simon Hart [MVP]]

A|re you accesing the database via Query Analyzer? although I think in CE
3.5 Query Analyzer no longer opens the database for exclusive access.

What exception are you getting? When you close you're app, check it is
actually closed before restarting.

 

[Simon Hart [MVP]]

A|re you accesing the database via Query Analyzer? although I think in CE
3.5 Query Analyzer no longer opens the database for exclusive access.

What exception are you getting? When you close you're app, check it is
actually closed before restarting.

 

[Scott Anderson]

I am not using Query Analyzer. The problem is intermittent but I have seen
this before: Error Code: 8007000E, which I've read is an out of memory error.
If that is really the problem then it would be because resources aren't
being freed up right? I am pretty certain I am closing all connections, etc.
How can I check if the application is really closed before restarting? Is
Application.Exit() non-deterministic? I thought it would release everything
the app was using immediately every time.

Thanks.

 

[Scott Anderson]

I am not using Query Analyzer. The problem is intermittent but I have seen
this before: Error Code: 8007000E, which I've read is an out of memory error.
If that is really the problem then it would be because resources aren't
being freed up right? I am pretty certain I am closing all connections, etc.
How can I check if the application is really closed before restarting? Is
Application.Exit() non-deterministic? I thought it would release everything
the app was using immediately every time.

Thanks.

 

[Chris Tacke, eMVP]

After you call Application.Exit are you verifying that your app process is
actually shutting down (with something like Remote Process Viewer)?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Chris Tacke, eMVP]

After you call Application.Exit are you verifying that your app process is
actually shutting down (with something like Remote Process Viewer)?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Simon Hart [MVP]]

Calling Application.Exit() simply tells the message pump to shutdown and for
control to return from Application.Run. It will forcibly close all windows
running under that pump. The documentation will tell you that Window events
such as Closed and Closing will not fire in this scenario.

I consider it bad design to use Application.Exit much like using
Thread.Abort. Why do you have the need to forcibly close your app?

 

[Scott Anderson]

Interesting...when I use Remote Process Viewer I can see that the process in
NOT shutting down after calling Application.Exit(). What is the correct way
to make sure the process is killed completely?

 

[Scott Anderson]

I am developing a kiosk app that the user should never shut down, so the
forms have the ControlBox property set to false. However for convenience I
have a form that temporarily exposes a button that calls Application.Exit()
so that I can get back to the CE shell when I want to. What is a better way
to do this? I confirmed with Remote Process Viewer that the process is not
killed when Application.Exit() is called...which seems to be causing problems.

 

[Paul G. Tobey [eMVP]]

If you have another thread running, the application won't exit until that
thread exits. When you want to exit, you should cleanly notify all running
threads to exit, assure that any blocking calls are unblocked, etc. You can
then close the main form, which should exit, or call Application.Exit().

Paul T.

 

[Chris Tacke, MVP]

The correct way to shut down is to exit the Main function. If you have any
threads created, you should signal them to shut down before doing so
(setting IsBackground to true when you create them will usually do it
automatically).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Scott Anderson]

The last line of my main function is a call to Application.Run(), so calling
Application.Exit() will exit the main function right? I set the IsBackground
property to true for the threads I am creating (three of them). Remote
process viewer shows that the process has 8 threads, and after calling
Application.Exit() it still shows the process with 5 threads running. Does
this mean there are other things that need to be cleaned-up/disposed? Is
there a way to find out what they are?

 

[Chris Tacke, eMVP]

The last line of my main function is a call to Application.Run(), so

calling
Application.Exit() will exit the main function right?

It *should* be, but I wouldn't count on that to be true. The proper way to
exit Run is to Close the Form instance that was passed to it.

I set the IsBackground
property to true for the threads I am creating (three of them). Remote
process viewer shows that the process has 8 threads, and after calling
Application.Exit() it still shows the process with 5 threads running.
Does
this mean there are other things that need to be cleaned-up/disposed?

Yes, that's exactly what it means. If you didn't create them then they were
created by-proxy for you. How I can't even guess since I don't know your
code. My bet is that one or more of them are blocked in a system call. Do
you have any waits in your code (on event handles, etc) that are infinite
waits (shouldn't even be an option IMO)?

Is there a way to find out what they are?

There are ways, but it's not easy. It's probably easier to just look for
likely candidates.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Scott Anderson]

Ugh, I do have some PInvoke calls to "WaitForMultipleObjects" with infinite
timeouts...for responding to power management events, etc. What is a good
way to refactor them so they are not infinite, or close them before calling
Application.Exit()?

Thanks.

 

[Chris Tacke, eMVP]

If they're on a worker thread, I'd make sure the thread is set to a
background thread and then change the waits from infinite to something on
the order of 3 seconds. The theory being that when the wait time's out, the
scheduler then will look at the thread to see what needs to be scheduled
next, but since it's a background thread and it's parent process is
terminating, it will then terminate the thread.

I'd not use direct calls to the wait anyway - I'd use something like an
EventWaitHandle (SDF exposes it with a string name overload so you can use
it for things like this).
--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Scott Anderson]

FYI I finally addressed this by adding another event for
"WaitForMultipleObjects" which I raised by my app before calling
Application.Exit(). This gave the opportunity to break out of an infinite
loop, close handles, and exit the thread.