Using VC 7.1.2 on Win2008R2sp1

Set up a task to execute simple cmd file which runs "date /t"

VC can execute this file with credentials that do not load user profile. VC cannot execute when credential loads user profile. Get error,
Exception in Task: Non zero exit code
Exit code: -1073741502 (description not found)

The behavior is not consistent in that a few weeks ago I had completely uninstalled VC, removed C:\Program Files (x86)\VisualCron directory, and reinstalled. Was able to execute this test task successfully using credential which loads user profile. Now two weeks later the error is present again. No known changes to server in interim period. No Windows updates occurred. I rebooted server and verified error still occurs.

I have read other posts on this subject and have tried various solutions with no success:

- tried running VC service as System but enabling "interact with desktop"
http://www.visualcron.co....aspx?g=posts&t=3286 

- tried running VC service as local admin
http://www.visualcron.co....aspx?g=posts&t=2602 

- tried running VC service as local admin and using same local admin credential to run the task
http://www.visualcron.co....aspx?g=posts&t=3207 

- tried disabling windows error reporting via setting HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI to 1
http://www.visualcron.co....aspx?g=posts&t=1916 

Looking for guidance on how to isolate the issue.

Thanks.

Setting service to LocalSystem + Interact with desktop + a reboot should solve it.

---

Thank you for the very prompt suggestion. In my case, the problem is still replicating after making this change (with the below caveat).

I did the following:

- Set VC service to log on as Local System
- Set VC service Local System account to interact w desktop
- Reboot server

HOWEVER

I found this in the system event log:

The VisualCron service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly.


I will attempt to correct this issue and revert.

Thanks

I do not think this message will actually affect the system. At least not how VC uses it.

The error started since we changed the service to not interact with desktop (when installing service). But then some users got this error. We have not been able to replicate it and it sounds like a bug in Windows so we have reverted to interact with desktop for next version.

---

epyx servers were hit by this problem after windows update reboots this weekend.
The workaround has fixed it.

epyx servers were hit by this problem after windows update reboots this weekend.
The workaround has fixed it.

Thanks for the feedback!

---

I compared the server where VC is nonfunctional vs a server where VC is functional.

I confirmed that the same event log error

"The VisualCron service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly."

appears on our server with a functional VC. It only appears once, seemingly at the time the service was configured, so I agree that this particular message does not seem to affect VC behavior.

I also noticed on the server where VC is functional, the VC service has dependencies:
- Windows Management Instrumentation
-- Remote Procedure Call (RPC)
--- DCOM Server Process Launcher
--- RPC Endpoint Mapper

The VC service that is not working has has no dependencies. Not sure what this means but will keep looking.

Also an important note. The server where VC is functional is running VC 7.0.8.

I'm wondering if it makes sense to downgrade to 7.0.8 and avoid 7.1.x, if the new problems are related to 7.1?

Also an important note. The server where VC is functional is running VC 7.0.8.

I'm wondering if it makes sense to downgrade to 7.0.8 and avoid 7.1.x, if the new problems are related to 7.1?

First, I thought this was resolved with the reboot? Did you do a reboot?

The dependencies is not the problem. And the warning is not. The problem is running with "Interact with desktop" unchecked in combination with "Load profile" option in the Credential. For some kind of reason this does not happen right away but after a time (maybe when someone with the same account has logged off).

Anyway, the only difference between 7.1.x and 7.0.8 is the "interactive flag at service. We have restored this for 7.1.4. But the fix is still the same. Check the checkbox and reboot.

---

Hi, no this wasn't resolved for me. Somebody else updated this thread.

Server has rebooted at least twice since I configured the service to interact with the desktop.

If the missing service dependencies are meaningless, is there another Windows configuration setting I could examine to compare vs the working server?
- Does the credentialed user need any special domain or server permissions?
- Does the server need to permit any special operation?

Thanks.

Hi, no this wasn't resolved for me. Somebody else updated this thread.

Server has rebooted at least twice since I configured the service to interact with the desktop.

If the missing service dependencies are meaningless, is there another Windows configuration setting I could examine to compare vs the working server?
- Does the credentialed user need any special domain or server permissions?
- Does the server need to permit any special operation?

Thanks.

Please create a local admin on the computer (no AD user). Use same settings with "Local logon" + "Load profile". Is this working? Also, could you test re-installing .NET 3.5 and 4.0? Try 3.5 first, reboot and test.

---

Running VC service as local admin (non-AD user) and using credentials for that same local admin (non-AD user) produced the same exception in VC.

I found this msg in system Event log:

Application popup: cmd.exe - Application Error : The application was unable to start correctly (0xc0000142). Click OK to close the application.

That message appears both when i run as local admin and when i run as Local System (interact with desktop), so not sure it's useful. At any rate, googling it just points me to similiar articles to what I've already read.

Will investigate how easy it is to re-install .NET

I also noticed this particular server has only .NET 4.5 installed. Are there any known issues with only .NET 4.5 installed?

Thanks, and thanks for your continued help.

Running VC service as local admin (non-AD user) and using credentials for that same local admin (non-AD user) produced the same exception in VC.

I found this msg in system Event log:

Application popup: cmd.exe - Application Error : The application was unable to start correctly (0xc0000142). Click OK to close the application.

That message appears both when i run as local admin and when i run as Local System (interact with desktop), so not sure it's useful. At any rate, googling it just points me to similiar articles to what I've already read.

Will investigate how easy it is to re-install .NET

I was not talking about running VC as another user. Use the same LocalSystem account. I was talking about using the a new local admin account as Credential (intead of the Credential that you use now).

---

I also noticed this particular server has only .NET 4.5 installed. Are there any known issues with only .NET 4.5 installed?

Thanks, and thanks for your continued help.

VC depend on .NET 3.5 and 4.0. Try first;

1. reinstall 3.5 - reboot - test
2. reinstall 4.0 - reboot - test

---

Before addressing .NET I performed a test:

- uninstall 7.1.2. Install 7.0.9. (Install on existing C:\Program Files (x86)\VisualCron directory.) Retest:
same failure

- uninstall 7.0.9. Remove C:\Program Files (x86)\VisualCron directory. Reinstall 7.0.9 (this is a clean install). Set up Test job / test task / credential and test:
works as expected

- upgrade 7.0.9 to 7.1.3. Check VC service settings (Local System / Do not interact with desktop). test:
works as expected

Not sure if this proves anything. Perhaps there's a corruption in the VC settings I imported when I set up this server.

Still more to test, but I think fundamentally the server is functional. And I'm also curious why VC works ok when service is set not to interact with Desktop. Will reboot and test further.

I'm also curious whether I corrupted something when I imported VC settings.

Before addressing .NET I performed a test:

- uninstall 7.1.2. Install 7.0.9. (Install on existing C:\Program Files (x86)\VisualCron directory.) Retest:
same failure

- uninstall 7.0.9. Remove C:\Program Files (x86)\VisualCron directory. Reinstall 7.0.9 (this is a clean install). Set up Test job / test task / credential and test:
works as expected

- upgrade 7.0.9 to 7.1.3. Check VC service settings (Local System / Do not interact with desktop). test:
works as expected

Not sure if this proves anything. Perhaps there's a corruption in the VC settings I imported when I set up this server.

Still more to test, but I think fundamentally the server is functional. And I'm also curious why VC works ok when service is set not to interact with Desktop. Will reboot and test further.

I'm also curious whether I corrupted something when I imported VC settings.

We do appreciate your tests. I do not think it is version dependent besides the fact that 7.1.3 installs without "Interact with desktop" unchecked. This is the only factor we have seen so far but it might go deeper than that. Your tests says that something gets "dirty" along the way.

I do not think VC settings affect this at all as there is no specific setting (except Credential settings which are the same format between these versions).

It seems to be something else. Like registry, user info, or windows info gets dirty.

Some suggests, on posts on the Internet, that the desktop heap memory gets maxed, and cause this, but then a reboot should help.

But, we have heard that users running with "interact with desktop" unchecked, that it might work for a while and then later fail. Perhaps related to that the user being used in the Credential gets logged on or off physically - but this is just a guess so far.

I would suggest that you only test with "Interact with desktop" checked. This is the setting we have used for 6 years except with version 7.1.3.

---

I confirm after server reboot that the test task fails with the same exception. I resolved the exception by setting the VC service to Interact with Desktop.

So now I have a working copy of VC 7.1.3. I am making a copy of it and then I will try to import just one job I need from another server. If I can get this job to import and it's functional I will be finished. If importing the job corrupts something I will have more questions.

Thanks.

I confirm after server reboot that the test task fails with the same exception. I resolved the exception by setting the VC service to Interact with Desktop.

So now I have a working copy of VC 7.1.3. I am making a copy of it and then I will try to import just one job I need from another server. If I can get this job to import and it's functional I will be finished. If importing the job corrupts something I will have more questions.

Thanks.

Thanks for your feedback!

---

Ok, I just wanted to indicate that things seem to be operational for me. I want to close this issue and highlight what I learned.

1. The correct VC service setup is to run as "Local System" and "Allow service to interact with desktop"

2. Recent changes to VC installer disabled the "interact with desktop" setting

3. Changes to the "interact with desktop" setting only seem to take effect on reboot, so users upgrading to 7.1.x would operate without issue initially and then have this problem occur seemingly at random, but most likely after reboot (at least, that's what happened to me).

4. VC installer will revert to setting VC service to interact with desktop (PLEASE CONFIRM this change will be in 7.1.4). Until that time, users experiencing this problem most likely can fix by setting VC service to interact with desktop and rebooting server.

====

Now the part I don't understand. There was something corrupt with my VC installation. I'm not sure what, but I required a clean install to get VC operational. I'm wondering if the setup I did -- specifically Credentials setup -- while the VC service was configured incorrectly was somehow related to the corruption. It would be great if the actual solution for me would have been to set the VC service correctly, reboot, then delete / re-add Credentials. I'm not positive I tested those steps.

Thanks for all the guidance.

Ok, I just wanted to indicate that things seem to be operational for me. I want to close this issue and highlight what I learned.

1. The correct VC service setup is to run as "Local System" and "Allow service to interact with desktop"

2. Recent changes to VC installer disabled the "interact with desktop" setting

3. Changes to the "interact with desktop" setting only seem to take effect on reboot, so users upgrading to 7.1.x would operate without issue initially and then have this problem occur seemingly at random, but most likely after reboot (at least, that's what happened to me).

4. VC installer will revert to setting VC service to interact with desktop (PLEASE CONFIRM this change will be in 7.1.4). Until that time, users experiencing this problem most likely can fix by setting VC service to interact with desktop and rebooting server.

====

Now the part I don't understand. There was something corrupt with my VC installation. I'm not sure what, but I required a clean install to get VC operational. I'm wondering if the setup I did -- specifically Credentials setup -- while the VC service was configured incorrectly was somehow related to the corruption. It would be great if the actual solution for me would have been to set the VC service correctly, reboot, then delete / re-add Credentials. I'm not positive I tested those steps.

Thanks for all the guidance.

Thanks for the feedback.

4. yes, 7.1.4 that was released two days ago do have "interact with desktop" set as default on

I cannot explain the "corrupt" issues with your install - especially as the format for Credentials have not changed. Only thing I can think of was that Load profile, for some reason, was set to false or true between the versions - but this is just a guess.

---

I would say now that this is pretty much handled in 7.1.6.

http://www.visualcron.co....aspx?g=posts&t=4017 

What we have done is to change that we "Open" the desktop before launching a process. It seems like on some servers, for some reasons the desktop object is lost and causing this error. We are currently stress-testing these methods but have not see any issues so far. Thanks for the feedback and report!

---