none
Office.dll access denied to VSTO add-in RRS feed

  • Question

  • Suddenly receiving the following error when starting Excel 365 (version 1902 build 11328.20222):

    Could not load file or assembly 'office, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. Access is denied.

    This error occurs when Excel tried to load a VSTO add-in on startup.  The add-in is suddenly unable to access office.dll.  The problem seems related to a Windows update applied in Mar 2019, which is when I first observed the problem.  I have two PCs with the same Office version/build and same VSTO add-in version, but one PC has this problem while the other does not.  The two PCs have different Windows OS versions, though, so it seems a Windows update is the problem.

    Wednesday, April 3, 2019 8:08 PM

All replies

  • Hi,

    Did this problem only appear in Excel? How about Office applications?

    Did all VSTO add-ins have this problem?

    I suggest you try to revert back to earlier version of Office and check if this problem is related to Office updates:

    https://www.cnet.com/how-to/how-to-revert-to-the-previous-version-of-office-365/

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Please try this method and let me know the result, I'm glad to help you.

    Regards,

    Emi Zhang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Office 2019.

    Thursday, April 4, 2019 8:42 AM
    Moderator
  • Emi,

    I did not try other Office applications or other VSTO add-ins since this is an Excel add-in and I do not have any other VSTO add-ins to test with.  Everything was working fine until one day recently it wasn't.  I hadn't updated the add-in software prior to this problem occurring, and updating the software since did not resolve the issue.

    Already tried rolling back Office to a Feb build (well before I had this problem) with no success, as expected since the Office version/build is apparently not the issue per my original post.  So, as I mentioned, it seems to be an issue with a Windows 10 update.

    Note that you have to set system environment variable VSTO_SUPPRESSDISPLAYALERTS=0 to show the VSTO error, since these errors are suppressed by default (without this, the only indication of a problem is that the add-in simply doesn't load).

    Thursday, April 4, 2019 12:45 PM
  • Hi,

    Did you know the detail version information of Windows?

    Regards,

    Emi Zhang


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Office 2019.

    Friday, April 5, 2019 6:22 AM
    Moderator
  • Windows 10 Pro version 1809
    Friday, April 5, 2019 1:27 PM
  • Hi!

    I have encountered this issue since March 2019. I suspect there is an issue with Windows'/Office's rights-management of a certain office.dll

    The error message refers to the file: 

    C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c\office.dll

    This file should have persmissions looking like this:  (sry cannot insert image)

    But you should have the read and execute right.

    However, it seems like some update broke some of this and some Office-Addons don't respond well to this.

    In spite of the missing permissions on the file. The affected users still have all rights on the folder itself:
    C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c

    I usually just rename this folder to 15.0.0.0__71e9bce111e9429c_old and copy its office.dll into a new folder with the original name.

    This way the user is owner of the file and has access again. All Addons work perfectly again until Windows decides to mess with the rights again. 

    You could automate this process with a script until Microsoft fixes this.

    Workaround in summary:

    RENAME C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c_old

    XCOPY C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c_old\office.dll C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c /y


    • Edited by Climeworker Wednesday, May 15, 2019 8:55 AM
    • Proposed as answer by JoeFulford Thursday, October 10, 2019 11:11 AM
    Wednesday, May 15, 2019 8:53 AM
  • @Climeworker, thanks for posting this answer.  I am sure this is within the capabilities of an IT professional, but how can we expect a regular person follow these steps?  More importantly, when is Microsoft going to fix this Windows/Office bug?  It's been over two months!
    Wednesday, May 15, 2019 11:29 AM
  • I don't work for Microsoft. I can't do anything but tell you how I fixed it.

    We followed the error message, found out it is an access rights problem and we identified which file it is. Then I found a way to trick Windows into changing the permissions on the tile to suit me.

    As an unexperienced user:

    Copy the path I posted into the Explorer window and rename the folder "15.0.0.0__71e....." to have a suffix "_OLD" or something like that.

    then copy and paste it in the same directory. then remove the "_OLD_copy" from the new folder. (so that it's new name is the same the other folder was called before)

    that's it.


    Friday, June 7, 2019 6:36 AM
  • Hi, @Climeworker

    Our third party software uses Interop Assemblies for our MSO integration code. We had been using Office 2010 PIA when this started occurring to some of our users. We have had this call coming in for at least 6 months, consistently, and do not have the problem except for users of Windows 10 version 1809. They seemed to have yanked compatibility for Office 2010 assemblies and are now re-directing so it expects 2013 or 2016 assemblies.

    Our developers decided to move up to Office 2013 assemblies and embed them instead of communicating with Microsoft's assembly location. We have not found any Microsoft documentation saying they would no longer support Office 2010 PIA, but that seems to be the takeaway for us. 

    This is who tends to call in:

    --Windows 10 user who ordered a new PC from Dell, Lenovo or HP and it shipped with a clean install of Windows 10 version 1809. 

    --Windows 10 user who is on version 1809 and is on Office 2016, 2019 or Office 365 version 1906 (may have been working on that 1809 version before they patched up to version 1906 for their Windows)

    Conservatively, this has affected probably about 200 PCs for our user base. We are not allowed to touch the Windows assembly location since those locations should be managed by the firm's desktop administrators. [Interestingly, I think one of our client's IT guys did the same workaround you did]. 

    Hope that helps!

    Monday, August 5, 2019 8:17 PM
  • Suddenly receiving the following error when starting Excel 365 (version 1902 build 11328.20222):

    Could not load file or assembly 'office, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. Access is denied.

    This error occurs when Excel tried to load a VSTO add-in on startup.  The add-in is suddenly unable to access office.dll.  The problem seems related to a Windows update applied in Mar 2019, which is when I first observed the problem.  I have two PCs with the same Office version/build and same VSTO add-in version, but one PC has this problem while the other does not.  The two PCs have different Windows OS versions, though, so it seems a Windows update is the problem.

    Hello yes98785, my name is Ryan and I work for Microsoft.  I wanted to check in with you about this issue.  Please email me at rycarter@microsoft.com if you're available to do so.  Thanks!

    Ryan Carter

    Tuesday, August 13, 2019 4:03 PM
  • Hi Ryan--

    I have a customer who is experiencing a nearly identical issue, except the assembly that's failing to load is Microsoft.Office.Interop.Excel:

    System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Office.Interop.Excel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. Access is denied.

    The customer is installing on a new machine with Office 365. The customer has other PCs that have been using our software for years now without issue, it's only the new machine that is experiencing issues.

    I've seen advice about embedding interop types, but this is not possible for all of our assemblies currently without significant rewrites of legacy code (the compiler will throw errors about embedded interop types being used with generic arguments that cannot be used across assembly boundaries--e.g. exposing publicly a CLR Dictionary<TKey, TValue> where one of the type args is an embedded interop type)

    Do you have any guidance at all on this issue?

    Thanks!

    Friday, August 16, 2019 6:57 PM
  • Hi - would you mind reaching out to me on email?  rycarter@microsoft.com I am unable to see your email via your profile.  Thanks!

    Friday, August 16, 2019 7:56 PM
  • Ryan,

    I also have run into issues with permissions on Microsoft Assemblies. My issue is this forum:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/9b6d7c2d-4783-412d-8e78-156219ff8baf/word-add-in-fails-to-load?forum=vsto&prof=required

    It's specifically wiping access to Microsoft.Office.Interop.Word.dll and the Office.dll. There is a windows update that is rebuilding these files and wiping access to them.


    Tuesday, August 20, 2019 8:29 PM
  • Ryan, 

    You are already aware of this, but it is good to know that my company has also been seeing this sort of problem with attempts to load COM Interop primary interop assemblies since roughly February 2019.  This has happened to scores of our customers in the field.  Here's that thread for reference.  We have been working with you and jmillerim2 to figure it out, and it sounds like you are making progress.  In our case, the integration was with Microsoft Project, whereas in the case of jmillerim2, it was with Microsoft Word.   The one common assembly that both of these rely upon is office.dll, which looks like it is the culprit in this current thread.  We worked around the problem by embedded all COM Interop directly into our assemblies, and that did the trick, but it was a pain to accomplish.


    ...Jim Black

    Friday, August 23, 2019 5:48 PM
  • Our company, which develops VSTO add-ins for Excel, PowerPoint, and Word, and its customers have been affected by this problem since Mar 2019.  I wanted to reply "me, too" here because I know that add-in publishers will take some comfort in knowing others are experiencing the same problem.

    We have been working with @Ryan_Carter_MSFT and his team on helping troubleshoot the issue, and I hope we are getting close to a solution.  If any other publishers want to network (or commiserate) offline with us on this issue, Ryan knows who we are and can put you in contact.

    We observed this permissions issue with office.dll, specifically, but in troubleshooting we learned that many of the Office-related DLLs are affected by the same problem.  So whether the problem is office.dll or another Office application DLL, the root cause is likely the same.

    We have considered embedding COM interop into our assemblies, as Jim's company has done, but this would not be trivial given the size of our code base and other factors, and likely only an interim solution that we would want to reverse once the problem is resolved.  We are hoping Microsoft will fix the problem before we are forced to go down this path. 

    Monday, August 26, 2019 1:13 PM
  • Thank you for your help. Your method didn't work 100% for me, I tried to do the renaming folder and then copy the DLL but for some reason it didn't work. So I simply wen't back to the original folder and then took ownership of the office.dll file. 

    Thank you!

    Thursday, October 10, 2019 11:10 AM
  • We're facing the same issue in one of our .NET COM Add-ins with AccessDenied when loading Office.dll, Microsoft.Office.Interop.PowerPoint.dll and Microsoft.Office.Interop.Excel.dll from the GAC. We found the error message using FusionLog. In Windows Explorer the user had no permissions to read/execute these DLLs in the GAC.

    We're telling our customers to contact Microsoft in the way Ryan suggested.

    Beside that an easy workaround/quick-fix is to fix the file permissions by copying the ones from notepad.exe from a PowerShell with administrative privileges:

    $file0 = "C:\Windows\notepad.exe"
    
    $file01 = "C:\Windows\assembly\GAC_MSIL\office\15.0.0.0__71e9bce111e9429c\OFFICE.DLL"
    get-acl $file0 | Set-Acl $file01
    
    $file11 = "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.PowerPoint\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.PowerPoint.dll"
    get-acl $file0 | Set-Acl $file11
    
    $file21 = "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll"
    get-acl $file0 | Set-Acl $file21

    We only load these three DLLs so we only 'fix' those. You might have to adjust it depending on which DLLs you're loading. This solution does not work for a deployment/production but might help in the short-run.




    Monday, October 28, 2019 3:44 PM
  • Same issues here on users with windows 10 1903 (updated), using Office 365. when opening any excel file, even new ones.

    A repair on .NET seems to fix the issue for a few days but always comes back.

    Error :

    Unhandled Exception: Could not load file or assembly 'Microsoft.Office.Interop.Excel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. Access is denied


    Monday, November 4, 2019 2:23 AM
  • Same issues here on users with windows 10 1903 (updated), using Office 365. when opening any excel file, even new ones.

    A repair on .NET seems to fix the issue for a few days but always comes back.

    Error :

    Unhandled Exception: Could not load file or assembly 'Microsoft.Office.Interop.Excel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. Access is denied


    Hello, could you please reach out to me directly ryan.carter at microsoft.com. We would like to work with you to capture this as you seem to be able to repro is fairly readily.  Thank you in advance!

    -Ryan

    Monday, November 4, 2019 10:20 PM