8

I have a .net console application written in c# which does exactly what it should when run inside visual studio and when clicking the .exe file in the file system. It runs like a charm. BUT when I create a scheduled windows task either in my Windows 7 dev machine or the Windows 2008 R2 prod machine it fails to carry out the last step in the application. This step is to open a .doc in the background and covert it (simply running a save as) to a .docx.

The application is designed to visita network path, create a dir called ~Converted which it does not problem and then for each .doc it finds it opens in background, performs a save as and them saves a .docx version of the do in the ~Converted dir. I believe there is nothing wrong with the code since it builds and runs without issue outside of the scheduled task. I have explored every setting inside the task, made alterations and re-tested with no success. I am running it wit a user who is part of the administrators group, IMO permissions is not the issue. I have tried it with the NETWORK SERVICE account, same result.

The actual stack trace error which is only being generated when run through the scheduled task is:

System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

The line of code which is doing this is:

Application oWord = new Application();

I have search for hours on this and found nothing helpful. It seems like running the code via the task is causing a COM access issue when the code is opening/initializing the word doc. The task is being fun with full admim privileges, running with highest privileges and when the user is logged on or not. As I said all these setting have been played with, it has not made a difference.

It has got to the stage now where I will have to re-write this console application as a service If I cant solve this issue. Hopefully somebody can save me a full days extra work and help me with the issue??

Adding - Based on @Dmitry Martovoi post below I have added ticks for the EVERYONE user and the stack trace has changed to:

System.NullReferenceException: Object reference not set to an instance of an object.

which is pointing to this line inside the same saveAs function:

oDoc.Close(false, Type.Missing, Type.Missing);

Adding - I have been changing users who own this path that much im not sure which user was running it this was generated. here is an application event log erorr. NOTE - This only happens when running the application via task scheduler:

Faulting application name: WINWORD.EXE, version: 14.0.6129.5000, time stamp: 0x5082f340
Faulting module name: btmofficea.dll, version: 3.0.2.280, time stamp: 0x4cc57919
Exception code: 0xc0000005
Fault offset: 0x0000000000005e1f
Faulting process id: 0x2a6c
Faulting application start time: 0x01ce8bec64ccf85d
Faulting application path: C:\Program Files\Microsoft Office\Office14\WINWORD.EXE
Faulting module path: C:\Program Files\Motorola\Bluetooth\btmofficea.dll
Report Id: a393403d-f7df-11e2-b68c-74de2b9ca154

OK problem is fixed. As can be seen in the link @dmay pasted MS do not recommend running office applications unattended on the server side and says this is unsupported. However the solution was down the track @Dmitry was headed:

  1. Start->Run->dcomcnfg

  2. Component Services->Computers->My Computer

  3. Right-click My Computer, Properties

  4. COM Security tab, Launch and Activation Permissions, Edit Default

  5. Add all access rights for NETWORK SERVICE (which is the best account to use apparently), you are using to run scheduled task

  6. Right-click My Computer > DCOM Config > Microsoft Word 97 - 2003 Document > Properties

  7. Go to identity Tab and tick the interactive user

  8. Go to Security tab and check the customize settings for all three sections. Make sure NETWORK SERVICE shows and has options ticked. This should be as a result of step 5.

  9. Repeat from step 6 for other office document types. I have done so for xls and mdb

  10. restart....All are working well now

Sorry I should have added this. If you can not see these at step 7:

               'Microsoft Word 97 - 2003 Document'

               'Microsoft Excel Application'

               'Microsoft Access Application

Then it probably a 32bit office installation on a 64 bit machine, here is the solution to make them visible:

TylerH
  • 20,799
  • 66
  • 75
  • 101
Mat41
  • 1,287
  • 4
  • 15
  • 29
  • sounds like the server where you are running the Scheduler has several things that could be the issue.. 1. MS Word is it installed on that server? 2. did you deploy the correct .dll's that support the version of Word that you are using on your local machine 3. Look at GAC as well as copying over a correct version of Microsoft Office dll – MethodMan Jul 28 '13 at 23:29
  • 1
    Its being run locally yes I do have Word installed. What dlls are you talking about? I am unsure about GAC? My theory is the code runs fine without the task being invloved so I am of the opionion the code and associated application dlls/files etc should be fine. I strongly suspect this DCOM CONFIG area is the problem. I just cat find the setting. IMO task scheduler is having security issue accessing COM.....Help – Mat41 Jul 28 '13 at 23:39
  • when you run the application how did you get Word to work you would have had to use / add some dll / reference to the references did you not – MethodMan Jul 28 '13 at 23:54
  • This reference was added using Microsoft.Office.Interop.Word which is the namespace provide support for interoperability between the COM object model of Microsoft Word 2010 and managed applications that automate Word 2010. Therefore it should automatically reference the correct dlls for me, shouldn't it? – Mat41 Jul 28 '13 at 23:59
  • never assume.. do you know how many different versions of MS Office there are.. and how many versions of Visual Studio there are .. you need to make sure that you have the same copy of the .dll installed on the target machine.. – MethodMan Jul 29 '13 at 00:03
  • Yes I understand. At the moment I am working locally so this eliminated this I believe. Everything is being run locally, it all works except when I run it via scheduled task. In my opinion if there was some dll issue I would not be able to run it directly via the exe file. Any other ideas? – Mat41 Jul 29 '13 at 00:10
  • not true.. don't be one of those developers who say's `Well it works on my Machine` – MethodMan Jul 29 '13 at 05:32
  • It seems like a permissions issue to me. Running the code inside VS is way too different to running it on its own. VS takes care of most of the stuff and makes life easy for the developer. Can you please check if the account you are using to run the scheduled task has permission to access the network path? – Robert Dinaro Jul 28 '13 at 22:46
  • Hi there. Yes I am running it under an account that has full administrator privileges. The path under the current test is a local C drive path, also the process is aloowign the user the create the ~Converted dir. IMO its not anything to do with the actual user....but I very stuck so open to all suggestions! – Mat41 Jul 28 '13 at 23:09
  • Ok Cool; can you try one more thing. try running the app manually by double clicking the .exe and see if it runs without any issues so we can separate the issue from problem with Scheduled task specifically. Apologies if you have done it already and I missed it. thanks – Robert Dinaro Jul 28 '13 at 23:35
  • HI Robert. Yes it runs 100% fine by eliminating task sheduler. Its runs fine inside Visual studio and fine by clikcing the .exe file. I strongly suspect this DCOM CONFIG area is the problem. I just cant find the setting. IMO task scheduler is having security issue accessing COM. – Mat41 Jul 28 '13 at 23:41

3 Answers3

10

You should grant to the specified user access to COM automation factory:

  • 1) Start->Run->dcomcnfg
  • 2) Component Services->Computers->My Computer
  • 3) Right-click My Computer, Properties
  • 4) COM Security tab, Launch and Activation Permissions, Edit Default
  • 5) Add all access rights for the specified user, you are using to run scheduled task.
Dzmitry Martavoi
  • 6,867
  • 6
  • 38
  • 59
  • I got excited when I saw this reply. It looked like a real good suggestion! It did not work for me. I added abd gave my local admin user and the NETWORK SERVICE account ticks in all the four boxes ans tried running the task on behalf of both users, same result. Any other ideas? – Mat41 Jul 28 '13 at 23:17
  • I have accepted this answer because its 80% of what needed to be done. Please note steps labelled 1-10 in my original edited post. Steps 1-5 being those suggested by @Dmitry – Mat41 Jul 29 '13 at 22:37
8

Faced with similiar problem, when application normally is worked as expected, but when i run it from the scheduled task, it's immediately closing, and throws an error: "File path not found ...".

Fixed it with setting scheduled task action parameter:

Start In (optional): c:\my application\executable folder path

Fragment
  • 1,555
  • 1
  • 26
  • 33
1

The first of all, take a look on this http://support.microsoft.com/?id=257757

You can try few things:

dmay
  • 1,340
  • 8
  • 23
  • I did find this very weird solution of creating C:\Windows\SysWOW64\config\systemprofile\Desktop folder on Friday which did not help me. My system is 64 but I will put it under system32 because at the moment I am willing to try anything. I am not liking the idea of re-writting this as a service. Surely there is a solution out there for me!!!! – Mat41 Jul 28 '13 at 23:20
  • The support.microsoft.com link no longer works. – EvilSnack Nov 03 '21 at 14:27