Hi Derek,

Have you tried to use the 32-bit version of the powershell.exe located in C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe? Since EventSentry is a 32-bit application and you're trying to use the 64-bit powershell.exe this could be causing the issue.

Steven

Hi Steven,

Good idea. Unfortunately in this case it hasn't fixed the issue. I'm still getting the same error message:

The process "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" "C:\Scripts\EventSentry\test.ps1" exceeded the maximum allowed time interval of 1 minute(s). The process was terminated. Please increase the timeout interval for this process in the management console (System Health -> Application Scheduler).

Running the 32-bit version of powershell & the script from the command line works fine.

Hi Derek,

This seems to have something to do with the fact that we are capturing the output from the powershell.exe process, it looks as if this might cause the process to hand indefinitely (and then be terminated).

We'll be looking into this shortly and let you know how this can be resolved.

Thanks Ingmar. I appreciate it. My company purchased EventSentry on the assumption that we would be able easily integrate the large number of Powershell scripts we have into a single monitoring solution. It was starting to look this might have been a mistake.

I look forward to hearing what you guys come up with. Thanks!

Hi Derek,

I wanted to give you an update on this issue. We have been looking into it, and we have more information. EventSentry redirects the output from executables it calls, so that the output can then be logged to the event log, making it easy to troubleshoot scripts as well review their output.

Unfortunately, powershell.exe does not appear to like this practice, and - as you noticed - as a result never terminates.

The only solution, at least at this point, is to not redirect the output handles when we call any script that runs powershell.

We might make the redirection an option going forward as well, but for now we will most likely issue a patch that checks for the powershell.exe. This will only work of course if you call powershell directly, if it's embedded in a command-line script then this will not work.

We will try to open a ticket with Microsoft about this issue, but we have not had good experiences when trying to resolve bugs with a Microsoft product unfortunately. The process is extremely tedious, time-consuming and more often than not leads nowhere (except for charges to us if you can believe it).

Would this work for you, even if you could not see the output from the powershell script in the event log?

Hi Ingmar. It would be better than nothing, as I could still use the exit code to indicate if the script was successful or not.

I have done some research & testing & I have come up with a workaround that seems to to do the job.

Firstly I created a batch file with the following single line:

powershell -inputformat none "C:\Scripts\EventSentry\test.ps1"

I then called this from EventSentry, & it worked!


However the actual "Hello World" string wasn't returned in the Event (similar to the option outlined by Ingmar above).

So I then changed my test.ps1 script to use Write-Output instead of Write-Host. So it looked like:

Write-Output "Hello World"


The "Hello World" string was then included in the EventSentry alert!

For more information on this see:

https://connect.microsoft.com/PowerShell/feedback/details/572313/powershell-exe-can-hang-if-stdin-is-redirected

Hi Derek,

Thanks for the update, that's great news. I'm glad you got that working, and I really appreciate you posting the solution in our forums here. I will see that we create a KB article that documents the solution as well.


Thank you again,
Ingmar.