We Keep Coding

how to Start exe with elevated rights when domain user logs in

I need to start a windows forms application with admin rights whenever a domain user logs in.
I am trying to start the application with service and task scheduler but the application UI does not show up. However I can see it running in the task manager. and if I add a timer and terminate the app. it terminates after correct interval as well.
Can someone help me on how to develop/deploy an application so that it shows "the UI" when whenever any user logs in to the machine. should I add some registry entry that will start me application or is there any other way to achieve this..

It seems to me that when the user logs in, the task does not really work because there are not enough rights. Try it like this:
you need to create a new task that simply launches the program you want to use without UAC dialogs. When creating this task, in the General tab, enter the name of the task (remember this name, you will need it later) and check the box that says “Run with highest privileges - Run with highest privileges”. This puts the task to run with administrator rights.
To make sure there are no compatibility issues, go to the “Configure for” drop-down list at the bottom of the Create Task window and select Windows ® 7, Windows Server ™ 2008 R2.
On the Actions tab - Actions, you need to create an action that launches the program. Everything is very simple here: select the action “Start a program”, specify the path to the program that will be executed, and click OK.
Your last stop is on the Settings tab. Here you need to make sure that the checkbox “Allow task to be run on demand” is checked. Also, make sure that when the task is already running, another instance will not be started by choosing the option “Do not start a new instance”
The second step in this procedure is to create a shortcut that launches the task you just created, which in turn launches the program of your choice without the UAC line appearing.
An important difference when creating a shortcut to a task compared to a normal shortcut on the desktop is to enter schtasks / run / tn Task Name - Schtasks / run / tn “Task Name” (Task Name must be replaced with the actual task name) in the Item Location field. In this command, the / Run parameter simply performs a specific task, and / tn allows you to enter the name of the task you want to run.
Once the shortcut is created, if you click on it, it will work like the task you created, and this in turn launches the program specified with administrator rights, but without UAC.
Thus, you can create a task to run the created shortcut.

To check if user has logged in into a domain, you can use
System.Security.Principal.WindowsIdentity.GetCurrent.Name which gives you "domain\username".
and for starting your application once user logged in, you have to run your program at start up, try this link.
And to run your app at startup using group policy (recommended) try this.

Is it possible to start a process with uiAccess=true from another process with uiAccess=true

A process is already running that has uiAccess=true in it's manifest. Is it possible for this program to start another such process with uiAccess=true? Currently, whenever Process.Start is called for the second process a Win32Exception is thrown with message:
The requested operation requires elevation
Running the first process as Administrator stops the failure however this is not an option for me.
I know it is possible to do this from a service using SetTokenInformation etc. (and I'm already doing this) but that's as user Local System so I'm presuming is not reusable.

Scheduled Console App Crashes with App.config

I have a C# console application that reads app settings from its app.config. The console application is targeted as the action of a Windows Scheduler Task. It runs once a day.
Since adding the code to read from the configuration file the app crashes only when run by the Task Scheduler. When run manually (from command prompt or by clicking on it in it's folder)), the application runs with no issues and it works exactly as expected.
Here's the code that reads from the app settings section:
int someValue = 1;
try
{
if (ConfigurationManager.AppSettings["someValue"] != null)
someValue = int.Parse(ConfigurationManager.AppSettings["someValue"].ToString());
}
catch(Exception exception)
{
// Write to error log
}
This is the exception I'm getting in my error log:
Exception: The type initializer for '<my application name>' threw an exception.
System.Configuration.ConfigurationErrorsException: An error occurred loading a configuration file: The parameter 'exePath' is invalid.
Parameter name: exePath ---> System.ArgumentException: The parameter 'exePath' is invalid.
Parameter name: exePath
I have tried allowing the task to run with highest privileges. I have tried accessing the configuration file in different ways (Configuration.OpenConfigurationExe(...)), etc... I get the same problem every time. I have tried putting my .exe in various locations on disk. This one is in C:\Program Files. I have looked around on S.O. and this post suggests that it might be a read permissions issue, but if the task runs under my domain's account and has the highest privileges, is that still possible? Note that it runs just fine if I run it manually from a command prompt or by clicking on it.
How can I reliably get a console application to read its app.config if it has been configured to run under Windows Task Scheduler?

Solved it. Turns out I had some legacy bits running code like this:
Configuration config = ConfigurationManager.OpenExeConfiguration("<app exe name>");
This where the exception was being thrown, not in the code in my question. Shame on me. Should have debugged that more thoroughly. I removed it all and replaced the local config object usage above with calls to:
ConfigurationManager.AppSettings["someValue"];

It could definitely be a permission issue, and maybe more than just read permissions. Things to check:
IS the task running under YOUR account, or another account? If this app is stored under a directory in your local profile then even other administrator accounts don't have permissions by default (they have to manually set permissions). Try moving the application to a local folder on the hard drive and set permissions as needed.
Try setting audit settings for the directory your app is stored in. If it is a permission issue then the security log will tell you more about what and why it is getting denied.

My C# application is returning 0xE0434352 to Windows Task Scheduler but it is not crashing

I have written a few C# apps that I have running via windows task scheduler. They are running successfully (as I can see from the log files that they are writing ) but windows task scheduler shows them returning a last run result of 0xE0434352. Is there something I need to do in my C# application so that it returns a success code to the windows task scheduler?

Another option is to simply use the Application log accessible via the Windows Event Viewer. The .Net error will be recorded to the Application log.
You can see these events here:
Event Viewer (Local) > Windows Logs > Application

When setup a job in new windows you have two fields "program/script" and "Start in(Optional)". Put program name in first and program location in second.
If you will not do that and your program start not in directory with exe, it will not find files that are located in it.

Hans Passant was correct, I added a handler for AppDomain.CurrentDomain.UnhandledException as described here http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.71).aspx I was able to find the exception that was occurring and corrected it.

I was referencing a mapped drive and I found that the mapped drives are not always available to the user account that is running the scheduled task so I used \\IPADDRESS instead of MAPDRIVELETTER: and I am up and running.

In case it helps others, I got this error when the service the task was running at didn't have write permission to the executable location. It was attempting to write a log file there.

I had this issue and it was due to the .Net framework version. I had upgraded the build to framework 4.0 but this seemed to affect some comms dlls the application was using. I rolled back to framework 3.5 and it worked fine.

I got the same error but I have fixed it by changing the file reading path from "ConfigFile.xml" to AppDomain.CurrentDomain.BaseDirectory.ToString() + "ConfigFile.xml"
In my case, this error due to file path error because task manager starts program from "System32" as initial path but the folder we thought.

I was getting the same message message within dotNet Core 2.2 using MVC 5, however nothing was being logged to the Windows Event Viewer.
I found that I had changed the Project sdk from Microsoft.NET.Sdk.Web to Microsoft.NET.Sdk.Razor (seen within the projects.csproj file). I changed this back and it worked fine :)

In my case it was because I had message boxes. Once I commented that code out, it started working. I remembered that could be a problem when I looked at the event log as suggested in this thread. Thank you everyone!

I encountered this problem when working with COM objects. Under certain circumstances (my fault), I destroyed an external .EXE process, in a parallel thread, a variable tried to access the com interface app.method and a COM-level crash occurred. Task Scheduler noticed this and shut down the app. But if you run the app in the console and don't handle the exception, the app will continue to work ...
Please note that if you use unmanaged code or external objects (AD, Socket, COM ...), you need to monitor them!

Also message box in PowerShell. I converted PowerShell script to exe. When running as admin it's worked but in task schedule I received this error also.
There was an line in PowerShell script with write-output. After commented this line and compile new exe Task Schedule was completed successfully.

It is permission issue in my case the task scheduler has a user which doesn't have permission on the server in which the database is present.

Can't schedule Program with Excel Interop

I have developed a console program in C# .NET, that uses Excel Interop.
The program works just fine on my development machine and in the windows server 2008, if I run it from command line.
When I try to schedule a task to run it daily, I got this annoying Interop error:
02/11/2011 00:30:05,000 [1] FATAL My.Program [(null)] - Unable to Microsoft Office Excel open file 'E:\excel.xls' by one of several reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as the currently opened book.
System.Runtime.InteropServices.COMException (0x800A03EC): Unable to access the Microsoft Office Excel file 'E:\excel.xls' by one of several reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as the currently opened book.
in Microsoft.Office.Interop.Excel.Workbooks.Open (String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, IgnoreReadOnlyRecommended Object, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad)
The file 'e:\excel.xls' exists and if completely closed when the program starts, because if I try to run the same program in my command line, it ended as expected.
I also have setup my task to run as Administrator, so it shouldn't be permissions issues.
Can you help me?

Check this out. Looks like you have to create a folder to get this thing to work right.
C:\Windows\System32\config\systemprofile\Desktop
Taken from this article here
http://social.msdn.microsoft.com/Forums/en/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91

In short make sure to create these folders with appropriate rights for the profile used in the task scheduler and that folder is is NOT SET as readonly:
C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\Desktop
And check this if doesn't work:
From the Start menu, click Run and type Dcomcnfg.exe.
In Component Services, click Console root, expand Component Services, expand Computers, expand My computer,expand DCOMConfig.
Search for relevant app, such as Microsoft Word 14.0 Object Library. Click on it.
Right click and select Properties.
On security tab, select Customize in "Launch and Activation" section.
Click edit and add identity of app pool under which you application is running.
Repeat above step for "Access Permission"

Create a directory “Desktop” under:
“C:\windows\system32\config\systemprofile\Desktop”
AND
“C:\windows\SysWow64\config\systemprofile\Desktop” for 64 bit operating systems
Grant full access to this folder for the user running the service.
It should solve your problem.

Things can get a bit weird when you do Office Automation from a scheduled task, so I'd suggest trying a different user account.
If it works when you're logged in, then I'd suggest setting up the task scheduler to run it under your account. If that still works, then create a new account with the same kind of permissions as your account and have it run under that account.
Otherwise, try logging on as the administrator account and make sure that the app runs when logged in as administrator. For example, maybe there is some bit of Office that gets setup during the first interactive login by the user or similar.

The file 'e:\excel.xls' exists
It doesn't. Mapped drive letters like E: are per-user. The drive is valid only under your user account, the scheduled task is probably running using another account. Instead of tinkering with accounts, the best thing to do is to use a universal name. Like \\server\share\excel.xls, that's valid for any account. Ask more questions about it at serverfault.com

I was struggling to get this to work. I had been all over google, I thought that I had solved my problem with help of one thread that had a drop down while setting up the scheduled task that allowed you to select XP as the "Configure for" option, the XP option is only available when creating the task from the beginning. That worked fine as long as the owner of the scheduled task was actually logged into the machine.
I finally was able to correct it in the DCOM config by adjusting the Identity and hard coding a user to the panel.