Ce qu'est vraiment « Ne répond pas » — comment Windows juge qu'une application est bloquée, et comment concevoir des applications qui ne le sont pas

« Pendant le traitement, l’écran devient blanc et la barre de titre affiche “Ne répond pas”. » « Les utilisateurs disent que ça se bloque de temps en temps, mais ça ne se reproduit jamais sur une machine de développement. » Ce sont des plaintes courantes pour les applications métier Windows.

Le premier point à retenir est que ce n’est pas l’application elle-même qui affiche « Ne répond pas », c’est Windows. Windows détecte que le traitement des messages de la fenêtre s’est arrêté et remplace l’écran d’origine par une fenêtre de substitution. La clé pour remonter à la cause est ce que fait le thread d’interface propriétaire de cette fenêtre, qui l’empêche de traiter le message suivant.¹²

Cet article s’adresse aux développeurs qui créent des applications métier sous Windows et aux responsables informatiques qui reçoivent des tickets sur des applications bloquées. Il procède dans l’ordre jugement de l’OS → boucle de messages → isolement de la cause par catégorie → conceptions qui ne se bloquent pas → procédure d’investigation. Si vous devez investiguer une application actuellement bloquée, lisez d’abord le chapitre 7.

1. La conclusion d’abord : ne pas masquer l’affichage, libérer le thread d’interface

Le mécanisme de « Ne répond pas », la façon de le corriger et la façon de l’investiguer deviennent plus clairs lorsqu’on les sépare ainsi.

Le principe de la contre-mesure est de ne pas attendre longtemps et de ne pas calculer lourdement sur le thread d’interface. Le thread d’interface s’occupe de l’entrée, du dessin, de l’affichage de progression et de l’acceptation de l’annulation, et est séparé du travail qui prend du temps.³

De plus, le délai jusqu’à l’affichage « Ne répond pas » et le temps de réponse confortable à l’usage sont deux choses distinctes. Rester sous 5 secondes ne suffit pas. La section 4.5 explique cette différence.

2. « Ne répond pas » est le jugement de l’OS : la règle des 5 secondes et l’écran de substitution

2.1 L’unité de jugement n’est pas le processus entier, mais la fenêtre et le thread propriétaire

Dans la description Microsoft de IsHungAppWindow, une fenêtre est considérée comme ne répondant pas lorsqu’elle satisfait les conditions suivantes.¹

L’OS ne regarde pas ce que l’application calcule, mais si la boucle de messages tourne. La boucle de messages est le mécanisme qui récupère dans l’ordre les demandes d’entrée et de repeindre et les traite. Le chapitre 3 explique le fonctionnement concret.

La même documentation indique aussi que la valeur de 5 secondes peut changer à l’avenir. C’est le délai interne du jugement de non-réponse, pas une règle de conception qui dirait « vous pouvez bloquer l’interface jusqu’à 5 secondes ».¹

Le jugement n’est pas par processus. Dans une application qui a plusieurs threads d’interface, une fenêtre peut être bloquée tandis que des fenêtres appartenant à d’autres threads continuent de fonctionner. Dans l’investigation aussi, il ne suffit pas de regarder le processus : il faut identifier le thread propriétaire de la fenêtre bloquée.

2.2 L’écran blanc givré est une « fenêtre fantôme »

Lorsqu’une fenêtre de premier niveau est jugée comme ne répondant pas, Windows masque la fenêtre d’origine et la remplace par une fenêtre fantôme de même ordre Z, position, taille et apparence. Le « (Ne répond pas) » du titre et l’aspect blanc givré sous le thème Aero viennent de cet écran de substitution, pas de l’application bloquée.²

Pouvoir déplacer la fenêtre de substitution ne signifie pas que le contenu de l’application a recommencé à fonctionner. L’OS ne fait que prendre en charge le minimum d’opérations.²⁴

Une réclamation du type « l’affichage apparaît trop tôt » se traite d’abord comme un problème de thread d’interface qui ne revient pas longtemps au traitement des messages. Investiguer le traitement arrêté passe avant de supprimer l’affichage.

2.3 Ne pas le voir sous le débogueur ne veut pas dire que ce n’est pas bloqué

Tant qu’un débogueur est attaché, l’OS ne crée pas de fenêtre fantôme. Un écart du type « ça n’apparaît pas en débogage, mais ça passe à Ne répond pas en exécution normale » peut donc masquer le même blocage du thread d’interface, seule l’affichage différant.²

Il existe aussi une API qui désactive le remplacement par une fenêtre fantôme à l’échelle du processus, mais ce n’est pas une API qui corrige le blocage lui-même. La section 6.2 sépare l’usage prévu.

3. Pourquoi l’écran s’arrête : le thread d’interface et la boucle de messages

3.1 L’entrée et le repeindre sont traités par le même thread

Les applications GUI Windows sont pilotées par événements. Elles reçoivent des messages pour la souris, le clavier, les demandes de repeindre, les minuteurs, etc., et exécutent le traitement correspondant. Chaque thread qui crée une fenêtre a une file de messages et exécute une boucle comme celle-ci.⁵

MSG msg;
while (GetMessage(&msg, NULL, 0, 0) > 0) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);   // la procédure de fenêtre est appelée
}

GetMessage récupère un message depuis la file, et DispatchMessage appelle la procédure de fenêtre de la fenêtre. La procédure de fenêtre est la fonction qui exécute le traitement correspondant à un message. Le traitement d’un clic de bouton, le repeindre, et les gestionnaires d’événements WinForms et WPF, tous se rattachent à ce traitement de messages sur le thread d’interface.⁶

flowchart TB
    accTitle: Structure de base de la boucle de messages
    accDescr: L'OS place la souris, le clavier et les autres entrées dans la file de messages du thread ; la boucle du thread d'interface la récupère avec GetMessage, appelle la procédure de fenêtre avec DispatchMessage, et revient en haut de la boucle lorsque le traitement se termine
    os["OS (entrée, demandes de repeindre, minuteurs)"] --> q["File de messages du thread"]
    q --> gm["Récupérer avec GetMessage"]
    gm --> dm["DispatchMessage"]
    dm --> wp["Traiter dans la procédure de fenêtre"]
    wp --> gm

Figure 1 : récupérer un message, le traiter dans la procédure de fenêtre, et revenir à la boucle. Ce cycle porte l’entrée et le dessin.

Que se passe-t-il alors si un traitement long est appelé depuis un gestionnaire de clic ? Tant que ce traitement n’est pas revenu, le thread d’interface ne peut pas récupérer le message suivant. Les clics et les demandes de repeindre qui arrivent ensuite ne peuvent plus être traités. C’est la structure de base d’un « écran gelé ».

3.2 PostMessage et SendMessage ne reviennent pas au même moment

La livraison des messages a deux chemins : l’un qui empile le message dans la file, et l’un qui attend la fin du traitement.⁵⁷

En particulier, lorsque SendMessage est envoyé à une fenêtre d’un autre thread, l’émetteur est lui aussi mis en attente jusqu’à ce que le destinataire puisse traiter le message. Cette différence mène directement à l’interblocage de la section 4.3.⁷

4. Causes par catégorie : cinq schémas qui bouchent le thread d’interface

L’apparence de « Ne répond pas » est la même, mais ce qui bouche diffère. Séparez d’abord les candidats, puis confirmez-les avec les dumps et traces du chapitre 7.

4.1 E/S synchrones et appels réseau

Le schéma le plus fréquent consiste, dans le gestionnaire de clic d’un bouton, à faire de façon synchrone la lecture ou l’écriture d’un gros fichier, une requête de base de données, une API Web, ou l’accès à un lecteur réseau.

Ce qui se termine en une fraction de seconde sur la machine de développement peut devenir une attente de plusieurs dizaines de secondes sous la latence réseau de production ou un problème du serveur de fichiers. Les lecteurs réseau ont des délais d’expiration longs en cas de coupure, ce qui aggrave le symptôme. « C’était rapide sur la machine de développement » n’est pas une raison d’attendre sur le thread d’interface.

4.2 Le thread d’interface attend un verrou tenu par un worker

Les verrous qui protègent des données partagées peuvent aussi arrêter l’interface. Si un worker tient un verrou longtemps et que le thread d’interface essaie de le prendre, le thread d’interface attend jusqu’à pouvoir l’acquérir.

Même après avoir déplacé le travail vers un worker, l’écran ne se libère pas si le thread d’interface attend la fin de ce travail ou la libération du verrou. La discipline des verrous est traitée en détail dans la série pratique sur le multithreading.

4.3 S’attendre mutuellement via SendMessage

L’interblocage classique est la combinaison dans laquelle le thread d’interface attend la fin d’un worker, et ce worker envoie SendMessage à l’interface et attend. L’interface est en attente et ne peut pas traiter les messages, et le worker ne peut pas revenir de SendMessage, donc aucun des deux n’avance.⁷⁵

sequenceDiagram
    accTitle: Interblocage par SendMessage entre threads
    accDescr: Lorsqu'un thread worker envoie SendMessage à la fenêtre du thread d'interface alors que celui-ci est bloqué en attendant le résultat du worker, chacun attend la fin de l'autre et il en résulte un interblocage
    participant U as Thread d'interface
    participant W as Thread worker
    U->>U: Attendre la fin du worker (bloqué)
    W->>U: SendMessage (ne revient pas avant la fin du traitement)
    Note over U: Ne peut pas traiter les messages (en attente)
    Note over W: Ne peut pas revenir de SendMessage
    Note over U,W: Attente mutuelle : interblocage

Figure 2 : déplacer le travail vers un worker ne suffit pas. Si l’interface et le worker attendent chacun la fin de l’autre, il y a interblocage.

L’envoi vers HWND_BROADCAST demande aussi de la prudence. Une seule fenêtre qui ne répond pas suffit à entraîner l’émetteur. Lorsque vous ne pouvez pas continuer à attendre, envisagez SendMessageTimeout, qui pose un délai, ou PostMessage, qui n’attend pas la fin du traitement.⁸

4.4 Un STA COM s’arrête et entraîne d’autres threads

Les appels d’autres threads vers un objet STA sont livrés comme messages de fenêtre. Par conséquent, lorsque le thread d’interface (un STA) est bouché, les appels COM vers lui se bloquent aussi. C’est une structure dans laquelle non seulement l’interface, mais aussi les appelants, se retrouvent en attente.

La relation entre appartements et traitement des messages est expliquée dans l’article COM STA/MTA.

4.5 Répéter « une fois, c’est un instant » 100 fois

Même un traitement synchrone de 50 ms fait 5 secondes s’il est répété 100 fois. Ne jugez pas en mesurant chaque fonction isolément et en la trouvant courte ; pensez en temps total jusqu’au retour du thread d’interface à la boucle de messages.

La sensation de lenteur commence vers 100 ms. Ne visez pas le seuil de 5 secondes du jugement de non-réponse ; concevez en considérant que le thread d’interface ne peut être bouché que pendant des millisecondes.

5. Conceptions qui ne se bloquent pas : séparer l’exécution du travail et la mise à jour de l’écran

5.1 Séparer le calcul et les API synchrones des E/S asynchrones

Le principe de la contre-mesure est de sortir le travail qui prend du temps du thread d’interface. Tout n’est toutefois pas déplacé de la même façon.

Avec des E/S asynchrones, il n’est pas nécessaire d’occuper un thread uniquement pour attendre. L’exemple de code ci-dessous aussi distingue : Task.Run pour le calcul, API asynchrone native pour la communication HTTP.³

5.2 En C#, revenir à l’interface avec async/await et la mettre à jour

L’exemple suivant sépare, dans un gestionnaire de clic WinForms, le travail lourd et la mise à jour de l’interface. Parce que cet exemple part d’un gestionnaire d’événement d’interface et conserve le contexte d’exécution de l’interface, la continuation après await revient sur le thread d’interface et peut mettre à jour les contrôles.³

private async void RunButton_Click(object sender, EventArgs e)
{
    runButton.Enabled = false;
    try
    {
        // Calcul CPU lourd et API uniquement synchrones : vers un worker via Task.Run
        var result = await Task.Run(() => HeavyCalculation(input));

        // Pour les E/S, utiliser une API nativement asynchrone (elle ne consomme pas de thread non plus)
        var data = await httpClient.GetStringAsync(url);

        // Après await on est de retour sur le thread d'interface, on peut toucher les contrôles directement
        resultLabel.Text = result + data.Length.ToString();
    }
    catch (Exception ex)
    {
        // Une exception qui fuit d'un gestionnaire async void fait planter l'application. L'attraper ici
        MessageBox.Show($"Le traitement a échoué : {ex.Message}");
    }
    finally
    {
        runButton.Enabled = true;
    }
}

Quatre points à retenir.

C’est un exemple de code qui montre la répartition des rôles ; l’implémentation de HeavyCalculation et analogues, la gestion de la fermeture du formulaire, ainsi que la progression et l’annulation, sont omises. La progression et l’interruption nécessaires à un travail long s’ajoutent à part, comme en section 5.4.

Les contrôles WinForms et les éléments WPF se manipulent depuis le thread qui les a créés. Les toucher directement depuis un worker mène à des exceptions ou à un comportement indéfini. Pour revenir explicitement au thread d’interface, utilisez Control.Invoke / BeginInvoke en WinForms et Dispatcher.InvokeAsync en WPF.³

5.3 En Win32, notifier la fin avec PostMessage

La répartition des rôles est la même en Win32 natif. Passez le travail à un worker, et une fois terminé, envoyez avec PostMessage un message de fin personnalisé et mettez à jour l’écran dans la procédure de fenêtre du thread d’interface. Comme PostMessage revient une fois le message empilé, le worker n’attend pas la fin du traitement de l’interface.⁷

flowchart TB
    accTitle: Répartition des rôles d'une application qui ne se bloque pas
    accDescr: Le thread d'interface ne s'occupe que de l'entrée, de l'affichage de progression et de l'acceptation de l'annulation ; un thread worker exécute le travail lourd et renvoie la fin au thread d'interface via PostMessage ou une continuation await
    ui["Thread d'interface : entrée, progression, annulation"] -->|"passer le travail"| w["Thread worker : travail lourd"]
    w -->|"PostMessage / continuation await"| ui
    ui -.-> ng["Pas d'E/S synchrones ni de long calcul sur le thread d'interface"]

Figure 3 : passer le calcul lourd et le travail synchrone au worker, et ramener les mises à jour d’écran au thread d’interface. Les E/S asynchrones s’attendent avec une API asynchrone, comme en section 5.1.

L’attente du worker elle-même se écrit selon la discipline traitée dans l’article sur les variables de condition. Il est aussi important que le thread d’interface ne se remette pas à attendre le worker de façon synchrone.

5.4 Concevoir dès le départ la progression et l’annulation

Même si l’écran ne gèle pas, si rien ne change pendant longtemps, l’utilisateur ne peut pas savoir si ça travaille encore. Donc concevez l’affichage de progression et l’acceptation de l’annulation comme une partie du traitement.

Le worker s’interrompt à un point de coupure raisonnable et fait le ménage. Disposer de moyens de progression et d’annulation réduit les situations où l’utilisateur recourt à une fin forcée. Une fin forcée peut entraîner une corruption de données.

6. Deux méthodes qui ressemblent à des contournements, et leurs limites

6.1 DoEvents fait entrer d’autres événements au milieu du traitement

Insérer Application.DoEvents() ou une boucle PeekMessage pendant un travail lourd traite les messages et évite l’affichage « Ne répond pas ». Cependant, un autre gestionnaire d’événement s’exécute alors alors que le traitement d’origine n’est pas encore terminé. C’est de la réentrance.

Par exemple, DoEvents est appelé au milieu d’une transformation de données, et un second clic de bouton déjà en file est traité. Ce gestionnaire réécrit les mêmes données, puis le traitement d’origine reprend. Dans cet ordre, l’état que le traitement d’origine supposait est déjà perdu.

Ce n’est pas seulement les boutons qui réentrent. La fermeture du formulaire et les minuteurs arrivent aussi. Des bugs comme des données en cours de traitement corrompues, ou une exception en touchant un formulaire fermé, dépendent du moment, se reproduisent mal, et tendent à être plus difficiles à investiguer que « Ne répond pas ».

Le principe est de séparer le travail, pas de pomper la boucle à la main. Le traitement manuel des messages reste confiné à des structures limitées, comme une boîte de dialogue de progression modale. Pour un travail long ordinaire, utilisez la séparation et la prévention de réentrance du chapitre 5.

6.2 Désactiver les fenêtres fantômes ne ramène pas le contrôle

DisableProcessWindowsGhosting est une API qui désactive le remplacement par une fenêtre fantôme pour le processus appelant. La désactivation dure pendant la durée de vie du processus.⁴

Elle existe pour des usages particuliers, comme un terminal kiosque, où l’on veut éviter que l’OS mette une fenêtre de substitution opérable. Le fait que le traitement des messages soit arrêté ne change pas, et l’utilisateur perd aussi le moyen de déplacer ou de quitter que la fenêtre fantôme offrait. Ce n’est pas un outil à utiliser comme contre-mesure « Ne répond pas » dans une application ordinaire.

7. Procédure d’investigation : conserver le moment du blocage avant de fermer

7.1 Prendre d’abord un dump

Dans l’investigation de « ça se bloque de temps en temps », le plus précieux est l’état des threads au moment même du blocage. Une fois que vous quittez ou redémarrez, cet état est perdu.

Dans l’onglet « Détails » du Gestionnaire des tâches, cliquez avec le bouton droit sur le processus cible et choisissez « Créer un fichier de vidage ». Vous obtenez un dump complet contenant les piles de tous les threads. Partagez aussi la procédure avec ceux qui reçoivent les tickets : « s’il se bloque, prenez un dump avant de fermer ».

Pour construire un mécanisme de collecte, voir l’article sur la collecte des dumps de crash.

7.2 Regarder le thread propriétaire de la fenêtre bloquée

Ouvrez le dump dans WinDbg et vérifiez la pile du thread d’interface. Le thread qui fait tourner la boucle de messages est en général le thread 0, mais certaines applications ont plusieurs threads d’interface, donc ne décidez pas seulement d’après le numéro ; regardez le thread propriétaire de la fenêtre bloquée.

La pile du thread d’interface montre ce sur quoi il attend. Si un interblocage est soupçonné, faites correspondre les cibles d’attente des deux threads, pas d’un seul. La façon de les lire est expliquée dans l’article d’introduction à WinDbg.

flowchart TB
    accTitle: Procédure de base pour investiguer Ne répond pas
    accDescr: Prendre un dump au moment du blocage, regarder la pile du thread d'interface, identifier s'il est arrêté sur des E/S synchrones, une attente de verrou ou un SendMessage entre threads, et relier cela à la correction de conception correspondante
    hang["Le moment du blocage"] --> dump["Prendre un dump (avant de fermer)"]
    dump --> stack["Regarder la pile du thread d'interface"]
    stack --> io["E/S synchrones ou attente réseau"]
    stack --> lock["Attente de verrou"]
    stack --> sm["SendMessage entre threads"]
    io -.-> fix["Séparer l'endroit concerné vers un worker"]
    lock -.-> fix
    sm -.-> fix

Figure 4 : à partir du dump du moment du blocage, suivre ce sur quoi le thread d’interface attend. Pour les E/S, asynchroniser ou séparer ; pour les verrous et SendMessage, vérifier aussi la structure d’attente.

7.3 Distinguer l’inspection en direct et l’analyse dans le temps

Outre les dumps, il y a un moyen de regarder un processus vivant sur place, et un moyen d’enregistrer le déroulement du temps.

La façon de prendre une série temporelle est traitée dans WPR/WPA en pratique.

7.4 Resserrer les candidats à partir du symptôme, puis confirmer avec des preuves

Les conditions de reproduction sont aussi une entrée dans l’investigation. Ne décidez toutefois pas la cause d’après le seul symptôme ; croisez-la avec les dumps et les traces.

8. Résumé

« Ne répond pas » est un mécanisme dans lequel Windows juge que le traitement des messages d’une fenêtre s’est arrêté et met un écran de substitution. L’unité de jugement est la fenêtre et le thread GUI propriétaire, pas le processus entier. Le délai interne de 5 secondes est une valeur qui peut changer à l’avenir, et se distingue du temps de réponse confortable d’une interface.¹²

Ce qu’il faut corriger n’est pas l’affichage, mais le calcul ou l’attente qui occupe longtemps le thread d’interface. Le travail CPU et les API uniquement synchrones vont vers un worker, les E/S asynchrones vers des API asynchrones, et les mises à jour d’écran reviennent au thread d’interface. Concevez ensemble la progression, l’annulation et la prévention de réentrance. Contourner avec DoEvents ou désactiver les fenêtres fantômes n’en est pas un substitut.

Lorsque la cause est inconnue, commencez par prendre un dump avant de quitter et regarder ce sur quoi attend le thread propriétaire de la fenêtre bloquée. Remplacez « on dirait que c’est cassé » par « le thread d’interface ne peut pas revenir au traitement des messages », et les lieux d’investigation et les corrections de conception se relient.

Articles connexes

• Réveils parasites — pourquoi les variables de condition se réveillent « sans avoir été notifiées » et comment attendre correctement sous Windows
• Bonnes pratiques de multithreading en pratique — édition .NET : ce qu’il faut décider avant d’ajouter des threads
• Les fondamentaux STA/MTA de COM - modèles de threads et comment éviter les blocages
• Lire un dump de plantage avec WinDbg + SOS — Guide pratique d’analyse après la collecte
• Process Explorer / Handle / VMMap en pratique — Diagnostiquer les blocages, fuites et « fichiers en cours d’utilisation » à partir de l’état du système à cet instant précis
• L’arrêt de Windows vu depuis l’application — survivre correctement aux notifications de fermeture, aux redémarrages et aux coupures d’alimentation

Domaines de conseil associés

KomuraSoft LLC prend en charge l’investigation des causes (analyse de dump et analyse de traces) d’applications métier qui « se bloquent de temps en temps » ou passent à « Ne répond pas », le refactoring de code d’interface héritée plein de traitements synchrones vers async/await et la séparation en threads worker, et les revues de conceptions d’interface qui ne gèlent pas. Même lorsque la procédure de reproduction n’est pas encore connue, nous pouvons aider à partir de la conception de la façon de collecter les preuves.

• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Dans quelles conditions « Ne répond pas » apparaît-il ?

L'OS juge une fenêtre comme ne répondant pas lorsqu'une application fenêtrée n'attend pas d'entrée, n'est pas dans son traitement de démarrage, et n'a pas récupéré de message (PeekMessage) pendant 5 secondes. La fenêtre de premier niveau ainsi jugée est masquée et remplacée par une « fenêtre fantôme » de la même position, taille et apparence. Le texte de barre de titre « (Ne répond pas) » et l'aspect blanc givré appartiennent à cette fenêtre fantôme, qui ne permet que de déplacer, réduire ou fermer. Autrement dit, « Ne répond pas » n'est pas quelque chose que l'application elle-même affiche : c'est un écran que l'OS met à sa place.

Y a-t-il un réglage pour empêcher « Ne répond pas » d'apparaître pendant qu'un travail est en cours ?

Appeler DisableProcessWindowsGhosting désactive le remplacement par une fenêtre fantôme pour ce processus. Cela ne fait toutefois que rendre le blocage moins visible pour l'utilisateur : la fenêtre ne réagit toujours pas à l'entrée, et du point de vue de l'utilisateur c'est un gel complet, sans moyen de déplacer ou de fermer. Le vrai correctif n'est pas de supprimer l'affichage, mais de déplacer le travail lourd vers un thread worker afin que le thread d'interface ne soit jamais bloqué même un dixième de seconde, encore moins cinq. Notez aussi que l'OS ne crée pas de fenêtre fantôme lorsqu'un débogueur est attaché, donc il peut sembler que « Ne répond pas n'arrive jamais pendant le débogage ».

Est-il acceptable d'éviter « Ne répond pas » avec DoEvents (en pompant manuellement la boucle de messages) ?

Ce n'est pas recommandé. Faire tourner DoEvents ou une boucle PeekMessage au milieu d'un travail lourd esquivera le jugement de non-réponse, mais n'importe quel gestionnaire d'événement peut alors réentrer : un second clic du bouton, fermer la fenêtre, un minuteur, etc. Qu'un autre gestionnaire réécrive des données encore en cours de traitement, ou touche un formulaire censé être déjà fermé et lève une exception, produit des bugs de réentrance dépendants du moment et difficiles à reproduire — plus gênants que « Ne répond pas » lui-même. L'approche correcte est de déplacer le travail lui-même vers un thread worker avec Task.Run ou analogue, et de laisser le thread d'interface responsable seulement de l'affichage de progression et de l'acceptation de l'annulation.

Comment mettre à jour l'écran (les contrôles) depuis un thread worker ?

Les contrôles WinForms et les éléments WPF ne peuvent être touchés que depuis le thread qui les a créés (normalement le thread d'interface). Les toucher directement depuis un thread worker provoque des exceptions ou un comportement indéfini. En C#, async/await est le chemin le plus facile : la continuation après await revient au thread d'interface appelant, donc vous pouvez mettre à jour les contrôles normalement après l'await. Pour basculer explicitement, utilisez Control.Invoke/BeginInvoke en WinForms et Dispatcher.InvokeAsync en WPF. En Win32 natif, le schéma établi est que le thread worker envoie avec PostMessage un message de fin personnalisé au thread d'interface, et que la procédure de fenêtre mette à jour l'écran.

Comment investiguer la cause d'une application qui affiche « Ne répond pas » ?

L'important est de capturer l'état au moment même du blocage. Prenez d'abord un dump complet depuis l'onglet Détails du Gestionnaire des tâches avec « Créer un fichier de vidage », puis dans WinDbg regardez la pile du thread d'interface (le thread qui exécute la boucle de messages). Qu'il soit coincé dans des E/S synchrones, une attente réseau, une attente de verrou, ou une attente sur un autre thread via SendMessage apparaît tel quel sur la pile. Pour regarder un processus en direct, utilisez la liste de threads et la vue de pile de Process Explorer ; pour le suivre dans le temps, capturez une trace avec WPR. Voir aussi l'article d'introduction à WinDbg de ce site, Process Explorer en pratique, et WPR/WPA en pratique.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.