none
ShellExecute of docx files crashes application in Office 2016 on Win 10 & 8.1 RRS feed

  • Question

  • We're developing an application that (as a minor function) opens docx documents with ShellExecute. When we test this with Office 2016 on Windows 10 and Windows 8.1 this often makes the application crash. The error message that shows up is : "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available".

    We have tested with ShellExecute from Visual FoxPro and both ShellExecute and Process.Start (With UseShellExecute=true) in C#. The problem seems to be with the way the docx and xlsx extensions are registered. doc and xls opens without any problems. Also ShellExecute of the Word application with the docx file as argument works fine.

    Tested with Office 2016 Preview and Office Professional Plus 2016 16.0.4229.1024.

    Are Microsoft aware of this problem? Are there any known fix for this problem?


    Wednesday, September 30, 2015 5:17 AM

All replies

  • Hi Jan,

    >> We have tested with ShellExecute from Visual FoxPro and both ShellExecute and Process.Start (With UseShellExecute=true) in C#. The problem seems to be with the way the docx and xlsx extensions are registered. doc and xls opens without any problems

    I am not familiar with ShellExecute, if there is something wrong in my reply, please feel free to let me know.

    I made a simple test with code below in winform application under win 10 and Office 2016 preview (I did not have release version at present), it worked correctly with doc and docx.

            private void button1_Click(object sender, EventArgs e)
            {
                ProcessStartInfo psi = new ProcessStartInfo(@"C:\Users\Administrator\Desktop\Test.docx");
                psi.UseShellExecute = true;
                Process.Start(psi);
                MessageBox.Show("ok");
            }

    It would be helpful if you could share us steps and code to reproduce your issue.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Thursday, October 1, 2015 7:35 AM
  • Hi Edward,

    Your code is fine. The problem seems to be difficult to reproduce reliably on .Net for some reason. The FoxPro code seems to be able to more reliably crash, I'm still looking into that. Will post sample code soon.

    In the meantime, I have some more findings (tested with Visual FoxPro on Windows 8.1 and Office 2016)

    * It does not crash on Windows 7, only 8 and 10.
    * Only a file with docx content with a .docx extension opened with ShellExecute will crash the process that called ShellExecute. A .docx file renamed to .doc will not crash, nor will a .doc file renamed to .docx crash.
    * The associated AssocStr.COMMAND string are the same for .doc and .docx, both are "C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE" /n "%1" /o "%u", so there should not be any difference in how they are launched.
    * Using ShellExecute to start C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE" /n "%1" /o "%u" with the .docx document replacing %1 will not crash. So apparently ShellExecute does something more or different from just running the AssocStr.COMMAND string.
    * I also substituted WINWORD.EXE with a C# program I wrote, and what happens is that .doc files and .doc files renamed to .docx files launches WINWORD.EXE, but .docx files with docx content crashes without launching WINWORD.EXE

    So the problem is not Office 2016 directly, but rather that ShellExecute on Windows 8 and 10 does something strange when launching .docx files with docx content. Presumably this has something to do with Metro file-associations?

    Thursday, October 1, 2015 10:27 AM
  • I haven't managed to reproduce the problem in C# yet, but here is a sample Visual Foxpro program that fails

    Code compiled with Microsoft Visual FoxPro 9 SP2 (on Windows 7 OS):

    vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

         

    Doc_ShellExecute('c:\tmp\test.docx')


    ProceDure Doc_ShellExecute
    LPARAMETERS tcFileName
    LOCAL lcFileName as String
    LOCAL cOperation  as String
    LOCAL cFileName as String
    LOCAL cParameters as String
    LOCAL cDirectory as String
    LOCAL nShowWindow as Integer

    nWinHandle = 0
    cOperation  = ''
    cFileName = tcFileName
    cParameters = ''
    cDirectory = ''
    nShowWindow = 1

    *-* HINSTANCE ShellExecute(hwnd, lpszOp, lpszFile, lpszParams, lpszDir, wShowCmd)
    *-* 
    *-* HWND hwnd - handle of parent window
    *-* LPCTSTR lpszOp - address of string for operation to perform
    *-* LPCTSTR lpszFile - address of string for filename
    *-* LPTSTR lpszParams - address of string for executable-file parameters
    *-* LPCTSTR lpszDir - address of string for default directory
    *-* INT wShowCmd - whether file is shown when opened
    DECLARE INTEGER ShellExecute ;
       IN SHELL32.DLL ;
       INTEGER nWinHandle,;
       STRING cOperation,;   
       STRING cFileName,;
       STRING cParameters,;
       STRING cDirectory,;
       INTEGER nShowWindow

    ShellExecute(nWinHandle, cOperation, cFilename, cParameters, cDirectory, nShowWindow)
    RETURN 0

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    run on Windows 8.1 Enterprise ( 6.3.9600) with Trial version of Office 2016 (16.0.4229.1024) crashed with the following information:

    Problem signature:
      Problem Event Name: APPCRASH
      Application Name: shellex.exe
      Application Version: 0.0.0.0
      Application Timestamp: 47139f24
      Fault Module Name: msoshext.dll
      Fault Module Version: 16.0.4229.1024
      Fault Module Timestamp: 55f00e46
      Exception Code: c0000005
      Exception Offset: 00078e8c
      OS Version: 6.3.9600.2.0.0.256.4
      Locale ID: 2057
      Additional Information 1: 5861
      Additional Information 2: 5861822e1919d7c014bbb064c64908b2
      Additional Information 3: a10f
      Additional Information 4: a10ff7d2bb2516fdc753f9c34fc3b069

    Read our privacy statement online:
      http://go.microsoft.com/fwlink/?linkid=280262

    If the online privacy statement is not available, please read our privacy statement offline:
      C:\Windows\system32\en-GB\erofflps.txt

    Thursday, October 1, 2015 12:18 PM
  • Hi Jan,

    To be honesty, I did not have Visual Foxpro environment, and could you share me how to use your code under Visual Studio 2013? Based on your original post, it did not work in C#, but with your post code, it seems it is not in C#. It would be helpful if you could share us a c# demo to reproduce your issue.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, October 5, 2015 8:45 AM
  • I finally figured out how to make C# crash reliably.

    The code (compiled with Build Target "Prefer 32-bit" set, seems to be default)

    ProcessStartInfo psi = new ProcessStartInfo(@"C:\Users\Administrator\Desktop\Test.docx");
    psi.UseShellExecute = true;
    Process.Start(psi);

    will crash if  Xmllite.dll version 1.0.1018 is present in the same folder as the C# app.

    What probably happens:

    Office have set up a hook to ShellExecute to call a function in msoshext.dll.
    The msoshext.dll checks if the file has an *x extension (docx/xlsx/pptx)
    If it has a docx/xlsx/pptx extension it then loads Xmllite.dll to parse the xml format in the file
    If there is a Xmllite.dll file in the same folder as the app then it will load that one instead of windows\system32\Xmllite.dll
    Since the Xmllite.dll that ships with MBS is an older version than the one in Windows 8.1 it does not have all the functions that the 8.1 version have. When it tries to call a function that the older  Xmllite.dll lacks it crashes

    Tuesday, October 6, 2015 10:10 AM
  • Hi Jan,

    Thanks for your sharing. It seems your issue has been resolved, right? If not, please feel free to let us know your current situation.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Wednesday, October 7, 2015 6:09 AM
  • I would not consider the issue resolved exactly. The visual foxpro code will crash in ShellExecute even if xmllite.dll isn't present, so that seems to be a different bug. Possibly Visual Foxpro have its own version of xmllite statically linked or something. The work-around would be to find an alternative to ShellExecute, which is of course possible but will add complexity and introduce possibility for new problems.

    What I would like to know is why does Office have a hook from ShellExecute? Why does that code need to parse the file before it is launched? And why, given that the code is run within any process that may call ShellExecute, does it not make certain to catch anything that could go wrong? (Ok, that last one was rhetorical. I know it's not possible to check for every possible thing that could go wrong. But still, when doing things behind the scenes that I have no possibility to know anything about, I consider it extremely bad behaviour to crash my process while doing so! )


    Thursday, October 8, 2015 3:32 AM
  • Hi Jan,

    With a simple winform or console application, there is no Xmllite.dll in the folder, I suggest you create a simple winform application to test your code. I am not sure whether there is reference between office and xmllite.dll. If you have xmllite.dll in the folder, and remove the code UseShellExecute, will it crash your application?

    It would be helpful if you could share us steps to reproduce your issue in C#.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Thursday, October 8, 2015 5:23 AM
  • "With a simple winform or console application, there is no Xmllite.dll in the folder, I suggest you create a simple winform application to test your code. I am not sure whether there is reference between office and xmllite.dll. If you have xmllite.dll in the folder, and remove the code UseShellExecute, will it crash your application?"

    No, it will not crash my application. My application crashes within the call to ShellExecute, so if I remove ShellExecute it will not crash.


    "It would be helpful if you could share us steps to reproduce your issue in C#."

    See my earlier answer:

    "I finally figured out how to make C# crash reliably.The code (compiled with Build Target "Prefer 32-bit" set, seems to be default)
    ProcessStartInfo psi = new ProcessStartInfo(@"C:\Users\Administrator\Desktop\Test.docx");
    psi.UseShellExecute = true;
    Process.Start(psi);
    will crash if  Xmllite.dll version 1.0.1018 is present in the same folder as the C# app."


    Monday, October 12, 2015 10:28 AM
  • Hi Jan,

    I have downloaded XMLLite.dll version 1.3.1000.0 (I did not find the 1.0.1018), and place it in same level with bin folder. It did not crash. I am not sure how it used in your project. Could you share us a simple project through OneDrive to reproduce your issue?

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Tuesday, October 13, 2015 5:57 AM
  • Amyuni is the reason we have XmlLite.dll at all in our application. You can get XmlLite.dll 1.0.1018 by downloading https://www.amyuni.com/downloads/pdfdrv500.zip and looking in folder "PDF Converter\PDF Converter Printer Driver". Just put xmllite.dll in the folder where your application is, you don't need to reference it or anything. When your app calls ShellExecute, ShellExecute will load msoshext.dll which in turn will load xmllite.dll. msoshext.dll ought to load the xmllite.dll in the system32 folder, but it will load the one  in the app-folder if it exists. *** This is why ShellExecute crash! ***


    We have also found another problem with Amyuni and Office 2016 (and Redemption); if Office 2016 is installed and a process creates "Redemption.RDOSession" before trying to convert a wordfile with Amyuni then the conversion fails. But I don't expect you can help me with that. I have already notified Amyuni and Redemption about this issue.

    Tuesday, October 13, 2015 6:47 AM
  • Hello,

    The xmllite.dll file is included in our product only for winXP support. Except for winXP, all subsequent versions of windows have been shipped with their versions of xmllite.dll file.

    The XmlLite.dll is only used in our Amyuni PDF Converter when using the XPS export functionality of our product and when using the functionality, the developer should use the xmllite.dll already on the system.

    Regards,

    Amyuni Tech Support

    Amyuni Technologies Inc.


    Amyuni Tech.

    Wednesday, December 2, 2015 5:54 PM
  • Thank you! Your details here were the solution for a crashing problemwith a product called AccuZip.

    It was crashing from an Open dialog every time we moved the mouse over an .xlsx file.

    There was a Xmllite.dll in the program folder next to the executable. All I did was

    COPY %SystemRoot%\System32\xmllite.dll PROGRA~2\ACCUZI~1.0

    and it started working.

    Windows 10 Pro x64 (10586).

    -Karl

    Friday, August 26, 2016 12:28 AM
  • Thanks Jan Ove Haaland. I would simply like to mention that I experienced the same issue with different conditions:

    I have a .NET 4.6.1 application that calls 'OpenFileDialog' with extension filter = xlsm. The application would crash when browsing for files on disk, with 'Access Violation' on msoshext.dll

    Extension causing the issue was xlsm (not mentionned anywhere on this page).

    Operating system is windows 7, 64 bit.

    Removing the older Xmllite.dll from where our application is run fixed this.





    • Edited by SylvainVol Tuesday, August 22, 2017 2:07 PM
    Tuesday, August 22, 2017 1:48 PM