Tuer le processus enfant lorsque le processus parent est tué

Je crée de nouveaux processus en utilisant la System.Diagnostics.Processclasse de mon application.

Je veux que ces processus soient tués quand / si mon application s'est plantée. Mais si je tue mon application à partir du Gestionnaire des tâches, les processus enfants ne sont pas tués.

Existe-t-il un moyen de rendre les processus enfants dépendants du processus parent?

De ce forum , crédit à «Josh».

Application.Quit()et Process.Kill()sont des solutions possibles, mais se sont avérées peu fiables. Lorsque votre application principale meurt, les processus enfants sont toujours en cours d'exécution. Ce que nous voulons vraiment, c'est que les processus enfants meurent dès que le processus principal meurt.

La solution consiste à utiliser des "objets de travail" http://msdn.microsoft.com/en-us/library/ms682409(VS.85).aspx .

L'idée est de créer un "objet de travail" pour votre application principale et d'enregistrer vos processus enfants avec l'objet de travail. Si le processus principal meurt, le système d'exploitation se chargera de mettre fin aux processus enfants.

public enum JobObjectInfoType
{
    AssociateCompletionPortInformation = 7,
    BasicLimitInformation = 2,
    BasicUIRestrictions = 4,
    EndOfJobTimeInformation = 6,
    ExtendedLimitInformation = 9,
    SecurityLimitInformation = 5,
    GroupInformation = 11
}

[StructLayout(LayoutKind.Sequential)]
public struct SECURITY_ATTRIBUTES
{
    public int nLength;
    public IntPtr lpSecurityDescriptor;
    public int bInheritHandle;
}

[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_BASIC_LIMIT_INFORMATION
{
    public Int64 PerProcessUserTimeLimit;
    public Int64 PerJobUserTimeLimit;
    public Int16 LimitFlags;
    public UInt32 MinimumWorkingSetSize;
    public UInt32 MaximumWorkingSetSize;
    public Int16 ActiveProcessLimit;
    public Int64 Affinity;
    public Int16 PriorityClass;
    public Int16 SchedulingClass;
}

[StructLayout(LayoutKind.Sequential)]
struct IO_COUNTERS
{
    public UInt64 ReadOperationCount;
    public UInt64 WriteOperationCount;
    public UInt64 OtherOperationCount;
    public UInt64 ReadTransferCount;
    public UInt64 WriteTransferCount;
    public UInt64 OtherTransferCount;
}

[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_EXTENDED_LIMIT_INFORMATION
{
    public JOBOBJECT_BASIC_LIMIT_INFORMATION BasicLimitInformation;
    public IO_COUNTERS IoInfo;
    public UInt32 ProcessMemoryLimit;
    public UInt32 JobMemoryLimit;
    public UInt32 PeakProcessMemoryUsed;
    public UInt32 PeakJobMemoryUsed;
}

public class Job : IDisposable
{
    [DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
    static extern IntPtr CreateJobObject(object a, string lpName);

    [DllImport("kernel32.dll")]
    static extern bool SetInformationJobObject(IntPtr hJob, JobObjectInfoType infoType, IntPtr lpJobObjectInfo, uint cbJobObjectInfoLength);

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern bool AssignProcessToJobObject(IntPtr job, IntPtr process);

    private IntPtr m_handle;
    private bool m_disposed = false;

    public Job()
    {
        m_handle = CreateJobObject(null, null);

        JOBOBJECT_BASIC_LIMIT_INFORMATION info = new JOBOBJECT_BASIC_LIMIT_INFORMATION();
        info.LimitFlags = 0x2000;

        JOBOBJECT_EXTENDED_LIMIT_INFORMATION extendedInfo = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION();
        extendedInfo.BasicLimitInformation = info;

        int length = Marshal.SizeOf(typeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION));
        IntPtr extendedInfoPtr = Marshal.AllocHGlobal(length);
        Marshal.StructureToPtr(extendedInfo, extendedInfoPtr, false);

        if (!SetInformationJobObject(m_handle, JobObjectInfoType.ExtendedLimitInformation, extendedInfoPtr, (uint)length))
            throw new Exception(string.Format("Unable to set information.  Error: {0}", Marshal.GetLastWin32Error()));
    }

    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    #endregion

    private void Dispose(bool disposing)
    {
        if (m_disposed)
            return;

        if (disposing) {}

        Close();
        m_disposed = true;
    }

    public void Close()
    {
        Win32.CloseHandle(m_handle);
        m_handle = IntPtr.Zero;
    }

    public bool AddProcess(IntPtr handle)
    {
        return AssignProcessToJobObject(m_handle, handle);
    }

}

En regardant le constructeur ...

JOBOBJECT_BASIC_LIMIT_INFORMATION info = new JOBOBJECT_BASIC_LIMIT_INFORMATION();
info.LimitFlags = 0x2000;

La clé ici est de configurer correctement l'objet de travail. Dans le constructeur, je mets les "limites" à 0x2000, qui est la valeur numérique de JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE.

MSDN définit cet indicateur comme:

Provoque l'arrêt de tous les processus associés au travail lorsque le dernier descripteur du travail est fermé.

Une fois cette classe configurée ... il vous suffit d'enregistrer chaque processus enfant avec le travail. Par exemple:

[DllImport("user32.dll", SetLastError = true)]
public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

Excel.Application app = new Excel.ApplicationClass();

uint pid = 0;
Win32.GetWindowThreadProcessId(new IntPtr(app.Hwnd), out pid);
 job.AddProcess(Process.GetProcessById((int)pid).Handle);

Cette réponse a commencé par l'excellente réponse de @Matt Howells et d'autres (voir les liens dans le code ci-dessous). Améliorations:

• Prend en charge 32 bits et 64 bits.
• Corrige quelques problèmes dans la réponse de @Matt Howells:
  1. La petite fuite de mémoire de extendedInfoPtr
  2. L'erreur de compilation 'Win32', et
  3. Une exception de pile déséquilibrée que j'ai reçue lors de l'appel CreateJobObject(à l'aide de Windows 10, Visual Studio 2015, 32 bits).
• Nomme le Job, donc si vous utilisez SysInternals, par exemple, vous pouvez le trouver facilement.
• A une API un peu plus simple et moins de code.

Voici comment utiliser ce code:

// Get a Process object somehow.
Process process = Process.Start(exePath, args);
// Add the Process to ChildProcessTracker.
ChildProcessTracker.AddProcess(process);

Pour prendre en charge Windows 7, il faut:

• Un simple changement app.manifest comme le décrit @adam smith .
• Paramètres de registre à ajouter si vous utilisez Visual Studio.

Dans mon cas, je n'avais pas besoin de prendre en charge Windows 7, j'ai donc une simple vérification en haut du constructeur statique ci-dessous.

/// <summary>
/// Allows processes to be automatically killed if this parent process unexpectedly quits.
/// This feature requires Windows 8 or greater. On Windows 7, nothing is done.</summary>
/// <remarks>References:
///  https://stackoverflow.com/a/4657392/386091
///  https://stackoverflow.com/a/9164742/386091 </remarks>
public static class ChildProcessTracker
{
    /// <summary>
    /// Add the process to be tracked. If our current process is killed, the child processes
    /// that we are tracking will be automatically killed, too. If the child process terminates
    /// first, that's fine, too.</summary>
    /// <param name="process"></param>
    public static void AddProcess(Process process)
    {
        if (s_jobHandle != IntPtr.Zero)
        {
            bool success = AssignProcessToJobObject(s_jobHandle, process.Handle);
            if (!success && !process.HasExited)
                throw new Win32Exception();
        }
    }

    static ChildProcessTracker()
    {
        // This feature requires Windows 8 or later. To support Windows 7 requires
        //  registry settings to be added if you are using Visual Studio plus an
        //  app.manifest change.
        //  https://stackoverflow.com/a/4232259/386091
        //  https://stackoverflow.com/a/9507862/386091
        if (Environment.OSVersion.Version < new Version(6, 2))
            return;

        // The job name is optional (and can be null) but it helps with diagnostics.
        //  If it's not null, it has to be unique. Use SysInternals' Handle command-line
        //  utility: handle -a ChildProcessTracker
        string jobName = "ChildProcessTracker" + Process.GetCurrentProcess().Id;
        s_jobHandle = CreateJobObject(IntPtr.Zero, jobName);

        var info = new JOBOBJECT_BASIC_LIMIT_INFORMATION();

        // This is the key flag. When our process is killed, Windows will automatically
        //  close the job handle, and when that happens, we want the child processes to
        //  be killed, too.
        info.LimitFlags = JOBOBJECTLIMIT.JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE;

        var extendedInfo = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION();
        extendedInfo.BasicLimitInformation = info;

        int length = Marshal.SizeOf(typeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION));
        IntPtr extendedInfoPtr = Marshal.AllocHGlobal(length);
        try
        {
            Marshal.StructureToPtr(extendedInfo, extendedInfoPtr, false);

            if (!SetInformationJobObject(s_jobHandle, JobObjectInfoType.ExtendedLimitInformation,
                extendedInfoPtr, (uint)length))
            {
                throw new Win32Exception();
            }
        }
        finally
        {
            Marshal.FreeHGlobal(extendedInfoPtr);
        }
    }

    [DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
    static extern IntPtr CreateJobObject(IntPtr lpJobAttributes, string name);

    [DllImport("kernel32.dll")]
    static extern bool SetInformationJobObject(IntPtr job, JobObjectInfoType infoType,
        IntPtr lpJobObjectInfo, uint cbJobObjectInfoLength);

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern bool AssignProcessToJobObject(IntPtr job, IntPtr process);

    // Windows will automatically close any open job handles when our process terminates.
    //  This can be verified by using SysInternals' Handle utility. When the job handle
    //  is closed, the child processes will be killed.
    private static readonly IntPtr s_jobHandle;
}

public enum JobObjectInfoType
{
    AssociateCompletionPortInformation = 7,
    BasicLimitInformation = 2,
    BasicUIRestrictions = 4,
    EndOfJobTimeInformation = 6,
    ExtendedLimitInformation = 9,
    SecurityLimitInformation = 5,
    GroupInformation = 11
}

[StructLayout(LayoutKind.Sequential)]
public struct JOBOBJECT_BASIC_LIMIT_INFORMATION
{
    public Int64 PerProcessUserTimeLimit;
    public Int64 PerJobUserTimeLimit;
    public JOBOBJECTLIMIT LimitFlags;
    public UIntPtr MinimumWorkingSetSize;
    public UIntPtr MaximumWorkingSetSize;
    public UInt32 ActiveProcessLimit;
    public Int64 Affinity;
    public UInt32 PriorityClass;
    public UInt32 SchedulingClass;
}

[Flags]
public enum JOBOBJECTLIMIT : uint
{
    JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE = 0x2000
}

[StructLayout(LayoutKind.Sequential)]
public struct IO_COUNTERS
{
    public UInt64 ReadOperationCount;
    public UInt64 WriteOperationCount;
    public UInt64 OtherOperationCount;
    public UInt64 ReadTransferCount;
    public UInt64 WriteTransferCount;
    public UInt64 OtherTransferCount;
}

[StructLayout(LayoutKind.Sequential)]
public struct JOBOBJECT_EXTENDED_LIMIT_INFORMATION
{
    public JOBOBJECT_BASIC_LIMIT_INFORMATION BasicLimitInformation;
    public IO_COUNTERS IoInfo;
    public UIntPtr ProcessMemoryLimit;
    public UIntPtr JobMemoryLimit;
    public UIntPtr PeakProcessMemoryUsed;
    public UIntPtr PeakJobMemoryUsed;
}

J'ai soigneusement testé les versions 32 bits et 64 bits des structures en comparant par programmation les versions gérées et natives les unes aux autres (la taille globale ainsi que les décalages pour chaque membre).

J'ai testé ce code sur Windows 7, 8 et 10.

Cet article est conçu comme une extension de la réponse de @Matt Howells, en particulier pour ceux qui rencontrent des problèmes avec l'utilisation des objets de travail sous Vista ou Win7 , en particulier si vous obtenez une erreur d'accès refusé ('5') lors de l'appel à AssignProcessToJobObject.

tl; dr

Pour garantir la compatibilité avec Vista et Win7, ajoutez le manifeste suivant au processus parent .NET:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <v3:trustInfo xmlns:v3="urn:schemas-microsoft-com:asm.v3">
    <v3:security>
      <v3:requestedPrivileges>
        <v3:requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </v3:requestedPrivileges>
    </v3:security>
  </v3:trustInfo>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <!-- We specify these, in addition to the UAC above, so we avoid Program Compatibility Assistant in Vista and Win7 -->
    <!-- We try to avoid PCA so we can use Windows Job Objects -->
    <!-- See https://stackoverflow.com/questions/3342941/kill-child-process-when-parent-process-is-killed -->

    <application>
      <!--The ID below indicates application support for Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
      <!--The ID below indicates application support for Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    </application>
  </compatibility>
</assembly>

Notez que lorsque vous ajoutez un nouveau manifeste dans Visual Studio 2012, il contient déjà l'extrait de code ci-dessus, vous n'avez donc pas besoin de le copier à partir de hear. Il comprendra également un nœud pour Windows 8.

explication complète

Votre association de travail échouera avec une erreur d'accès refusé si le processus que vous démarrez est déjà associé à un autre travail. Entrez l'assistant de compatibilité des programmes, qui, à partir de Windows Vista, attribuera toutes sortes de processus à ses propres travaux.

Dans Vista, vous pouvez marquer votre application comme étant exclue de PCA en incluant simplement un manifeste d'application. Visual Studio semble faire cela automatiquement pour les applications .NET, donc tout va bien.

Un simple manifeste ne le coupe plus dans Win7. [1] Là, vous devez spécifier spécifiquement que vous êtes compatible avec Win7 avec la balise dans votre manifeste. [2]

Cela m'a amené à m'inquiéter pour Windows 8. Dois-je à nouveau changer mon manifeste? Apparemment, il y a une rupture dans les nuages, car Windows 8 permet désormais à un processus d'appartenir à plusieurs tâches. [3] Je ne l'ai donc pas encore testé, mais j'imagine que cette folie sera terminée maintenant si vous incluez simplement un manifeste avec les informations prises en charge par OS.

Astuce 1 : Si vous développez une application .NET avec Visual Studio, comme je l'étais, voici [4] quelques instructions intéressantes sur la façon de personnaliser votre manifeste d'application.

Astuce 2 : Soyez prudent lorsque vous lancez votre application à partir de Visual Studio. J'ai constaté qu'après avoir ajouté le manifeste approprié, j'avais toujours des problèmes avec PCA lors du lancement à partir de Visual Studio, même si j'utilisais Démarrer sans débogage. Le lancement de mon application depuis Explorer a cependant fonctionné. Après avoir ajouté manuellement devenv pour l'exclusion de PCA à l'aide du registre, le démarrage des applications utilisant des objets de travail de VS a également commencé à fonctionner. [5]

Astuce 3 : Si vous voulez savoir si PCA est votre problème, essayez de lancer votre application à partir de la ligne de commande ou copiez le programme sur un lecteur réseau et exécutez-le à partir de là. PCA est automatiquement désactivé dans ces contextes.

[1] http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an -installer-take-2-car-we-change-the-rules-on-you.aspx

[2] http://ayende.com/blog/4360/how-to-opt-out-of-program-compatibility-assistant

[3] http://msdn.microsoft.com/en-us/library/windows/desktop/ms681949(v=vs.85).aspx : "Un processus peut être associé à plus d'un travail dans Windows 8"

[4] Comment puis-je intégrer un manifeste d'application dans une application à l'aide de VS2008?

[5] Comment arrêter le débogueur Visual Studio en démarrant mon processus dans un objet de travail?

Voici une alternative qui peut fonctionner pour certains lorsque vous contrôlez le code exécuté par le processus enfant. L'avantage de cette approche est qu'elle ne nécessite aucun appel Windows natif.

L'idée de base est de rediriger l'entrée standard de l'enfant vers un flux dont l'autre extrémité est connectée au parent, et d'utiliser ce flux pour détecter quand le parent est parti. Lorsque vous utilisez System.Diagnostics.Processpour démarrer l'enfant, il est facile de s'assurer que son entrée standard est redirigée:

Process childProcess = new Process();
childProcess.StartInfo = new ProcessStartInfo("pathToConsoleModeApp.exe");
childProcess.StartInfo.RedirectStandardInput = true;

childProcess.StartInfo.CreateNoWindow = true; // no sense showing an empty black console window which the user can't input into

Et puis, sur le processus enfant, profitez du fait que Reads du flux d'entrée standard retournera toujours avec au moins 1 octet jusqu'à ce que le flux soit fermé, quand ils commenceront à renvoyer 0 octet. Un aperçu de la façon dont j'ai fini par le faire est ci-dessous; my way utilise également une pompe de message pour garder le fil principal disponible pour des choses autres que regarder la norme, mais cette approche générale pourrait également être utilisée sans pompes de message.

using System;
using System.IO;
using System.Threading;
using System.Windows.Forms;

static int Main()
{
    Application.Run(new MyApplicationContext());
    return 0;
}

public class MyApplicationContext : ApplicationContext
{
    private SynchronizationContext _mainThreadMessageQueue = null;
    private Stream _stdInput;

    public MyApplicationContext()
    {
        _stdInput = Console.OpenStandardInput();

        // feel free to use a better way to post to the message loop from here if you know one ;)    
        System.Windows.Forms.Timer handoffToMessageLoopTimer = new System.Windows.Forms.Timer();
        handoffToMessageLoopTimer.Interval = 1;
        handoffToMessageLoopTimer.Tick += new EventHandler((obj, eArgs) => { PostMessageLoopInitialization(handoffToMessageLoopTimer); });
        handoffToMessageLoopTimer.Start();
    }

    private void PostMessageLoopInitialization(System.Windows.Forms.Timer t)
    {
        if (_mainThreadMessageQueue == null)
        {
            t.Stop();
            _mainThreadMessageQueue = SynchronizationContext.Current;
        }

        // constantly monitor standard input on a background thread that will
        // signal the main thread when stuff happens.
        BeginMonitoringStdIn(null);

        // start up your application's real work here
    }

    private void BeginMonitoringStdIn(object state)
    {
        if (SynchronizationContext.Current == _mainThreadMessageQueue)
        {
            // we're already running on the main thread - proceed.
            var buffer = new byte[128];

            _stdInput.BeginRead(buffer, 0, buffer.Length, (asyncResult) =>
                {
                    int amtRead = _stdInput.EndRead(asyncResult);

                    if (amtRead == 0)
                    {
                        _mainThreadMessageQueue.Post(new SendOrPostCallback(ApplicationTeardown), null);
                    }
                    else
                    {
                        BeginMonitoringStdIn(null);
                    }
                }, null);
        }
        else
        {
            // not invoked from the main thread - dispatch another call to this method on the main thread and return
            _mainThreadMessageQueue.Post(new SendOrPostCallback(BeginMonitoringStdIn), null);
        }
    }

    private void ApplicationTeardown(object state)
    {
        // tear down your application gracefully here
        _stdInput.Close();

        this.ExitThread();
    }
}

Mises en garde à cette approche:

1. le fichier .exe enfant réel qui est lancé doit être une application console afin qu'il reste attaché à stdin / out / err. Comme dans l'exemple ci-dessus, j'ai facilement adapté mon application existante qui utilisait une pompe de message (mais n'a pas montré d'interface graphique) en créant simplement un petit projet de console qui faisait référence au projet existant, en instanciant mon contexte d'application et en appelant Application.Run()à l'intérieur de la Mainméthode du console .exe.

2. Techniquement, cela signale simplement le processus enfant lorsque le parent se termine, donc cela fonctionnera si le processus parent s'est terminé normalement ou s'est écrasé, mais il appartient toujours aux processus enfants d'effectuer leur propre arrêt. C'est peut-être ce que vous voulez ou non ...

Une façon consiste à transmettre le PID du processus parent à l'enfant. L'enfant interrogera périodiquement si le processus avec le pid spécifié existe ou non. Sinon, il s'arrêtera.

Vous pouvez également utiliser la méthode Process.WaitForExit dans la méthode enfant pour être averti lorsque le processus parent se termine, mais cela peut ne pas fonctionner dans le cas du Gestionnaire des tâches.

Il existe une autre méthode pertinente, simple et efficace, pour terminer les processus enfants à la fin du programme. Vous pouvez implémenter et leur attacher un débogueur à partir du parent; lorsque le processus parent se termine, les processus enfants seront tués par le système d'exploitation. Il peut aller dans les deux sens en attachant un débogueur au parent de l'enfant (notez que vous ne pouvez attacher qu'un débogueur à la fois). Vous pouvez trouver plus d'informations sur le sujet ici .

Ici, vous avez une classe utilitaire qui lance un nouveau processus et y attache un débogueur. Il a été adapté de ce billet par Roger Knapp. La seule exigence est que les deux processus doivent partager le même témoin. Vous ne pouvez pas déboguer un processus 32 bits à partir d'un processus 64 bits ou vice versa.

public class ProcessRunner
{
    #region "API imports"

    private const int DBG_CONTINUE = 0x00010002;
    private const int DBG_EXCEPTION_NOT_HANDLED = unchecked((int) 0x80010001);

    private enum DebugEventType : int
    {
        CREATE_PROCESS_DEBUG_EVENT = 3,
        //Reports a create-process debugging event. The value of u.CreateProcessInfo specifies a CREATE_PROCESS_DEBUG_INFO structure.
        CREATE_THREAD_DEBUG_EVENT = 2,
        //Reports a create-thread debugging event. The value of u.CreateThread specifies a CREATE_THREAD_DEBUG_INFO structure.
        EXCEPTION_DEBUG_EVENT = 1,
        //Reports an exception debugging event. The value of u.Exception specifies an EXCEPTION_DEBUG_INFO structure.
        EXIT_PROCESS_DEBUG_EVENT = 5,
        //Reports an exit-process debugging event. The value of u.ExitProcess specifies an EXIT_PROCESS_DEBUG_INFO structure.
        EXIT_THREAD_DEBUG_EVENT = 4,
        //Reports an exit-thread debugging event. The value of u.ExitThread specifies an EXIT_THREAD_DEBUG_INFO structure.
        LOAD_DLL_DEBUG_EVENT = 6,
        //Reports a load-dynamic-link-library (DLL) debugging event. The value of u.LoadDll specifies a LOAD_DLL_DEBUG_INFO structure.
        OUTPUT_DEBUG_STRING_EVENT = 8,
        //Reports an output-debugging-string debugging event. The value of u.DebugString specifies an OUTPUT_DEBUG_STRING_INFO structure.
        RIP_EVENT = 9,
        //Reports a RIP-debugging event (system debugging error). The value of u.RipInfo specifies a RIP_INFO structure.
        UNLOAD_DLL_DEBUG_EVENT = 7,
        //Reports an unload-DLL debugging event. The value of u.UnloadDll specifies an UNLOAD_DLL_DEBUG_INFO structure.
    }

    [StructLayout(LayoutKind.Sequential)]
    private struct DEBUG_EVENT
    {
        [MarshalAs(UnmanagedType.I4)] public DebugEventType dwDebugEventCode;
        public int dwProcessId;
        public int dwThreadId;
        [MarshalAs(UnmanagedType.ByValArray, SizeConst = 1024)] public byte[] bytes;
    }

    [DllImport("Kernel32.dll", SetLastError = true)]
    private static extern bool DebugActiveProcess(int dwProcessId);

    [DllImport("Kernel32.dll", SetLastError = true)]
    private static extern bool WaitForDebugEvent([Out] out DEBUG_EVENT lpDebugEvent, int dwMilliseconds);

    [DllImport("Kernel32.dll", SetLastError = true)]
    private static extern bool ContinueDebugEvent(int dwProcessId, int dwThreadId, int dwContinueStatus);

    [DllImport("Kernel32.dll", SetLastError = true)]
    public static extern bool IsDebuggerPresent();

    #endregion

    public Process ChildProcess { get; set; }

    public bool StartProcess(string fileName)
    {
        var processStartInfo = new ProcessStartInfo(fileName)
        {
            UseShellExecute = false,
            WindowStyle = ProcessWindowStyle.Normal,
            ErrorDialog = false
        };

        this.ChildProcess = Process.Start(processStartInfo);
        if (ChildProcess == null)
            return false;

        new Thread(NullDebugger) {IsBackground = true}.Start(ChildProcess.Id);
        return true;
    }

    private void NullDebugger(object arg)
    {
        // Attach to the process we provided the thread as an argument
        if (DebugActiveProcess((int) arg))
        {
            var debugEvent = new DEBUG_EVENT {bytes = new byte[1024]};
            while (!this.ChildProcess.HasExited)
            {
                if (WaitForDebugEvent(out debugEvent, 1000))
                {
                    // return DBG_CONTINUE for all events but the exception type
                    var continueFlag = DBG_CONTINUE;
                    if (debugEvent.dwDebugEventCode == DebugEventType.EXCEPTION_DEBUG_EVENT)
                        continueFlag = DBG_EXCEPTION_NOT_HANDLED;
                    ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, continueFlag);
                }
            }
        }
        else
        {
            //we were not able to attach the debugger
            //do the processes have the same bitness?
            //throw ApplicationException("Unable to attach debugger") // Kill child? // Send Event? // Ignore?
        }
    }
}

Usage:

    new ProcessRunner().StartProcess("c:\\Windows\\system32\\calc.exe");

Je cherchais une solution à ce problème qui ne nécessitait pas de code non managé. Je n'étais pas non plus en mesure d'utiliser la redirection d'entrée / sortie standard car il s'agissait d'une application Windows Forms.

Ma solution était de créer un tube nommé dans le processus parent, puis de connecter le processus enfant au même tube. Si le processus parent se termine, le canal est rompu et l'enfant peut le détecter.

Voici un exemple utilisant deux applications de console:

Parent

private const string PipeName = "471450d6-70db-49dc-94af-09d3f3eba529";

public static void Main(string[] args)
{
    Console.WriteLine("Main program running");

    using (NamedPipeServerStream pipe = new NamedPipeServerStream(PipeName, PipeDirection.Out))
    {
        Process.Start("child.exe");

        Console.WriteLine("Press any key to exit");
        Console.ReadKey();
    }
}

Enfant

private const string PipeName = "471450d6-70db-49dc-94af-09d3f3eba529"; // same as parent

public static void Main(string[] args)
{
    Console.WriteLine("Child process running");

    using (NamedPipeClientStream pipe = new NamedPipeClientStream(".", PipeName, PipeDirection.In))
    {
        pipe.Connect();
        pipe.BeginRead(new byte[1], 0, 1, PipeBrokenCallback, pipe);

        Console.WriteLine("Press any key to exit");
        Console.ReadKey();
    }
}

private static void PipeBrokenCallback(IAsyncResult ar)
{
    // the pipe was closed (parent process died), so exit the child process too

    try
    {
        NamedPipeClientStream pipe = (NamedPipeClientStream)ar.AsyncState;
        pipe.EndRead(ar);
    }
    catch (IOException) { }

    Environment.Exit(1);
}

Utilisez des gestionnaires d'événements pour créer des hooks sur quelques scénarios de sortie:

var process = Process.Start("program.exe");
AppDomain.CurrentDomain.DomainUnload += (s, e) => { process.Kill(); process.WaitForExit(); };
AppDomain.CurrentDomain.ProcessExit += (s, e) => { process.Kill(); process.WaitForExit(); };
AppDomain.CurrentDomain.UnhandledException += (s, e) => { process.Kill(); process.WaitForExit(); };

Juste ma version 2018. Utilisez-le en dehors de votre méthode Main ().

    using System.Management;
    using System.Diagnostics;

    ...

    // Called when the Main Window is closed
    protected override void OnClosed(EventArgs EventArgs)
    {
        string query = "Select * From Win32_Process Where ParentProcessId = " + Process.GetCurrentProcess().Id;
        ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);
        ManagementObjectCollection processList = searcher.Get();
        foreach (var obj in processList)
        {
            object data = obj.Properties["processid"].Value;
            if (data != null)
            {
                // retrieve the process
                var childId = Convert.ToInt32(data);
                var childProcess = Process.GetProcessById(childId);

                // ensure the current process is still live
                if (childProcess != null) childProcess.Kill();
            }
        }
        Environment.Exit(0);
    }

Je vois deux options:

1. Si vous savez exactement quel processus enfant peut être démarré et que vous êtes sûr qu'ils ne sont lancés qu'à partir de votre processus principal, vous pouvez envisager de simplement les rechercher par nom et de les tuer.
2. Parcourez tous les processus et tuez tous les processus dont votre processus est parent (je suppose que vous devez d'abord tuer les processus enfants). Voici comment obtenir l'ID du processus parent.

J'ai créé une bibliothèque de gestion de processus enfant où le processus parent et le processus enfant sont surveillés grâce à un canal WCF bidirectionnel. Si le processus enfant se termine ou si le processus parent se termine, l'un l'autre est notifié. Il existe également un assistant de débogage disponible qui attache automatiquement le débogueur VS au processus enfant démarré

Site du projet:

http://www.crawler-lib.net/child-processes

Packages NuGet:

https://www.nuget.org/packages/ChildProcesses https://www.nuget.org/packages/ChildProcesses.VisualStudioDebug/

appelez job.AddProcess est préférable de faire après le démarrage du processus:

prc.Start();
job.AddProcess(prc.Handle);

Lorsque vous appelez AddProcess avant la fin, les processus enfants ne sont pas tués. (Windows 7 SP1)

private void KillProcess(Process proc)
{
    var job = new Job();
    job.AddProcess(proc.Handle);
    job.Close();
}

Encore un ajout à l'abondante richesse des solutions proposées jusqu'à présent ...

Le problème avec beaucoup d'entre eux est qu'ils comptent sur le processus parent et enfant pour s'arrêter de manière ordonnée, ce qui n'est pas toujours vrai lorsque le développement est en cours. J'ai constaté que mon processus enfant était souvent orphelin chaque fois que je terminais le processus parent dans le débogueur, ce qui m'obligeait à tuer le ou les processus orphelins avec Task Manager afin de reconstruire ma solution.

La solution: transmettez l'ID du processus parent sur la ligne de commande (ou encore moins invasive, dans les variables d'environnement) du processus enfant.

Dans le processus parent, l'ID de processus est disponible sous la forme:

 Process.CurrentProcess.Id;

Dans le processus enfant:

Process parentProcess = Process.GetProcessById(parentProcessId);
parentProcess.Exited += (s, e) =>
{
    // clean up what you can.
    this.Dispose();
    // maybe log an error
    // ...

    // And terminate with prejudice! 
    //(since something has already gone terribly wrong)
    Process.GetCurrentProcess().Kill();
};

Je ne vois pas si c'est une pratique acceptable dans le code de production. D'une part, cela ne devrait jamais arriver. Mais d'un autre côté, cela peut faire la différence entre le redémarrage d'un processus et le redémarrage d'un serveur de production. Et ce qui ne devrait jamais arriver le fait souvent.

Et c'est certainement utile lors du débogage des problèmes d'arrêt ordonné.