The script file in formerly attached ZIP file works.

Some advice for writing UltraEdit/UEStudio scripts:

1. Click on ribbon tab Layout in second ribbon group Views on check box item Output Window to open the output window view and if necessary click on pin symbol on title bar of this view to make it permanently visible. Syntax error messages detected by JavaScript interpreter on execution of a script are redirected by UEStudio to the output window, except configuration setting Show status information in output window is checked at Advanced - Settings or Configuration - Scripting. This configuration setting should be not checked on developing a script.
2. Open Advanced - Settings or Configuration - Editor display - Miscellaneous and check the setting Auto-correct keywords. Then UEStudio automatically corrects words defined in active syntax highlighting wordfile on language being case-sensitive and the keyword is not correct typed. This is a really useful feature on writing scripts.
3. Click on ribbon tab Layout in second ribbon group Views on check box item Tag list and select at top the group UE/UES Script Commands. Double click on a tag in Tag List view to insert at current position of caret in active file the tag. That saves a lot of typing and avoids typing mistakes. The caret is positioned after inserting a tag on where something must be added manually if that is necessary at all for inserted command or property.

Good luck on further coding of UEStudio scripts.

By the way: You are using already UEStudio v18.20.0.18 which is a full Unicode aware application and supports also UTF-8 and UTF-16 encoded script files without or with BOM. So feel free to code the script with Korean characters in comments and yes, also in strings, in Unicode using encoding UTF-8 or UTF-16. You can see on execution that the Unicode characters in JavaScript strings are correct written into a Unicode encoded file or copied to clipboard on execution of the script.

I could not see on your Process Monitor log files the reason for failure on script execution. But I could see on log files your user account name, a string consisting of three Korean characters which must be Unicode encoded in file system. So I used next Process Monitor on my machine to find out if UE/UES use the temporary files directory on running a script and the answer is: yes, it does. UE/UES use the directory specified by environment variable TMP.

So I tried what happens if I create the directory C:\Users\YourAccountName\AppData\Local\Temp and edit my user account related environment variables TEMP and TMP to this path with the three Unicode encoded Korean characters. After making this modification on my environment variables, I started UltraEdit and executed the script. It worked and I was really surprised that it worked.

I looked on Process Monitor log on my Windows 7 computer how an environment variable is defined by Windows 7 which contains Unicode characters. Well, the environment variable is defined as Unicode encoded string. So no problem if the application is full Unicode aware and uses the Unicode variant of the environment variable. But I wanted to know how such a path is managed by Windows for non-Unicode aware applications. Therefore I opened next a command prompt window and executed command line set T to see all environment variables starting with letter T in any case and saw TEMP and TMP defined using short 8.3 path of C:\Users\YourAccountName\AppData\Local\Temp which does not contain Unicode characters.

Then I wanted to know what happens if the folder path assigned to environment variable TMP specifies a folder which does not exist at all. So I edited once more the TMP variable and modified the path to C:\Users\YourAccountName\AppData\Local\TempX and saved the modification. There was of course no directory with name TempX. After restarting UltraEdit to get the modification of environment variable TMP effective for UltraEdit process, I executed the script once again and now it failed with the same error message as you see always in output window. I looked on the environment variable TMP in a newly opened command prompt window and it was defined as C:\Users\???\AppData\Local\TempX. There was three times the wildcard character ? in folder path instead of short 8.3 name of the user account directory. This is of course invalid. The wildcards ? and * are not allowed in file/folder paths. So if Windows can't find the directory containing the Unicode characters in path to determine the path in short 8.3 format, it replaces the Unicode characters by question marks and application's behavior becomes unexpected.

I suggest following:

1. Create a directory C:\Temp
2. Open System settings of Windows Control Panel.
3. Click on Advanced system settings on left side.
4. Click at bottom on button Environment Variables.
5. In the upper half of the window double click on variable TEMP, modify the variable value at bottom to C:\Temp and click on button OK.
6. In the upper half of the window double click on variable TMP, modify the variable value at bottom also to C:\Temp and click on button OK.
7. Close the Environment Variables dialog window with button OK.
8. Close the System Properties dialog window with button OK.
9. Start now UltraEdit or UEStudio.
   It is important to start UE/UES new if they were already running as otherwise the changes on the two environment variables do not become effective.
10. Run the script from the script list.

Does it work now as expected by me with directory for temporary files being C:\Temp?

I recommend restarting Windows if the change of the directory for temporary files to simple C:\Temp really works because of other applications should use now this directory, too.

Well, support of IDM Computer Solutions, Inc. could only grope around in the dark like I before I saw your account name respectively the name of your user's profile directory with three Korean characters in Process Monitor logs. Nobody in Western European or North American countries would ever come on the idea to use non Windows-1252 characters for the user account. You have always made your account name unreadable or replaced it by a generic string for understandable reasons to keep it private, but the Unicode encoded account name was the important information we would have needed to find out why the script executions always failed on your computers.

However, problem is solved now and I learned a lot about how Windows handles user accounts with Unicode characters which could be helpful in similar use cases in the future.