Answered by:
Crash during TerminateProcess()

Question
-
As per my understanding crash/exception is expected(may or may not happens) if an application is terminated using TerminateProcess() similar to killing a process. Please correct me if i am wrong?
Reference
======
http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547
"It is generally a bad idea to call TerminateProcess()because the system does not shut down the process in an orderly fashion. Any DLLs used by the process will not receive the DLL_PROCESS_DETACH event, disk buffers are not properly flushed, and memory shared with other processes can be left in an inconsistent state."
Thanks, Renjith V R
Sunday, March 4, 2018 6:46 PM
Answers
-
And see the old KB178893
- Marked as answer by Renjith V Ramachandran Sunday, April 22, 2018 2:32 PM
Monday, March 5, 2018 8:47 AM
All replies
-
For the application you are terminating, then no exceptions are expected. Since Windows just stops executing the process and kills it dead. It doesn't even get a chance to thrown an exception.
However, for other applications then it can cause problems. For example, if you are using shared memory through file mappings then terminating a process during a write can lead to an incomplete write leaving the shared memory in a corrupt state.
The same is true when writing to files or the registry. It could be in the middle of writing to a file leaving parts of the file corrupted. If multiple applications use the file or registry keys then it can cause exceptions. The application itself could end up crashing or losing settings if it is the settings file for that application.
So yes, killing a process using TerminateProcess is always a bad idea.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Sunday, March 4, 2018 7:35 PM -
This is not a C++ question. You might get better responses if it were in a Windows forum.
The MSDN documentation has gotten sloppy. It also used to say things like that but now it is not so clear and explicit.
TerminateProcess is less likely to cause a crash but is likely to cause a problem for applications. Any data that has not been saved won't be saved and there is no way for an application to respond to the TerminateProcess. Users like to use the Task Manager to get rid of applications and most users don't understand the potential problem. It is the type of thing that people do and then when they have problems they ask for help and people trying to help might not know that they have been killing a process or some processes. As a programmer you should use TerminateProcess as a last resort in unusual circumstances.
Sam Hobbs
SimpleSamples.InfoSunday, March 4, 2018 7:44 PM -
I have an application from which multiple applications can launch. While closing the application, it will try to close all child application using some inter process communication method. If that method fails, it will go for TerminateProcess(). I am working on crash dumps. So i wanted to know that whether it is worthy to analyse crashes while TerminateProcess() or those are expected.
Thanks, Renjith V R
Monday, March 5, 2018 6:05 AM -
I have an application from which multiple applications can launch. While closing the application, it will try to close all child application using some inter process communication method. If that method fails, it will go for TerminateProcess(). I am working on crash dumps. So i wanted to know that whether it is worthy to analyse crashes while TerminateProcess() or those are expected.
Thanks, Renjith V R
- Merged by Stanly Fan Tuesday, March 6, 2018 1:22 AM the same thread
Monday, March 5, 2018 6:08 AM -
If that method fails, it will go for TerminateProcess().
That is not the solution recommended by Microsoft.
The way a typical application works is that it creates a main window and then goes into a message loop. When the message loop gets a quit message it ends and the application ends.
So let us back up. Typically a window is sent a WM_CLOSE message to close the window and the application. The typical (and default) behavior of the close message is to call the DestroyWindow function which sends a WM_DESTROY message. The typical behavior of a destroy message is to call the PostQuitMessage function and that sends a quit message. So before using a TerminateProcess you should send a close message. Applications typically do clean-up in the close message. See the following. Note that TerminateProcess is worse than sending a destroy message.
- Sending a window a WM_DESTROY message is like prank calling somebody pretending to be the police – The Old New Thing
- Closing the Window
Sam Hobbs
SimpleSamples.InfoMonday, March 5, 2018 6:57 AM -
If that method fails, it will go for TerminateProcess().
That is not the solution recommended by Microsoft.
The way a typical application works is that it creates a main window and then goes into a message loop. When the message loop gets a quit message it ends and the application ends.
So let us back up. Typically a window is sent a WM_CLOSE message to close the window and the application. The typical (and default) behavior of the close message is to call the DestroyWindow function which sends a WM_DESTROY message. The typical behavior of a destroy message is to call the PostQuitMessage function and that sends a quit message. So before using a TerminateProcess you should send a close message. Applications typically do clean-up in the close message. See the following. Note that TerminateProcess is worse than sending a destroy message.
- Sending a window a WM_DESTROY message is like prank calling somebody pretending to be the police – The Old New Thing
- Closing the Window
Sam Hobbs
SimpleSamples.InfoMy suggestion is PostQuitMessage() so that it will close all windows according to its creation order.
But i am getting so many crashes while closing application using TerminateProcess(). For example if a child modal dialog is present and TerminateProcess() is invoked, as per my understanding the parent dialog may close before child. We are observing call stacks from which parent is closed when child is active which is not expected in case of modal dialog.
Thanks, Renjith V R
- Edited by Renjith V Ramachandran Monday, March 5, 2018 7:44 AM
Monday, March 5, 2018 7:40 AM -
PostQuitMessage will not close windows. It will only stop the message loop and then normally the application ends without doing anything more, especially not anything the window does when it is closed normally.
TerminateProcess will not close windows and won't let the code run that is normally done by the application when it closes gracefully. With TerminateProcess it does not matter who is open and what order they are in or what needs to be done by the cleanup of the window and application; none of that is done.
Sam Hobbs
SimpleSamples.InfoMonday, March 5, 2018 8:43 AM -
And see the old KB178893
- Marked as answer by Renjith V Ramachandran Sunday, April 22, 2018 2:32 PM
Monday, March 5, 2018 8:47 AM -
And see the old KB178893
Yes that is a good one. I used to link to it (such as here) but I have had problems finding old articles and did not try to find that one.
Sam Hobbs
SimpleSamples.InfoMonday, March 5, 2018 9:10 AM -
I have an application from which multiple applications can launch. While closing the application, it will try to close all child application using some inter process communication method. If that method fails, it will go for TerminateProcess().
Monday, March 5, 2018 11:44 AM -
This is the whole point. The only way to guarantee that applications close down in any kind of orderly fashion is to close them down in the way that they expect.
TerminateProcess is obviously out because it kills a process so indiscriminately that it has no chance to finish what it is currently doing let alone clean up.
But what about PostQuitMessage? At first glance this may seem acceptable because you are telling the application that it is quitting. However if you dig into the Window procedure then you will start figuring out why it is a bad idea.
Take the average window procedure. This is what defines the behaviour of the window, and Windows calls this whenever anything happens.
LRESULT CALLBACK WindowProc(HWND wnd, UINT msg, WPARAM w, LPARAM l) { switch(msg) { //other messages here, the contents are unimportant case WM_CLOSE: //do document cleanup here DestroyWindow(wnd); return 0; case WM_DESTROY: //do window cleanup here PostQuitMessage(0); return 0; //maybe other messages here, the contents are unimportant } return 0; };
Notice that glossing over the other stuff, the way that these three highlighted messages interact with each other? The WM_CLOSE message is originally sent/posted to the window somehow. Maybe using the x button in the top right or maybe through some other means. In response to this the application starts the cleanup. This is where I start doing the automatic saving of any documents open, or prompting the user if they want to save their work.
The next thing that this does is call DestroyWindow, which eventually sends WM_DESTROY. This is where I normally clean up the window related data structures. For example, if I'm using Direct2D to draw and DirectWrite for text then I clean up the objects here. Then it calls PostQuitMessage.
So you are starting with the very final step an application should do. It is also the very last thing an application does itself after it has cleaned up everything. So what you really need to do is start off the whole WM_CLOSE chain. The other thing that you really should do is not even touch TerminateProcess. In your code you should wipe away all traces of this and figure out how to close the application without it.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Monday, March 5, 2018 1:21 PM -
I don't understand the question. Please see Crash during TerminateProcess(); if the answer is not there then please clarify the question.
Sam Hobbs
SimpleSamples.InfoMonday, March 5, 2018 8:53 PM -
As should have been made obvious, if you have applications communicating via IPC and you just terminate one of them, then crashes in others that rely on the one you just terminated in some form, like reading from/writing to shared memory or files, sharing synchronisation objects or have some other interactions (like a window in one process has a child created from another process) have a high probability of crashing.
This is for the simple fact that the process you terminate will be terminated at an indeterminate time and it could be doing anything. The damage it can do can multiply when there are more threads that interact this way.
So if you are asking is it worth your time debugging any crashes in one application after another is terminated using TerminateProcess? Especially if they interact using IPC or some other method? Then the answer is no, the likely cause of the crashes are some form of corrupted state caused by the act of terminating that one process. You should also compare this to the times when the clean methods of exiting those applications work and they shut down without resorting to TerminateProcess. If there is a much higher chance of one of the applications that interact with the terminated process to crash after you terminate then it is a good bet that the crash is caused by terminating the process.
This is the whole reason why the original discussion turned to saying that you shouldn't use TerminateProcess at all because it is very likely to cause problems after, and you should try really hard to close the applications by some internal IPC method or sending the WM_CLOSE message to start the application shutdown cleanly and in the expected way.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
Tuesday, March 6, 2018 1:48 AM -
This is the whole reason why the original discussion turned to saying that you shouldn't use TerminateProcess at all because it is very likely to cause problems after, and you should try really hard to close the applications by some internal IPC method or sending the WM_CLOSE message to start the application shutdown cleanly and in the expected way.
Sam Hobbs
SimpleSamples.InfoTuesday, March 6, 2018 2:08 AM -
Yes, he posted this question as a reply to my original reply.
You directly replied to that one.
This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.
- Edited by Darran Rowe Tuesday, March 6, 2018 4:44 PM
Tuesday, March 6, 2018 4:43 PM -
This is not a C++ question. You might get better responses if it were in a Windows forum.
This is why i re-posted Windows forum.
From the parent process i can launch multiple child processes. While closing parent process, we already have a mechanism to notify client. If it fails then it will call TerminateProcess(). My child application is not communicating with other processes. As per MSDN,
"TerminateProcess() stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled. When a process terminates, its kernel object is not destroyed until all processes that have open handles to the process have released those handles"
Since it is stopping all threads, it doesn't have any function call/ memory access. So there no crashes are expected.
Regarding PostQuitMessage(), i know it just stops the message loop(while(GetMessage() will exit) and application mail thread will return.
I tried a test application which will create a modal and non modal dialog. After 1 minute application it self will call PostQuitMessage() from its main thread. I could see the OnDestroy() and destructors are getting invoked in proper order though theoretically it is not expected to happen.
1.Create dialog based application.
2. Start a timer with 2 or 3 minutes which invokes PostQuitMessage().
3. Launch a non-modal and modal child dialog.
4. Add logs in OnDestory and destructor
Thanks, Renjith V R
Thursday, March 8, 2018 10:21 AM -
Hi,
>>I tried a test application which will create a modal and non modal dialog. After 1 minute application it self will call PostQuitMessage() from its main thread. I could see the OnDestroy() and destructors are getting invoked in proper order though theoretically it is not expected to happen.
Have you checked the sequence of these messages?
Typically the PostQuitMessage is used in response to a WM_DESTROY message.
Or could you please share your test project on OneDrive so that we could reproduce your issue?
Best Regards,
Baron Bi
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.Wednesday, March 21, 2018 8:58 AM -
This is not a C++ question. You might get better responses if it were in a Windows forum.
This is why i re-posted Windows forum.
From the parent process i can launch multiple child processes. While closing parent process, we already have a mechanism to notify client. If it fails then it will call TerminateProcess(). My child application is not communicating with other processes. As per MSDN,
"TerminateProcess() stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled. When a process terminates, its kernel object is not destroyed until all processes that have open handles to the process have released those handles"
Since it is stopping all threads, it doesn't have any function call/ memory access. So there no crashes are expected.
Regarding PostQuitMessage(), i know it just stops the message loop(while(GetMessage() will exit) and application mail thread will return.
I tried a test application which will create a modal and non modal dialog. After 1 minute application it self will call PostQuitMessage() from its main thread. I could see the OnDestroy() and destructors are getting invoked in proper order though theoretically it is not expected to happen.
1.Create dialog based application.
2. Start a timer with 2 or 3 minutes which invokes PostQuitMessage().
3. Launch a non-modal and modal child dialog.
4. Add logs in OnDestory and destructor
Thanks, Renjith V R
Thanks, Renjith V R
Sunday, April 22, 2018 2:30 PM