LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

SysExec (cmd) : Run as administrator

Solved!
Go to solution

I have read older posts about trying to make LabVIEW's SysExec function (command window) run as administrator

The goal is, in our LabVIEW 2019 app on Win 10, execute a single command (SysExec) that runs a third-party non-LV exe, with some command-line options. The command doesn't work unless the "caller" (LV or the Windows command prompt) is run as admin.

 

Seems like it's necessary to do one of the following:

1. Run our LabVIEW app (built exe or LabVIEW itself during development) as admin.

2. Lower Windows UAC setting.

3. Create an official manifest for our LV app.

 

#1 & 2 might not be allowed at some of our customers (those with an attentive IT dept).

#3 seems like a lot of trouble, or am I wrong about that?

Are there any updates on this, any new tricks?

-- Meg

0 Kudos
Message 1 of 14
(5,716 Views)

I'm fighting the same issue, but haven't found a good solution.

0 Kudos
Message 2 of 14
(5,672 Views)

There are a few things to note. The System Exec uses the CreateProcess() Windows API and that one does not support any way of forcing an UAC elevation for the created child process. 

 

The only way I have found that works reliably is to call the Windows Shell API function ShellExecuteA() with the "runas" verb. If you need to wait for the process to terminate you have to call the ShellExecuteExA() function which takes a structure instead and therefore is a pita to call through the LabVIEW Call Library Node.

 

Rolf Kalbermatter
My Blog
Message 3 of 14
(5,649 Views)

Hallo, Rolf, und danke!

I'm lazy, do you have an example I can download?  ; )

If not, I'll figure it out.

 

LG,

Meg

0 Kudos
Message 4 of 14
(5,621 Views)

This is a VI I quickly threw together, so you will need to do some more testing with it. I haven't used ShellExecute from a LabVIEW diagram directly before but always from some form of intermediate shared library that I then interfaced to LabVIEW.

 

The "verb" is the value you will want to wire the "runas" string too if you want the program do be elevated but only if the resulting executable does not have an elevation manifest included. In that case you need to use the default verb "open" anyways or ShellExecute might get confused. Other possible values for verb can be: 

edit

Launches an editor and opens the document for editing. If lpFile is not a document file, the function will fail.

explore

Explores a folder specified by lpFile.

find

Initiates a search beginning in the directory specified by lpDirectory.

open

Opens the item specified by the lpFile parameter. The item can be a file or folder.

print

Prints the file specified by lpFile. If lpFile is not a document file, the function fails.

 

file name is the path to the executable you want to open or alternatively it can also define a document that is then opened with the default application for that document type.

 

parameters is the optional parameter list to pass to an executable and should remain empty for documents

 

directory is the directory path the executable should inherit as startup directory, in case it uses relative paths they will be relative to this directory.

 

And yes even if an executable includes an elevation manifest you need to use ShellExecute. CreateProcess can not deal with the elevation requirements as it is not meant to allow any form of privilege escalation. It anyhow seems that the entire UAC business really is implemeted inside the Windows shell rather than the Windows kernel.

Rolf Kalbermatter
My Blog
Message 5 of 14
(5,605 Views)

Thanks, I'll try it !

 

0 Kudos
Message 6 of 14
(5,588 Views)

I tested this and the behavior is interesting, but not yet what I need.

I set file=path to exe, directory=folder of exe, verb=runas, params=same param string that works in command line (has no spaces), in double quotes""

When I run the VI (from non-elevated LV 2019), I get the UAC popup "Do you want to allow this app...." so the elevation isn't working. If I click "Yes" then the command runs, and works correctly, BUT I get error 42 (generic) from the ShellExecute call library node and also error 1097 from the Call Library node itself (exception occurred within the external code...). Note that despite the errors, the command worked correctly.

So, as they say, no joy ... yet. I'll keep researching. Thanks a lot.

0 Kudos
Message 7 of 14
(5,529 Views)
Solution
Accepted by FermWorks

@FermWorks wrote:

I tested this and the behavior is interesting, but not yet what I need.

I set file=path to exe, directory=folder of exe, verb=runas, params=same param string that works in command line (has no spaces), in double quotes""

When I run the VI (from non-elevated LV 2019), I get the UAC popup "Do you want to allow this app...." so the elevation isn't working. If I click "Yes" then the command runs, and works correctly, BUT I get error 42 (generic) from the ShellExecute call library node and also error 1097 from the Call Library node itself (exception occurred within the external code...). Note that despite the errors, the command worked correctly.

So, as they say, no joy ... yet. I'll keep researching. Thanks a lot.


You misunderstand. The elevation is working. There is absolutely NO way except exploiting a zero day vulnerability, to avoid that dialog if the calling process is not elevated already. Think about it, if that would work any virus could simply spawn a child process and assign to it elevated rights and then run havoc on your machine. (Well it still can try but you get at least a dialog prompting you that a process was requested to be elevated and if you want to allow that. So it's never a good idea to click random dialogs simply away!)

Shell Execute is also defined to return a value higher than 32 if successful and values 32 and below are indicating errors. And the VI should be programmed to ignore return values higher than 32, which I strongly believe I did. I did make it return the generic error number 42 but also added the return value from the ShellExecute() API in the text so it might be helpful if you could report the number in the text message. I was to lazy to make a full error code translator for this VI.

 

The error 1097 is another issue that I'm not sure where it could come from. The parameters at least should be definitely ok, so the problem may be an exeception thrown somewhere in the shell for whatever reason.

 

CORRECTION: I checked the Call Library Node and I did indeed forget to change the Calling convention to stdcall. Almost all Windows APIs are stdcall calling convention! So change that and your 1097 error at least should be gone. Still interested to hear what error code you get in your error message that the function returns.

 

NOTE: I managed to update the VI in the previous post with a fixed version where the calling convention is now set correctly. Thanks to Lili for this! Smiley Happy

Rolf Kalbermatter
My Blog
Message 8 of 14
(5,522 Views)

OK, yes, I was wondering about hackers.... ; )

Yes, you did handle errors 32 and below by replacing them with 42.  The error from ShellExecute actually is 42 (it's not being replaced with 42).

I also tested it on a different test network and the command also works, but the VI never completes; the Call Library node is hung. I have to kill LV.  Weird.

 

0 Kudos
Message 9 of 14
(5,515 Views)

OK, sorry, it's all good now!!  Now I understand that error code 42 means success because it's > 32. So 0 is also an error?!

I changed the calling convention to stdcall and I don't get error 1097 (on the one test computer) nor does it hang (on the other). Yay!

 

0 Kudos
Message 10 of 14
(5,511 Views)