WM_CLOSE

  • Thread starter Thread starter Brandon
  • Start date Start date
B

Brandon

Sorry for the long post, but I need to provide background for questions that
I know will be asked.

I have been hunting for this information for some time, and I'm just not
sure the information is available publicly, so I thought I'd try my luck here.

We have a fairly sophisticated group of in-house applications and utilities,
for the most part all C#, running on WM2K3 devices. We have done our best to
minimize the number of long-running service-type processes...there's one to
manage connectivity/least cost routing, one that locks down the shell,
providing the user access to only what is necessary, etc. In total there 4
or 5 of our processes that should be running at all times, then there's the
application that the user is using. Total process count including everything
that CE starts up is about 21-22.

We have this issue where one of the service-type processes frequently
recieves WM_HIBERNATE and WM_CLOSE messages from the OS...we handle this by
gracefully shutting down, but it's got to be running, so one of our other
service-type processes is currently watching it, and will restart it.

Now I know that when the OS runs short on resources, it uses WM_HIBERNATE to
kindly ask "valid applications" to free up what they can, and then starts
using WM_CLOSE if it isn't satisfied with the result...I was curious if
anyone has any information about the algorithm/thresholds it uses to decide
this is all necessary. It seems that process count is a factor, but we
haven't hit the limit... I know free program memory is a factor, but a call
to find out how much free memory is available says there's 20MB... Is
virtual memory within a process a factor (if so, can anyone suggest tools for
taking a look at VM?)? What else?

Thanks in advance for any information you might be able to provide.
 
Yea, the code is definitely not public; it's Windows Mobile, which is
guarded pretty closely. There is a process limit in the version of Windows
CE on which that version of Windows Mobile is based, 32. It's possible, I
suppose that, as you approach that limit, the system is trying to shut down
things that it doesn't think are particularly active or perhaps it has some
other criteria. If you can reduce the number of processes, perhaps by
adding some of the capabilities in one process to another, for example, that
might help reduce the number of times that this happens. The fact the one
process in particular seems to be the lightening rod for being shut down is
suspicious to me, though. Is this process a particular user of memory or
other resources?

Paul T.
 
I've never seen any published numbers for the criteria but it's almost
certainly a lack of virtual space that is causing the OS to try to reclaim.
When you get the WM_HIBERNATE call GC.Collect (though the CF should be doing
that already) and then ignore the WM_CLOSE.

Querying virtual memory won't do much good becasue you'll only get the
virtual space your process has - not the space that the problem process is
worried about.
 
Thanks for the response.

We have certainly considered consolidating processes, but there are some
complications. Two or three of them are handled by one department, and two
or three of them are handled by another, and then we are unsure of how much
VM is left available within each individual process...with all of the native
dll's loaded, the VM ceiling is around 15M for each process (one of the
service-type processes is responsible for loading up all of the native dll's
and keeping them loaded so as not to fragment the upper portion of the VM,
and bringing each process's ceiling as high as possible, giving priority to
the end-user application - when I refer to each process's ceiling, I am
referring to the bottom of the lowest dll that each particular process has a
reference to).

Yes, this process is responsible for sql mobile replication - we have
encapsulated all of our replication into a single process, and end-user
applications can issue different types of requests reguarding the database
file being replicated (change hostname, sync, cancel sync, etc) - in turn it
provides events (via socket) when syncs start/stop/error off. It handles
replication jobs in a queue so that only one is going on at any particular
time. It is also responsible for all serial communication (with a GPS device
and a serial cable connected to the Electronic Control Module of the
vehicle), supporting a request/reply (again via socket) for different data
items that are pulled from these sources. It also has a thread that is
responsible for determining whether the vehicle is moving (using the serial
data), and if so, it blanks out the screen so that the driver cannot interact
with it (this is currently the only reason it has a form...I am working on
turning it into a console app that spawns a form only when it is going to be
on top...the intent is to make it no longer qualify as a "valid application"
that is a candidate to be WM_CLOSE'd. ...I know that this probably means
that the issue will just move to some other process, unless there is
specifically a problem with the VM within this process.
 
Thanks for the response.

From the documentation I have read, if the OS is trying to shut you down
because of resources, and it issues the WM_CLOSE, it gives you a certain
amount of time to shutdown gracefully, and then issues a process.terminate.
Before we found this documentation, we were attempting to ignore the
WM_CLOSE, and we would see the process exit memory anyway, so we felt that
the documentation is accurate.
 
Back
Top