Why is killing an excel process bad?

Question

I saw a lot of articles and questions on how to be sure that Excel actually quits when you want it, and the process does not stay alive. Here is a knowledge base article describing the problem and a solution recommended by Microsoft. Essentially:

'close files 'Quit Excel xlApp.quit() 'Release and collect garbage System.Runtime.InteropServices.Marshal.FinalReleaseComObject(xlApp) GC.Collect() GC.WaitForPendingFinalizers() 

Many people do not recommend killing the process; See How to properly clean Excel interaction objects and Understanding garbage collection in .net

On the other hand, many people do not recommend using GC.Collect. See What's Wrong About Using GC.Collect ()?

In my experience, killing a process is the fastest and easiest way to make sure Excel is gone. My code kills only the exact process that it launches, none other. I close all open books, Close the application and release the xlApp object. Finally, I check if the process is alive, and if so, kill it.

 <System.Runtime.InteropServices.DllImport("user32.dll", SetLastError:=True)> _ Private Shared Function GetWindowThreadProcessId(ByVal hWnd As IntPtr, _ ByRef lpdwProcessId As Integer) As Integer End Function Sub testKill() 'start the application Dim xlApp As Object = CreateObject("Excel.Application") 'do some work with Excel 'close any open files 'get the window handle Dim xlHWND As Integer = xlApp.hwnd 'this will have the process ID after call to GetWindowThreadProcessId Dim ProcIdXL As Integer = 0 'get the process ID GetWindowThreadProcessId(xlHWND, ProcIdXL) 'get the process Dim xproc As Process = Process.GetProcessById(ProcIdXL) 'Quit Excel xlApp.quit() 'Release System.Runtime.InteropServices.Marshal.FinalReleaseComObject(xlApp) 'set to nothing xlApp = Nothing 'kill the process if still running If Not xproc.HasExited Then xproc.Kill() End If End Sub 

I saw how many people say that killing the process is bad, but I have not seen any qualitative answers to the question why. Especially after the files are closed, Excel is gone, and we will only kill the exact process that we started. My question is what are the potential problems with killing the Excel process. Does it harm work? Will it harm Excel?

Many will also say that with good coding, I don’t need to kill the process. Maybe, but this does not answer the question "Why is it bad to kill the process?" After closing the files, exit Excel and free the objects; why would it be bad to just make sure the process is gone?

Edit: also what remains after exiting excel? If Excel was visible, it usually closes normally, disappears from the view and from the taskbar. And indeed, Excel has really gone away or failed to do so. It seems to me that Excel really stopped working and we only have an empty working shell. Can anyone comment on this?

Edit: I am interested to note that GC (aka Garbage Collection) through GC.Collect () GC.WaitForPendingFinalizers () will actually free the process shell remaining after exiting Excel. Does this support my assumption that the empty shell of the process is indeed garbage after all?

Edit: just found a great site on the issue: 50 ways to kill Excel

Answer 1

Look, the fact is that you should always let the application work normally, if at all possible. Killing an application is the last resort. I understand that you are convinced that in this case you do not see anything wrong, and perhaps you are right. Even if there are no negative consequences for your system to kill it, this does not change the fact that it is wrong. It’s like breaking the law because you know you won’t be caught, and it’s a crime without victims in any case.

There are, however, potential side effects that you may not be aware of. For example, when you forcefully terminate an application, the OS may save crash data for it. Or he may send telemetry failures to Microsoft. You basically tell Microsoft that applications crash more often than they really are, and as a result their crash statistics are slightly skewed.

Another possible side effect is that registry hives may not be unloaded correctly. You may have seen this error in the event log from time to time. This usually happens when the application is forcibly closed and it does not close the descriptors in the registry correctly.

Even if none of this happens, you may not know what a future version of the OS can do. What works today may not work tomorrow. That's why you should ALWAYS follow the documented API and recommendations, because they will usually work very hard on what they published, but usually don’t work very hard to support what they specifically told you not to do.

Answer 2

When you use automation to control an Office application from another application, you sometimes have to kill the Office process, as you do, to avoid the “leak” of invisible Office applications. This is a bad result of how Office applications try to act both as an end user and as an automation server.

I used more or less the same solution as when using Word server-side (don't ask why). No matter how much effort we put into shutting down Word, the number of "invisible" Word processes on the server has duly increased. The only good decision was to kill the theses, which did not stop after they were ordered to leave.

When a Windows process is destroyed, all resources used by the process are cleared by the operating system, for example. files and other operating system descriptors, such as registry descriptors, are closed, memory is freed, etc. From the point of view of the operating system, nothing leaks out at the end of the process.

However, the application may create temporary files that it intends to delete during normal termination. Over time, these orphaned files can use more and more disk space. In addition, if the user has other files open in the application, these files may remain in an inconsistent state when the process ends, and unsaved changes may be lost. Basically, the fact that a killed application can “leak out” is the files that it intends to clean or delete when it shuts down. Another source of leaks is resources purchased online (for example, files open to stocks). However, when the process ends, the network descriptor will eventually become "obsolete" and will be restored by the network server.

In addition, I would like to point out that Dr. Watson will not collect dump data on failure if the process is killed. This only happens if there is an unexpected process failure (for example, it has an unhandled exception).

The bottom line: If you carefully kill Excel, probably the best way to avoid the "leak" of invisible Excel processes over time. An alternative that allows them to run more and more system resources before the system restarts is not viable. The cost, if any, should be no more than small files left in a temporary folder.

---

As an alternative to Office automation, you can use the Open XML SDK to open and modify Office files. This may initially be a little more complicated, but you completely avoid using heavy Office applications in the process.

Answer 3

In my experience there are several things that a program does when it shuts down:

• Cancel all memory references
• Delete temporary or work files
• Save Status Data

For these reasons, it is critical to disable Excel as described in the API using app.Quit() . If this example deviates from Norma, it is that the API does not release all COM objects. This leads to the fact that step 1) is incomplete. It is impossible to guarantee that the application is effectively disconnected in all cases, since you cannot always control which COM objects are created.

I found the best way to use Excel (among other office programs) is to use the following process:

• Get a list of process identifiers with a name that contains Excel
• Open excel
• Repeat step 1. Use this to determine the process ID of the newly created Excel instance.
• Use excel
• Quit Excel by freeing all the objects you created and ending with Application.Quit()
• Kill the process

This gives Excel the ability to release any objects, delete any temporary files, and save any state data until the process is complete. I usually create a singleton class that is responsible for managing excel instances. It implements IDisposable, and upon disposal it will exit all other Excel applications.