Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non pris en compte » ou un ACCESS DENIED

« J’ai modifié le fichier de configuration, mais le comportement de l’application ne change pas » ; « ça fonctionne sur la machine de développement, mais chez le client, l’application plante juste après le démarrage » ; « ça marchait encore hier, je n’ai pourtant rien changé dans le programme » — c’est généralement sous cette forme que nous parviennent les demandes d’investigation de bugs. Et pour la plupart de ces symptômes, on a beau relire le code source, on ne parvient pas à en trouver la cause. Car quels fichiers l’application lit réellement, quelle clé de registre elle consulte, et ce qui échoue — tout cela est déterminé non pas par le code, mais par l’environnement d’exécution.

Ce qui permet d’enregistrer « ce qui s’est réellement passé », c’est Process Monitor (ProcMon), un outil Sysinternals fourni gratuitement par Microsoft. C’est en quelque sorte un enregistreur du journal de comportement de Windows, qui capture en temps réel l’intégralité de l’activité du système de fichiers, du registre et des processus/threads ; chez nous, c’est un outil que nous utilisons aussi fréquemment que WinDbg lors des investigations de bugs.¹

Mais il est si puissant que, si on le lance sans rien configurer, plusieurs milliers voire dizaines de milliers d’événements défilent chaque seconde, et la première impression se résume souvent à « il y en a trop, c’est illisible ». Cet article présente le chemin le plus court pour utiliser ProcMon en conditions réelles — comment poser des filtres, comment lire la colonne Result, les schémas d’investigation classiques par type de symptôme, les précautions à prendre en production, et enfin comment le positionner par rapport aux autres outils d’investigation — le tout du point de vue du terrain de l’investigation de bugs.

1. D’abord, l’essentiel

• La question à laquelle ProcMon répond est : « quand ce processus a-t-il fait quoi sur quel chemin, et avec quel résultat ? » En quelques minutes, on découvre d’où est lu un fichier de configuration, dans quel ordre les DLL ont été recherchées, ou quelle opération s’est soldée par un ACCESS DENIED.
• La règle d’usage classique est : « d’abord appliquer un Include sur Process Name pour cibler le processus concerné, puis restreindre sur Result aux cas anormaux ». Ce n’est pas un outil que l’on parcourt ligne par ligne depuis le début.
• La colonne Result contient de nombreux cas qui paraissent anormaux mais qui sont en réalité normaux. BUFFER OVERFLOW correspond à un aller-retour d’API normal, et NAME NOT FOUND traduit le plus souvent une étape intermédiaire de l’ordre de recherche (chapitre 4).
• Le filtre n’est qu’une restriction d’affichage : en arrière-plan, tous les événements sont enregistrés. Lorsqu’on sauvegarde le journal pour le transmettre, il faut donc enregistrer tous les événements. À l’inverse, pour une capture de longue durée, Drop Filtered Events permet de préserver la mémoire (chapitre 5).
• ProcMon n’est pas une solution universelle. « Quel processus retient actuellement ce fichier » relève de Process Explorer, l’état au moment précis d’un crash relève du dump de crash, et savoir où le CPU est consommé relève de PerfView (chapitre 7).

Voici d’abord un tableau de référence rapide pour choisir l’outil selon le symptôme.

2. Qu’est-ce que ProcMon — l’installation prend une minute

Process Monitor fait partie de la suite d’outils Sysinternals ; c’est un outil de surveillance qui affiche en temps réel l’activité du système de fichiers, du registre et des processus/threads. Il est le successeur, issu de la fusion et du renforcement, des deux outils historiques Filemon et Regmon, et propose des informations détaillées pour chaque événement, un filtrage non destructif, l’enregistrement des piles d’appel des threads, ainsi que la journalisation au démarrage (boot logging).¹

L’installation est simple : il n’y a pas de programme d’installation, il suffit de récupérer le ZIP depuis la page de téléchargement, de l’extraire, puis d’exécuter Procmon.exe. Pour une investigation urgente, on peut aussi l’exécuter directement via le service Sysinternals Live, à l’adresse https://live.sysinternals.com/procmon.exe.² Au premier lancement, on doit accepter le contrat de licence, et comme l’outil charge un pilote noyau, des droits administrateur (élévation UAC) sont nécessaires. La question générale de savoir pourquoi des droits administrateur sont requis a été traitée dans « Quand les privilèges administrateur de Windows sont-ils nécessaires » : un outil qui observe les événements de l’ensemble du système d’exploitation relève typiquement du camp « élévation requise ».

Dès le lancement, la capture démarre et les événements commencent à défiler à l’écran. Il suffit de retenir trois opérations principales.

Chaque ligne d’événement est composée de Time (l’heure), Process Name (le processus), PID, Operation (l’opération), Path (le chemin visé), Result (le résultat) et Detail (les détails). Operation correspond globalement à la granularité des API Win32 : CreateFile (ouvrir/créer un fichier), ReadFile/WriteFile, RegOpenKey/RegQueryValue, etc. Autrement dit, le journal de ProcMon constitue un enregistrement de la conversation entre l’application et l’OS, et l’on y voit directement l’écart entre « ce que l’application avait l’intention de lire » comme fichier de configuration et « ce qu’elle a réellement lu ».

3. Filter — ProcMon est un outil que l’on filtre avant de lire

Si l’on capture sans rien faire, même un Windows au repos génère plusieurs milliers d’événements par seconde. On peut dire que l’utilité pratique de ProcMon dépend entièrement de la façon dont on utilise le Filter, et la méthode classique comporte deux étapes.

Première étape : filtrer par processus. Ouvrez la boîte de dialogue de filtre avec Ctrl+L et ajoutez Process Name / is / myapp.exe / Include. On peut aussi faire glisser l’icône de visée (viseur) de la barre d’outils vers la fenêtre de l’application ciblée, pour filtrer directement sur ce seul processus.

Deuxième étape : filtrer par résultat ou par opération. Pour rechercher les opérations en échec, utilisez Result / is not / SUCCESS / Include (afin de n’afficher que les cas anormaux). Pour ne voir que les écritures, utilisez Category / is / Write / Include. Pour savoir qui touche à un fichier de configuration donné, ne filtrez pas par processus mais utilisez Path / contains / app.config / Include — et ainsi de suite.

Une autre pratique très utilisée est le filtrage interactif par clic droit sur une ligne d’événement. Une fois qu’on a trouvé une ligne proche de ce qu’on cherche, il suffit de faire un clic droit et de choisir « Include ‘ce chemin’ » ou « Exclude ‘ce processus’ » pour empiler les filtres sans même ouvrir la boîte de dialogue. Le geste de base consiste à éliminer par Exclude les sources de bruit (antivirus, indexeur, etc.) pour ne conserver que ce qui entoure l’opération recherchée. Pour l’aide visuelle, on peut aussi utiliser la mise en surbrillance (Ctrl+H) : elle permet de colorer des lignes selon les mêmes expressions conditionnelles qu’un filtre, donc si l’on souhaite « voir l’ensemble du flux tout en faisant ressortir les cas anormaux », on privilégiera la surbrillance plutôt qu’un filtre.

Il y a trois particularités à connaître, sous peine de s’y faire piéger.

• Le filtre est une restriction d’affichage, pas une restriction d’enregistrement. En arrière-plan, (par défaut) tous les événements sont enregistrés, et retirer le filtre permet à tout moment de revenir à la vue complète. C’est ce qu’on appelle un filtre non destructif, une conception qui limite le risque de « trop filtrer et rater une preuve ».¹
• La configuration du filtre est conservée au démarrage suivant. Se retrouver perplexe devant un affichage vide parce qu’un filtre d’une précédente investigation est resté actif, tout le monde y passe une fois. Si l’affichage vous semble anormal, pensez d’abord à Reset Filter (Ctrl+R) dans le menu Filter.
• Quelques Exclude sont présents par défaut. ProcMon lui-même, les I/O de pagination, etc. sont exclus dès le départ. Si l’exigence de l’investigation est de « couvrir l’ensemble du système sans rien manquer », gardez à l’esprit l’existence de ce filtre par défaut.

4. Comment lire la colonne Result — des valeurs qui paraissent anormales mais sont normales

Une fois le filtre restreint aux cas anormaux, on est surpris de voir apparaître un grand nombre de « résultats qui semblent anormaux ». Ce qui compte ici, c’est que la majorité des valeurs anormales de la colonne Result font en fait partie d’un fonctionnement normal. Voici comment lire les principales valeurs de Result.

Parmi ces valeurs, celles qui jouent le rôle principal dans une investigation sont NAME NOT FOUND, ACCESS DENIED et SHARING VIOLATION. Chacune a son schéma d’investigation classique, que nous allons aborder par type de symptôme dans le chapitre suivant.

À l’inverse, un schéma souvent négligé est celui où « la cause est un SUCCESS ». Par exemple, il n’est pas rare que la réponse à « le fichier de configuration que j’ai corrigé n’est pas pris en compte » soit un SUCCESS sur un ancien fichier de configuration situé ailleurs. Si l’on ne regarde que les cas anormaux, on risque de manquer cette « mauvaise bonne réponse » chargée avec succès. La méthode sûre consiste donc à filtrer par chemin et à examiner tous les accès à ce type de fichier, y compris les succès.

5. Schémas d’investigation classiques par symptôme

5.1 « J’ai corrigé la configuration mais elle n’est pas prise en compte » — identifier d’où elle est lue

En appliquant un Include sur Path / contains / nom_du_fichier_de_configuration puis en lançant l’application, on obtient la liste des dossiers dans lesquels, et dans quel ordre, l’application a recherché un fichier de ce nom. La vérité cachée est généralement l’une des suivantes :

• L’application lisait, non pas le fichier situé dans le même dossier que l’exécutable, mais une copie sous %APPDATA% ou ProgramData (le programme était conçu pour copier le fichier au premier démarrage)
• Un accès au registre ou à un dossier système depuis un processus 32 bits subissait la redirection WOW64, ce qui créait un décalage entre l’emplacement que l’on croyait consulter et l’emplacement réel
• Les écritures vers le dossier d’installation sous Program Files étaient virtualisées (VirtualStore), et les lectures/écritures se retrouvaient transformées vers un autre emplacement

Dans tous les cas, ProcMon affiche le chemin complet dans la colonne Path, ce qui permet de comprendre la situation d’un seul coup d’œil. Le sujet inverse — comment concevoir l’emplacement des fichiers de configuration — a été traité dans « Pas seulement appsettings.json — la pratique de la gestion de la configuration ».

5.2 « Ça ne démarre que dans cet environnement » — suivre la recherche des DLL

Si l’application plante juste après le démarrage ou qu’une erreur du type « DLL introuvable » apparaît, ajoutez un Include sur le processus puis Path / ends with / .dll, et observez la chaîne de NAME NOT FOUND. La recherche de DLL sous Windows parcourt les dossiers dans un ordre précis, si bien que le journal de ProcMon affiche directement ce schéma : « une suite de NAME NOT FOUND qui suit l’ordre de recherche, puis un SUCCESS quelque part (ou aucun jusqu’au bout) ». La DLL coupable est celle qui n’aboutit jamais à un SUCCESS. On trouve aussi ici le schéma inverse : « un SUCCESS survient, mais c’est une ancienne DLL chargée depuis un emplacement non voulu ». Pour la logique de l’ordre de recherche, reportez-vous également à « Le mécanisme de résolution de noms de DLL sous Windows ».

L’erreur « la classe n’est pas enregistrée » liée à COM/ActiveX suit le même schéma : elle s’observe comme un NAME NOT FOUND sur un RegOpenKey sous une clé CLSID. Pour l’accident classique où une confusion entre 32 et 64 bits fait consulter la mauvaise vue du registre, ProcMon reste la voie la plus rapide, comme décrit dans la procédure de « Pourquoi ActiveX ne fonctionne pas sous Office 2024/Microsoft 365 : causes et procédure de vérification ».

5.3 « J’obtiens un ACCESS DENIED » — s’interroger sur l’identité utilisée pour l’exécution

Lorsque vous trouvez un ACCESS DENIED, double-cliquez sur cet événement pour consulter l’onglet Process. On y voit sous quel utilisateur ce processus s’exécutait, ce qui permet de repérer un décalage tel que « le service tournait sous un compte de service restreint, et non sous SYSTEM » ou « seul le lancement via le planificateur de tâches utilisait un autre utilisateur ». Si la cible est un fichier, confronter cette information avec l’ACL du chemin en question permet de confirmer la cause. Notez aussi que, lorsqu’un antivirus intervient, on voit souvent un autre processus (le moteur de l’antivirus) toucher au même chemin juste avant ou juste après — une preuve elle aussi propre à ProcMon, grâce à son enregistrement chronologique.

5.4 « Le traitement de fichier échoue de temps en temps » — rechercher l’auteur d’un SHARING VIOLATION

Une violation de partage est une investigation où la chronologie est primordiale. En capturant avec un Include sur le chemin, sans filtrer par processus, on voit apparaître, dans les lignes qui précèdent et qui suivent l’instant de l’échec, qui avait ouvert le même fichier. Les suspects habituels sont un logiciel de sauvegarde, un antivirus, ou un processus Excel résiduel. La conception permettant d’éviter ce type de conflit dès la base dans un échange de fichiers est traitée dans « Notions de base sur le contrôle d’exclusion mutuelle des échanges de fichiers », et le problème des processus Excel qui restent en mémoire est traité dans « Le problème d’EXCEL.EXE qui persiste lors de l’interop Excel en C# ». Précisons enfin que, si l’on veut simplement savoir « qui retient ce fichier à cet instant précis », la recherche de handle (Ctrl+F) de Process Explorer est plus rapide que ProcMon.³

5.5 « Le démarrage est lent » — repérer où le temps est consommé

En ajoutant la colonne Duration dans la configuration des colonnes, on voit le temps pris par chaque opération individuelle. Le menu Tools propose aussi Process Activity Summary et File Summary, qui permettent d’agréger le nombre d’opérations et le temps passé par processus ou par fichier. Cela suffit largement pour des constats comme « des dizaines de milliers de lectures de registre au démarrage » ou « un accès à un chemin réseau qui attendait jusqu’au timeout ». En revanche, le profilage approfondi de la consommation CPU n’est pas du ressort de ProcMon. Si la lenteur vient du calcul et non des I/O, on passe le relais à PerfView et dotnet-trace.

5.6 Problèmes au démarrage ou à l’ouverture de session — la journalisation au démarrage (boot logging)

Pour les cas où le problème survient avant même qu’on puisse lancer ProcMon manuellement — « un service échoue avant l’ouverture de session », « une application enregistrée au démarrage ne se lance pas » — on utilise Enable Boot Logging dans le menu Options. Les événements sont enregistrés dès le tout début du démarrage suivant, et au prochain lancement de ProcMon, une sauvegarde est proposée. La journalisation au démarrage est une fonctionnalité officielle de ProcMon,¹ et c’est le seul œil disponible pour les investigations liées à l’ordre de démarrage ou aux scripts d’ouverture de session.

6. Enregistrer et transmettre le journal — quand la capture doit être faite chez le client

Dans la pratique de l’investigation de bugs, il n’est pas rare que l’environnement où le problème se reproduit n’existe que chez le client. Le journal de ProcMon peut être sauvegardé sous forme de fichier PML, et même ouvert sur une autre machine, toutes les colonnes et tous les détails restent visibles ; cela permet une répartition du travail du type « le client effectue la capture, et nous l’analysons de notre côté ». Voici la forme que prend notre procédure lorsque nous la demandons au client :

1. Exécuter Procmon.exe en tant qu’administrateur et accepter le contrat de licence
2. Une fois lancé, arrêter d’abord la capture avec Ctrl+E, puis effacer l’affichage avec Ctrl+X
3. Démarrer la capture avec Ctrl+E, puis reproduire l’opération problématique
4. Dès que le problème est reproduit (ou qu’une erreur apparaît), arrêter immédiatement avec Ctrl+E
5. Dans File > Save, choisir All events plutôt qu’Events displayed using current filter, sauvegarder au format PML, compresser en ZIP et l’envoyer

Le point clé est le « All events » de l’étape 5. Même si un filtre est resté actif à l’écran du côté du client, l’enregistrement complet existe bel et bien, ce qui nous permet de refiltrer librement de notre côté. Pour les problèmes longs à reproduire ou dont on ignore le moment d’apparition, laisser la capture tourner ainsi continuerait à consommer de la mémoire ; il faut donc préciser au moins l’une des deux options suivantes : activer Filter > Drop Filtered Events pour ne conserver que le processus ciblé, ou basculer, via File > Backing Files, la destination d’enregistrement vers un fichier plutôt que vers la mémoire virtuelle. Faire tourner la capture toute une nuit sans connaître ces deux options épuise la mémoire, et ProcMon atteint ses limites avant même que le problème étudié ne se manifeste.

Pour automatiser, on peut aussi utiliser des paramètres en ligne de commande : /AcceptEula pour supprimer la boîte de dialogue de consentement, /BackingFile pour indiquer le fichier de destination de l’enregistrement, /Runtime pour un arrêt automatique après un nombre de secondes donné, /Terminate pour fermer une instance de ProcMon en cours d’exécution. En combinant ces options, on peut arriver à une situation où « l’opérateur exécute un seul script au moment de l’incident, et la preuve est conservée ». Cette idée de décider à l’avance ce qu’il faut collecter en cas d’incident est commune avec la collecte des dumps de crash et la conception du journal des événements.

7. Limites de ProcMon et répartition des rôles avec d’autres outils

ProcMon est un outil qui observe la « chronologie des opérations » ; il ne convient pas à toutes les investigations. Voici comment nous répartissons les rôles dans nos investigations.

Voici les trois cas limites où l’on hésite le plus souvent.

• Réseau : ProcMon enregistre les événements de connexion et d’envoi/réception TCP/UDP (quel processus a communiqué avec qui), mais le contenu des paquets n’est pas visible. Pour l’investigation au niveau du protocole, tournez-vous vers Wireshark ou pktmon, l’outil standard de Windows.⁴
• Mémoire : « la consommation mémoire augmente continuellement » ne peut pas se suivre avec ProcMon. Pour un tas managé, passez à la procédure de distinction entre GC et fuite mémoire ; pour les handles, à celle de l’investigation de fuite de handles.
• Pile d’appel : en réalité, ProcMon enregistre aussi, pour chaque événement, la pile d’appel du thread émetteur (double-cliquer sur l’événement puis onglet Stack), et en configurant les symboles, on peut identifier au niveau du code « qui a émis cet accès fichier ». Arrivé là, on rejoint directement le monde de WinDbg, où la gestion des symboles (PDB) devient déterminante.

8. Résumé — « regarder les faits avant de lire le code »

Face à un bug dépendant de l’environnement, la première chose à faire n’est ni de lire le code, ni de formuler des hypothèses, mais d’enregistrer ce qui s’est réellement passé. ProcMon est le chemin le plus court pour cela : en une minute d’installation et quelques minutes de capture, on obtient les faits incontestables — quels chemins ont été touchés, dans quel ordre, sous quels droits, et ce qui a échoué. En maîtrisant ces trois points — le filtrage en deux étapes (processus puis Result), la lecture des valeurs de Result qui paraissent anormales mais sont normales, et la transmission avec sauvegarde de tous les événements — une investigation bloquée sur « ça ne se reproduit pas sur la machine de développement » peut avancer d’un cran dans la journée même.

Nous prenons en charge l’investigation de bugs dont les conditions de reproduction sont inconnues, la mise en place de procédures de collecte de preuves pour les incidents qui ne surviennent que chez le client, ainsi que l’analyse des causes en combinant ProcMon, WinDbg et PerfView. Nous pouvons intervenir même dès le stade où « rien n’apparaît dans les journaux, mais ça ne fonctionne pas ».

Articles connexes

• Lire un dump de crash avec WinDbg + SOS — introduction pratique à l’analyse après la collecte
• Identifier une « lenteur » avec PerfView et dotnet-trace — introduction pratique à l’investigation de performance .NET
• Introduction à la collecte des dumps de crash Windows — WER/ProcDump/WinDbg
• Le mécanisme de résolution de noms de DLL sous Windows — ordre de recherche et SxS
• Investigation d’un crash après fonctionnement prolongé d’une caméra industrielle — volet fuite de handles

Domaines de conseil associés

KomuraSoft LLC (合同会社小村ソフト) prend en charge l’investigation des causes de bugs dépendants de l’environnement et difficiles à reproduire, la mise en place de procédures de collecte de preuves en cas d’incident, ainsi que l’accompagnement au dépannage d’applications Windows existantes.

• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Modification et maintenance de logiciels Windows existants
• 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.

Peut-on faire tourner ProcMon en toute sécurité en environnement de production ?

Une capture de courte durée est une pratique courante, mais ce n'est pas sans risque pour autant. ProcMon charge un pilote et enregistre un très grand nombre d'événements, ce qui consomme de façon visible le CPU et la mémoire sur les serveurs à fort volume d'événements. Trois précautions s'imposent : (1) démarrer juste avant l'opération de reproduction et arrêter immédiatement après, afin de réduire au minimum la durée de capture ; (2) si une surveillance prolongée est nécessaire, activer Drop Filtered Events dans le menu Filter pour ne pas conserver les événements hors filtre ; (3) configurer un Backing File afin que l'enregistrement se fasse sur un fichier plutôt qu'en mémoire. Il est également recommandé de faire passer cette opération par le même processus d'approbation qu'un changement standard — par exemple en dehors des heures ouvrées ou juste après la prise d'un instantané (snapshot).

Il y a trop d'événements et je n'arrive pas à trouver la ligne qui m'intéresse. Comment filtrer efficacement ?

La méthode classique consiste d'abord à appliquer un Include sur Process Name pour ne garder que le processus visé, puis à restreindre sur Result aux cas anormaux (NAME NOT FOUND, ACCESS DENIED, etc.). Une fois qu'une ligne pertinente est trouvée, on peut affiner de façon interactive en faisant un clic droit dessus pour choisir Include ou Exclude. À l'inverse, l'erreur classique consiste à enregistrer le journal alors qu'un filtre est encore actif, et à se retrouver avec des informations insuffisantes : lorsque vous sauvegardez le journal dans un fichier pour le transmettre à quelqu'un d'autre, gardez à l'esprit que le filtre n'est qu'une restriction d'affichage, et enregistrez bien tous les événements. Par ailleurs, la configuration du filtre est conservée au prochain démarrage : si « rien ne s'affiche », pensez à vérifier qu'un ancien filtre de la session précédente n'est pas resté actif, via Reset Filter dans le menu Filter.

Un BUFFER OVERFLOW dans la colonne Result est-il le signe d'un bug ou d'une attaque ?

Non. Cela n'a aucun rapport avec l'attaque par débordement de tampon au sens de la sécurité informatique : il s'agit d'un aller-retour d'API tout à fait normal, où « les données nécessaires étaient plus grandes que le tampon fourni par l'appelant, donc l'API a renvoyé la taille requise ». De nombreuses API sont conçues pour être appelées une première fois avec un petit tampon afin d'obtenir la taille nécessaire, puis rappelées après une nouvelle allocation ; si un SUCCESS sur le même chemin suit immédiatement, il n'y a aucun problème. De la même façon, NAME NOT FOUND signifie souvent simplement que « l'élément n'a pas été trouvé à cette étape de l'ordre de recherche », et ce n'est pas anormal si un SUCCESS finit par apparaître quelque part. Un Result appartenant aux cas anormaux ne peut être qualifié de cause réelle qu'après avoir vérifié que l'échec de cette opération est bien lié causalement au symptôme observé dans l'application.

Comment répartir l'usage entre Process Explorer et Process Monitor ?

Process Monitor est un outil qui enregistre chronologiquement le « déroulement des opérations » (quand, quel processus, sur quel chemin, quelle action, quel résultat), tandis que Process Explorer permet d'observer « l'état à l'instant présent » (quels fichiers ou DLL sont ouverts par quel processus, utilisation du CPU et de la mémoire). Par exemple, si vous voulez savoir « je n'arrive pas à supprimer ce fichier, qui le retient ? », la recherche de handle de Process Explorer est la voie la plus rapide ; si vous voulez savoir « quand et dans quel ordre l'application lit-elle ce fichier ? », c'est Process Monitor qu'il faut utiliser. En pratique, on garde les deux sous la main au sein de la Sysinternals Suite, et il suffit de retenir : l'état avec Process Explorer, l'historique avec Process Monitor.

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.