I have a .NET console application written in C# (myApp.exe), that runs an external application ('bob.exe'). The console application works great when I run myApp.exe manually. The C# code that calls the application is:
System.Diagnostics.ProcessStartInfo procStartInfo =
new System.Diagnostics.ProcessStartInfo("C:\\bob.exe");
procStartInfo.RedirectStandardOutput = true;
procStartInfo.UseShellExecute = false;
// Do not create the black window.
procStartInfo.CreateNoWindow = true;
// Create the process and assign its ProcessStartInfo and start it
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo = procStartInfo;
proc.Start();
In Windows Server 2003, I created a Scheduled Task that executed 'myApp.exe' on a regular basis. It was set to execute even if the user was not logged in. The Scheduled Task worked and called 'bob.exe' (I was able to verify this by viewing the output files from 'bob.exe')
We then upgraded to Windows Server 2012. I created a Scheduled Task in Windows Server 2012, setting it to execute even if the user was not logged in and configuring it for Windows Server 2003.
I set the Action to call 'C:\myApp.exe', similar to how I had it set up in Windows Server 2003
When the scheduled tasks executes and I am logged in, the 'bob.exe' application is executed from 'myApp.exe'. However, when I am not logged in and the scheduled task executes, 'myApp.exe' is executed but 'bob.exe' is never executed (I can verify this by seeing there are no output files from 'bob.exe'). There are no errors reported by the Scheduled Task and the Last Run Result says "The operation completed successfully. (0x0)".
I found a similar post here but I was unable to resolve my situation. What am I missing?
I had a similar issue with my app calling out 7za.exe to archive db backups. When I ran my app manually it worked fine, but when I scheduled my app via Task Scheduler, the 7z routine would not fire off and didn't give my app a verbose error. I found that adding the directory I ran my app from to the task scheduler's Start in (optional): box corrected my issue.
Program/script: "C:\Program Files (x86)\CustApp\CustApp.exe"
Start in (optional) C:\Program Files (x86)\CustApp\
Note not to use double-quotes on the "Start in (optional)" setting for the directory, it errors when I did.
I had a similar problem with running a Batch file (on WS2008) and the problem was due to the permissions given to the user executing the scheduled task on the folders where the Batch file and the Executable files were set.
I'm not sure if the security of WS 2012 is different, but if I were You I'll try to debug the application (if you have the code) checking for permissions.
HTH
Related
My console application is responsible for starting a WCF service in interactive mode (ie. the service does not get installed as a Windows service in that case).
In order for my application to start the latter, the application invokes the compiled executable using the following method:
static bool AutoStartService()
{
var MyProcessFile = System.IO.Path.GetFullPath($"pathToExecutable/MyServiceExe.exe");
Process myProcess = new Process();
myProcess.StartInfo.FileName = MyProcessFile;
myProcess.StartInfo.Arguments = "";
myProcess.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
myProcess.Start();
Thread.Sleep(WaitForTheServiceToStart);
}
return true;
}
Note that this approach works just fine when debugging from Visual Studio.
However, when the console application is invoked from Jenkins (note that I gave Jenkins admin access and it logs in as a normal user), then the service process does not seem to stick or be visible from the Console application. I can tell it at least starts and stops as I can see the logs being written to file.
The Console application is started using a batch command from Jenkins (I also tried using Powershell, but without luck).
Any suggestion on how to do that?
I have tried with both debug and release builds of my Console app C# project, but it makes no difference.
EDIT
I have edited the following properties, but without success:
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.Environment.Add("BUILD_ID", "dontKillMe");
I am now seeing the following warning, but I don't believe installing the service is the only way to go as this is what I am doing when running this code without Jenkins and it works. Maybe Jenkins does not allow it though?:
Cannot start service from the command line or a debugger. A Windows Service must first be installed (using installutil.exe) and then started with the ServerExplorer, Windows Services Administrative tool or the NET START command.
EDIT2
I went a step further. The reason why I was getting the former message is that the service checks "Environment.UserInteractive" to either run as interactive or to start/run the installed service. For some reasons this flag is always set to false, while it should be true in my case.
Is there a way to fool the service to think that flag is true?
I am attempting to run a batch file that utilizes the VMWare VIX API and VMRun.exe to power on/off virtual machines in VMWare Workstation. Currently my batch files work correctly when run from the command prompt. However, I can not successfully execute them from my Windows Service built in C# & .NET. I executed my batch files in my service in the following way:
string myBatchFile = ConfigurationManager.AppSettings.Get("MyBatchFile");
System.Diagnostics.ProcessStartInfo processBat = new System.Diagnostics.ProcessStartInfo(myBatchFile);
processBat.WindowStyle = ProcessWindowStyle.Normal;
processBat.ErrorDialog = true;
Process.Start(processBat);
I have been able to run a simple batch file that creates a text document from the service. The code for this batch file looks like this:
#echo off
echo Hello World>"C:\Users\MyPC\Documents\HelloWorld.txt"
This works as expected when executed by my Windows Service.
When I try to execute my VMWare batch file I am unsuccessful, and can not find any way to check log my output or debug it. My code for this batch file looks like this:
#echo off
set LOGFILE=batch.log
call :LOG > %LOGFILE%
exit /B
:LOG
cd "C:\PROGRA~2\VMware\VMWARE~2\"
vmrun.exe -T ws Start "C:\Users\MyPC\Documents\Virtual Machines\VM1\VM1.vmx"
PAUSE
I attempted to add a way for a log file to be created but nothing gets generated when I execute the batch file from the service. Any guidance would be greatly appreciated, thank you.
I have a service that runs and accepts remote commands. I am trying to send a remote command to uninstall. This works and executes the msiexec. The msiexec gets to the point where it tries to stop the service and then hangs and eventually fails saying no privileges to stop the service.
If I run the same command from a command window it works fine.
I have tried this running the service as local system (with admin privs) as well as administrator (I enabled the administrator account)
I just can't seem to figure out why I am getting permission errors stopping the service running the msiexec
added information
We have a single service - it does required work and sleeps periodically
the service typically runs as local system
we have the installer set using custom actions - and all cases work fine - installing and uninstalling from command line - but running msiexec uninstaller initiated within the C# code has this issue
When a remote request is made to uninstall the desire is to remove the service, registry entries, and files on disk
The request is handled by the running service - it goes to the registry, finds the product entry and retrieves the uninstall command
when the uninstall is performed I use C# process and include in the StartInfo parameters the program name, arguments, and verb (defined as run as) - among other parameters
the uninstaller starts properly, does some actions, and then gets to the point of stopping the service
stopping the service sits until it times out after which it writes in the uninstall log that there may not be sufficient privileges to stop the service
The note from Quercus triggered the solution to my problem. It turns out changing to not run the uninstall as a child of the service allowed the uninstaller to perform the msiexec without issue. To accomplish this I had to change UseShellExecute from false to true.
Im hosting an asp.net application in IIS8 on windows server 2012.
this application suppose to execute an batch file.
it works perfect if i execute the application with visual studio in debug mode. but when i upload it to the IIS the application cant execute the batch file.
i tried to change the batch file with exe file. same problem.
the batch file suppose to execute from the application(WCF application) that in the IIS:
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo.WorkingDirectory = #"C:\path";
proc.StartInfo.FileName = #"C:\path\executer.bat";
proc.Start();
proc.Close();
please help,
Most likely the problem you are experiencing is due to permissions. You need to check what account the IIS Application Pool that your app is running under is configured for and whether that account has rights to run your batch file or the commands within that batch file.
When running in Visual Studio you're likely running IIS Express as the interactive user.
When running under IIS by default you're running under ApplicationPoolUser identity which has no rights to execute code, has no file access or anything else. Unless you've explicitly set a different account with appropriate file access rights to the batch file, and rights to execute the commands inside of the batch file, you won't be able to run the batch file from within IIS. To change that change the Application Pool user identity to a user that does have rights to both read and execute the batch file on disk and has any rights required to run what's executing in the batch file.
Make sure any folder or file accessed by your application have permissions granted to the AppPoolUser account. It is also important to check your applications resource folders too. For example, if you are writing logs, make sure you give the appPool user account enough permission to write to that file.
Your code is working fine . May be there is some issue in batch file i faced before .My batch file is
start "" BATCHLOG.exe
where BATCHLOG.exe is the executable
Some times batchfile named only
BATCHLOG.exe
does not work correctly on windows scheduler so may be in that case of yours
I'm able to successfully uninstall a third-party application via the command line and via a custom Inno Setup installer.
Command line Execution:
MSIEXEC.exe /x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn
Inno Setup Command:
[Run]
Filename: msiexec.exe; Flags: runhidden waituntilterminated;
Parameters: "/x {{14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
StatusMsg: "Uninstalling Service...";
I am also able to uninstall the application programmatically when executing the following C# code in debug mode.
C# Code:
string fileName = "MSIEXEC.exe";
string arguments = "/x {14D74337-01C2-4F8F-B44B-67FC613E5B1F} /qn";
ProcessStartInfo psi = new ProcessStartInfo(fileName, arguments)
{
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardOutput = true
};
Process process = Process.Start(psi);
string errorMsg = process.StandardOutput.ReadToEnd();
process.WaitForExit();
The same C# code, however, produces the following failure output when run as a compiled, deployed Windows Service:
"This action is only valid for products that are currently installed."
Additional Comments:
The Windows Service which is issuing
the uninstall command is running on
the same machine as the code being
tested in Debug Mode. The Windows
Service is running/logged on as the
Local system account.
I have consulted my application logs
and I have validated that the
executed command arguments are thhe
same in both debug and release mode.
I have consulted the Event Viewer
but it doesn't offer any clues.
Thoughts? Any help would be greatly appreciated. Thanks.
Step 1: Check the MSI error log files
I'm suspicious that your problem is due to running as LocalSystem.
The Local System account is not the same as a normal user account which happens to have admin rights. It has no access to the network, and its interaction with the registry and file system is quite different.
From memory any requests to read/write to your 'home directory' or HKCU under the registry actually go into either the default user profile, or in the case of temp dirs, c:\windows\temp
I've come across similar problems in the past with installation, a customer was using the SYSTEM account to install and this was causing all sorts of permission problems for non-administrative users.
MSI log files aren't really going to help if the application doesn't appear "installed", I'd suggest starting with capturing the output of MSIINV.EXE under the system account, that will get you an "Inventory" of the currently installed programs (or what that user sees installed) http://blogs.msdn.com/brada/archive/2005/06/24/432209.aspx
I think you probably need to go back to the drawing board and see if you really need the windows service to do the uninstall. You'll probably come across all sorts of Vista UAC issues if you haven't already...
Thanks to those offering help. This appears to be a permissions issue. I have updated my service to run under an Administrator account and it was able to successfully uninstall the third-party application. To Orion's point, though the Local System account is a powerful account that has full access to the system -- http://technet.microsoft.com/en-us/library/cc782435.aspx -- it doesn't seem to have the necessary rights to perform the uninstall.
[See additional comments for full story regarding the LocalSystem being able to uninstall application for which it installed.]
This is bizarre. LocalSystem definitely has the privileges to install applications (that's how Windows Update and software deployment in Active Directory work), so it should be able to uninstall as well.
Perhaps the application is initially installed per-user instead of per-machine?
#Paul Lalonde
The app's installer is wrapped within a custom InnoSetup Installer. The InnoSetup installer, in turn, is manually executed by the logged in user. That said, the uninstall is trigged by a service running under the Local System account.
Apparently, you were on to something. I put together a quick test which had the service running under the LocalSystem account install as well as uninstall the application and everything worked flawlessly. You were correct. The LocalSystem account has required uninstall permissions for applications in which it installs. You saved the day. Thanks for the feedback!