Hi Mark,
Thanks for your post!
Barry points out the correct API. However, the solution to your problem is
much complex than I expected. GenerateConsoleCtrlEvent Win32 API has a
special limitation. From MSDN:
"Only those processes in the group that share the same console as the
calling process receive the signal."
While .Net Process class internally encapsulate CreateProcess Win32 API, if
you use windbg to set a breakpoint on KERNEL32!CreateProcessW, you will see
that the dwCreationFlags parameter is passed with 0x4000410 from .Net
Process class, which included CREATE_NEW_CONSOLE(0x10) flag. So the new
lauched process will be openned in a new console window, which does not
meet the GenerateConsoleCtrlEvent API requirement.
So if you use GenerateConsoleCtrlEvent API with Process class, you will
have no lucky.
The only way is p/invoke win32 CreateProcess API manually, and do not
specify CREATE_NEW_CONSOLE(0x10) flag. Then the new lauched process will
share the same console as the calling process.
I have written a little sample project to demonstrate this:
using System;
using System.Runtime.InteropServices;
using System.Diagnostics;
using System.Threading;
using System.Text;
namespace consoletest
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
///
[DllImport("Kernel32.dll")]
public static extern bool GenerateConsoleCtrlEvent(int dwCtrlEvent, int
dwProcessGroupId);
[StructLayout(LayoutKind.Sequential)]
internal class STARTUPINFO
{
public int cb;
public IntPtr lpReserved;
public IntPtr lpDesktop;
public IntPtr lpTitle;
public int dwX;
public int dwY;
public int dwXSize;
public int dwYSize;
public int dwXCountChars;
public int dwYCountChars;
public int dwFillAttribute;
public int dwFlags;
public short wShowWindow;
public short cbReserved2;
public IntPtr lpReserved2;
public IntPtr hStdInput;
public IntPtr hStdOutput;
public IntPtr hStdError;
}
[StructLayout(LayoutKind.Sequential)]
internal class PROCESS_INFORMATION
{
public IntPtr hProcess;
public IntPtr hThread;
public int dwProcessId;
public int dwThreadId;
}
[DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
public static extern bool CreateProcess(string lpApplicationName, string
lpCommandLine, IntPtr lpProcessAttributes, IntPtr lpThreadAttributes, bool
bInheritHandles, int dwCreationFlags, IntPtr lpEnvironment, string
lpCurrentDirectory, STARTUPINFO lpStartupInfo, PROCESS_INFORMATION
lpProcessInformation);
[STAThread]
static void Main(string[] args)
{
STARTUPINFO si =new STARTUPINFO();
si.cb=Marshal.SizeOf(si);
PROCESS_INFORMATION pi=new PROCESS_INFORMATION();
string szCmdLine="ping msjeff1 -t";
Console.WriteLine("Press any key to lauch the process \nand press again
to generate the Ctrl+C signal");
Console.ReadLine();
// Spawn the other processes as part of this Process Group
bool f = CreateProcess(null, szCmdLine, IntPtr.Zero, IntPtr.Zero, true,
0, IntPtr.Zero, null, si, pi);
Console.ReadLine();
bool fResult=GenerateConsoleCtrlEvent(0, 0);
if(!fResult)
{
Console.WriteLine("GenerateConsoleCtrlEvent failed with error
"+Marshal.GetLastWin32Error());
}
Console.ReadLine();
}
}
}
I ignored this limitation at first and wasted a lot of time in test :-(
Further more, there is another issue: since the WinDump.exe is lauched
invisible, you can not simply tell the lauch console application when to
exit by pressing any key. To resolve this problem, you need another
application to controll the stub console application that lauches the
WinDump.exe and use some inter-process communication to tell it to exit
with GenerateConsoleCtrlEvent. You may use .Net Remoting as the IPC
technology or any native Win32 technologies.
Jeffrey Richter has written an article targeting the above problems, you
may give it a good reading:
http://www.microsoft.com/msj/0698/win320698.aspx
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
