A pesar de todos los esfuerzos por tratar de capturar todos los mensajes de la consola, estoy experimentando un problema extraño en el que tengo dos aplicaciones de consola:

1. "DeviceController.exe": una aplicación de consola que se comunica con un dispositivo a través de una DLL de C++ usando PInvoke
2. "ConsoleWrapper.exe": desde donde ejecuto un proceso que apunta a la aplicación anterior e intento registrar todos sus mensajes de salida y error y, por supuesto, envío algunas entradas en su flujo de entrada de consola para controlarlo. (En pocas palabras, utiliza esta clase ConsoleManagerApp que inicia la primera aplicación en un proceso separado, establece la redirección de los indicadores de entrada y salida en verdadero y se agrupa de forma asíncrona en sus salidas estándar y también puede escribir en la entrada estándar del proceso).

El problema es que si ejecuto directamente "DeviceController.exe", recibo algunos mensajes útiles de salida de la consola de la DLL de PInvoked junto con mis mensajes previstos de la aplicación. Si, en cambio, lo inicio a través de "ConsoleWrapper.exe", se produce un efecto muy extraño: los mensajes de PInvoke DLL se retrasan de alguna manera. Con esto quiero decir que parecen perderse pero en realidad se vacían todos a la vez cuando finaliza el proceso de "DriverController.exe" o cuando ordeno un (kernel32).FreeLibrary() de la DLL al "DeviceController.exe ". Es como si la DLL de PInvoked tuviera un búfer de consola diferente al de mis aplicaciones de C#.

¿Alguien tiene una idea de por qué sucede esto y cómo forzar el lavado de esos mensajes en el momento adecuado?

Yo he tratado:

1. redirigir mensajes a un archivo de registro directamente desde "DeviceController.exe" usando este método pero todos los mensajes de PInvoke se pierden
2. usando la aplicación de consola mencionada anteriormente "ConsoleWrapper.exe" hecha con este método pero descubrió este extraño efecto

Otra pregunta útil pero sin respuesta que he encontrado es:

• ¿Obtener stdout al invocar p a DLL no administrado? donde el reconocimiento de que no todos los mensajes de la consola pueden ser capturados.
• ¿Redirigir la salida de la consola desde DLL? lo que tiene mucho sentido en mi caso porque para usar el dispositivo necesito iniciar un nuevo subproceso que se atascará en un método de "ejecutar". Para finalizar la comunicación con el dispositivo, necesito llamar a un método de "salir" que hará que "ejecutar" regrese, finalizando así el hilo.