PRB: Office Application Remains in Memory After Program Finishes (238987)

RESOLUTION

• If you're using #import, it is very likely you could be running into one of the reference-counting bugs associated with it. Often these bugs can be worked around, but usually it is preferred to use one of the other Automation methods. #import doesn't work very well with the Office applications because its type libraries and use are fairly complex. Also, such reference counting problems are hard to track down because a lot of the interface-level COM calls are behind-the-scenes when using #import.
• Check to see if you are calling any methods, such as Open or New, that return an IDispatch * (LPDISPATCH), and ignoring the return value. If you are, then you are abandoning this returned interface and you will need to change your code so that you release this IDispatch * when no longer needed.
• Gradually comment out sections of your code until the problem disappears, then add it back judiciously to track down where the problem starts.
• Note that some applications will stay running if the user has "touched" the application. If this occurs while you are automating, then the application will probably stay running afterwards. Office applications have a "UserControl" property on the Application object that you can read/write to change this behavior.
• Also, some applications will decide to stay running if enough user-interface "action" has occurred. If you intend for the application to exit, then call its Quit() method on the Application object. Word will shut down regardless of its reference count when Quit is called. This isn't expected COM behavior. Excel, however, will properly just hide itself but stay running until all outstanding interfaces are released. In general, you should release all outstanding references, and only call Quit() if you intend the application to quit.