I'm trying to find a way to start an application when the user logs on. The application must have administrative privileges.
This seems to be easy: just create a new registry key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
This works, but the user is asked every time by the User Account Control window. This is annoying, especially at startup. So I'm trying to find a way to launch this applications with elevated privileges but without the UAC prompt.
I've found here a solution: it uses Windows Task Scheduler. However, this Windows utility seems a bit unreliabled: sometimes it works well, sometimes not. On two computer tested, my application is started with a delay average of 46 seconds.
On the link given below, it says that you can recall the Task Scheduler operation with this command (where MyOperationName is the name of the scheduled task):
schtasks /run /tn "MyOperationName"
so, if I try to combine this command to a new key in CurrentVersion\Run I should get what I want. Would this work?
I'm working on VB.NET WinForms, Visual Studio 2013 and I use this library to interoperate with Task Scheduler.
Thanks,
FWhite
Related
I want to develop an application with VB.NET 4.7.2 Framework, using WinForms. The application must run like a service, that is, ran at Windows startup (after boot, before login). It's intended to run only on a local enviroment, and play some sound files while the local user hasn't logon yet.
My first aproach to this problem was developing a WinForm app that accepted command line args, so when it was executed without args, the GUI appeared to let the user customize some of the features of the program, and when it was executed with args, then no GUI is shown and music is played.
However, the method for detecting when login/logouts and other NT Session Events happened was by hooking a script onto the Windows Scheduler, which ended up being a bad idea, because half of the times, the program would lock up (as the Windows Scheduler would try to execute multiple times) or didn't even execute the program (because it didn't even fire up correctly the login event).
Now, I've considered remaking my code into two programs, a service that runs the code, and a GUI app that sets up the settings for the service program. My idea is to embed an executable inside the main GUI app executable, so it automatically extracts it to a folder in order to run the service program.
However, I can imagine this isn't a pretty clean solution; more so if it triggers by error an antivirus.
I would appreciate some kind of help to get this working on a much clean and safe way.
Note: The main goal of this question is to preserve the all-in-one executable format, if possible. If not, either design a way to run a WinForm app like a system service (run at Windows startup, before login), or two individual programs, one as a service and the other as the GUI program.
I currently have 2 applications; The main application and an Updater. The main application runs with the manifest in "asInvoker", whilst the Updater runs with "requireAdministrator".
However, I currently need the main program to modify contents of its own folder in ProgramFiles, but in order to do this I need elevated access. Instead of creating another application to separate the process, would it be possible to have a messagebox appear saying "Restart in Admin Mode?" and then proceed to restart the application in Administrative mode only the one time?
I don't want the end user being spammed with Window's UAC every time they open the application, which is why I already separated the updater.
Any ideas and suggestions are greatly appreciated.
Simpliest solution is to not store application in Program Files, where access is restricted for non-administrators, but in %LocalAppData%, where is unrestricted access for logged user. This is how update is solved in ClickOnce-distributed applications.
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
I'm using Windows Task Scheduler Wrapper to schedule the tasks (basically to launch an exe console every two minutes or so) in a .net desktop application.
However, I don't want it to pop-up the console every 5 minutes or even once.
How do I hide it?
I understand if I was using vb.net to launch the exe, there are several things I could have done. However, I am using windows task scheduler to launch it. What do you suggest in that scenario?
The console app will only display if scheduled to run under your account. Simply create a new account, and schedule it to run under that account.
I'm trying to write automated test, to ensure that the installer for my program works okay.
The program can be installed for all users (requires admin privs), or for current user (does not require admin privs). The program can also autoupdate itself, which in some cases requires admin privileges, and in some cases doesn't.
I'm looking for a way where I can have an automated test click "Yes, Allow" on the UAC dialogs, so I can write tests for all different scenarios, on many different operating systems, so that I can be confident when I make changes to the installer that I didn't break anything.
Obviously, the installer process itself cannot do this. However, I control the complete machine, and could easily start some sort of daemon process with administrative rights, that the testprogram could make a socket connection to, to request it to "please click ok on the UAC now".
I actually figured out how to do this while looking to answer a similar question about UAC. Here is what you can do:
Write a service that runs as SYSTEM.
Open the process token of the winlogon.exe instance running in your logon session.
Use that token to launch a helper process on the Winlogon desktop via CreateProcessAsUser.
At this point, you have a helper process running as SYSTEM in your logon session on the Winlogon (secure) desktop. From here you can use some kind of IPC mechanism to communicate from your automated test program to the helper process. In the helper process you can EnumDesktopWindows to find the UAC prompt. This is as far as I took it; I didn't actually try to simulate clicking Yes or No, but I don't see any reason why it wouldn't work. Also, I only tested on Windows 7 32-bit; I believe the UAC architecture is identical to Vista, but I didn't test on it.
It took me a while to figure all this out; I can provide some code if you want.
EDIT: Just as a follow up I added code to use FindWindow() to find the "Yes" button and I was able to successfully send it a BM_CLICK message; the UAC prompt went away and the application was allowed to run.
An alternative solution might be to turn UAC off
The least bad solution I've found so far is to run the tests in a VMWare session, and control the mouse/keyboard trough the vmware sdk. Would love to hear about other solutions
Remote Desktop to it or run it as a guest VM (using Virtual PC or whatever, just don't boot to it.) This is also the best way to take a screenshot or video of the UAC prompt.