The .Exited is not working for all cases, for example: to C:\foo.png when I close the responsible application that show the image, I don't get the MessageBox.Show("exited!");
here's my code:
public static void TryOpenFile(string filename)
{
Process proc = new Process();
proc.StartInfo = new ProcessStartInfo(filename);
proc.EnableRaisingEvents = true;
proc.Exited += (a,b) => { MessageBox.Show("Exited!"); }
proc.Start();
}
how I call the function TryOpenFile(#"C:\foo.png");. How to fix this?
Is it possible that you already have your image editing program open? When you call proc.Start(), if the process is already running, then the existing process is reused. You should check the return value of proc.Start() to see if this is the case.
From MSDN:
Return Value
true if a process resource is started; false if no new
process resource is started (for example, if an existing process is
reused).
...
Remarks
...
If the process resource specified by the FileName member of the StartInfo property is
already running on the computer, no additional process resource is started. Instead, the
running process resource is reused and false is returned.
Related
I am using System.Diagnostics in c#. My problem is I am using code for starting and killing the process in c# and it's working fine. But my question is my process id is changing in-between while running the process. Is that possible. If yes then how can I get the actual process id which I want to kill. I can't do it by name because I have multiple instance are running on different at a time and I want to kill only single instance on started port.
My code is :
Process p2 = new Process();
ProcessStartInfo processStartInfo2 =
new ProcessStartInfo(
unitoolLauncherExePath,
"options --port " + port);
p2.StartInfo = processStartInfo2;
p2.Start();
System.Threading.Thread.Sleep(1000);
int processId = p2.Id;
Now it will return something like 14823 and when I am trying to kill it it's changed.
Process[] _proceses = null;
_proceses = Process.GetProcessesByName("UNIToolAPIServer");
foreach (Process proces in _proceses)
{
if (proces.Id == processId)
{
proces.Kill();
}
}
But here nothing is killed because no process with the above id is fetched.
No, the process id of a running process does not change while it is running.
If there is no process to kill with the process id of the process you started, it means either of two things:
The process has already exited before you obtain the process list.
The name of the process is not "UNIToolAPIServer".
If you want to kill the created process you should keep the process-object and call the kill method on it. There should be no need to go thru all the processes in the system to find the started process. For example:
public class MyProcess{
private Process myProcess;
...
public void Start(){
myProcess = new Process();
var processStartInfo2 = new ProcessStartInfo(
unitoolLauncherExePath,
"options --port " + port);
myProcess.StartInfo = processStartInfo2;
myProcess.Start();
}
public void Kill(){
if(myProcess != null && !myProcess.HasExited){
myProcess.Kill();
}
}
}
I have a .NET Core 2.1 service which runs on an Ubuntu 18.04 VM and calls Tesseract OCR 4.00 via a Process instance. I would like to use an API wrapper, but I could only find one available and it is only in beta for the latest version of Tesseract -- the stable wrapper uses version 3 instead of 4. In the past, this service worked well enough, but I have been changing it so that document/image data is written and read from disk less frequently in an attempt to improve speed. The service used to call many more external processes (such as ImageMagick) which were unnecessary due to the presence of an API, so I have been replacing those with API calls.
Recently I've been testing this with a sample file taken from real data. It's a faxed document PDF that has 133 pages, but is only 5.8 MB in spite of that due to grayscale and resolution. The service takes a document, splits it into individual pages, then assigns multiple threads (one thread per page) to call Tesseract and process them using Parallel.For. The thread limits are configurable. I am aware that Tesseract has its own multithreading environment variable (OMP_THREAD_LIMIT). I found in prior testing that setting it to "1" is ideal for our set up at the moment, but in my recent testing for this issue I have tried leaving it unset (dynamic value) with no improvement.
The issue is that unpredictably, when Tesseract is called, the service will hang for about a minute and then crash, with the only error showing in journalctl being:
dotnet[32328]: Error while reaping child. errno = 10
dotnet[32328]: at System.Environment.FailFast(System.String, System.Exception)
dotnet[32328]: at System.Environment.FailFast(System.String)
dotnet[32328]: at System.Diagnostics.ProcessWaitState.TryReapChild()
dotnet[32328]: at System.Diagnostics.ProcessWaitState.CheckChildren(Boolean)
dotnet[32328]: at System.Diagnostics.Process.OnSigChild(Boolean)
I can't find anything at all online for this particular error. It would seem to me, based on related research I've done on the Process class, that this is occurring when the process is exiting and dotnet is trying to clean up the resources it was using. I'm really at a loss as to how to even approach this problem, although I have tried a number of "guesses" such as changing thread limit values. There is no cross-over between threads. Each thread has its own partition of pages (based on how Parallel.For partitions a collection) and it sets to work on those pages, one at a time.
Here is the process call, called from within multiple threads (8 is the limit we normally set):
private bool ProcessOcrPage(IMagickImage page, int pageNumber, object instanceId)
{
var inputPageImagePath = Path.Combine(_fileOps.GetThreadWorkingDirectory(instanceId), $"ocrIn_{pageNumber}.{page.Format.ToString().ToLower()}");
string outputPageFilePathWithoutExt = Path.Combine(_fileOps.GetThreadOutputDirectory(instanceId),
$"pg_{pageNumber.ToString().PadLeft(3, '0')}");
page.Write(inputPageImagePath);
var cmdArgs = $"-l eng \"{inputPageImagePath}\" \"{outputPageFilePathWithoutExt}\" pdf";
bool success;
_logger.LogStatement($"[Thread {instanceId}] Executing the following command:{Environment.NewLine}tesseract {cmdArgs}", LogLevel.Debug);
var psi = new ProcessStartInfo("tesseract", cmdArgs)
{
RedirectStandardError = true,
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true
};
// 0 is not the default value for this environment variable. It should remain unset if there
// is no config value, as it is determined dynamically by default within OpenMP.
if (_processorConfig.TesseractThreadLimit > 0)
psi.EnvironmentVariables.Add("OMP_THREAD_LIMIT", _processorConfig.TesseractThreadLimit.ToString());
using (var p = new Process() { StartInfo = psi })
{
string standardErr, standardOut;
int exitCode;
p.Start();
standardOut = p.StandardOutput.ReadToEnd();
standardErr = p.StandardError.ReadToEnd();
p.WaitForExit();
exitCode = p.ExitCode;
if (!string.IsNullOrEmpty(standardOut))
_logger.LogStatement($"Tesseract stdOut:\n{standardOut}", LogLevel.Debug, nameof(ProcessOcrPage));
if (!string.IsNullOrEmpty(standardErr))
_logger.LogStatement($"Tesseract stdErr:\n{standardErr}", LogLevel.Debug, nameof(ProcessOcrPage));
success = p.ExitCode == 0;
}
return success;
}
EDIT 4: After much testing and discussion with Clint in chat, here is what we learned. The error is raised from a Process event "OnSigChild," that much is obvious from the stack trace, but there is no way to hook into the same event that raises this error. The process never times out given a timeout of 10 seconds (Tesseract typically only takes a few seconds to process a given page). Curiously, if the process timeout is removed and I wait on the standard output and error streams to close, it will hang for a good 20-30 seconds, but the process does not appear in ps auxf during this hang time. From the best that I can tell, Linux is able to determine that the process is done executing, but .NET is not. Otherwise, the error seems to be raised at the very moment that the process is done executing.
The most baffling thing to me is still that the process handling part of the code really hasn't changed very much compared to the working version of this code we have in production. This suggests that it's an error I made somewhere, but I am simply unable to find it. I think I will have to open up an issue on the dotnet GitHub tracker.
"Error while reaping child"
Processes hold up some resources in the kernel, On Unix, when the parent dies, it is the init process that is responsible for cleaning up the kernel resources both Zombine and Orphan process (aka reaping the child). .NET Core reaps child processes as soon as they terminate.
"I have discovered that removing the stdout and stderr stream ReadToEnd
calls causes the processes to end immediately instead of hang, with
the same error"
The error is due to the fact that you are prematurely calling p.ExitCode even before the process has finished and with the ReadToEnd you are just delaying this activity
Summary of updated code
StartInfo.FileName should point to a filename that you want to start
UseShellExecute to false if the process should be created directly from the executable file and true if you intend that shell should be used when starting the process;
Added asynchrnous read operations to standard ouput and error streams
AutoResetEvents to signal when the output and error when the operations complete
Process.Close() to release the resources
It is easier to set and use ArgumentList over Arguments property
Redhat Blog on NetProcess on Linux
Revised Module
private bool ProcessOcrPage(IMagickImage page, int pageNumber, object instanceId)
{
StringBuilder output = new StringBuilder();
StringBuilder error = new StringBuilder();
int exitCode;
var inputPageImagePath = Path.Combine(_fileOps.GetThreadWorkingDirectory(instanceId), $"ocrIn_{pageNumber}.{page.Format.ToString().ToLower()}");
string outputPageFilePathWithoutExt = Path.Combine(_fileOps.GetThreadOutputDirectory(instanceId),
$"pg_{pageNumber.ToString().PadLeft(3, '0')}");
page.Write(inputPageImagePath);
var cmdArgs = $"-l eng \"{inputPageImagePath}\" \"{outputPageFilePathWithoutExt}\" pdf";
bool success;
_logger.LogStatement($"[Thread {instanceId}] Executing the following command:{Environment.NewLine}tesseract {cmdArgs}", LogLevel.Debug);
using (var outputWaitHandle = new AutoResetEvent(false))
using (var errorWaitHandle = new AutoResetEvent(false))
{
try
{
using (var process = new Process())
{
process.StartInfo = new ProcessStartInfo
{
WindowStyle = ProcessWindowStyle.Hidden,
FileName = "tesseract.exe", // Verify if this is indeed the process that you want to start ?
RedirectStandardOutput = true,
RedirectStandardError = true,
UseShellExecute = false,
CreateNoWindow = true,
Arguments = cmdArgs,
WorkingDirectory = Path.GetDirectoryName(path)
};
if (_processorConfig.TesseractThreadLimit > 0)
process.StartInfo.EnvironmentVariables.Add("OMP_THREAD_LIMIT", _processorConfig.TesseractThreadLimit.ToString());
process.OutputDataReceived += (sender, e) =>
{
if (e.Data == null)
{
outputWaitHandle.Set();
}
else
{
output.AppendLine(e.Data);
}
};
process.ErrorDataReceived += (sender, e) =>
{
if (e.Data == null)
{
errorWaitHandle.Set();
}
else
{
error.AppendLine(e.Data);
}
};
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
if (!outputWaitHandle.WaitOne(ProcessTimeOutMiliseconds) && !errorWaitHandle.WaitOne(ProcessTimeOutMiliseconds) && !process.WaitForExit(ProcessTimeOutMiliseconds))
{
//To cancel the read operation if the process is stil reading after the timeout this will prevent ObjectDisposeException
process.CancelOutputRead();
process.CancelErrorRead();
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine("Timed Out");
//To release allocated resource for the Process
process.Close();
//Timed out
return false;
}
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Completed On Time");
exitCode = process.ExitCode;
if (!string.IsNullOrEmpty(standardOut))
_logger.LogStatement($"Tesseract stdOut:\n{standardOut}", LogLevel.Debug, nameof(ProcessOcrPage));
if (!string.IsNullOrEmpty(standardErr))
_logger.LogStatement($"Tesseract stdErr:\n{standardErr}", LogLevel.Debug, nameof(ProcessOcrPage));
process.Close();
return exitCode == 0 ? true : false;
}
}
Catch
{
//Handle Exception
}
}
}
In my web application I use wkhtmltopdf to process reports to output them as a PDF. I have a few functions that compile some HTML together, some headers etc. and then pass this information to wkhtmltopdf to compile the PDF and serve it to the user.
Something like:
public JsonResult BuildPDF(string one, string two, SomeData[] data, SomeList[] {
lock(PDFLock) {
// ... Code here to compile HTML and save to files
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = #"C:\inetpub\wwwroot\MySite\wkhtmltopdf.exe";
psi.UseShellExecute = true;
psi.Verb = "runas";
...
Process p = Process.Start(psi);
p.WaitForExit();
}
}
After the PDF is compiled I push it to the user then delete the file.
As you can see I have a lock around this function to prevent two attempts at processing a PDF at one time. On IIS Express this function behaves as I would expect: if two requests are made at the exact same time, the request that makes it in first will be processed, and the 2nd request will sit and wait on the lock until the first request is complete.
In release IIS, it appears to be ignoring this lock, and does not wait for the first request to be finished. It actually ends up skipping through the function so quickly that the first request is still running while the 2nd request completes (unsuccessfully), so the user receives a message that the request failed.
I am unsure why it would ignore this lock, or why it would work in debug (IIS Express).
Is there any possibility this is due to IIS's configuration?
Edit:
The issue with lock was a problem of multiple worker processes in IIS. I am testing Mutex again now with multiple processes.
Edit:
Mutex usage: the Mutex is declared in the class as private static Mutex mut = new Mutex();
public JsonResult BuildPDF(string one, string two, SomeData[] data, SomeList[] {
mut.WaitOne();
// ... Code here to compile HTML and save to files
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = #"C:\inetpub\wwwroot\MySite\wkhtmltopdf.exe";
psi.UseShellExecute = true;
psi.Verb = "runas";
...
Process p = Process.Start(psi);
p.WaitForExit();
//... Return some JSON to user
}
Then inside the Download method:
public virtual void Download() {
// ... Response headers and stuff
Response.TransmitFile(#"C:\inetpub\wwwroot\MySite\temppdfs\pdfout.pdf");
Response.End();
System.IO.File.Delete(#"C:\inetpub\wwwroot\MySite\temppdfs\pdfout.pdf");
mut.ReleaseMutex();
}
My understanding was a bit off on lock and Mutex usage.
The reason lock was not working is my application pool in IIS had multiple worker processes allowed (4), so the lock could not work cross-process.
I was using the Mutex improperly by declaring it outside the functions, now the proper usage of Mutex in my case (release IIS with multiple processes in the application pool):
public JsonResult BuildPDF(string one, string two, SomeData[] data, SomeList[] {
Mutex mut = new Mutex(false, #"Global\PDFMutex");
mut.WaitOne();
// ... Code here to compile HTML and save to files
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = #"C:\inetpub\wwwroot\MySite\wkhtmltopdf.exe";
psi.UseShellExecute = true;
psi.Verb = "runas";
...
Process p = Process.Start(psi);
p.WaitForExit();
mut.ReleaseMutex();
//... Return some JSON to user
}
This usage of Mutex appears to be successful across multiple processes and multiple functions.
I'm writing an application to check the exit code of another application. The application I am monitoring may already be running so I'm checking for it with Process.GetProcessesByName. If it exists I'm checking the exit code after a call to WaitForExit but when I do I get an exception:
"Process was not started by this object, so requested information cannot be determined."
If I start the process (if it isn't already running) then it doesn't give me the exception.
(Windows 8.1)
So how do I find out what the ExitCode was when I haven't started the process? The only option I can think of is to write an output code to a text file on exit and read that in...
System.Diagnostics.Process exposes events that you can access after setting EnableRaisingEvents to true:
int processId = 0; // TODO: populate this variable
var proc = System.Diagnostics.Process.GetProcessById(processId);
proc.EnableRaisingEvents = true;
proc.Exited += ProcessEnded;
Event handler:
private void ProcessEnded(object sender, EventArgs e)
{
var process = sender as Process;
if (process != null)
{
var test = process.ExitCode;
}
}
variable test now contains the exit code.
Tested on Windows 8.1
As is asked in this post, there are two ways to call another process in C#.
Process.Start("hello");
And
Process p = new Process();
p.StartInfo.FileName = "hello.exe";
p.Start();
p.WaitForExit();
Q1 : What are the pros/cons of each approach?
Q2 : How to check if error happens with the Process.Start() method?
With the first method you might not be able to use WaitForExit, as the method returns null if the process is already running.
How you check if a new process was started differs between the methods. The first one returns a Process object or null:
Process p = Process.Start("hello");
if (p != null) {
// A new process was started
// Here it's possible to wait for it to end:
p.WaitForExit();
} else {
// The process was already running
}
The second one returns a bool:
Process p = new Process();
p.StartInfo.FileName = "hello.exe";
bool s = p.Start();
if (s) {
// A new process was started
} else {
// The process was already running
}
p.WaitForExit();
For simple cases, the advantage is mainly convenience. Obviously you have more options (working path, choosing between shell-exec, etc) with the ProcessStartInfo route, but there is also a Process.Start(ProcessStartInfo) static method.
Re checking for errors; Process.Start returns the Process object, so you can wait for exit and check the error code if you need. If you want to capture stderr, you probably want either of the ProcessStartInfo approaches.
Very little difference. The static method returns a process object, so you can still use the "p.WaitForExit()" etc - using the method where you create a new process it would be easier to modify the process parameters (processor affinity and such) before launching the process.
Other than that - no difference. A new process object is created both ways.
In your second example - that is identical to this:
Process p = Process.Start("hello.exe");
p.WaitForExit();