March 23 2015
I am a bit confused about RunAs. I can launch VS13 as Administrator
and everything works as expected: the NetMonUI reloads the saved configuration
and window placement info, loads the driver, and queries process information
(for everything except the system process). However, when I run NetMonUI from
the command line using RunAs:
NetMon> runas /profile /user:ChipAdmin@nlited "netmonui --driver S:\App\NetMon\NetMon.sys"
The driver fails to load with "access denied" (5) if the driver is
already loaded. I can unload the driver and reload it. Then the
driver loads, but the process information queries still fail with
"access denied". I thought runas admin was the same thing as using
Explorer right-click "Run as administrator", but apparently not.
The solution to the driver loading may be file permissions. NetMonUI.exe might need to set the FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE flags when it opens the driver file. This was part of the problem, changing the file share mode allows me to connect to a driver that is already installed. I am still unable to install the driver.
I added a user/password dialog to logon as the admin.
The calls to LogonUser() and ImpersonateUser() succeed, but the call to OpenSCManager() still fails with "ERROR_ACCESS_DENIED".
I think that once a process has been launched, its UAC credentials cannot be changed. I can launch a new process with elevated credentials, but I cannot elevate the current process nor can I launch a new thread with elevated credentials. So the net effect, even with my own admin logon window, would be the same as having the user close and relaunch as admin. There is not much benefit to having my own logon window. This is probably "by design" as far as Redmond is concerned.
Bottom line: The current version of NetMon (without any admin logon window) is about as good as it will get, with respect to Admin privileges.
I still don't understand why RunAs ChipAdmin fails.