Hi,

I have an executable which needs to be scheduled for daily usage. So far no problem.
I create a new task, fill out the command and Working Directory. Simple enoug, did this before, but the executable returns an error.
(Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at ExportNamespace.ExportNamespace.main(String[] sArgs) in C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\Projects\ExportNamespace\ExportNamespace\Module1.vb:line 98)

The Log file created by the program looks like this:

ERROR: mscorlib
ERROR: The handle is invalid.


The weird thing is that it doesn't return the error when i launch it through explorer or when i schedule it using Windows scheduler. It seems to be VC bound.

Any ideas on what might be happening here?

Hans

---

Hi Hans,

the question is what you are trying to do in your .exe. Do you have the source? What is the reason you get an error on line 98 in your code?

Most common reason is that your code require some elevated rights, other than SYSTEM which is the default user. If that is so you might require a Credential. If you are only working locally you need to add your local admin user as a Credential and select it.

---

Henrik,

Thanks for the quick response.

It's a third party .exe, so i do not have the source code. I'm in contact with them though to find out what happens on line 98. ;)

The exe is executed on a server and Credentials are always used. If i log on to the server and execute it manually the app runs correctly, running it from VC using the same credentials should have the same outcome, right?

---

Yes, depending on what you try to do (in the code). For example, if you need to reach server X you need to use UNC paths in the code (because mapped drives are not shared among users). Also, you need to use a user on server X, not a local one (together with option "Network Credentials".

---

Actually there is a call from server A to Server B in the code.
However, i don't understand why this should matter. Even using a user that has full access/privileges on both servers, the app keeps throwing the error when run in VC.

---

It does matter because it is Executed by the SYSTEM account by default (VisualCron is running as a service). So, by default, it has not network access unless you give the right privileges. If you are using a local user right now on server A you don't have access to Server B.

But, it could be more things that is in the code that changes this.

There are 3 ways to solve this:

1. use the right Credential (best option)
2. Run the Execute Task in foreground mode (limited - not recommended)
3. change the user that runs the VisualCron service (not recommended)

---

I might not have been very clear in my previous post.
I understand the importance an use of the right credentials to run a task.

We _ALWAYS_ use credentials for our tasks and in this particular case the credentials have access to both servers. I just don't see that this could be the reasoon for failure.

Running the task in Foreground mode hassen't helped either.

I'll try the third option as soon as i have the change...

Thanks for the input.

---

Ok, it was just my guess that this was the issue. But, according to the very little debug information we have it seems to be about namespaces (and could be some kind of problem where your exe refers to a dll somewhere else - if workdir is changed or something like that). But please try to get this information from the developers.

---

I've tried changing the user running the Vc service but that wasn't the solution either.

Windows scheduler performes the task without any problem.
I'm thinking there might be a fundamental difference in the way tasks are executed between VC and windows scheduler, that is causing this problem.

Maybe once i know what happens on line 98 of the code, i'll be closer to a solution...

---

I've tried changing the user running the Vc service but that wasn't the solution either.

Windows scheduler performes the task without any problem.
I'm thinking there might be a fundamental difference in the way tasks are executed between VC and windows scheduler, that is causing this problem.

Maybe once i know what happens on line 98 of the code, i'll be closer to a solution...

Yes, please get back to us. If we could have the source we could examine ourselves.

---

The issue has been resolved.
I don't know what the failing code was suppossed to do but by enabling the "Use shell Execute" option and subsequently providing no credential, the app runs without a problem.

Thanks for the helpfull suggestions.

---

Ok, thanks for the update. One of the differences is that output is not captured the same way which could affect the behavior.

---