none
Word experienced an error trying to open the file.

    Question

  • Hi all -
    I've got a Word document with code that's been distributed to an end user.

    When she saves the document herself she sees a typical "Word experienced an error trying to open the file" message when she attempts to open the documents she has saved on her machine (with or without code).  When I open them I also see this error.

    Does anyone have any suggestions to troubleshoot?

    A permissions thing at the user machine perhaps?

    My first step is going to be to make sure the document she has is the latest and that it matches the code installed.  For future reference is there an easy way to explain to end-users how to do this?  The deploy model I'm using is:  1. end-user does one-time install and gets automatically updated.  2. end-user gets Word Document (from a central SharePoint area) and uses it locally.


    In case it matters I'm using:

    ThisDocument.SaveAs()

    ThisDocument.RemoveCustomization()

    Tuesday, June 09, 2009 12:53 PM

Answers

  • I think I can help on this, you maybe trying to load a document that is a DOCX based file with a DOC based extension and or the other way round this will cause this error to occur.

    Regards
    Mike Walker MVP - Visual Developer VSTO - Please mark the best replies as Answers !
    Tuesday, June 09, 2009 3:58 PM
  • I will also drill deeper into how I used SaveAs().  I may not have used as many of the arguments as I should have.  The description at msdn shows all the arguments as optional so I went with:

    Globals

     

    .ThisDocument.SaveAs(ref FileNameCode, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing);


    There shouldn't be any problems with this, from what I can see. The one thing I would check, however, is the default file format setting on the user's machine: Word Options/Save, the first entry. If this is set to something other than docx that could be an issue.

    Assuming that's all correct, the next thing I'd try is to have the user start Word in Safe Mode (have her hold down the Ctrl key). This will start Word with the installation defaults - locking out all add-ins as well as user customizations. In addition, it will also not load Normal.dot. Work with a new VSTO document and see if you get the same result as before, or if it now works. If it now works, then the problem is something in the Word configuration.

    If I understand correctly, the document is not being saved to a network location, but on the machine? So a loose network cable or something like that can't be an issue?
    Cindy Meister, VSTO/Word MVP
    • Marked as answer by USP45 Wednesday, June 10, 2009 4:33 PM
    Wednesday, June 10, 2009 6:45 AM
  • Cool, so the problem was what I thought caused it but the way you can fix this is by overidding the SaveAs to include the document format switch so that the default option from the user wouldn't be used by passing wdFormatXMLDocument to the FileFormat parameter.

    Regards

    Mike Walker MVP - Visual Developer VSTO - Please mark the best replies as Answers !
    Wednesday, June 10, 2009 5:00 PM

All replies

  • Which versions of VSTO and Office are involved, here?

    From the error message, the problem isn't with permissions; it's damaged internal structures in the document file. To put it another way, something is happening to "break" the document so that Word can't read it.

    One thought that occurs to me is, if this is a *.doc solution, programmed for Office 2003, and the document is being saved in a different format (such as Word 2007 docx)?

    Or, it could have something to do with removing the customization. Do you know what happens with the document after RemoveCustomization has run? It would need to be saved again... are you sure that's happening? Could the user being doing something to the document after that point that might be reinstating parts of VSTO into the document?

    It might be helpful for you to "watch over the user's shoulder" to see exactly what's being done that might be different from the scenario you were using when you developed the solution.
    Cindy Meister, VSTO/Word MVP
    Tuesday, June 09, 2009 2:16 PM
  • Hi,

    I'd suggest downloading procmon.exe (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and watching the file system activity when you try to open the file.  If Word is getting an error back from the file system, procmon will show it to you.  It could very well be a permissions issue where both you and your user have write, but not read access to the directory.  While I would expect that you would get an "access denied" error in that case, it may be that Word is simply masking the error.  Anyway, if that is the problem, you will see the real error in procmon.

    If procmon isn't showing any errors, then the trouble may well be corruption of the file itself.  Can you copy the file to another machine or location and open it successfully from there? 

    Sincerely,

    Geoff Darst
    Microsoft VSTO Team
    Tuesday, June 09, 2009 2:33 PM
  • I think I can help on this, you maybe trying to load a document that is a DOCX based file with a DOC based extension and or the other way round this will cause this error to occur.

    Regards
    Mike Walker MVP - Visual Developer VSTO - Please mark the best replies as Answers !
    Tuesday, June 09, 2009 3:58 PM
  • Hi all -
    Thanks for the suggestions.  Here is some more information in reply:
    - Office 2007 (Word extension is .docx).  User and developer both have Office 2007.
    - VSTO 2008
    - RemoveCustomization() and SaveAs() appear to be implemented correctly.  At least it works as expected on my dev as well as test machine.  i.e. I can open a Word document while testing without code and no GUI appears.  When I open the one saved without RemoveCustomization() a GUI appears.
    - Emailing her files to my machine resulted in nothing different (same error).  Emailing test saves of Word docs on my machine to hers is successful (she can open mine).
    - I watched over her shoulder as we reinstalled the code and got a fresh document from SharePoint.  She appears to be doing nothing out of the ordinary.

    I will try procmon.exe next.
    Tuesday, June 09, 2009 6:51 PM
  • I will also drill deeper into how I used SaveAs().  I may not have used as many of the arguments as I should have.  The description at msdn shows all the arguments as optional so I went with:

    Globals

     

    .ThisDocument.SaveAs(ref FileNameCode, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing);

    Tuesday, June 09, 2009 7:48 PM
  • I will also drill deeper into how I used SaveAs().  I may not have used as many of the arguments as I should have.  The description at msdn shows all the arguments as optional so I went with:

    Globals

     

    .ThisDocument.SaveAs(ref FileNameCode, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing, ref Missing);


    There shouldn't be any problems with this, from what I can see. The one thing I would check, however, is the default file format setting on the user's machine: Word Options/Save, the first entry. If this is set to something other than docx that could be an issue.

    Assuming that's all correct, the next thing I'd try is to have the user start Word in Safe Mode (have her hold down the Ctrl key). This will start Word with the installation defaults - locking out all add-ins as well as user customizations. In addition, it will also not load Normal.dot. Work with a new VSTO document and see if you get the same result as before, or if it now works. If it now works, then the problem is something in the Word configuration.

    If I understand correctly, the document is not being saved to a network location, but on the machine? So a loose network cable or something like that can't be an issue?
    Cindy Meister, VSTO/Word MVP
    • Marked as answer by USP45 Wednesday, June 10, 2009 4:33 PM
    Wednesday, June 10, 2009 6:45 AM
  • The one thing I would check, however, is the default file format setting on the user's machine: Word Options/Save, the first entry. If this is set to something other than docx that could be an issue.




    Cindy Meister, VSTO/Word MVP


    You nailed it!  When the user changed the default save behavior locally in options to docx the problem went away.
    So I will probably try to make my SaveAs() a little more robust by specifying file format so it doesn't matter what the user has set locally.

    Thanks a lot!
    Wednesday, June 10, 2009 4:37 PM
  • Hi

    Could you qualify whether the document format was set for that user differently as I stated as am keen to know whether it was the same thing I pointed to in that the DOCX filename extension actually was a binary DOC formatted file.

    Regards


    Mike Walker MVP - Visual Developer VSTO - Please mark the best replies as Answers !
    Wednesday, June 10, 2009 4:38 PM
  • That's correct; but it was impossible (well difficult) to tell because after reading your post we checked the document and it *did* have the .docx extension as expected.

    Checking the local options of the user is what finally clued us in.
    Wednesday, June 10, 2009 4:48 PM
  • Cool, so the problem was what I thought caused it but the way you can fix this is by overidding the SaveAs to include the document format switch so that the default option from the user wouldn't be used by passing wdFormatXMLDocument to the FileFormat parameter.

    Regards

    Mike Walker MVP - Visual Developer VSTO - Please mark the best replies as Answers !
    Wednesday, June 10, 2009 5:00 PM