We have persistent a recurring problem with VC starting executable tasks. The symptoms are identical to our earlier posting: Job Failure after Windows Updates 

Problem Description:
When a task that has an EXECUTE task configured, it fails immediately with the following drwtsn32.exe Application Error:
The application failed to initialize properly (0xc0000142). Click on OK to terminate the application

This is occuring on EVERY execute task. All other tasks types are working correctly without problems

All of these jobs/tasks have been running fine without issue in the past. The problem started happening after a windows update /server reboot weekend. The problem stopped happening for an unknown reason, and has now reappeared (no changes to the server).

All of the .exe programs run without problem, when run manually in CMD window when logged on as the user that is credentialed for the task.

Details:
Win 2003 Server. All of the latest windows updates.

All Execute tasks were originally configured with the following parameters:
- Run in Hidden Window
- Credentials
- Logon Type: With Profile (Run with API code)

Steps Taken:
We have tried the following, all without success:
- Stop VC Tray client
- Restart VC Service
- Reboot Server
- Changed "Run with API code" to "Run with managed code"
(This caused the problem where the task would run but not with the configured credentials)
- changed the credentials to be a different user (with same permissions)
- Configured new executable tasks.

- uninstall/reinstall VC server - restore tasks from backup)
This did not work.

- uninstall/reinstall VC server - reconfigure all tasks by hand.
This worked for a few weeks, but the problem has returned.

We have now installed VC on a different server, restored the jobs from a backup, and they are running fine on the new server. However, we must get VC working on the original server.(several licensed programs are tied to the specific server, and we can't move them to the new server).


What else can we try? What information can we provide you to help troubleshoot this problem?

Which version are you running?

---

Version 5.3.1
Protocol Version 5.1.3
Build 33574

Could you please do some tests:

1. create a simple hello.bat that just contains echo hello
2. create an execute Task that runs the file
3. Try 3 modes:

3.1 without credentials
3.2 with credentials - API
3.3 with credentials - managed

Do any one of them succeed?

---

All 3 work fine. However, when I do a batch file of:
net view \\remoteserver

It fails on all 3.

It seems that it has to do with tasks that require credentials to run.

What if you place the .bat file on \\remoteserver - does that work (using Credentials)?

---

New information. We have just determined that the following is occuring.

1) It is running the task as localmachine\username rather than the credential of ourdomain\username.
(Security log errors are showing this).
2) When we change the task to run under a different credential (ourdomain\user2) it is still trying to run the task as localmachine\username
3) I have changed the password on the credentials, and that is still failing.
4) I have tried running it as managed code, and API
5) We have rebooted the server, and it still used the localmachine\username credential
6) We have restarted the service, after changign it to ourdomain\user2 and it is still using localmachine\username

This seems like it is the wrong username or password. What if you do the following:

1. Create a new local admin
2. Set the Task to API and With profile
3. The the Task with new Credentials

---

By the way, what permission is required on remote computer to accept the net view command?

---

This seems like it is the wrong username or password. What if you do the following:

1. Create a new local admin
2. Set the Task to API and With profile
3. The the Task with new Credentials

The existing credentials appear to have been corrupted somehow. The username/password has NOT changed at the domain level, nor been reconfigured within VC before this problem started occuring

We reset the password for the credentialed user within VC, and that did not solve the problem.


We have just created a new Credential, for the same user (all in CAPS), reconfigured a task to run under domain\USERNAME credential, and it appears to be working.


What information can we provide you to try and reproduce the cause of the credentials becoming corrupted?

By the way, what permission is required on remote computer to accept the net view command?

Not positive. I think you just need to have permission to view IPC$ on the destination computer. So likely any authenticated user?

Glad it was resolved!

However, it would be interesting to analyze your credentials file. We will of course handle the details very carefully.

This is what we would like to do:

1. you send your backup file (or just extract the file credentials.xml from the backup file) to support@visualcron.com
2. you say the user name that was corrupt
3. we get back to you with the password that was in that file - hopefully that will shed some light. It is most probable that someone has changed the password - and if you do recognize it that must be the reason.

---

It is most probable that someone has changed the password - and if you do recognize it that must be the reason.

The password was NOT changed. One of our troubleshooting steps was to re-enter the password. (Was copy/pasted from our password vault, so it wan't incorrectly entered).

Since our last posting, we have assigned the new credential to existing tasks... and those tasks fail. The new credential only works with newly created tasks.

What might cause this situation?

There must be something different in the settings of Execute Task. Perhaps it is the case that you use a new Credential for the new Tasks.

I don't know if there is any difference of the .exe in new vs old Tasks.

Even if you say the password was not changed it is very interesting for us to see what password is being used - that might help solve the problem. If it is a "rubbish" password that has makes no sense - then it is a more serious problem decoding passwords. If it is a password that makes sense and something that you recognize - then we can focus on other things.

If a new Credential is used at old Tasks then it might be as simple as the settings regarding Logon type and Run managed/Run API.

---