[GH-ISSUE #331] Script monitors ocassionally failing #2157

Closed
opened 2026-03-14 02:47:52 +03:00 by kerem · 10 comments
Owner

Originally created by @sdm216 on GitHub (Mar 17, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/331

Since 0.4.24 (Which actually fixed this same issue happening all the time), agents are still occasionally getting the alert below with script checks failing. Repairing the Tactical Agent through Agent Recovery seems to temporarily fix it. With about 200 agents, it's happening about 3-5 devices a day, at random times throughout the day. It keeps failing until the agent is "recovered".

CompanyName, SiteName DeviceName - Script Check: Script Name Failed - Return code: 85
Stdout:
Stderr: open C:\WINDOWS\TEMP\trmm\198018948.ps1: The system cannot find the path specified.

Originally created by @sdm216 on GitHub (Mar 17, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/331 Since 0.4.24 (Which actually fixed this same issue happening all the time), agents are still occasionally getting the alert below with script checks failing. Repairing the Tactical Agent through Agent Recovery seems to temporarily fix it. With about 200 agents, it's happening about 3-5 devices a day, at random times throughout the day. It keeps failing until the agent is "recovered". CompanyName, SiteName DeviceName - Script Check: Script Name Failed - Return code: 85 Stdout: Stderr: open C:\WINDOWS\TEMP\trmm\198018948.ps1: The system cannot find the path specified.
kerem closed this issue 2026-03-14 02:47:58 +03:00
Author
Owner

@dinger1986 commented on GitHub (Mar 17, 2021):

Have you created the exclusions in your AV?

<!-- gh-comment-id:801478003 --> @dinger1986 commented on GitHub (Mar 17, 2021): Have you created the exclusions in your AV?
Author
Owner

@sdm216 commented on GitHub (Mar 17, 2021):

Yep. I use Defender, and checked the defender event logs, and it isn't blocking anything. And it all works again after recovering the agent, at least for a while.

<!-- gh-comment-id:801478765 --> @sdm216 commented on GitHub (Mar 17, 2021): Yep. I use Defender, and checked the defender event logs, and it isn't blocking anything. And it all works again after recovering the agent, at least for a while.
Author
Owner

@dinger1986 commented on GitHub (Mar 17, 2021):

Ok. That's interesting I have afew machines that do that as well but always seems to be when they are under load and then it runs fine next time

<!-- gh-comment-id:801479660 --> @dinger1986 commented on GitHub (Mar 17, 2021): Ok. That's interesting I have afew machines that do that as well but always seems to be when they are under load and then it runs fine next time
Author
Owner

@sdm216 commented on GitHub (Mar 17, 2021):

It seems like the script is being deleted from the temp folder, and the agent isn't automatically re-downloading it until it's recovered. The most recent one was actually not too long after a reboot.
Edit: which makes sense, if Windows empties the temp folder after a reboot. But it just keeps failing until the agent is recovered, so maybe the agent needs to know to re-download the script if it isn't there already.

<!-- gh-comment-id:801479797 --> @sdm216 commented on GitHub (Mar 17, 2021): It seems like the script is being deleted from the temp folder, and the agent isn't automatically re-downloading it until it's recovered. The most recent one was actually not too long after a reboot. Edit: which makes sense, if Windows empties the temp folder after a reboot. But it just keeps failing until the agent is recovered, so maybe the agent needs to know to re-download the script if it isn't there already.
Author
Owner

@dinger1986 commented on GitHub (Mar 17, 2021):

The way the scripts work in my understanding is they are downloaded and ran each and every time.

When you said you checked defender logs did you check in event viewer?

<!-- gh-comment-id:801480397 --> @dinger1986 commented on GitHub (Mar 17, 2021): The way the scripts work in my understanding is they are downloaded and ran each and every time. When you said you checked defender logs did you check in event viewer?
Author
Owner

@sdm216 commented on GitHub (Mar 17, 2021):

Yeah, under Applications & Service Logs> Microsoft > Windows > Windows Defender > Operational. I monitor this log for the events indicating it found something, but I did check manually as well.

<!-- gh-comment-id:801480907 --> @sdm216 commented on GitHub (Mar 17, 2021): Yeah, under Applications & Service Logs> Microsoft > Windows > Windows Defender > Operational. I monitor this log for the events indicating it found something, but I did check manually as well.
Author
Owner

@sdm216 commented on GitHub (Mar 17, 2021):

Should also note I have all Attack Surface Reduction Rules enabled, but again, it isn't logging that it blocked anything, which it would if it was.

<!-- gh-comment-id:801481470 --> @sdm216 commented on GitHub (Mar 17, 2021): Should also note I have all Attack Surface Reduction Rules enabled, but again, it isn't logging that it blocked anything, which it would if it was.
Author
Owner

@dinger1986 commented on GitHub (Mar 17, 2021):

Ok that's fine, just making sure, like I said I have noticed it. I'll keep an eye on it. @wh1te909 have you seen this happening on your machines?

<!-- gh-comment-id:801481675 --> @dinger1986 commented on GitHub (Mar 17, 2021): Ok that's fine, just making sure, like I said I have noticed it. I'll keep an eye on it. @wh1te909 have you seen this happening on your machines?
Author
Owner

@wh1te909 commented on GitHub (Mar 17, 2021):

ive had this happen only once on 1 agent since I released the fix for the original but. Seems something is deleting the trmm folder in C:\Windows\TEMP.

The agent creates this directory everytime the tacticalagent windows service starts up, which is why doing a recovery fixes it cuz part of the recovery is to restart that service.

I've fixed this already here github.com/wh1te909/rmmagent@67a8ab822c which will just create the directory if it doesn't exist right before running a script. It will be in the next agent release

<!-- gh-comment-id:801495715 --> @wh1te909 commented on GitHub (Mar 17, 2021): ive had this happen only once on 1 agent since I released the fix for the original but. Seems something is deleting the `trmm` folder in C:\Windows\TEMP. The agent creates this directory everytime the `tacticalagent` windows service starts up, which is why doing a recovery fixes it cuz part of the recovery is to restart that service. I've fixed this already here https://github.com/wh1te909/rmmagent/commit/67a8ab822c762a819fd65bc8734ba3fd291c547a which will just create the directory if it doesn't exist right before running a script. It will be in the next agent release
Author
Owner

@wh1te909 commented on GitHub (Mar 19, 2021):

Fixed in 0.4.27 / agent 1.4.13

<!-- gh-comment-id:802566625 --> @wh1te909 commented on GitHub (Mar 19, 2021): Fixed in 0.4.27 / agent 1.4.13
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#2157
No description provided.