Discussion :

[Auteur]

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.

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 ?

[ok.Idriss]

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 .

Cordialement,
Idriss

[Auteur]

bonsoir,

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

[ok.Idriss]

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

[LittleWhite]

Bonjour,

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

[Auteur]

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.

[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...

[Auteur]

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
J'ai effectivement des fichiers tlb... Ils ont un r�le particulier ?

[M�dinoc]

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).

[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.

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

[mala92]

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

[Auteur]

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

[bacelar]

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

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*.

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.

[Auteur]

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.

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...

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

[bacelar]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[Auteur]

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�

[bacelar]

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.

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

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".

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 ?

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