Yesterday (Friday) I just got one of these very long ‘there must be a bug somewhere’ sessions.
The Windows Service that is a part of the quite old and not well thought through system architecture (that I currently maintain) needed to open an Excel file.
We just moved it to a Windows Server 2008 R2 and out of blue the service wasn’t able to open the Excel file.
Reporting an exception:
Microsoft Office Excel cannot access the file '\\data\data.xls'. There are several possible reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook.
Trying to find the reason I did the usual, that is:
- open Excel in Excel on local box (worked 😉
- open Excel from a Python script using pyExcelerator on the server (worked)
- open Excel from .net 4 from a small console app using the same COM Interop wrapper (worked)
So it was clearly about the Windows Service, I went out to check security rights – got all (to the folder where Excel file live).
That was the highest time to bring cannons to the battle. As the problem was in the file access area, I started up Process Monitor and hopefully was able to filter by the Windows Service process.
And here I got it, when the Excel instance was starting (mind it was a 32-bit process on 64-bit Windows) it could get access to the mystery location:
I’m not even going to pretend I understand why Excel try to get access to this folder.
Probably something on the WoW64 layer.
Of course, as soon as I got that path and googled it the problem become obvious (about 1.5k results)
By the way, as a side dish I’ve read the Best Practices for WOW64 – really worth scanning through.
If for anything else just to asses how hard it might be to make sure your 32-bit still works on 64-bits Windows.
Consider even such obscure bugs like the issue with GetThreadContext() that may return stale contents (described by Zach Saw on his blog)!
But why would Excel try to access Desktop under WoW64 ?
Here comes the (infamous?) KB257757: Considerations for server-side Automation of Office
Now I know – that isn’t the only issue I will face – Excel need to go server-side wise.
There is little option to get Excel Services there, but probably the best approach is to make sure that incoming data aren’t in any application specific file format.
I wonder how long it would be before I will google my own post 😉