[RESOLVED] Start Program At Computer Startup With Admin and NO UAC

I have done quite a bit of research on this and I am at a stand still. I have looked at every post on VB Forums relating to setting programs to startup when the computer starts up and even after my research, I cannot find any guidance.

I need the application I am building to startup when the computer starts up (which I have accomplished), but without the UAC prompt. The program searches through and looks for harmful processes and requires administrator level access. I need the administrator level access, but the user should not have the UAC popup on startup. That would defeat the security in the program that I am working on if the "standard user" could just click no.

This is what I do have as far as my code for creating my startup registry:

vb.net Code:

If CheckBox1.Checked = True Then
            My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion\Run", True).SetValue(Application.ProductName, Application.ExecutablePath & " -min")
 
        Else
            My.Computer.Registry.LocalMachine.OpenSubKey("SOFTWARE\Microsoft\Windows\CurrentVersion\Run", True).DeleteValue(Application.ProductName)
 
        End If

Again, I am looking for any advice for having it startup as admin without a prompt on boot.

Thanks you guys!

It sounds like you should be creating a Windows service and running it under a different account to the interactive session. The reason you can't find out how to do what you're trying to do is almost certainly because it's not possible. How could it be, given that it obviously violates the whole purpose of these security measures?

Quote:

---

Originally Posted by jmcilhinney

It sounds like you should be creating a Windows service and running it under a different account to the interactive session. The reason you can't find out how to do what you're trying to do is almost certainly because it's not possible. How could it be, given that it obviously violates the whole purpose of these security measures?

---

Okay, so for instance, antivirus programs typically startup with the administrative level access and do not provoke the "standard user" with the UAC. You mentioned creating a Windows service, I know what services, but could you elaborate a little more so I can fully understand. I am not familiar with creating a Windows service.

Quote:

---

Originally Posted by kshadow22

I am not familiar with creating a Windows service.

---

Then head to a search engine and start researching, then post back here when you have a specific question.

Quote:

---

antivirus programs typically startup with the administrative level access and do not provoke the "standard user" with the UAC.

---

They use one or more services and the 'user programs' are just a front-end to these services. The services run with system-level access, not the user programs.

Depending upon whether these user programs are run as an administrator or not, sets what operations the user can perform ie what operations the user program allows with the service(s). It's the service(s) that perform the operations - so the user program doesn't need UAC.

I was able to research the windows service, and I created my own. I know how to install my service using the Visual Studio Command Prompt, but how can I install the service on the first boot of my Windows Forms Application?

Don't.

Do you really want security to be something that you can set aside when it isn't convenient? Does what you are thinking of doing make sense from a security sense, or would it represent a massive security hole? If it is the latter, don't you think that might be a problem? If it is not the latter, then what steps do you expect the standard user to perform to get to the point of installing the service? Consider what they will have to do to stay within the context of the security. It may well be a nuisance for them, but if you could just dispense with that nuisance, even one as minor as signing in as an administrator, then you don't have security in the first place.

Quote:

---

Originally Posted by Shaggy Hiker

Don't.

Do you really want security to be something that you can set aside when it isn't convenient? Does what you are thinking of doing make sense from a security sense, or would it represent a massive security hole? If it is the latter, don't you think that might be a problem? If it is not the latter, then what steps do you expect the standard user to perform to get to the point of installing the service? Consider what they will have to do to stay within the context of the security. It may well be a nuisance for them, but if you could just dispense with that nuisance, even one as minor as signing in as an administrator, then you don't have security in the first place.

---

So overall, I should keep the windows service and the windows form app separate for security? Now it is possible to have the administrator install the program and the service under the same installer right? and then they would be held separate still. (Today was my first time creating my first windows service.)

I looked into this post How to create an installer for a .net Windows Service using Visual Studio and it provides an example of creating a setup, which I believe is what I need, I just don't know how to add my windows form to this setup as well.

Each application would have its own installer but one primary installer would bootstrap the other(s). You'll have seen this happen often when installing software yourself, although you may not even have realised it.

Quote:

---

Originally Posted by jmcilhinney

Each application would have its own installer but one primary installer would bootstrap the other(s). You'll have seen this happen often when installing software yourself, although you may not even have realised it.

---

Yeah, I have seen that. I read up a little on that at Deploy two projects Windows Service and Application in one Setup Project. I am going ahead and trying this bootstrap method and I will get back with you guys on what I am able to accomplish.

Quote:

---

Originally Posted by jmcilhinney

Each application would have its own installer but one primary installer would bootstrap the other(s). You'll have seen this happen often when installing software yourself, although you may not even have realised it.

---

I was able to do this using Advanced Auto Installer. I have my application and service being installed into C:\Program Files\ and my application isn't able to write to any of the files in its own directory. I did look into this, and I wasn't able to find much information. I did try changing the security on the files, and I didn't get anywhere doing that unless I opened up the security to everyone and everything.

What can I do so my application can access and modify its own files in its own directory in C:\Program Files\

You don't. You're not supposed to write to the Program Files folder. Windows has various other locations specifically intended for applications to write data.

Quote:

---

Originally Posted by jmcilhinney

You don't. You're not supposed to write to the Program Files folder. Windows has various other locations specifically intended for applications to write data.

---

I did some research on establishing communication between the Windows Service and Application. What I was able to find was using Interprocess Communications, which seems very complex and I am not really able to understand how to use this. So continuing on, I was able to read on about Windows Communication Foundation (WCF) and yet with this, I am not sure if this is something I would want to establish. What I am trying to accomplish is to have the application to store data on a non administrator level (without storing it in the documents folder) so my Windows Service can read from it. The Windows Service will not need writing abilities to the files. The application must store the information into a file because it holds information for timers and processes in which the Windows Service will manage. So when the computer boots up, the Windows Service can access those files without relying on the application to be running.

I hope I have done everything close to protocol as possible, especially with me being new to some of this. You mentioned there being specific locations for managing files associated with my program. Where would be the appropriate locations? I thought about possibly using the user config settings, but after reading about that, I learned that this wouldn't be the best route to pursue as far as what I am trying to accomplish because it isn't practical at all.

Any guidance of where I should point my research on figuring this out?

Quote:

---

Originally Posted by kshadow22

[...]
Any guidance of where I should point my research on figuring this out?

---

I would start here...

Quote:

---

Originally Posted by Arve K.

I would start here...

---

I reviewed the article you shared. I didn't receive any insight or direction by the article. I seen the information regarding adding a button to add to a listbox. I then read on to the class methods which understood. I don't see where these methods would help in my case. As far as the events and properties, I really don't see anything either that pertains to this thread. Perhaps I am misunderstanding what you are trying to point out to me.

I do see this information:

Quote:

---

UserAppDataPath - Gets the path for the application data of a user.

UserAppDataRegistry - Gets the registry key for the application data of a user.

---

This wouldn't fit my case because the application could be ran by different users and no matter the user, the application will have to be able to access the same path.

Possibly useful links:

https://docs.microsoft.com/en-us/win...ns-programdata

https://www.howtogeek.com/278562/wha...er-in-windows/

https://social.technet.microsoft.com...s?forum=ws2016

kshadow, our network is really locked down and I'm routinely developing apps for different departments. I've mainly moved to web based apps and rarely look back, although I do love the ease of manipulating office applications with VB so I come back for that. (Maybe it's just easy because I'm used to it).

Anyway, any config, log or output files that your client needs to access and write to should be located in the \users folder for the current user. The Program Files folder should be reserved for binary files such as DLLs and the executable and batch files if necessary.

Quote:

---

Originally Posted by acy.forsythe

kshadow, our network is really locked down and I'm routinely developing apps for different departments. I've mainly moved to web based apps and rarely look back, although I do love the ease of manipulating office applications with VB so I come back for that. (Maybe it's just easy because I'm used to it).

Anyway, any config, log or output files that your client needs to access and write to should be located in the \users folder for the current user. The Program Files folder should be reserved for binary files such as DLLs and the executable and batch files if necessary.

---

Thank you for your reply and the information. That definitely clears up some information. I do believe that is what jmcilhinney was getting at. That I would not be able to use the Program Files folder as to host these files. jdc2000 kind of elaborated this by referring to using the Program Data folder.

Quote:

---

Originally Posted by jdc2000

Possibly useful links:

https://docs.microsoft.com/en-us/win...ns-programdata

https://www.howtogeek.com/278562/wha...er-in-windows/

https://social.technet.microsoft.com...s?forum=ws2016

---

I did look into these links and I believe I have found my answer. Thank you for providing this! I will go ahead and implement this into my program. If I find that it fits the solution, I will be marking this thread as resolved.

A huge thanks to everyone who helped me and to jmcilhinney as you are always actively helping everyone.

I was able to use the Program Files method mentioned by jdc2000 to carry out the functionality of my program. However, when doing this, there was some restriction in place that I had to work around. When running the program under a standard user (non-elevated), the program cannot modify the files within the Program Data folder. If you run the program under a admin account (non-elevated), the program can modify the programdata files. I found that this event was a little strange. I did not look much further into this because this has been quite the lengthy process for me to create this program. I then proceeded to use this functionality to benefit the security of the program and applied additional code to work around this and gain from it.

Overall, you all have been a great help. :) If anyone wants to see the final first release of this program, you can click here to download the setup file.

Similar programs have been created, yes I am aware. However, this was a fun project for me and my intentions were to make this program carry out one purpose. Below is a brief description and some pinpoints to this program in case you were interested before you download my mysterious program.

Quote:

---

-Stop students/ staff / employees from accessing programs and features you don't believe they should be touching.

-Single feature software. You will only find that the software carries out this one task.

-Creates logs anytime the user attempts to open a forbidden process.

-Light weight program.

-Little computer experience required... easy to learn.

-Completely free.

---

If you happen to download my program and you have any tips, ideas, or constructive criticism, I would be happy to hear from it. (Of course there are so many features I could have added, but I chose not to for the sake of time.)

Lastly, this program will be hosted on my website.