If you're coming down this rabbit hole, chances are you're trying to run run excel through matlab non-interactively (for example as a service or scheduled command).
Excel was not meant to run in the background unattended, but personally I see no technical reason why MS can't address this.
Some of these exceptions give misleading error messages, such as COM exception MATLAB:COM:E2148140012 Invoke Error Dispatch exception, cannot access the file 'blah blah' when doing xlsread() . When you convert that number to hexidecimal, you get MATLAB:COM:E 0x800A03EC . The 'cannot access file' actually makes sense when you consider Excel cannot access the Desktop path (and you can see this OS call result in "Not Found" if you do a file trace).
So try this one before messing with DCOM permissions. Excel likes to have access to a desktop directory. When you use Excel in your MCC compiled application running in the background, it is also looking for that Desktop directory, but because the user profile isn't always fully loaded, it can't find a desktop directory and you will run into problems.
Two of the default locations are as follows: 'c:\windows\system32\config\systemprofile\desktop' % for x64-excel on x64 hardware, or x86 on x86
'c:\windows\syswow64\config\systemprofile\desktop' % for x86-excel on x64 hardware
You will only need one, but go ahead and create both. Create these folders with an admin account and then run your remote app as non-elevated user.
As far as my testing and file tracing has determined, no files are persisted here. Excel just opens the folder and I think xlswrite will put a temp file there and moved it.
For reference: https://social.msdn.microsoft.com/Forums/office/en-US/ac2549f5-fc1e-494d-9015-70cb31d3aeb2/opening-excel-workbook-fails-when-run-from-scheduled-task-on-windows-server-2008-rw?forum=exceldev
