Pièges d'enregistrement et de bitness dans le développement COM/OCX/ActiveX

Dans les projets COM ou OCX / ActiveX, ce qui pose problème se situe plus souvent aux frontières de l’environnement d’exécution, de l’enregistrement, de l’hôte et des droits que dans le code lui-même.

Les symptômes typiques ressemblent à ceci.

• La build passe, mais au démarrage vous obtenez 0x80040154.
• Ça fonctionne sur votre poste de développement, mais pas sur d’autres PC.
• Ça tourne bien à l’exécution, mais seul le Designer de Visual Studio meurt.
• Ça fonctionne lorsqu’on lance en administrateur, mais casse avec des droits normaux.
• Vous avez beau lancer regsvr32, rien ne se répare.

Il ne s’agit pas de bugs isolés, mais d’un état où une hypothèse de COM n’est plus satisfaite quelque part.

Si vous souhaitez d’abord clarifier la terminologie elle-même — COM / ActiveX / OCX — commencez par Qu’est-ce que COM / ActiveX / OCX ? — Différences et relations expliquées ensemble pour avoir une vue d’ensemble. Cet article traite l’étape suivante : où l’on se retrouve concrètement bloqué, en couvrant aussi la bitness de Visual Studio et les questions de droits administrateur.

1. La conclusion d’abord

Pour formuler cela de façon directement utile en pratique :

1. Les problèmes COM / OCX / ActiveX viennent plus souvent d’une incohérence de bitness (32 bits / 64 bits), d’emplacement d’enregistrement, d’hôte et de droits que de la logique du code.
2. Visual Studio 2022 est un processus 64 bits, donc l’intégration en mode design qui supposait du 32 bits et qui fonctionnait autrefois casse telle quelle.¹²
3. regsvr32 n’est pas une commande magique qui enregistre n’importe quoi. Il est destiné aux serveurs COM in-proc natifs (DLL / OCX). Pour exposer .NET Framework à COM, on utilise Regasm.exe ; pour .NET 5+ / .NET 6+ / .NET 8+, le flux consiste à enregistrer le .comhost.dll généré.³⁴⁵⁶
4. « Ça marche en administrateur, donc c’est bon » est dangereux. Il n’est pas rare que le composant soit visible seulement par hasard grâce à un enregistrement per-user, ou qu’un enregistrement qui devrait normalement être fait par l’installateur n’ait été réalisé à la main que sur le poste de développement.³⁷⁸

Autrement dit, pour manipuler COM / OCX / ActiveX, il est plus sûr d’examiner d’abord ces quatre axes.

• Quel processus héberge le composant
• Ce processus est-il en 32 bits ou en 64 bits
• Où est-il enregistré (HKCU / HKLM, vue 32 bits / vue 64 bits)
• L’opération ou l’exécution nécessite-t-elle des droits administrateur

2. En partant des symptômes, voici ce qu’on trouve généralement

Officiellement, 0x80040154 correspond à REGDB_E_CLASSNOTREG, littéralement Class not registered.⁹ De même, le 0x80070005 de regsvr32 est officiellement décrit comme le cas où l’absence de droits administrateur empêche d’écrire dans le registre ou dans System32.¹⁰

Ce qui compte ici, c’est de ne pas se fier aveuglément au nom de l’erreur. Par exemple, Class not registered ne signifie pas forcément « totalement non enregistré » — cela se produit aussi lorsque le composant est enregistré dans une autre vue de registre, ou enregistré dans un emplacement visible seulement par cet utilisateur.¹¹⁷

3. Le piège de la bitness de Visual Studio

3.1. Visual Studio 2022 est passé en 64 bits

C’est le point sur lequel on bute le plus souvent aujourd’hui en développement COM / ActiveX.

Dans Visual Studio 2022, devenv.exe est exclusivement en 64 bits.¹ En conséquence, dans l’expérience de conception WinForms, Visual Studio lui-même ne peut pas charger directement des composants 32 bits. Microsoft précise d’ailleurs explicitement que, Visual Studio 2022 étant un processus 64 bits, il ne peut pas charger de composants .NET / COM / ActiveX 32 bits.²

Autrement dit, ce qui tenait auparavant à peu près, sous les hypothèses suivantes,

• le projet est en x86
• l’ActiveX référencé est aussi en x86
• Visual Studio lui-même est en 32 bits

se retrouve, sous VS2022, dans cette situation tordue :

• l’application peut toujours s’exécuter en x86 au runtime
• mais le Designer tourne du côté du Visual Studio 64 bits

Le résultat est un état assez désagréable où l’application reste vivante à l’exécution alors que seul le Designer plante.²

3.2. Passer en AnyCPU ne résout pas forcément le problème

C’est aussi un malentendu courant.

AnyCPU n’est pas une formule magique qui rend neutres jusqu’à vos dépendances. Comme l’explique Microsoft, même un composant qui a l’air d’être en AnyCPU pose problème au moment de la conception sous Visual Studio 2022 s’il référence, plus loin dans la chaîne, un composant COM / ActiveX fixé en 32 bits.²

Donc, lorsque passer en AnyCPU ne fait pas disparaître l’erreur, il est plus rapide de suspecter :

• une dépendance native 32 bits plus loin dans cet assembly
• un ActiveX / OCX fixé en x86
• du code qui n’est chargé qu’au moment de la conception (Designer)

3.3. Le piège de System32 et SysWOW64

Sous Windows x64, l’impression donnée par les noms ne correspond pas à la réalité, ce qui prête facilement à confusion.

Microsoft Learn explique que, sous Windows x64, %windir%\System32 est destiné aux applications 64 bits. Le côté 32 bits est redirigé ailleurs par le redirecteur de système de fichiers WOW64.¹² Le registre fonctionne de la même façon : le redirecteur de registre WOW64 présente des vues logiques distinctes au 32 bits et au 64 bits.¹¹

C’est pourquoi, lors d’un diagnostic local, il est plus sûr d’expliciter quelle bitness de regsvr32 vous utilisez.

# Pour enregistrer une DLL / un OCX 64 bits
C:\Windows\System32\regsvr32.exe vendor.ocx

# Pour enregistrer une DLL / un OCX 32 bits sous Windows x64
C:\Windows\SysWOW64\regsvr32.exe vendor.ocx

Ce qui rend ce piège désagréable, c’est que si vous enregistrez du mauvais côté, le composant reste invisible pour le processus visé alors même que vous pensiez l’avoir enregistré. Le résultat ressemble à ceci :

• regsvr32 a réussi
• mais l’application renvoie quand même 0x80040154
• le registre semble contenir l’entrée
• mais vous regardez en fait une autre vue

¹¹¹³

3.4. regsvr32 ne peut pas tout enregistrer

C’est aussi une zone riche en malentendus.

Un serveur COM in-proc natif prend normalement en charge l’auto-enregistrement en exportant DllRegisterServer / DllUnregisterServer.³ regsvr32 est l’outil destiné à ce type de DLL / OCX.⁴

En revanche, si vous voulez utiliser depuis COM un assembly .NET Framework, l’outil de base est Regasm.exe. Microsoft Learn explique de même que Regasm.exe sert à enregistrer les assemblies utilisés avec COM.⁵¹⁴

De plus, l’exposition COM en .NET 5+ / .NET 6+ / .NET 8+ fonctionne un peu différemment : en configurant <EnableComHosting>true</EnableComHosting> puis en compilant, un fichier *.comhost.dll est généré, et c’est celui-ci que l’on enregistre avec regsvr32.⁶

En résumé, cela se répartit ainsi :

Mélanger ces distinctions produit souvent ce schéma :

• appliquer regsvr32 à une DLL managée
• DllRegisterServer est naturellement introuvable
• on en conclut, à tort, que « la DLL est cassée »

Dans le monde qui a besoin d’une bibliothèque de types (VBA / VB6 / certains clients à liaison anticipée), la génération et l’enregistrement du TLB constituent en outre un problème à part. Avec .NET Framework, on peut générer et enregistrer une bibliothèque de types via Regasm.exe /tlb, et Microsoft explique lui-même que « l’enregistrement des types » et « l’enregistrement de la bibliothèque de types » sont deux activités distinctes.¹⁵

4. Le piège des droits administrateur

4.1. Un enregistrement en post-build qui ne réussit qu’en administrateur

Dans les builds C++ de Visual Studio, appeler regsvr32.exe depuis un build event ou une custom build step est tout à fait possible. Microsoft Learn cite d’ailleurs l’enregistrement via regsvr32.exe comme exemple de post-build event.¹⁶

Cependant, ce qui est possible et ce qui est sûr sont deux choses différentes.

Exécuter regsvr32 avec un utilisateur standard peut échouer avec 0x80070005, faute de pouvoir écrire dans le registre ou dans System32. La base de connaissances de Microsoft impute elle aussi cette cause à l’absence de droits administrateur.¹⁰

Ce qui tend à se produire ici :

• lancer Visual Studio avec des droits normaux laisse passer la build
• mais seul l’enregistrement en post-build échoue
• l’échec passe inaperçu dans le journal
• l’ancien enregistrement précédent est encore en place, donc ça fonctionne par hasard en local
• sur un environnement propre, cela ne fonctionne évidemment pas

Ce type d’incident est fréquent.

Pour ce genre de projet, la règle de base est de séparer la build de l’enregistrement.

• La build ne fait que produire les binaires
• L’enregistrement se fait via une étape d’installation, un script ou un installateur explicites
• En CI, placez les « étapes nécessitant un enregistrement » dans un job distinct de la build

Cette seule séparation réduit considérablement les incidents.

4.2. Mélanger enregistrement per-user et per-machine casse tout

Si votre seul modèle mental est « COM regarde HKCR », c’est ici que vous vous bloquez.

En réalité, comme l’indique Microsoft Learn, COM regarde d’abord HKEY_CURRENT_USER\Software\Classes, puis traite les informations valables pour l’ensemble de la machine.³ Par ailleurs, HKEY_CLASSES_ROOT est une vue fusionnée de HKLM\Software\Classes et HKCU\Software\Classes.⁷¹⁷

Autrement dit, il est courant que :

• le développeur A ait enregistré le composant manuellement sous son propre utilisateur
• cela fonctionne sous le compte de A
• cela ne fonctionne pas pour le développeur B
• cela ne fonctionne pas non plus pour le compte de service
• le comportement change si on l’exécute en administrateur

De plus, Microsoft indique que les applications nécessitant des droits administrateur devraient enregistrer leurs objets COM dépendants dans le magasin de configuration COM per-machine au moment de l’installation.⁸⁷

C’est pourquoi, sur le terrain, il faut clarifier explicitement cette distinction :

• s’agit-il d’un enregistrement de développement réservé à votre propre utilisateur ?
• s’agit-il d’un enregistrement de production utilisé par tous les utilisateurs de cette machine ?
• s’agit-il d’un enregistrement consulté par un service ou une application élevée ?

Laisser ce point flou mène à des situations du type « ça ne marche que sous administrateur, allez savoir pourquoi » ou « ça marche dans l’extension Explorer mais pas dans le service ».

4.3. Toujours lancer Visual Studio « en tant qu’administrateur » n’est pas une solution

Il existe effectivement des cas où c’est nécessaire. Mais garder Visual Studio en permanence lancé en administrateur peut masquer, derrière l’élévation de l’IDE, un problème qui devrait normalement être résolu par un installateur ou un script d’enregistrement.

De plus, Visual Studio lui-même traite différemment les extensions per-user lorsqu’il est élevé. Microsoft Learn décrit un paramètre selon lequel exécuter Visual Studio en mode élevé désactive les extensions per-user.¹⁸

Il vaut donc mieux, en pratique :

• faire le développement courant avec des droits normaux
• réserver les étapes nécessitant un enregistrement à une invite de commandes développeur / PowerShell / un installateur explicitement élevés
• si un problème « ne se reproduit qu’en administrateur », traiter cette prémisse elle-même comme un point à formaliser dans les spécifications

Cela évite bien des ennuis par la suite.

5. Pièges spécifiques à ActiveX / OCX

5.1. La licence de conception et la licence d’exécution sont distinctes

Un aspect discrètement pénible d’OCX / ActiveX est la licence.

En particulier avec les anciens contrôles ActiveX, la licence de conception (design-time) et la licence d’exécution (run-time) peuvent être distinctes. La documentation MFC sur ActiveX décrit elle aussi ce mécanisme séparant design-time et run-time via des fichiers de licence et des clés de licence.¹⁹²⁰

Dans ce monde-là, on rencontre des situations comme :

• le composant fonctionne à l’exécution
• mais en essayant de le déposer sur un formulaire, on obtient « licence introuvable »
• il peut être déposé sur le poste de développement A
• mais pas sur le poste de développement B

Les erreurs du type « les informations de licence de ce composant sont introuvables » ou « vous ne disposez pas de la licence appropriée » ne sont pas rares avec les anciens ActiveX.²¹

5.2. Dès qu’il est déposé sur WinForms, un wrapper est déjà en jeu

Lorsqu’on utilise ActiveX depuis WinForms, Windows Forms n’héberge pas directement l’ActiveX. Comme le décrit la documentation Microsoft Learn d’Aximp.exe, l’ActiveX Control Importer génère un wrapper WinForms à partir de la bibliothèque de types COM, puis le traite comme un contrôle basé sur AxHost.²²²³

Le problème ne se limite donc pas à une seule couche, mais se répartit sur plusieurs :

1. l’OCX / ActiveX d’origine lui-même
2. la bibliothèque de types
3. l’interop / le wrapper généré
4. le Designer / runtime WinForms

D’où des situations comme :

• remplacer l’OCX du fournisseur a changé les signatures d’événements
• réajouter la référence a régénéré le wrapper et produit un énorme diff
• le résultat de génération de l’interop diffère subtilement d’un poste de développement à l’autre

Le voir apparaître dans Choose Toolbox Items ne suffit pas à rassurer. Il est plus sûr de vérifier séparément si le Designer peut le déposer, si les événements arrivent bien à l’exécution, et si le wrapper tient debout, avec tout ce qu’il embarque, sur l’environnement de déploiement cible.

5.3. Sous-estimer STA / MTA et la boucle de messages fait tout se figer

COM doit être initialisé via CoInitializeEx sur chaque thread qui l’utilise. Microsoft Learn précise explicitement que chaque thread utilisant COM doit appeler CoInitializeEx individuellement.²⁴

Par ailleurs, un STA (single-threaded apartment) nécessite une boucle de messages.²⁴²⁵

Les OCX / ActiveX orientés UI supposent particulièrement souvent un STA, d’où le schéma désagréable suivant :

• ça fonctionne sur le thread UI
• ça se fige lorsqu’on l’envoie vers Task.Run ou le ThreadPool
• les événements ne reviennent jamais
• ça ne se reproduit que de temps en temps

Un bug pénible s’ensuit.

De plus, en STA, il existe la règle selon laquelle on ne doit pas simplement copier un pointeur d’interface vers un autre thread — il faut le marshaler si nécessaire.²⁴²⁵

Ce type d’anomalie est bien moins explicite que 0x80040154 : tout ce que vous voyez, ce sont des blocages, des absences de réponse, des plantages occasionnels, ce qui fait perdre autant de temps que les problèmes liés au registre.

6. L’ordre de diagnostic qui fonctionne sur le terrain

En pratique, plutôt que de foncer directement dans les détails, découper le problème dans cet ordre est plus rapide.

6.1. D’abord, fixer « quel processus, quelle bitness »

C’est le premier point à examiner.

• Quel est l’hôte (Designer de Visual Studio / votre propre application / Office / Access / Explorer / un environnement de compatibilité navigateur)
• Cet hôte est-il en 32 bits ou en 64 bits
• Le DLL / OCX ciblé est-il en 32 bits ou en 64 bits
• Est-il in-proc ou out-of-proc

Si vous commencez à examiner le registre alors que ce point reste flou, vous vous perdez presque à coup sûr.

6.2. Ensuite, vérifier « le type d’enregistrement »

Le point suivant à vérifier est avec quoi il convient d’enregistrer quoi.

• DLL / OCX natif → regsvr32
• Exposition COM .NET Framework → Regasm.exe
• Exposition COM .NET 5+ / 6+ / 8+ → .comhost.dll
• Une DLL qui, de toute façon, ne dispose pas d’auto-enregistrement → ce n’est pas un cas pour regsvr32

Cette seule classification permet d’arrêter une bonne partie des erreurs de tir.

6.3. Puis, regarder « où l’enregistrement a eu lieu »

Se contenter de regarder HKCR ne suffit pas. Il faut vérifier :

• HKCU\Software\Classes
• HKLM\Software\Classes
• les vues de registre 32 bits / 64 bits si nécessaire
• le ProgID / CLSID / TypeLib visé
• InprocServer32 / LocalServer32
• le ThreadingModel
• le chemin réel de la DLL référencée

Constater que « c’est présent dans HKCR » ne suffit pas — cela ne prend son sens que lorsqu’on précise aussi depuis où, avec quelle bitness et à travers quelle vue on regarde.⁷¹¹

6.4. Enfin, vérifier si les droits ne masquent pas le problème

Enfin, vérifiez si le problème vient réellement des droits, ou si les droits font simplement apparaître un enregistrement différent.

• Le comportement change-t-il entre utilisateur standard et administrateur
• Que change l’élévation de Visual Studio
• Le problème se reproduit-il avec un compte de service ou un autre utilisateur
• Tient-il aussi dans un environnement propre provisionné via l’installateur

Si vous n’avez observé qu’un seul poste de développement, c’est ici que vous risquez vraiment de vous tromper.

7. Des décisions d’exploitation prises en amont réduisent les incidents

Dans le développement et la maintenance COM / ActiveX / OCX, la façon de décider du fonctionnement compte parfois plus que les techniques d’implémentation.

7.1. Décider d’abord la politique de bitness

Décidez ceci en premier.

• Restez-vous fixé en x86
• Le x64 est-il la référence
• Prenez-vous en charge les deux
• Ce composant doit-il impérativement être in-proc

Si un OCX du fournisseur est fixé en x86 en particulier, ignorer ce point et passer uniquement l’application en x64 vous bloquera plus tard. Ce sujet, en tant que question d’architecture plus large, rejoint aussi Comment appeler une DLL 64 bits depuis une application 32 bits — étude de cas où un pont COM aide.

7.2. Décider la stratégie d’enregistrement

Là aussi, mieux vaut ne pas procéder au coup par coup.

• Utilisation à l’échelle de la machine → enregistrement per-machine via l’installateur
• Utilisation réservée à un utilisateur → utiliser délibérément le per-user
• Usage limité à votre propre application → envisager le COM sans enregistrement (registration-free COM)
• Nécessaire seulement pour le développement → le confiner dans un script de configuration de développement explicite

Le registration-free COM permet de porter les informations d’activation dans un manifeste plutôt que dans le registre, ce qui en fait un moyen efficace de réduire l’enfer de l’enregistrement. Le registration-free COM côté Win32 comme le RegFree COM côté .NET sont tous deux documentés officiellement.²⁶⁶²⁷

7.3. Ne pas laisser trop d’artefacts en dehors du contrôle de version

Un piège fréquent dans le monde OCX / ActiveX est la dispersion des dépendances.

• l’OCX lui-même
• les DLL dont il dépend
• le TLB
• le fichier .lic
• la DLL d’interop
• le wrapper AxHost
• les scripts d’enregistrement
• un hôte d’exemple

Si tout cela ne réside que sur le poste local de quelqu’un, un incident se produira à coup sûr quelques mois plus tard.

Au minimum, conservez au même endroit que le code :

• quelle version est présumée
• quoi installer, et dans quel ordre
• quelle commande effectue l’enregistrement
• si c’est destiné à x86 ou x64

8. Ce type de sujet se prête bien à ces consultations

Sur ce thème, le simple fait de faire une triage et une clarification de politique, avant de se lancer dans une refonte complète, apporte souvent déjà de la valeur.

Par exemple, cela s’accorde particulièrement bien avec des consultations comme :

• vous voulez trier les causes de 0x80040154 ou 0x80070005 entre bitness / enregistrement / droits
• le Designer a cassé après la mise à niveau vers Visual Studio 2022 et vous voulez voir jusqu’où c’est récupérable
• vous voulez conserver un OCX du fournisseur tout en rapprochant l’environnement vers .NET et C#
• vous voulez décider jusqu’où prolonger des actifs fixés en x86, et à partir d’où ponter / envelopper / remplacer
• vous voulez arrêter de dépendre d’un regsvr32 lancé à la main et reconcevoir l’installation / le déploiement

Pour la décision conserver / envelopper / remplacer elle-même, Comment traiter ActiveX / OCX aujourd’hui — Tableau de décision conserver, envelopper, remplacer devrait aussi être utile.

9. Résumé

Lorsqu’on bute sur du développement de composants COM ou OCX / ActiveX, la cause se ramène presque toujours à l’une de ces quatre choses :

1. la bitness ne correspond pas
2. la méthode d’enregistrement est erronée
3. la portée d’enregistrement (HKCU / HKLM, vue 32 bits / 64 bits) est décalée
4. un état qui n’est visible que par hasard grâce aux droits est confondu avec un état normal

Avec le passage au 64 bits de Visual Studio 2022, les conceptions du passé qui « fonctionnaient tant bien que mal » sont devenues bien plus faciles à mettre en évidence.¹² C’est justement pour cela que, en touchant à COM / OCX / ActiveX, le raccourci consiste à aligner les hypothèses de l’environnement avant même d’écrire du code.

Plutôt que de compter le nombre de fois où vous lancez regsvr32, il est bien plus rapide de résoudre le problème en clarifiant :

• quel processus héberge le composant
• quelle est sa bitness
• où l’enregistrement doit avoir lieu
• si cet enregistrement suppose réellement des droits administrateur
• si vous examinez séparément le Designer et le runtime

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.

Comment enquêter sur 0x80040154 (Class not registered) ?

Officiellement, il s'agit de REGDB_E_CLASSNOTREG, littéralement une erreur de « classe non enregistrée », mais cela ne signifie pas forcément que le composant est totalement non enregistré. Cela peut aussi se produire lorsque le composant n'est enregistré que dans la vue de registre de l'autre bitness, ou uniquement du côté HKCU, visible seulement pour cet utilisateur. Le plus rapide est d'abord de déterminer si le processus hôte est en 32 bits ou en 64 bits, puis de vérifier si la méthode d'enregistrement est correcte, et enfin de contrôler où l'enregistrement a eu lieu — HKCU / HKLM et vue 32 bits / 64 bits.

Pourquoi l'enregistrement avec regsvr32 ne fonctionne-t-il pas malgré tout ?

regsvr32 est destiné aux serveurs COM in-proc natifs (DLL / OCX) qui exportent DllRegisterServer ; ce n'est pas une commande magique capable de tout enregistrer. Pour exposer un assembly .NET Framework à COM, on utilise Regasm.exe ; à partir de .NET 5, le flux consiste à enregistrer avec regsvr32 le fichier .comhost.dll généré via EnableComHosting. Par ailleurs, sous Windows x64, il faut utiliser le bon regsvr32 selon la cible — celui de System32 pour le 64 bits, celui de SysWOW64 pour le 32 bits — car un enregistrement effectué du mauvais côté réussit en apparence tout en restant invisible pour le processus visé.

Pourquoi seul le Designer casse-t-il sous Visual Studio 2022 ?

Parce que devenv.exe, sous Visual Studio 2022, est un processus 64 bits qui ne peut pas charger directement des composants COM / ActiveX 32 bits. Même si l'application s'exécute correctement en x86 au runtime, le Designer, lui, tourne dans le processus 64 bits de Visual Studio, d'où ce décalage où l'application reste vivante à l'exécution alors que seul le Designer plante. Passer en AnyCPU ne règle pas non plus le problème si, plus loin dans les dépendances, un composant COM / ActiveX reste fixé en 32 bits.

Pourquoi le composant fonctionne-t-il en tant qu'administrateur, mais pas avec des droits normaux ?

Le fond du problème n'est le plus souvent pas les droits eux-mêmes, mais un décalage dans la portée de l'enregistrement ou dans la conception de l'installation. COM consulte d'abord HKCU\Software\Classes, et HKEY_CLASSES_ROOT est une vue fusionnée de HKLM et de HKCU. Si le développeur A a enregistré le composant manuellement sous son propre compte, il est courant que cela fonctionne pour A mais pas pour un autre développeur ni pour un compte de service. La bonne pratique consiste à distinguer l'enregistrement per-user réservé au développement de l'enregistrement per-machine réalisé en production par l'installateur, et à séparer la construction (build) de l'enregistrement.

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.