Have there been any reports of seemingly-random lockups of PowerShell tasks? We have several VisualCron installations that run a job with a PowerShell task. On a couple of these, we've had instances where the PowerShell task hangs indefinitely, and we've only cleared it by restarting the VisualCron service. Once the service is restarted, the job functions normally for hours or days before it hangs again. All the installations are 8.2.7.

Have there been any reports of seemingly-random lockups of PowerShell tasks? We have several VisualCron installations that run a job with a PowerShell task. On a couple of these, we've had instances where the PowerShell task hangs indefinitely, and we've only cleared it by restarting the VisualCron service. Once the service is restarted, the job functions normally for hours or days before it hangs again. All the installations are 8.2.7.

I just started to have the same issue as of today, version 8.2.8.

Edit:
Work around provided by MRomer did fix the issue. Just stopping and restarting the server was not enough, a full restart of the service in the windows "services" application was required.

We wonder if it depends what the Task do? What if you just create a PowerShell script that outputs the current user? Is that working?

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

---

We wonder if it depends what the Task do? What if you just create a PowerShell script that outputs the current user? Is that working?

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

In our case, it was all of our PowerShell tasks: calculating a Unix timestamp, modifying and updating jobs on the server through the API, generating directories, etc. It happens intermittently, and I cannot replicate. I haven't had it happen again in 2 days.

If it happens again then please create a small script that just outputs to host like:



It would be interesting if that works.

---

We wonder if it depends what the Task do? What if you just create a PowerShell script that outputs the current user? Is that working?

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

In my case the scripts that lock up all are interacting with a SQL Express database via SQLOLEDB. But it doesn't happen all the time, and it doesn't happen at all on my test equipment. All the affected installations are remote satellite offices. We haven't found a pattern to it, either. The jobs running the scripts run frequently (every 2 or 3 minutes). They may be fine for hours and then they lock up.

We wonder if it depends what the Task do? What if you just create a PowerShell script that outputs the current user? Is that working?

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

In my case the scripts that lock up all are interacting with a SQL Express database via SQLOLEDB. But it doesn't happen all the time, and it doesn't happen at all on my test equipment. All the affected installations are remote satellite offices. We haven't found a pattern to it, either. The jobs running the scripts run frequently (every 2 or 3 minutes). They may be fine for hours and then they lock up.

But during a "lockup" - can you run another script like the one above?

---

We wonder if it depends what the Task do? What if you just create a PowerShell script that outputs the current user? Is that working?

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

In my case the scripts that lock up all are interacting with a SQL Express database via SQLOLEDB. But it doesn't happen all the time, and it doesn't happen at all on my test equipment. All the affected installations are remote satellite offices. We haven't found a pattern to it, either. The jobs running the scripts run frequently (every 2 or 3 minutes). They may be fine for hours and then they lock up.

But during a "lockup" - can you run another script like the one above?

Other jobs with scripts continued to run without error during times that one script gets locked up.

We've worked around it for now by specifying flow entries for the PowerShell tasks and for the jobs running them. The job gets ended if the script runs for more than a minute. That seems to be working--the complaints have gone away.

Thanks, it is hard to say what level the lockups are in but it is good that we isolated it to your specific scripts. Maybe they can be analyzed by running part of script to see which exact call causes the problem.

---