Compiled exe file stops and displays Error Opening File message during execution

[Ed5000]

The compiled (exe) program stops whenever it encounters any Winbatch Function which requires creating a new file. For example FileOpen, ArrayFilePut, ArrayFilePutCsv functions will all stop execution when encountered.  However when the file is run As Administrator, the program will run faultlessly.  So the problem appears to be related to some missing Permission or Right relating to the creation of files, and that area is completely beyond my capability. 
I have "taken ownership"  of the WBCompiler file, the DLL files and the source wbt file,  but without success.
If someone has come across this problem and can suggest a solution I would be very grateful.

[JTaylor]

This would generally indicate you don't have the rights to create a file in the location you are trying to place it.   It doesn't have anything to do with who owns the script you are running.   If you use Windows File Explorer and go to the same location you will probably have the same issue.   You don't happen to be trying to open a file in the Program Files path, do you?

Jim

[td]

Recompiling the script after changing the manifest settings to highestAvailable could fix the problem.

More information can be found in the Consolidated WIL Help file and the online documentation:

https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_S__005.htm

[Ed5000]

Thank you Jim, you nailed it!  Problem solved.   Yes, the file WAS in a Program Files folder. as you predicted.  I have now moved it.   
Thank you again.

Ed.

[JTaylor]

Glad to hear it solved your problem.   Also, if you are not familiar with it, you may find the ShortcutDir() function very useful.    It allows you to determine file paths for the current user.   That is, if you wanted to store settings or data files for each user in their respective Appdata folder you can easily obtain that path or other similar paths.


Jim

[td]

Installing a compiled script in a directory that is not a "secure" directory - like Program Files or Program Files (X86) are - can cause the script to fail if it performs certain tasks. The better general solution is either to modify the script's manifest so that it executes with full admin privileges or use an install script to pre-install the extracted files.

[td]

A simple way to install a compiled script in one of the "Program Files" folders is to manifest the compiled script as "highestAvailable" and execute the script once after installing it. Since you need to be an elevated admin to copy the script into "Program Files" the installing account can extract the payload files to the installation folder.  Once the files are extracted, the compiled script will not attempt to extract them again. This means non-admin users will not encounter extraction-related problems. The only downside is that depending on the system's UAC configuration, any admins executing the compiled script may need to respond to an elevation prompt every time they execute the compiled script.

[edit] Of course, any not extracted files created by the script during execution should be placed in a folder that is not a "secure" folder. As you discovered non-elevated admins and standard users cannot create files in "secure" folders.

[kdmoyers]

Tony, just checking that I understand this. (After all this time, I'm still not really good on UAC stuff.)

By "extract the payload files" you mean the extracting the dlls that are packed inside a "Large" mode compiled exe, correct?

And if I had installed a "Small" mode exe into the program files folder, along with its dlls, (or the dlls were otherwise available on the PATH), the program would not need to write there, and so this issue would not come up, correct?

[td]

You are correct as long as the exe is being executed by a standard user or a restricted admin and is installed in Program Files or Program Files (x86) and assuming those folders have out-of-the-box security settings.  Keep in mind that the WIL interpreter DLL is always needed so it must always be present in the Windows system directory, the Windows directory, the current directory (which is the exe's launch directory at startup), or one of the directories listed in the PATH environment variable.

You are not the only one that does not always have a firm grasp on all the implications of UAC and that is why I posted what I did even though it is only tangentially related to the OP's topic. In fact and after thinking about it I was going to delete the posts because they do not follow the "on-topic rule". Now I am glad I hadn't gotten to it yet.

[td]

Noticed that I need to clarify something I typed in my previous post because I have a talent for obfuscating the obvious.

When I used the term "system directory", I was not necessarily referring to a directory named "System". I was referring to the directory that the currently running version of the Windows OS defines as the system directory, which is the directory returned by a call to the Windows API function "GetSystemDirectory". Of course, that directory is most frequently the "C:\Windows\System32" directory.