none
System.Runtime.InteropServices.COMException (0x800A140C): Word cannot start the converter MyConverter RRS feed

  • Question

  • Hi guys,

    We have developed a Word add-in that makes use of a COM File Converter  to convert the .DOCX/.DOC file to our own format (the File Converter gets the raw content of the file, encrypts it, generates other resources such as the document in PDF, etc... let's say that the final document has multiple documents inside, that's why we need the File Converter).

    Our solution has been working perfectly in Office 2013 and 2016 for at least a hundred of users. But a week ago we found a couple of users for whom the creation of the file in our format is failing (is only happening in Office 2013). This is the exception Word is throwing:

    System.Runtime.InteropServices.COMException (0x800A140C): Word cannot start the converter MyConverter.
       en Microsoft.Office.Interop.Word.DocumentClass.SaveAs(Object& FileName, Object& FileFormat, Object& LockComments, Object& Password, Object& AddToRecentFiles, Object& WritePassword, Object& ReadOnlyRecommended, Object& EmbedTrueTypeFonts, Object& SaveNativePictureFormat, Object& SaveFormsData, Object& SaveAsAOCELetter, Object& Encoding, Object& InsertLineBreaks, Object& AllowSubstitutions, Object& LineEnding, Object& AddBiDiMarks)

    This error is raised when we call to Document.SaveAs. We only define a value for the first two parameters:

    • FileName: the path is correct, the filename too and the user has permission to save there.
    • FileFormat: retrieved by calling to Microsoft.Interop.Office.Word.Application.FileConverters then iterating on them and asking for the field FormatName that has the expected value (MyConverter). It is always found and in fact the value passed to SaveAs is 25 (just if it could be of help)

    For the rest of parameters we are passing Type.Missing.

    This is how we get the FileConverter (and so the FileFormat when calling to SaveAs):

    public static Word.FileConverter GetFileConverter(Word.Application application, string formatName)
            {
                Word.FileConverters fcs = application.FileConverters;
                foreach (Word.FileConverter fc in fcs)
                {
                    if (formatName.Equals(fc.FormatName))
                        return fc;
                }
                return null;
            }


    Unfortunately our COM File Converter doesn't get called, that would mean there is an error in our side, but is Word that decides not to call our File Converter for some reason.

    We have made several tests in order to find what might be happening:

    • Same operating system, same Office version, same .NET framework version
    • User with administrator rights, user without (we install the FileConverter and the Addin in HKLM branch)
    • For the COM File Converter the identity of the user is Interactive.
    • In Office 2013 the same features are installed (filters and converters too)
    • AD accounts and Local accounts (at the beginning we thought this could be relevant)

    The result of our tests is that there could be two PCs apparently equal for which in one it works but in the other it fails. There must be something else we are not taking into account, GPOs?? Local policies??

    We are quite desperate as we have tried everything we know, and the error 0x800A140C is not informative enough in the searches.

    These are the versions of each component:

    • Microsoft Office Word 2013 version 15.0.4833.1000 32 bits (checked that in 64 bits fails too)
    • C# .NET Framework version 4.0.30319
    • Microsoft Windows NT 6.2.9200.0
    • Microsoft Visual Studio Tools 2010 for Office Runtime (x64) (PCs are 64 bits) version 10.0.50903
    • Microsoft Office 2010 Primary Interop Assemblies version 14.0.4763.1024

    I would really thank you if any of you could have an idea of what might be happening or could tell us how to get more information from the exception thrown.

    Thank you in advance!

     


    Jose Garcia Almajano

    Wednesday, February 8, 2017 6:50 PM

Answers

  • We have finally detected the reason why it was failing.

    In those PCs where it was failing users had Office 2013 (15.0.4833.1000) BUT also Skype for Business 2016 (16.0.4266.1001).

    So in those PCs where it fails there is a mix between Office 2013 and Office 2016. After uninstalling Skype for Business 2016 the problem got fixed. I don't really know the reason why IT decided to make that mixture but we are now in converstations with them in order to understand the scenario.

    Skype for Business 2016 may have an integration with Office and that is the reason for the issue, an incompatibility between both versions.

    Celest, thank you for your time.

    Regards,


    Jose Garcia Almajano

    • Proposed as answer by Chenchen LiModerator Wednesday, February 22, 2017 1:59 AM
    • Marked as answer by josimapi Wednesday, February 22, 2017 8:47 AM
    Tuesday, February 21, 2017 5:35 PM

All replies

  • >>The result of our tests is that there could be two PCs apparently equal for which in one it works but in the other it fails

    When does it work and when does not? Do you mean it works when using Admin account?

    To check whether the issue is related with the add-in or file converter, I suggest you test:

    1) test the add-in without file converter.

    2) create a winform application to use the file converter.


    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.

    Thursday, February 9, 2017 9:56 AM
    Moderator
  • First of all I wanted to thank you for your response.

    Apparently both PCs are equal and no matter if account is Admin or not, in one PC always work, in the other doesn't.

    We have checked that the add-in without file converter works correctly, but we don't know how can a COM File Converter be tested without using Office, as the lifecycle of the service is controlled by Office. The only way that comes to my mind is by creating a WinForm application that uses the Microsoft.Office.Interop.Word library, which should be the same we are now doing.

    Am I correct?

    Thank you


    Jose Garcia Almajano

    Thursday, February 9, 2017 10:18 AM
  • Hi,

    I am trying to involve someone familiar with this topic to further look at this issue and it will take some time. Your patience will be greatly appreciated.

    Sorry for any inconvenience and have a nice day! 

    Regards,

    Celeste



    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, February 15, 2017 8:52 AM
    Moderator
  • Thank you Celeste. We have been doing more testing and might be something related to the software itself, we are testing on a VM by uninstalling relevant hotfixes just to check if it could be any of them.

    Regards,


    Jose Garcia Almajano

    Wednesday, February 15, 2017 9:01 AM
  • We have finally detected the reason why it was failing.

    In those PCs where it was failing users had Office 2013 (15.0.4833.1000) BUT also Skype for Business 2016 (16.0.4266.1001).

    So in those PCs where it fails there is a mix between Office 2013 and Office 2016. After uninstalling Skype for Business 2016 the problem got fixed. I don't really know the reason why IT decided to make that mixture but we are now in converstations with them in order to understand the scenario.

    Skype for Business 2016 may have an integration with Office and that is the reason for the issue, an incompatibility between both versions.

    Celest, thank you for your time.

    Regards,


    Jose Garcia Almajano

    • Proposed as answer by Chenchen LiModerator Wednesday, February 22, 2017 1:59 AM
    • Marked as answer by josimapi Wednesday, February 22, 2017 8:47 AM
    Tuesday, February 21, 2017 5:35 PM
  • Hi,

    We are glad that the issue has been fixed. I suggest you mark your post as answer, it might be helpful for others with similar issue.

    Regards,

    Celeste 


    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, February 22, 2017 2:02 AM
    Moderator