I have a DLL which does as plugin into the TS3 client.
The problem is, the plugin provokes a crash that I cannot seem to find in my code directly.
So my idea is to set the Console Output of the console windows in the background (-console option) to a file, because when the program crashes there is no way I can read the console output as the console disappears immediately.
Is there a way to set the output of a crashing console to a file?
Because so far, when using the stdout operator (ts3client_win64 -console > output.txt) it does not write anything to the file. (I assume it cannot close the file handle and loses all its data?) But I want to keep the console output when the crash occurs.
It also has to be said that I can not just run it with a batch file and a pause statement, because when starting the application it opens its own console window (and thats the one of which I want the output).
It is the type of crash one would get from failed (safe) string operations in C like strtok_s or strcpy_s.
Related
I am writing a service program which is expected to run in background. On Windows it will open a console window when run. I want it to go to background directly without that console window, so I used the -ldconf "-H=windowsgui" option, which worked as expected.
However, there is a catch. The program has a command line option -help, which output command line usage in the console. If I use -H=windowsgui, the help text is NOT printed even I start it in cmd.exe prompt.
It seems that the windowsgui option is not what I want. Is there anyway that the -help still works at commant line, and the console window will not persist if the program runs normally. I do not care if there is a console window pops up, provided that it disappears shortly without user intervention. i.e. I want a way on windows which is similar to the & operator on Linux.
P.S. if provided solution uses any other tools, I want that tool to be a Windows component, not any 3rd-party program. Thanks.
I am trying to control and read the output of a 3rd party console application, of which source code I cannot change.
I want to use QProcess for this, but this should not matter, as the issue is the same when just using cmd:
The 3rd party app seems to never call flush().
Therefore, directly calling it in cmd.exe works fine(Output appears in cmd window), but when calling e.g.
3rdPartyApp.exe > Output.txt
Output.txt stays empty until 3rdPartyApp.exe terminates or quits.
After 3rdPartyApp.exe quits or is terminated, all stdout can be found in Output.txt .
Question:
What can I do to create an environment where the buffer size of the pipe is limited, like when calling directly in cmd.exe, which seems to limit the buffer size to one line?
What you can do is create your own Console type application that will run 3rd party process and "handle" buffering of it.
Then instead redirecting output of 3rd party application, you simply redirect output of proxy console app.
How to do it? You can read it here: https://www.codeproject.com/Articles/16163/Real-Time-Console-Output-Redirection
The author provides explaination and ready to use Console app called RTConsole.exe.
I had big time issue to get unbuffered output from 3rd party pyhton executable spawned from my .NET app and this RTConsole.exe saved me.
If I have a code in C# .NET (winforms) which contains a Console.WriteLine("TEST"); and visual studio is attached to the process it doesn't write "TEST" in the output window.
(application is correctly attached)
If I start my program normal with visual studio, it works.
Why does it not work in the first case?
Visual Studio, when debugging windows programs (/target:winexe) will launch them with the stdout and stderr redirected to Named Pipes. The other end of the named pipe is owned by the VS debugger and anything read on these pipes (ie. anything written by the app to stdout or stderr) will be displayed in the Debug Output window (which by no means is the debugged application Output window).
When attach to an application, this redirect can no longer be done (obviously, since the application is already started and stderr and stdin cannot be redirected post-factum). So the Console.Write is no longer auto-magically redirected to the Debug output.
Note that this stdout/stderr redircetion does not occur for console programs (/target:exe)
But there is a dedicated API to write Debug info: Debug.Write. This uses the OutputDebugString functions, which sends text to the attached debugger (if any). This works no matter when or how the debugger is attached, as is not dependent upon stdout/stderr redirection tricks.
Replace your Console.Write with Debug.Write.
I have a Windows application application that is normally GUI-only and declares the WINDOWS subsystem. It doesn't open a console window when launched.
Alas, I would like to offer additional console output when the application happens to be started from console window (say, from interactive cmd.exe).
Is there a way of detecting if some process "up the chain" has an open console, and to attach to that console?
The closest I've found is a way to explicitly open a console for a gui application, but I don't want to open a console if there isn't one already there.
At first glance it seems like the AttachConsole() function will let you attach to the console of your parent process:
AttachConsole(ATTACH_PARENT_PROCESS);
If the process doesn't actually have a console the function will fail with ERROR_INVALID_HANDLE. The function will also fail if your parent process no longer exists. If it fails you can then call AllocConsole() to create your own.
I've never tried this so don't actually know if it will work or not :)
I am doing some debugging of a crash dump file using NTSD. Is it possible to redirect all the output that I am seeing on console now to a txt file? I am getting all the call stacks of all the threads however can't see that information in a debugger window.
Thanks
Look at the .logopen and .logclose commands. You should be able to do .logopen foo.txt, issue your command (which I'm assuming is ~*k), and then when it's done, do .logclose.