none
Creating class in new thread in new app domain and providing it with Office COM object in embedded mode leads to zombie process RRS feed

  • Question

  • Hi,

    I have created new Excel 2010 Add-in for .NET 4.0.

    And created MarshalByRefObject object in code and run new background STA thread.

    A called this object and provided it with Application instance. No objects reference were stored.

    If I opened and closed Excel in usual mode, then everything works Ok.

    If Excel was launched with "-embedded" and embedding application closed, then I get zombie Excel process.

        public class Test : MarshalByRefObject
        {
            public void ReceiveOfficeComObject(object app)
            {
    
            }
        }
    
        public partial class ThisAddIn
        {
            private void ThisAddIn_Startup(object sender, System.EventArgs e)
            {
                var thread = new Thread
        (() =>
        {
            AppDomain td = AppDomain.CreateDomain("Test", null, new AppDomainSetup());
            string bootstrapperPath = typeof(Test).Assembly.CodeBase;
            string bootstrapperClassName = typeof(Test).FullName;
            var t = td.CreateInstanceFromAndUnwrap(bootstrapperPath, bootstrapperClassName) as Test;
            // next line reproduces zombie process of excel if launched as embedded (like preview in Explorer)
            t.ReceiveOfficeComObject(Application);
        });
                thread.IsBackground = true;
                thread.SetApartmentState(ApartmentState.STA);
                thread.Start();
            }

    What can cause such misbehavior and what fix should be?

    Note:

    Using app domain and thread separately does not leads to issue.

    Only embedding leads to zombie.

    Issue was reproduced on Excel 2003/2010, VSTO or Shim, .NET 4.0, XP SP3 32 or Windows 7 SP1 64.

    I think the same will be with other versions office and environment.

    Links:

    Sample: http://dl.dropbox.com/u/1608850/Samples/ExcelEmbeededDomainThreadIssue.zip

    Source code of solution with my fixing tries: https://gitorious.org/asdandrizzo/windows/trees/master/excel-addin-thread-appdomain

    Thanks






    Monday, February 27, 2012 11:20 AM

Answers

  • Hello,
    You state “So it seems not to be valid reason to
    refactor our code because of issue seems to be bug of MS Office COM/.NET
    interlop.(sic)”

    Reporting bugs to Microsoft Development is the job of Microsoft Customer
    Support engineers and Microsoft Technical Account Managers.

    Because of the complexity of your project please consider opening a technical
    support incident with Microsoft Customer Technical Support.  If the Customer Support Engineer confirms
    that the issue is a bug the charge for the incident will be refunded. Otherwise
    the Engineer will work with you to resolve the issue to your satisfaction.

    To view the options for using Customer support please visit the following link:
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone
    Regards
    Chris Jensen
    Senior Technical Support Lead


    Chris Jensen

    Friday, March 2, 2012 9:17 PM
    Moderator

All replies

  • Hello,

    Accessing an Office object model in a thread other than the main one IS NOT recommended, see On using threads in managed Office extensions.

    > If Excel was launched with "-embedded" and embedding application closed

    If the embedding app is an Office application, you can handle this by creating an add-in for that Office application.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Monday, February 27, 2012 12:14 PM
  • >> If the embedding app is an Office application, you can handle this by creating an add-in for that Office application.

    Embedding app is one of these - Word, Power Point, Explorer, IE. I already created add-in for Excel. And actions taken in it make embedded Excel become zombie.

    >> Accessing an Office object model in a thread other than the main one IS NOT recommended

    My code sample does not access COM object. Seem marshaling by itself it reason for zombie.

    In real scenario we have several modules loaded by our add-in into separate app domains. We load them concurrently and provide them with COM objects. These COM object are stored and used when processing ribbon callbacks.

    If we need to access COM from not COM thread we politely ask through Dispatcher of COM thread or through IMessageFilter to do it in COM thread.

    Monday, February 27, 2012 2:09 PM
  • We support Word, Power Point and Excel; 2003 (with very custom task panes), 2007-2010 (with partially custom task panes in PowerPoint and Word); supporting VBA scripting and inter process communication through Office COM add-ins; and several modules migrated from VSTO/Shim.

    So it seems not to be valid reason to refactor our code because of issue seems to be bug of MS Office COM/.NET interlop.

    Monday, February 27, 2012 2:53 PM
  • Hi Robin,

    Thank you for posting.

    I will help you involve others to help you. There might be some delay about the response. Appreciate your patience.

    Best Regards,


    Bruce Song [MSFT]
    MSDN Community Support | Feedback to us

    Friday, March 2, 2012 8:14 AM
  • Hello,
    You state “So it seems not to be valid reason to
    refactor our code because of issue seems to be bug of MS Office COM/.NET
    interlop.(sic)”

    Reporting bugs to Microsoft Development is the job of Microsoft Customer
    Support engineers and Microsoft Technical Account Managers.

    Because of the complexity of your project please consider opening a technical
    support incident with Microsoft Customer Technical Support.  If the Customer Support Engineer confirms
    that the issue is a bug the charge for the incident will be refunded. Otherwise
    the Engineer will work with you to resolve the issue to your satisfaction.

    To view the options for using Customer support please visit the following link:
    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone
    Regards
    Chris Jensen
    Senior Technical Support Lead


    Chris Jensen

    Friday, March 2, 2012 9:17 PM
    Moderator
  • Hi,

    I will do it (find who in charge in our company to do such things).

    Also I tried to marshal COM object in main thread, but subscribing events made zombie again.

    Now I am trying to identify that embedded windows were closed and kill AppDomains/RCWs then.

    Thursday, March 15, 2012 9:05 AM
  • I tried to react on "HCBT_DESTROYWND" of "EXCEL9" window(embedded Excel host window destruction) and monitor all  "IsWindowVisible" windows of Excel thread. And then unload all AppDomains created by our Shim. It worked to some extension. 
    But failed when e.g. PowerPoint closes all embedded  Excel windows, but retains Excel process for future uses. It leads to issue when our add-in loaded first time, then unloaded and not loaded when used activates embedded workbook again.
    Monday, March 19, 2012 2:25 PM
  • I tried to kill PowerPoint when it embeds Excel without add-ins. It leads to Excel zombie. It means that PowerPoint notifies Excel before closing.

    What message it is and how can I intercept it?

    Monday, March 19, 2012 2:28 PM
  • I made solution based on EXCEL9, monitoring parent processes and windows. Monitoring is needed because EXCEL reused even if no EXCEL window visible and our add-in should be loaded when embedded transform to full. I leads to crashes sometimes and does not work sometimes. E.g when tested Win7 Virtual PC via RDP hook was never notified about EXCEL9 lifecycle.

    Friday, May 11, 2012 10:19 AM
  • Now I faked IUnknown.Release and AddRef of Excel.Application and trying to do something with it. 
    Friday, May 11, 2012 10:21 AM
  • Accessing Excel from non UI thread leads to zombie in embedding mode regardless of AppDomains involved. I came up with such tests only now. It means that AppDomains are not relevant to embedding zombie.


    Friday, May 11, 2012 10:52 AM
  • We had add-in with several modules each loaded into its AppDomain. Loading each addin in its own STA thread was thought as optimization of  start time. I was feeling really against it, but did not have arguments at that time.

    Right now I can say:

    Much time spent on doing workarounds, teaching developers that they are not in main Office UI thread, should marshal calls via different ways, handling errors of calling into Office API, fixing dozens of Office crashes and hangs upon close employing hacks with STA message pumping, fixing that there is no one to open known time when Startup called really and in custom module, nobody was sure when something already was callbacked, open and slose Office fast crashes, etc.  

    IF WE SPENT ALL THIS TIME ON NORMAL OPTIMIZATION WE WOULD HAVE BETTER START UP TIME INSTEAD OF OUR ASYNC LOADING HACK WHICH STILL ROTS.

    Friday, June 13, 2014 3:50 PM