We Keep Coding

How to allow a process to be shut down cleanly

I have a process that I would like to be able to cleanly shut down from an external process. That is, I would like to give it a chance to clean up it's resources (save it's data etc.) before it dies.
Process.CloseMainWindow appears to be the ordinary way to go, except the process in question doesn't have any windows and I don't want to immediately call Process.Kill because I want to give it chance to clean up first (and a kill process command can't be intercepted by the target process).
So what is the best way to allow my process to be shut cleanly from another process?
I have control over both processes. The process to be shut does have a message loop (Application.Run()) so I would think there would be some message I could post through there.
I have read the msdn article on terminating processes and this article about closing processes cleanly however both mention methods that seem quite sophisticated despite the simplicity of what I am trying to achieve. Given that I have control over both processes I am hoping there's something a bit simpler that can be implemented cleanly in C#. Is there one?
The process to close is not a service, so can't do service stop.

I'm not sure if a .NET message loop supports thread messages, or only window messages. If it supports thread messages, then the terminating app can use PostThreadMessage() to post a WM_QUIT message (or a custom message that the message loop can look for) to the main thread of the target process so it can stop its message loop and exit the app.
Otherwise, have the target app create a named kernel event object using EventWaitHandle and then wait on the event, either by calling EventWaitHandle.WaitOne() in a manual thread, or calling ThreadPool.RegisterWaitForSingleObject() to use a system-provided thread pool. When the event is signaled, you can notify the main thread to exit the app. The terminating app can then open the event object by name using EventWaitHandle.OpenExisting(), and then signal the event with EventWaitHandle.Set().

Detect if child GUI is hung from a parent process

In my application there is a parent process that spawns its children. I am trying to leverage this parent process to watch over the children to ensure that the GUI remains responsive, and if not, generate a dump file.
The problem I'm running into is that Process.Responding is only detecting some GUI hangs (such as sleeping on the GUI thread or a stack overflow) but not others (such as deadlocks on the GUI thread).
So the question is: How else can I check whether or not the GUI of the child is still updating from the parent process?
EDIT: Based on the comments so far I guess I should clarify. I am responsible for maintaining the framework of an application with a plugin architecture that is heavily multi-threaded and has a code base of hundreds of thousands of lines of code, much of which is outside my control. While I understand that the ideal approach is not to hang in the first place, it still happens on occasion. I would like these situations gracefully and collect debug information along the way so that the issue can be addressed.
Another approach I've considered is using the GUI thread to touch a file and have the parent process check the time stamp of the file. However, I'd rather not perform file operations on the GUI thread.

After a few failed attempts with the strategies I mentioned above, here's how I ended up solving this:
At child application start I save a reference to the GUI thread
A timer is started that periodically checks the thread state of the
GUI thread (about every 200ms). If it is ThreadState.Running, I
report the process as responding to the parent through
inter-process communication.
In the parent process I keep a dictionary of the process IDs
and the time the process was last reported as responding. If a
child is still alive but hasn't reported a responding result within
the timeout period, the user is notified that the process is not
responding.
So far, everything seems to be working as I would expect it to.

DLL should finish its operation although the referencing app gets closed

I have a C# winforms project which has a reference to a library also coming from myself. The winforms app triggers some work to do for the library. Is it possible that the library can finish its work even if the winforms app gets closed?

There are two possible approaches:
create a separate subprocess. Ending the parent process will not end the child, thus, the newly created task will continue when the parent app is closed
make the parent app in such way that closing the main form doesn't end the application, thus, giving the application time to end all worker threads spawned during its lifetime
I am not sure which of the two I would recommend, both seem risky as chances are the long-running background operation will not finish in reasonable time. And then what?

Is it possible that the library can finish its work even if the
winforms app gets closed?
No, not if that library is simply hosted in the main process.
You would need to do something along the lines of create a windows (or web) service and host the library in the service along with a message passing mechanism. Then call into it by having your windows application call a command on the service.

Process management in .NET

So i have a helper process written in C++ and I open it, feed it arguments, and it feeds my program back information through the standardoutput stream.
PS. I don't have the source for the helper process exe.
If my application were to be terminated from the task manager, or for some reason crash, how could I ensure that my helper exe is closed? Is this possible? Would I need an external file?

Use Job Objects to manage groups of processes. In this case you want to create a job object using CreateJobObject, use SetInformationJobObject to set the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE flag, and assign the helper process to the job using AssignProcessToJobObject. Don't close the handle to the job object unless you want to kill the helper process. When your process terminates (through any means), the handle will be closed and your helper process will be killed.

You should create an inheritable duplicate of the parent process handle and pass its value to the helper process on the commandline. The helper process can then wait on that handle on a separate thread (or the main thread if you're clever). When the handle becomes signaled, it means that the launching process has terminated.
Edit
Since you can't change the helper process, your options are more limited. Your could try attaching a handler to the launching process's OnAppDomainUnloaded event, but I'm not sure this will work in all the cases you're concerned about. You could also create a third process to monitor the first. This process would work as I described above. If you wanted to get really fancy, you could inject a remote thread into the helper process to monitor the parent. This is very technical, so I recommend against it.

The easiest way would be to close it on normal application exit and when AppDomain.CurrentDomain.UnhandledException is invoked (i.e. your app is about to crash)

running processes step by step

I need to install mysql in my system in the first step
After installing or modifying the mysql in the system , I need to the run the data base scripts.
The problem here is db scripts started running before mysql setup completes.
I have tried different ways.. using auto run methods...using processes etc
can anybody tell me how to capture the (child)process id which is invoked by the current process(parent). Here in my case parent is invoking child process and exiting.

System.Diagnostics.Process has a method WaitForExit.
Edit: To also watch for subprocesses, you can use Win32 Job objects. If you create a process in a job, all of its child processes will also belong to the job (unless someone explicitly detaches them). You can monitor the job for events such as process creation and termination. There is a C# wrapper for job objects, JobObjectWrapper.