2010-02-01 3 views
16

J'intègre un SDK tiers basé sur C dans mon application .NET. L'application s'exécutera en tant que service Windows sur un serveur, de sorte qu'elle ne devrait en aucun cas interagir avec l'utilisateur.Comment puis-je empêcher une bibliothèque tierce d'afficher un MessageBox?

Malheureusement, dans certaines conditions d'erreur, il insiste sur l'appel MessageBoxA, sans doute pour signaler que quelque chose est arrivé. Lorsque cela se produit, le service cesse de répondre. Je devine qu'il attend que quelqu'un appuie sur OK?

Il est impossible d'avoir le vendeur changer leur code pour moi.

Est-il possible que je puisse faire cet appel dans un no-op donc mon code peut faire face à la situation automatiquement?

EDIT: Il peut être important de mentionner que dans mon cas particulier, le service serait automatiquement redémarrer si elle est écrasé. Une sortie gracieuse (si possible) et soudaine est probablement la meilleure solution pour une situation où un MessageBox est affiché dans mon cas.

+9

Ce n'est pas une vraie réponse je sais, mais trouver une meilleure bibliothèque/service. Si une bibliothèque a ce type de problème, elle risque d'en avoir plus. –

+0

Je me souviens d'un idiot ex-collègue à moi mis dans une boîte de message dans le code qui était connu pour être un service.Je lui ai dit de l'enlever mais il l'a laissé et nous avons dû relancer le logiciel ... n'était pas bon. – Tim

+0

Non, disons que ce n'est pas un MessageBox d'une bibliothèque !!!! Bonne question –

Répondre

10

Découvrez Detours from Microsoft Research. Il vous permet de détourner les fonctions arbitraires de l'API Windows. La programmation C/C++ est nécessaire pour que cela fonctionne. Tu n'auras pas besoin de beaucoup.

+0

Wow, je ne savais pas que vous pouviez faire ça. – Jeremy

+2

@nobugz Vous êtes comme une bibliothèque. Sérieusement. –

+0

J'ai lu les réponses de nobugz ici et sur les forums MSDN, et je suis convaincu qu'il est Dave Cutler. –

3

Vous pouvez utiliser un éditeur pour trouver l'emplacement de ce et de supprimer l'appel de leur binaire. Mais cela peut ou non être autorisé dans les limites d'utilisation avec le logiciel. Certainement, si vous le redistribuez, cela peut causer des problèmes - vous devriez demander au fournisseur et le signaler comme un défaut et suggérer que vous avez une solution de contournement pour votre propre usage.

Pour les personnes habituées à faire ce genre de chose (cracking licences ou autre reverse engineering), c'est assez simple, mais la vraie question est: que se passe-t-il s'il est ignoré - continue-t-il à fonctionner?

+1

Crash est ok dans ce cas. C'est bien pire pour le service d'accrocher comme il le fait. – Jeremy

+0

Eh bien, si vous savez que vous pouvez arrêter, vous pouvez également quitter le processus et utiliser un autre chien de garde pour le remettre en marche s'il n'est pas trouvé en cours d'exécution. J'éviterais cette complexité si je le pouvais et je verrais juste si vous pouvez vous en sortir avec NO-OPing. Alors bien sûr, le problème juridique avec la distribution/utilisation? Si vous ne connaissez pas quelqu'un qui a des capacités, je connais quelqu'un qui me rapportait et qui aime faire de l'ingénierie inverse des binaires. – Tim

+0

Il ya déjà un chien de garde d'un tri - si le programme venait à planter, il serait redémarré automatiquement. C'est pourquoi c'est si frustrant pour moi que ça pend! :) Je ne connais pas encore les problèmes juridiques. – Jeremy

0

Ce n'est pas très facile. Je pense que le seul moyen est d'écrire un crochet de message pour piéger les messages pompés à travers toutes les boucles de messages Windows sur le système. Mais je ne suis même pas sûr qu'un service peut créer un crochet de message étant donné qu'il n'a pas accès à la station de fenêtre par défaut sous ses informations d'identification par défaut (LocalSystem). Donc, la tâche n ° 1 serait de voir si cela fonctionnerait réellement.

Mais voici une esquisse de la façon dont je voudrais essayer de le faire en dehors d'un contexte de service et vous pouvez voir si elle applique:

  1. Créer une fenêtre hook aux messages d'interruption de toutes les fenêtres des files d'attente de messages sur le système.
  2. Interceptez tous les messages WM_CREATE et recherchez le paramètre CREATESTRUCT pour les messages provenant de votre bibliothèque tierce. Vous devrez peut-être enregistrer tous les messages WM_CREATE, puis analyser les données pour voir comment vous pouvez différencier le dialogue de votre bibliothèque de tout autre dialogue sur le système. (Plusieurs fois, le membre « de lpszName » diffère entre les implémentations de dialogue.)
  3. si vous croyez que le WM_CREATE particulier est venu de votre bibliothèque, le retour d'un « traité » réponse de votre crochet de message et ne pas appeler le gestionnaire de message suivant dans la chaîne .

Tout cela est très risqué, mais c'est le chemin qui semble avoir une chance pour moi.

Questions connexes