im having a problem with ftdi based USB ports loosing connection due to noise issues (i have read on these forums this isnt uncommon). the only way to fix this is to unplug usb cable then plug it back in. i would like to do this programmatically using devcon.exe with the command "devcon restart *ROOT_HUB20*", but i need to run the system exec.vi as administrator. i have tried the put the text cmd /r and the text cmd /c before the devcon command in the line input to the system exec.vi but still get the message restart failed no matching devices. however when i run the devcon command through cmd.exe as administrator manually it works perfectly. im not sure what i am doing wrong. i need to run the system exec.vi as administator how can i do this. please find attached the vi i am working on.
Welcome to modern OS security. Commands executed by System Exec inherit the parents security privileges, here your LabVIEW application. There is not much you can do about that since Microsoft deliberately limited the possibilities for child process to be invoked with different privileges than the parent to avoid privilege escalation.
One thing you can try is to place a manifest in the same directory as devcon that will specify the app to need to be started with admin privileges. I'm not sure that is going to work, as the CreateProcess() API that is used inside System Exec might deliberately ignore manifests. Another approach would be to create a little service application in LabVIEW that provides an interapplication communication interface such as TCP/IP or directly uses VI server. Services are started by default under the system account which already has fairly extensive rights but you can configure it to run under a different account too if you want. Then have your LabVIEW app issue a command to your service to reset the device whenever you feel that to be necessary.
Last but not least you can try to interface yourself directly to the CreateProcessAsUser() or CreateProcessWithLogon() Windows API but the whole issue about those APIs is that they are pretty complex and require fairly involved datatypes as parameters.
Whatever solution you choose except when going with the service solution you will likely end up having the user to enter the administrator credentials whenever you issue your devcon command. An exception might the the CreateProcessAsUser() API but that is a beast of its own as it requires your process to acquire (and be privileged enough to do so) several Windows privileges before invoking that API.
I posted briefly about this here: http://forums.ni.com/t5/LabVIEW/enable-and-disable-ethernet-adapters/m-p/3107615#M890686
One way of having your application be able to bypass UAC is to create a headless 'helper' application that runs as a service on the target PC and does the thing you need admin rights to do. Installed services run with the SYSTEM account and as such has full administrator access (but obviously requires administrator rights for installation).
Hi! Do you mind elaborating on your issue? Did you try some of the ideas mentioned in this thread? Also, I recommend starting a new thread so that the active users in the LabVIEW forums can see and work on your issue.