Invoke code: Could not find file 'C:\Users\*\AppData\Local\Temp\zhxbulim.dll

Hi there, I have a problem that only exists on my VDI when I run the process from Orchestrator/Assistant. This problem does not happen when I run from Studio.
I have this process that uses the Invoke Code activity and it has been running perfectly in Orch on the VDI, but yesterday when I deployed a new version of my process to Orch the process started experiencing an error when it gets to the Invoke Code activity. (Note: my new version did not change anything with the Invoke Code activity). The error is as follows:

> Invoke code: Could not find file 'C:\Users*\AppData\Local\Temp\zhxbulim.dll

The interesting part is that when the bot tries to process the next queue item and fails at the same activity it throws the same error except this time the .dll file name is different, i.e.

> Invoke code: Could not find file 'C:\Users*\AppData\Local\Temp\ggsgfnut.dll

Every time the process runs the .dll file that it says it is looking for is named something else.

Then today I deleted the activity and recreated it on Studio, then deployed to Orch, and the process ran successfully. Then later in the day I had to deploy a new version of the process, and the same error started appearing again. So, I once again deleted the activity and recreated it and then deployed, but this time that did not solve the issue. I am still experiencing the error.

I do not know if this is a bug or if my nuget package did not build properly for some reason? Any ideas or solutions are welcome.


Hi @fouried96,

Here are a few things you can try to troubleshoot the issue:

  1. Check the permissions for the user account running the process on the VDI. Ensure that the account has read/write access to its own temporary folder (C:\Users\<username>\AppData\Local\Temp).
  2. Check the file system for any file system or disk issues that may be preventing files from being written or accessed properly.
  3. Check if there are any antivirus or security software on the VDI that may be blocking access to the temporary folder.
  4. Try running the process with elevated privileges or as a different user to see if that resolves the issue.

Additionally, you can try changing the default temporary folder for the user account by setting the %TEMP% environment variable to a different location that the user has write access to. This can be done by going to Control Panel > System and Security > System > Advanced system settings > Environment Variables, and then adding a new user variable for %TEMP% pointing to a different folder.