DLL interfaces com : conflits possibles ?

bonjour,

j'utilise une application commerciale dans laquelle je peux ajouter des DLL qui implémentent des interfaces COM. Pour que cette application puisse "voir" ces DLL un GUID est nécessaire.

J'ai ajouté à ce logiciel deux DLLs réalisées sous Visual Studio.

1- j'ai ajouté la 1ère DLL et je n'ai pas eu de souci de fonctionnement de l'ensemble (Software + DLL)
2- J'ai ensuite ajouté la seconde DLL et là j'ai eu des soucis de fonctionnement.
3- J'ai supprimé la seconde DLL, mais malheureusement les soucis persistent. :koi:

Le problème en question est un problème de timing : le software doit normalement envoyer des événements à un temps fixé très précisément (à la milliseconde près). Après l'ajout de ces DLL, ces timings ne sont plus respectés, il viennent trop tard.


> la 1ère DLL est réalisée chez un de nos fournisseurs, je n'ai pas le code source.
> la 2nde DLL est de moi, j'ai le code source.
J'ajoute que ces deux dll utilisent toutes les deux des sockets, mais ne se connectent pas sur les mêmes machines distantes (IP différentes).


Ma question est la suivante : avant l'insertion de ma DLL, je n'avais pas de soucis, après l'insertion les problèmes sont apparus. Malgré la suppression de la DLL (suppression de son enregistrement de la base de registre, renommage de la DLL, redémarrage de la machine...) les problèmes de timing persistent.

Avez-vous des idées sur l'origine de mon problème ?

Bonsoir.

As-tu pu monitorer le réseau avec un sniffer dans le style Wireshark ? (lors de l'envoie de messages via l'application en question).
Ça peux toujours fournir des pistes de recherche.

En tout cas, bon courage :aie: .

Cordialement,
Idriss

bonsoir,

il y a moyen de voir avec Wireshark si le réseau est saturé ? Si oui comment ?

Re bonjour.

Bon c'est pas trop mon domaine, mais oui entre autre on peut voir si le réseau est "saturé", si des paquets se perdent, si l'application émet trop tardivement, ...

En parallèle, un ping permettrai aussi d'évaluer la latence de la machine d'où émet l'application ... c'est peut être une cause possible également.

Cordialement,
Idriss

Bonjour,

Comment sont vérifiés les timing ? À la réception des paquets sur les serveurs en question ?

Les timing ne portent pas sur les données reçues ou envoyées.
Ce logiciel envoie des commandes TTL à des moments très précis (un log de ce même logiciel me confirme le moment exact où le TTL a été envoyé). L'ajout de ces DLLs perturbe complètement l'envoi de ces commandes.

Attends, as-tu besoin du code lui-même ou juste des interfaces? Si c'est le second cas, peut-être peux tu extraire la bibliothèque de types (fichier .tlb) qui doit être en ressources dans les DLL...

Citation:

---

Envoyé par Médinoc

Attends, as-tu besoin du code lui-même ou juste des interfaces? Si c'est le second cas, peut-être peux tu extraire la bibliothèque de types (fichier .tlb) qui doit être en ressources dans les DLL...

---

Je suis pas familier avec ce genre de DLL donc j'avoue ne pas avoir compris de quoi tu me parles :oops: :oops:
J'ai effectivement des fichiers tlb... Ils ont un rôle particulier ?

Les TLB définissent les interfaces de manière compilée, ils sont utilisées lors de la compilation du projet dans certains cas (comme le Compiler COM Support de Visual Studio, la directive #import; ou l'utilisation de COM dans d'autres langages comme C#) et en run-time dans d'autres (comme la génération automatique d'un proxy ou simplement l'introspection). Elles ne contiennent pas de code exécutable.

La DLL elle-même n'est généralement pas liée au projet, elle est à la place chargée dynamiquement lors de l'appel à CoCreateInstance(), étant référencée dans la base de registre (HKEY_CLASSES_ROOT).

Je ne cherche pas à avoir le code de la DLL, mais à comprendre pourquoi j'ai ce bug. Et surtout pourquoi il persiste après suppression de la DLL qui semble le provoquer, j'ai pourtant :
- supprimé la DLL de la base de registre ;
- renommé la DLL pour être sûr que tous les liens entre le soft et cette DLL étaient coupés.

Je suis même allé jusqu'à arrêter la machine (pour vider la RAM) et supprimé manuellement dans la base de registre les clefs qui restaient.

Je n'arrive donc pas à retourner à l'état avant insertion de la 2nde DLL.

Citation:

---

Envoyé par Auteur

Je ne cherche pas à avoir le code de la DLL, mais à comprendre pourquoi j'ai ce bug. Et surtout pourquoi il persiste après suppression de la DLL qui semble le provoquer, j'ai pourtant :
- supprimé la DLL de la base de registre ;
- renommé la DLL pour être sûr que tous les liens entre le soft et cette DLL étaient coupés.

Je suis même allé jusqu'à arrêter la machine (pour vider la RAM) et supprimé manuellement dans la base de registre les clefs qui restaient.

---

Pour savoir si ta 2e DLL est bien "cleanée" (si tu as toujours son GUID ou ProgId), utilise oleview, c'est un outil qui va te donner tous les objet COM de ta machine.
Cet outil est livré avec Visual

merci mala92 pour cet outil, je garde le lien sous le coude :ccool:
J'espère que cela m'aidera à comprendre ce qu'il se passe :)

Vous n'êtes pas très clair dans la description des dysfonctionnements.
Mais bon, vous n'auriez peut-être pas besoin de nous sinon. :aie:

Alors, d'une, si vous avez des contraintes de l'ordre de la milliseconde, oubliez Windows. Ce n'est pas un système temps-réel.
Les seuls timer qui peuvent s'approcher, en mode user, de ces contraintes, ces des timers multimédias et il n'y a pas de garantie de résultat. Ce n'est pas un OS temps-réel.

Pour des applications à forte contraintes, je passe par de la programmation Kernel, driver. Vous avez un meilleur contrôle sur le timing mais là aussi, il n'y a pas de garantie de résultat. Ce n'est pas un OS temps-réel.

En résumé, votre architecture va direct dans le mur. A moins que vous ne relâchiez un peu les contraintes.

En second, si je dois faire un programme pouvant accueillir des plug-Ins sous forme de Dll, je ferais vraisemblablement une copie en cachette des DLL, histoire de ne pas me faire avoir si un boulet supprimer le Dll et que j'en ai besoin pour dé-sérialiser des données générées par ces DLL. En plus je m'arrangerais pour que la copie de la DLL ne porte pas le même nom que l'originale.

En troisième, c'est plutôt logique que le fait de mettre plusieurs composants en notification d'évènement COM prenne plus de temps que si il n'y en a qu'un. Bin, il y a tous simplement plus de code exécuté donc plus de temps.

Et ça, c'est sans compter les injections de DLL que les anti-virus et autres "outils" systèmes collent dans tous les exécutables.

Donc vous êtes dans le cac*.:aie:

Alors primo, revenez sur les rails, en utilisant une machine ou une VM vierge et faites la manipulation qui est sensé fonctionné, celle juste avec la première DLL. C'est pas gagné que cela marche, cela a peut-être fonctionné la première fois par "hasard".
Soit cela ne fonctionne pas, et donc cela ne vient pas de la "seconde DLL".
Soit cela fonctionne et vous disposez d'un étalon pour comprendre les différences.

Mes premières remarques illustrent que la probabilité de la première alternative est loin d'être négligeable, c'est le syndrome du "c'est tombé en marche".

Si vous êtes dans le second cas de figure, utilisez des outils comme processExplorer (http://technet.microsoft.com/fr-fr/s...rnals/bb896653) pour voir les Dll chargées dans le process incriminé et voir les différences.

Mais, je vous le redis, avec vos contraintes, vous allez dans le mur.

Citation:

---

Envoyé par bacelar

Alors, d'une, si vous avez des contraintes de l'ordre de la milliseconde, oubliez Windows. Ce n'est pas un système temps-réel.
Les seuls timer qui peuvent s'approcher, en mode user, de ces contraintes, ces des timers multimédias et il n'y a pas de garantie de résultat. Ce n'est pas un OS temps-réel.

---

pour couper court aux débats du genre "Windows, c'est pas bô" : comme je l'ai indiqué j'utilise un logiciel commercial qui fonctionne exclusivement sous Windows qui utilise des composants COM, des DLL, etc. Les contraintes sont ce qu'elles sont.

Citation:

---

Envoyé par bacelar

En second, si je dois faire un programme pouvant accueillir des plug-Ins sous forme de Dll, je ferais vraisemblablement une copie en cachette des Dll

---

C'est ce que je soupçonne...

Citation:

---

Envoyé par bacelar

Si vous êtes dans le second cas de figure, utilisez des outils comme processExplorer (http://technet.microsoft.com/fr-fr/s...rnals/bb896653) pour voir les Dll chargées dans le process incriminé et voir les différences.

---

ok je testerai avec cette application ;)

Code:

---

pour couper court aux débats du genre "Windows, c'est pas bô"

---

Je suis un spécialiste de Windows et je ne dénigre en rien Windows, bien au contraire.
Je suis juste conscient de ces limites, et ces limites existent aussi sur les Linux "standards", par exemple.
Je veux juste vous faire prendre conscience que vos contrainte sont irréaliste.

Pour des contraintes de l'ordre de la milliseconde, il vous faut des OS temps-réels comme les versions Embedded de certain Windows, mais en programmant dans l'univers Kernel.

processExplorer ou un dérivé un outil "obligatoire" de tout programmeur système sous Windows.

Bacelar : Je viens de trouver une version plus récente (v15.13) de Process Explorer
http://technet.microsoft.com/en-us/s...rnals/bb896653

Je ne suis pas sûr que la version (11.02) que tu me proposes fonctionne avec Windows 7 Entreprise 64 bits.


Avec ProcessExplorer, j'ai pu constater qu'une des deux DLL n'était pas chargée au moment du démarrage de l'application. Il semblerait qu'elle ne soit chargée qu'au moment où on commence à appeler les fonctions qu'elle contient.

La DLL en question est la 1ère DLL. La 2nde DLL, celle que j'ai conçue, est chargée dès le démarrage de l'application.

Maintenant, je suis incapable de dire si la source de mon problème vient de là :?

Désolé pour le lien vers une ancienne version de ProcessExplorer.
J'ai pris la 1ère entrée Google sans vérifier la version.

Citation:

---

Avec ProcessExplorer, j'ai pu constater qu'une des deux DLL n'était pas chargée au moment du démarrage de l'application. Il semblerait qu'elle ne soit chargée qu'au moment où on commence à appeler les fonctions qu'elle contient.

---

C'est classique dans le cadre d'une architecture à Plug-Ins. COM facilite grandement ce type d'architecture.

Comme vous n'êtes pas très clair sur le mode d'ajout des Dll dans "l'application commerciale", un sous répertoire?, une catégorie COM?, un fichier de configuration avec les GUID des composants?, une configuration en base de registre?, dans un projets VS à la compilation?, autres? ; je ne peux que faire de vagues hypothèses.

Pouvez-vous être plus précis que

Citation:

---

Pour que cette application puisse "voir" ces DLL un GUID est nécessaire.

---

?

Pouvez-vous utiliser un utilitaire type Dependency Walker http://www.dependencywalker.com/ pour voir comment et quelles Dll sont statiquement liées (avec ou sans delay-loading) à "l'application commerciale".

Citation:

---

La 2nde DLL, celle que j'ai conçue, est chargée dès le démarrage de l'application

---

Je ne comprends pas, je croyais que vous l'aviez supprimée du disc ? 8O

J'insiste, vos contraintes temporelles sont irréalistes.