I am trying to create an application/service which will be running in the machine without any console or remote log-in. And if any user is trying to log-in this application will perform following task in sequence:
Put the log-in process on hold.
Do its own processing and and upon completion of its work,
It should allow the Windows to resume with the log-in process.
I could not find any way to put the windows log-in process on hold. Any suggestion/help appreciated.
Note: I am using Windows Embedded Standard 7.
Related
I've got one for you thats been bugging me for a bit.
If you run a Windows Service as Local System, how can that service display forms or prompts on the user desktop?
I tried this in one of my previous apps and couldn't get it to work; I settled on having an 'invisible' app running in the user context to handle any user interaction. But as time has passed, I've seen some apps that have nothing more than a service running as local system and yet they produce prompts and forms on the user desktop.
Thanks in advance for any info :)
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'm writing a VB.NET application that I want to load at Windows start up before the user logs in. It's going to run on a server and launch other process and kill and restart them as needed to get around a memory leak issue. It also needs to have a GUI to view the current status of the processes its managing.
Now, I can get the application to load when the user logs in but that's not very helpful because the server could reboot for some reason and no user would be logged on, but this application still needs to run in the background.
How do I do this? Do I need to write it as a service, or is there another way? I tried writing a WinForms app but it wouldn't load until after the user logs in.
You need to write a service. Also, probably best to write a second app that will interact with the service and provide a GUI to control what it does.
I have a deployment package that opens an application when the instalation has finished.
On opening, this application validates a connection to a database using Integrated windows security.
The Problem is that when it calls
Process.Start(XXXXXXXXXX)
The application is opened under the machine account, the one that actualy does the install under UAC in Windows 7.
I know i can use the ProcessStartInfo object to ask the user to specify their password etc however this will be really annoying for them when they are already logged onto the machine.
I have tried using ProcessStartInfo, WinAPI etc but to no avail.
Has anyone else encountered this type of issue and/or have a suggested solution.
In summary I am trying to call
Process.Start........
Under the credentials of the logged on user as the last action of an deployment package under Windows 7
VB.NET application developed in VS2010 using Windows Installer Deployment.
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.