Comment savoir qui tue mes fils

Question

J'ai un thread qui est juste bannir.. je voudrais savoir qui est en train de tuer mon fils et pourquoi.

Il se présente à moi mon fils est tué par l'OS, mais je tiens à le confirmer et si possible savoir pourquoi c'est de le tuer.

Comme pour le fil, je peux affirmer qu'elle a au moins 40 min de l'exécution avant de mourir, mais il meurt subitement autour de 5 min.

public void RunWorker()
{
    Thread worker = new Thread(delegate()
    {
        try
        {
            DoSomethingForALongLongTime();
        }
        catch(Exception e)
        {
           //Nothing is never logged :(
           LogException(e);
           throw e;
        }
    });

    worker.IsBackground = true;
    worker.SetApartmentState(System.Threading.ApartmentState.STA);
    worker.Start();
}

EDIT: l'Adressage des réponses

• Try/Catch exceptions Possibles:
  Il est mis en œuvre et il attrape rien :(
• Thread principal de mourir:
  Ce thread est créé par le serveur web, qui continue de s'exécuter
• D'achèvement des travaux:
  Le travail n'est pas terminé, que ça finalement affecte la base de données, je peux vérifier si c'est fait ou pas lorsque le thread meurt.

Avoir pensé à ces choses m'ont amené à cette question, qui est en train de tuer mon fils??

ps. Ce n'est pas Lady Goldent dans le salon avec la bougie bâton :)

Answer 1

Diverses personnes (y compris moi-même, ici) a souligné que l'hébergement d'un long thread en cours d'exécution dans IIS est une mauvaise idée. Votre thread en cours d'exécution à l'intérieur d'un IIS " du processus de travail. Ces processus sont périodiquement mis fin (recyclé) par IIS, qui sera la cause de votre fil de mourir.

Je suggère que vous essayez d'activer-désactiver les processus de travail IIS recyclage pour voir si cela fait une différence. Vous pouvez trouver plus d'informations ici.

Answer 2

Votre fil probablement juste jeté une exception. Essayez de mettre un bloc try/catch autour DoSomethingForALongLongTime et voir ce qu'il ramasse.

---

Mise à jour: je n'avais pas remarqué avant que vous lanciez ce à partir d'un serveur web. Cela peut être une très mauvaise idée. En particulier, c'est le thread séparé à l'aide d'autres informations provenant de HttpContext.Current? Qui comprendrait Request, Response, Session, etc., ainsi que toutes les informations de la page.

C'est mauvais parce que ces choses ne durent que tant que la demande dure. Une fois que la demande est de plus, ils deviennent invalides, pour dire le moins.

Si vous avez besoin de lancer un long thread en cours d'exécution à partir de l'intérieur d'un service ou d'application web, alors vous devriez créer un simple Windows Service et d'accueil d'un service WCF en son sein. Avoir la page web envoyer toutes les informations nécessaires pour effectuer la tâche pour le service. Le service peut même utiliser MSMQ comme un moyen de transport, ce qui permettra de garantir qu'aucun message n'est perdu, même si le service devient occupé.

Answer 3

Un moyen potentiel pour obtenir de plus amples renseignements: attacher un débogueur et un break sur la fin des threads. Selon la façon dont votre fils a été arrêté, cela pourrait ne pas fonctionner.

1. Télécharger les Outils de Débogage pour Windows si vous ne l'avez pas déjà
2. Exécuter windbg.exe, joindre à votre processus
3. Pause dans windbg, tapez sxe et afin de permettre la rupture à la sortie thread
4. Lorsque le débogueur pauses, inspecter l'état du système, les autres threads, etc.
5. Pour obtenir la gestion de la pile, de la charge sos.dll (.loadby sos mscorsvr, .loadby sos mscorwksou .loadby sos clr devrait fonctionner), puis exécutez !clrstack (voir !help pour les autres commandes sos)

Si vous obtenez beaucoup de bruit à partir d'autres threads de quitter, script windbg pour continuer après la rupture, si ce n'est pas l'ID de thread que vous vous souciez.

Edit: Si vous pensez que le thread est en cours de résiliation de votre processus, vous pouvez également définir un point d'arrêt sur TerminateThread (bp kernel32!TerminateThread) et ExitThread (bp kernel32!ExitThread) pour attraper la pile de l'assassin.

Answer 4

Je ne connais pas la réponse, mais quelques réflexions:

• Pourrait-il être lancer une exception? Avez-vous essayé de mettre un try/catch autour de la DoSomethingForALongLongTime() appel?
• Existe-il des points d'où il sort normalement? Essayez de mettre de l'abattage sur eux.
• Obtenez-vous le même comportement dans et hors de la débogueur? La fenêtre de sortie dans le débogueur de fournir tous les conseils?

Mise à JOUR

Vous avez dit:

Ce thread est créé par le web serveur, qui continue de s'exécuter

Si le thread est en cours d'exécution à l'intérieur de asp.net alors il se peut que le fil qui est tué lors de l'asp.net processus de travail est recyclé, ce qu'il fera périodiquement. Vous pouvez essayer de désactiver recyclage des processus de travail et voir si cela fait une différence.

Answer 5

Votre modifier révèle la réponse:

C'est le majordome de serveur web.

Exactement comment pensez-vous organiser ces fils? Un serveur web environnement n'est pas exactement conçu pour accueillir long processus vivants. En fait, il est probablement configuré pour stopper l'emballement des sites, toutes les 40 minutes, peut-être?

Edit:
Pour une solution rapide, votre meilleure chance est de fixer worker.IsBackground = false; parce que votre réglage actuel de la vraie permet au système de tuer le parent-fil w/o en attente de votre bgw.

Sur une autre note, il y a peu d'intérêt à l'aide d'un BackgroundWorker dans un ASP.NET demande, il est prévu pour WinForms et WPF. Il serait préférable de créer un thread séparé pour cela, puisque vous êtes à la modification de certains d'entre les Fils des propriétés. Ce n'est pas conseillé pour un pool de threads (Bgw) thread.