Despite all efforts of trying to capture all console out messages, I am experiencing a strange issue in which I have two console apps:

1. "DeviceController.exe" : a console app which communicates with a device through a C++ DLL using PInvoke
2. "ConsoleWrapper.exe" : from which I launch a Proccess pointing at the above app and try to log all of its output and error messages and of course send some inputs on its console input stream to control it. (In a nutshell it uses this ConsoleManagerApp class which starts the first app on a separate Process, sets redirection of input and output flags to true and pools asynchronously on its standard outputs and you can aslo write on the standard input of the process).

The issue is that if I directly launch "DeviceController.exe" then I get some useful console output messages from the PInvoked DLL along with my intended messages from the app. If instead I start it through "ConsoleWrapper.exe" then a very strange effect occurs: the messages from PInvoke DLL are somehow delayed. By this I mean that they seem to get lost but in reality they are all flushed at once when the process of "DriverController.exe" finishes or when I order a (kernel32).FreeLibrary() of the DLL to the "DeviceController.exe". It is as if the PInvoked DLL has a different console buffer from the one on my C# apps.

Does someone has an idea of why this happens and how to force flushing of those messages at the right time?

I have tried:

1. redirecting messages to a log file directly from "DeviceController.exe" using this method but all PInvoke messages get lost
2. using the above mentioned console app "ConsoleWrapper.exe" made using this method but discovered this strange effect

Other helpful but unanswered question I have found is:

• Getting stdout when p-invoking to unmanaged DLL? where the acknowledge that not all console messages can be caught.
• Redirect Console Output From DLL? which makes alot of sense in my case because to use the device I need to launch a new Thread which will be stuck in a "run" method. To finish communication with the device I need to call a "quit" method which will make "run" return thus ending the thread.