Script scheduled thru Windows Scheduler

[wagert]

I thought i would share the solution to a problem that several folks have reported here in the past.
I have a script which loads and manipulates some Excel files (xlsx's, csv's, etc) .  The code (in studio or as an exe) works fine when invoked manually. But, when run as a scheduled task (I'm running this on a Windows/2012 server), it just hangs.

Using a bunch of debugtraces, I narrowed down where it was hanging.. which was in a ObjectOpen("Excel.Application").

I was pulling my hair out .. fussing with permissions, file locations, etc etc.

After much google-ing, I finally found the solution .. which was reported started (based on the forum thread) back in 2010.

Here's the url to the forum thread which matches my problem and contains the solution.

https://social.msdn.microsoft.com/Forums/Lync/en-US/ac2549f5-fc1e-494d-9015-70cb31d3aeb2/opening-excel-workbook-fails-when-run-from-scheduled-task-on-windows-server-2008-rw?forum=exceldev

The original link in that thread with the suggested solution is broken, so reading further in the thread yielded the solution i applied.

Basically, there is a missing folder in c:\windows\syswow64\config\systemprofile .. and/or C:\Windows\System32\config\systemprofile.
Adding the folder 'desktop' to those folders .. ie., c:\windows\syswow64\config\systemprofile\desktop and/or c:\windows\syswow64\config\systemprofile\desktop resolved my issue ..

The folder(s) were added (and you may need to adjust security/permissions to allow the folder(s) to be created and accessed).. no content, just the existence of the folders made things work.

I believe the SYSWOW64 folder is used if running 64-bit Excel.. and the System32 folder is required if running 32-bit Excel.. though i'm speculating here.  I added both.. and didn't try to make things fail by having one or the other, but not both.

I've not seen a good explanation of why this fixes the problem.. but it works.. at least for my situation running 32 bit Excel from a scheduled task.

Hope this helps folks with a similar problem.

Scott

[td]

Thanks for sharing your discovery. 

You do have it backwards.  The  SYSWOW64 folder is used by 32-bit exes and system32 is used by 64-bit exes.  The OS uses file redirection to makes 32-bit exes use  SYSWOW64 when they attempt to access system32.

And IIRC the solution you suggest is mentioned either on this forum or in the Tech Database someplace but now there is another reference for users to find.