Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, April 3, 2019 8:08 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.
All replies (24)
Thursday, April 4, 2019 8:42 AM
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 [email protected].
Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Office 2019.
Thursday, April 4, 2019 12:45 PM
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).
Friday, April 5, 2019 6:22 AM
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 [email protected].
Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Office 2019.
Friday, April 5, 2019 1:27 PM
Windows 10 Pro version 1809
Wednesday, May 15, 2019 8:53 AM | 3 votes
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
Wednesday, May 15, 2019 11:29 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!
Friday, June 7, 2019 6:36 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.
Monday, August 5, 2019 8:17 PM
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!
Tuesday, August 13, 2019 4:03 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 [email protected] if you're available to do so. Thanks!
Ryan Carter
Friday, August 16, 2019 6:57 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 7:56 PM
Hi - would you mind reaching out to me on email? [email protected] I am unable to see your email via your profile. Thanks!
Tuesday, August 20, 2019 8:29 PM
Ryan,
I also have run into issues with permissions on Microsoft Assemblies. My issue is this forum:
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.
Friday, August 23, 2019 5:48 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
Monday, August 26, 2019 1:13 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.
Thursday, October 10, 2019 11:10 AM
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!
Monday, October 28, 2019 3:44 PM
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, 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
Monday, November 4, 2019 10:20 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
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, December 2, 2019 11:20 PM
Same here. Have you figured anything out datachick?
Monday, December 16, 2019 4:36 PM
Hi All,
This issue is possibly a bug and Microsoft is investigating it further. Sorry for the inconvenience caused due to this issue.
I will update this thread whenever we have more details on this issue.
Regards
Pradip
Wednesday, January 8, 2020 4:07 PM
Hi All,
This issue is possibly a bug and Microsoft is investigating it further. Sorry for the inconvenience caused due to this issue.
I will update this thread whenever we have more details on this issue.
Regards
Pradip
Hi Pradip,
do you have an ID or a link where I can see the status of this issue? We have multiple customers running into this problem when using our office add in. So a quick solution would be necessary.
Thanks in advance
Wednesday, January 15, 2020 2:44 PM
I believe it is important to post an update on this issue affecting many vendors and their customers. We have been interfacing regularly with Microsoft on this issue since about July 2019, and this is what we know so far:
The "Centennial" version of Office that shipped with new PCs is at the root of the problem. Microsoft guided PC manufacturers ("OEMs") to discontinue shipping Centennial Office with new PCs, but this practice nonetheless continued into 2019. Centennial Office updates automatically from the Windows Store, and when it does, permissions on Office DLLs are corrupted. Uninstalling and reinstalling Office temporarily resolves the problem, but uninstalling Office does not completely remove Centennial Office, and when the remaining Centennial Office files are again updated from the Windows Store, permissions are again corrupted. This likely explains why other solutions proposed here and in other forums (e.g., copying permissions from notepad.exe, repairing .NET Framework) provide only temporary relief.
Temporarily disabling automatic updates from the Windows Store (if this is even possible) until Microsoft releases a permanent could theoretically offer a more permanent remedy, but potentially affect updates of other installed software was well, of course.
Microsoft continues to work on developing a fix for this problem, and has involved multiple teams in researching this issue. We are satisfied that this issue is getting adequate attention internally at Microsoft. The reason the fix is taking so long is that the problem could not be reproduced by Microsoft for months, and they needed to collect a lot of data in customer repros to pin down the root cause. Having identified the root cause, the question is now how best to deliver the fix. We would all hope for an Office or Windows update that fixes the problem, but the nature and scope of the problem present challenges to releasing a fix this way, and require internal approvals at a high(er) level. Alternatively, the fix could come in the form of a script that admins run on affected PCs. Our last communication with Microsoft suggested that they believe they can release the fix in an Office / Windows update. Our sense is that Microsoft is getting close to a solution and will offer a permanent fix in weeks, not months.
In the meantime, OEMs should no longer be shipping Centennial Office preinstalled (according to Microsoft), so this problem's frequency should decrease going forward. Although the number of our own customers reporting this problem has indeed decreased since Aug/Sep (when we often received multiple reports each day), it is unclear if this is just due to seasonality in the new PC market (we received relatively few reports in Oct, Nov, and Dec, but in Jan we are seeing a small spike in reports).
Sunday, February 16, 2020 1:59 PM
Same problem with my preloaded office..
System.IO.FileLoadException
HResult=0x80070005
Message=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.
Hope to get Microsoft quick resolution.
Friday, May 1, 2020 7:46 PM | 1 vote
Microsoft released a fix for this problem on Apr 28. See this article for more information: https://docs.microsoft.com/en-us/office/troubleshoot/installation/access-denied-error-when-starting-third-party-apps?branch=pr-en-us-1383.