I'm running a program in command mode (behind the scene) and output its data to form window. When the I read specific line (i.e., "run failed") I try to close the program using this code:
if (line.Contains("run failed"))
Process[] runProc = Process.GetProcessesByName("abc");
if (runProc .Length == 1)
runProc [0].Kill();
In some computers it works fine, in others I receive: "Access Denied".
I understand it's concerned with the user privileges.
My question is how can I kill the process differently?
The process runs in tcl mode (don't know if it matters) and I see the last line in the form window output is:
abc%
(where abc is the program). Obviously, it shows the command prompt of the program.
If it was running in a command window, I would have typing in the command window:
'quit'
and the program would have ended and terminated.
How can I send a 'quit' to tcl if something went wrong?
The Tcl command to make the current process cease running is exit. By default it exits “successfully” with code 0; use exit 1 (or a larger number, numbers up to 127 are reasonably portable) to use a non-zero exit code indicate a failure.
It might be worthwhile converting the code that you run in the Tcl subprocess into a script so that termination on error happens automatically. It only doesn't do that when you're running interactively.
Related
I am writing a c# windows form project and when I stop the process this message is shown in the output terminal:
The program '[12460] TestProject.exe' has exited with code -1 (0xffffffff).
Though the app is running correctly, the -1 exit code seems unfamiliar. Please can anyone explain me what -1 exit code means? Could'nt wrap my head around it.
That's the expected behavior. If you click the "Stop" button in Visual Studio, that kills the application immediately and reports the return code as -1 (0xffffffff). If you want to terminate your application normally, click the "X" at the top right corner of the window (if it is a windowed application).
You can also use the "Debug->Detach" menu option to detach the debugger from the application without killing it.
I run an update process from my c# wpf program like this:
Process sql = Process.Start("sqlcmd.exe", param);
sql.WaitForExit(1200000);
The variable param is build from user input in the ui, here is a example:
sqlcmd.exe -S .\SQLEXPRESS -d mydatabase -v db_src = "db\file.bak" -i db\update.sql -o "\log\log_update.txt"
Now the black cmd window opens and runs for a while (1-5 minutes). On some machines the white curos blinks. What I want is that something like "Please wait... & " is printed on the cmd window.
I've tried different approaces but the sqlmd erases everything. Like putting a echo Please wait... in front of param.
Displaying something in the c# program is also difficult because while the process runs, the program is frozen. But if anyone knows a solution which makes it possible to display a message in the program this would also be fine.
Using .WaitForExit() blocks your current application thread. Instead you should just start the process in the background, and wait for the Exited event.
To quote MSDN - see the remarks:
WaitForExit() makes the current thread wait until the associated
process terminates. It should be called after all other methods are
called on the process. To avoid blocking the current thread, use the
Exited event.
If your thread isn't blocked you can write progress/status messages that'll actually appear.
Short explanation:
Starting a cmd.exe process from C# with an improper exe or com file as parameter opens an "Unsupported 16-Bit Application" window.
Any idea how to detect / suppress this window and report an error to the caller?
Longer explanation:
In porting our server application from VMS to .NET I wrote a VMS/DCL command interpreter as we need to support DCL command scripts and we are not allowed to touch the business layer which supports DCL scripts.
The DCL interpreter now also needs to call native programs and cmd.exe scipts.
For this, my DCL interpreter supports a "DCL" command which starts a cmd.exe process in a hidden window, redirects the input/output and/or passes a DCL parameter as script to cmd.exe.
Now, when a bad script file get's passed (ex. a DCL command file with a ".COM" extension), cmd.exe tries to start the file/program and launches a modal "Unsupported 16-Bit Application" window and this regardless of WindowStyle and CreateNoWindow.
As this runs on the server, I need to close/suppress the window and report an error back to my DCL.
My solution:
The only solution I could find till now was to check the MainWindowTitle of the launched process for "Unsupported 16-Bit Application", kill the process and report an error back to DCL.
But unfortunately as this runs in a separat process and DCL not necessarely needs to wait for the process to end, it's not defined at which point the title shows up and the check may be too early and fail.
Any ideas?
SetErrorMode is infact the solution and it's even a documented errorMode.
The following line of code disables the message box:
var oldMode = SetErrorMode(ErrorModes.SEM_FAILCRITICALERRORS);
The following line will set it back to the original value:
SetErrorMode(oldMode );
I just wrote a clever program called helloworld. It's a C#/.NET 4.5 console app. Deep within the twisted nested mazes of logic there's use of Console.WriteLine().
When I'm running this at a command line, it runs and I see the output. I can do other commands and mess around a bit, and later scroll up to see the output again.
Now I'm in Visual Studio, tweaking the source ("Hi" is more efficient than "Hello") and testing by tapping F5. What happens is a console window pops up and immediately vanishes. I have no idea what the program printed. How can I see the output?
I don't want to modify my source at all. After searching for solutions, I find some who say to use Console.ReadKey() - but then it would suck to be using the program at the command line. There's no real reason the user should have to tap a key when the program has already done its work. Even if i go with this, there's the problem of the output disappearing when the console window closes after a key tap.
I don't want to use Debug.WriteLine() which does write to the output window in VS, but doesn't write ordinary output for the end user to see.
I have discovered ctrl-F5, which runs the program as if it had a final Console.ReadKey() line, but there's still the problem of when I tap any key, all the output vanishes along with the window. Three minutes later, I'm thinking "Oh wait, did it print 'Hello' or 'Helo'?" No way to check.
Seems like the Visual Studio IDE should somehow capture all that a freshly built program writes to its stdout or the Microsoft equivalent thereof, and show it in its "Output" panel, or some panel, for later scrutiny. Maybe it does do this, and I don't yet know the trick to it? Seems like this would be a common desire among millions of C# developers.
If you're working on a .NET Core console application (or .NET Framework via the .NET SDK) using Visual Studio 2019, the behaviour of leaving the console window open after the program has executed will now happen by default:
Specifically:
This should prevent the need to add Console.Read() calls to console apps to prevent the console window from closing immediately after the program has finished executing. The launched console window is also re-used for subsequent runs, so if you’re used to using ctrl+f5, you won’t have lots of console windows to close after you’ve launched your application a few times.
The reason it closes automaticly is because it's done running the program. If you want to see what it did, make it need a new command like hitting any key. The Console.ReadKey(); pauses it and waits for a User to hit a key to continue. Put that command after the commands of instruction you are doing and it will pause it until you hit any key.
Console.ReadKey(); // Pauses until you hit any key
You can also run your program pressing F10 (executes one line by one), with F11 (goes inside a function).
The other option you have is to set breakpoints in Visual Studion and run the program by pressing F5 - it will stop at the next breakpoint. And the breakpoints can have conditions - i.e. conditional breakpoints.
Some options are:
1. wrap #if DEBUG around Console.ReadKey()
2. run directly from an open terminal
3. create a Test project - but again you'll need Console.ReadKey() to stop it closing.
I have a .Net windows C# application, fairly complete and working, that I have been asked to support calling it from another program like LabView. I have added the ability to parse command line arguments at startup so I can detect that it is supposed to behave like a console application and be provided with enough information to function.
What I would like to do is have the program print out to the console its results and have the calling program pipe it or just pull the data and use it.
The printing to the console works fine but when I start the program up, it tells the command prompt window that it is done (a new prompt immediately shows up and the command prompt is waiting for input). In the process it also closes the redirection that was part of the startup line. Is there anyway to keep it from telling the calling program that it has completed before it has actually finished?
The simple solution is to pass a file to save the data to but I would prefer not to have to do that. I could also do a separate version that is a console app, but that means supporting two separate programs.
Thanks
Instead of invoking the program directly, you can use cmd /c myapp.exe.