I dont know if this has to do with how the program is programmed or how it is set up or how it is started.
But I created a program in WPF and I would like to make sure that none of he regular users on the computer shut it down.
The regular users need to be able to interact with it but they should not be able to close it.
The correct approach would be to run the application as a service with permissions set by the administrator to not let the user manipulate the service. Otherwise you will run into trouble with user-initiated shutdown and with preventing the application from being terminated.
If it is the case that the OP wants to prevent visibility of the OS, creating a terminal like experience. The best way to do this is to create a shell replacement.
Then the user wouldn't see the OS as windows directly.
Related
I have a console application written in c#, which downloads a file to program files. So of course it needs to run as admin. This program gets called from a Win32 C++ application which almost certainly is not running as administrator
What are my options. How can I get this to work on UAC and non UAC enabled boxes ( I don't know if there needs to be separate solution in each case )
Oh and the console app is in .NET 2.0
On a machine with UAC you need to include a manifest resource to specify that you want the process to run as administrator.
On a machine without UAC you will simply have to instruct your users that they need to run it as a user in the administrators group. Almost all users of XP (the version that you will most commonly encounter without UAC) are in the administrators group so you won't encounter many problems.
I never tried it, but this can probably be done using the
CreateProcessAsUser Function.
I have a program, which users sometimes want to restart with administrative privileges to perform administrative tasks.
Currently, it has a menu item, which does the following call:
Process.Start(new ProcessStartInfo("self.exe") { Verb = "runas" })
That works if program is installed with MSI. It displays a usual UAC prompt, which lets user to elevate the program.
However, when converted using Desktop Bridge converter, and installed the Store way, this call crashes due to insufficient privileges. Is there another way for me to (re-)start self with UAC prompt?
Alternatively, is it possible to perform elevation using COM?
I am on release branch, Creators Update btw
Is there another way for me to (re-)start self with UAC prompt?
No. According to this page (https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare, look for Your app requires UIAccess), it seems that requesting the UAC prompt from your app is not currently supported.
Remember, as a UWP app, it needs to work while running as the interactive user.
There is a one-year-old post from MSDN that answers a similar question: https://social.msdn.microsoft.com/Forums/en-US/a35b4c70-5fc6-4f1a-b80a-b11ee90105eb/uwpdesktop-bridgeproject-centennial-appconverter-convert-admin-apps?forum=wpdevelop
Alternatively, is it possible to perform elevation using COM?
Given the findings above, the answer is probably no.
If I were in your position, I would rethink these Administrative tasks. They might even be something that you would not be able to run as a UWP app anyways. For instance, any attempt to create an HKLM key will fail.
I'd like to schedule a task that is a program that launches another program. The other program is a Windows.Form application.
Is it possible to programmatically interact with a Windows.Form application on a non-interactive desktop session?
Specifically, because I know this sounds very odd, I'd like to launch SpaceSniffer or something similar, and provide some interaction with it.
No, well it's not a good idea, anyway. Call a program with an API or a command line interface.
Is it possible to run handle.exe (from sysinternals) from a service (in windows7) without having to turn off UAC?
The service is a custom c-app that needs to find out which process is locking a file it tries to access and handle.exe seems to be a good way to solve it but i can't get it to work with UAC turned on. This app runs all the time so i can't have a UAC prompt while its running but its fine if it shows up at startup.
Handle.exe works fine from an admin commandprompt but fails when trying to run from a normal prompt.
I call handle.exe from CreateProcess() and get the output from pipes. I guess there should be a way to solve this but i can't figure it out. Setting up the service to log in from an admin account does not seem to work.
UAC does not affect services (it only affects interactive sessions) so that should work.
However, if you don't want to move your entire program into a service then there are better ways to do this which don't require creating, installing and managing a separate service process in addition to your main program.
If your program requires admin rights to work at all, and this isn't the only place it will require them, then you could flag your program (via its embedded manifest resource) as requiring administrator rights. It will then trigger one UAC prompt whenever it is run and be run with full admin rights, including the ability to run Handle.exe.
On the other hand, if this is the only place where your program needs admin rights, it may make sense to create a COM DLL which wraps your Handle.exe call (or any other admin work) so that you can use UAC to make elevated calls to that function from your non-elevated app. You will then trigger a UAC prompt each time you create (an elevated version of) that COM object. You can keep the COM object open as long as you want, and create it whenever you want, so when and how often the UAC prompt(s) appear are still up to you.
Both 1 & 2 are standard uses of UAC so any good documentation or tutorial on UAC will describe how to do them in detail.
You may want to look at the Win32 API method CreateProcessWithLogonW.
There is also an elevate VBS script here you may learn from: http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx
I'm not sure if this is technically a Kiosk, but it's basically the same idea. I have a program that runs full screen all the time from boot to shutdown to control a machine that the computer is hooked to.
Right now I just have a shortcut to the exe in the Startup folder so it starts when the system boots up and logs in. Is there any better way to do this? I'd really like the user to never see the Windows environment (just the windows loading progress bar on boot) if at all possible, but I'm guessing that's not possible.
Just thought I'd ask and see if there is a better way to do this than putting it in the startup folder?
The best option is to use Windows Embedded. This gives you much more control over the shell, and what is run and installed with the system.
If you have to do this with a consumer OS, you can try to bypass the login prompts to auto-login your user, and have your program setup in the registry to startup. Disable any other services you don't need. That will minimize the time the shell is displayed (but it's very difficult to remove it).