Usually that means an earlier action spawned a process in the client’s __Download folder and the process never terminated; the process may be trying to present a user interface dialog but does not have access to the interactive session and cannot display its message.
Yes, you have to troubleshoot this on the client side and will probably need to kill whichever process is running.
You won’t be able to correct this through BigFix because the client won’t process other actions until it can clear the folder.
I set up a system of Scheduled Tasks to find and kill these ‘stuck’ processes, check out my posts on BESChildKiller at Running a command with a timeout . There’s significant overhead to this so it’s only worthwhile if this becomes a recurring problem for you (it happens pretty frequently to me).
I had an RFE to timeout and kill child processes, and it was implemented but the fix doesn’t work for me. It requires setting an override on the ‘wait’ command, which means predicting ahead of time which actions might hang and modifying the action scripts. The hangs for me occur in a lot of default content and I didn’t want to rewrite every fixlet to use the new method.