Usage de WaitForDebugEvent

Bonjour à tous le monde,
dans un grand nombre de mes programme j'utilise la fonction OutputDebugString. Et ceci de la façon suivante :

Code:

---

1 2 3 4 5

procedure MyOutputDebugString(v: integer); begin if (v > 0) then OutputDebugString(PChar(FAppAlias + '>' + IntToStr(Abs(v)))) else OutputDebugString(PChar(FAppAlias + '<' + IntToStr(Abs(v)))); end;

---

En utilisant DebugView j'obtient bien le résultat attendu.
Mais, dans chacune de mes applications, ou service, j'ai également insérer un code faisant office de moniteur d'entrée et de sortie des méthodes (cf. image ci-jointe) qui est codé comme suit :

Code:

---

1 2 3 4 5 6 7 8 9 10

procedure Mon(v: integer); begin {$IFDEF LEDMON} LedMon.SetLed(v); {$ENDIF}   {$IFDEF DBGMON} DbgMon.MyOutputDebugString(v); {$ENDIF} end;

---

Or ce code pèse, quelque peu, sur les performances de mes applications et demande à être maintenu, alors même que l'application ne requiert plus de maintenance. Pour éviter ces problèmes, je souhaiterais pouvoir récupérer et traiter (d'après un formatage spécifique) les chaines émise par la méthode " OutputDebugString ".

Après quelques recherche sur le MSDN, j'ai découvert la fonction " WaitForDebugEvent ". Je tente donc d'utiliser celle-ci pour récupérer les chaines émises lors des événements de type " OUTPUT_DEBUG_STRING_EVENT " (Cf. fichier " UChild.pas " ci-joint).

Bon jusque là je pense que je ne suis pas trop faux dans ma démarche (enfin j'espère). Hélas, trois fois hélas, cela ne semble par marcher. Pire encore, lorsque cela veut bien marcher et après fermeture de mon application de " debug " le processus l'application observer est détruit...

Donc, l'objet de ma demande consiste à savoir si une main secourable pourrais m'aiguiller quelque peu afin de trouver la " bonne " méthode.

Cordialement,
Dominique.

Normallement OutputDebugString ne fonctionne que si l'application est lancé en débugage, voir IsDebuggerPresent ...

tu pourrais dans ton MyOutputDebugString, vérifie une variable (initializé lors de la première consultation avec IsDebuggerPresent, tu mettre ça dans une méthode de classe ...)

ainsi, au lieu de de faire OutputDebugString, tu remplace cela par un SendMessage WM_COPYDATA ou un autre message, on peut envoyer des chaines sans problèmes tant que l'on ne fait que les lire via wParam et lParam, et bien sur très facilement des entiers, (attention, il faut récupérer la chaine, et la stocker dans une fifo pour traitement ultérieure car SendMessage attent que le receveur aie fini son traitement pour continuer l'execution de l'emetteur), ainsi dans ton programme, tu ajoute une sorte d'accroche, une fonction exporté façon DLL ou un SendMessage pour envoyer à l'application à debugger le handle de l'application de surveillance à qui envoyer les chaines de débug ... sinon Socket, ... mais c'est déjà plus lourd ...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

procedure TDebugger.Activate(var Msg: TMessage); // message UM_ACTIVE_DEBUG // dans interface begin FHandleReceiver := Msg.wParam; FActivated := LongBool(Msg.lParam) and (FHandleReceiver > 32); end;   function TDebugger.RunInDebbuger(): Boolean; begin if FRunInDebbugerReaded then Result := FRunInDebbuger else begin // Plein de Code, avec IsDebuggerPresent, ou System.DebugHook // _IsDebuggerPresent => LoadLibrary et GetProcAddress FRunInDebbugerReaded := True; FRunInDebbuger := _IsDebuggerPresent(); end; end;   procedure TDebugger.OutputDebugString(const S: string); begin if RunInDebbuger() then begin if S <> '' then SendMessage(FHandleReceiver, UM_ODS, Cardinal(@S[1]), 0); end else begin OutputDebugString(PChar(S)); end; end;

---

PS : ton appli de debug à l'air sympa, ça me fait penser aux outils de debug d'un programme machine trieuse avec lequel je communicais quand je faisais presque de la programmation industrielle ?

Merci ShaiLeTroll pour réponse on ne peut plus rapide...

Hélas ta solution, certes plaisante, ne me semble pas convenir. La fonction " IsDebuggerPresent " est uniquement valable dans le cas ou l'on exécute le programme depuis un débogueur tels que, par exemple, Delphi. En outre ses trames sont débrayable via un fichier INI.

Qui plus est, vue la masse de message émis, pour ton information un log de DebugView pour une période de 24h peut peser plusieurs Go, j'ai un peu peur que cela n'impacte trop fortement les performances du système. Tant par la quantité émise que par la quantité à traiter. Il est important, pour moi, d'impacter le moins possible le fonctionnement habituel du système ainsi que celui de mes applications, services et librairies.

En fait " OutputDebugString " est une fonction idéal pour ce que je souhaite faire. Dans le cas ou l'on débugge via Delphi elle est intercepter par le débogueur. Sinon un outil, tels que DebugView, me permet de suivre l'ensemble des " trames de débogage " émise par les applications, services et librairies.

Delors l'implémentation d'une application complémentaire et autonome, afin d'externaliser le monitoring des applications et services, prend tout son sens. C'est pour cela que l'utilisation de " WaitForDebugEvent " me semblais " logique ".

Cordialement,
Dominique.

P.S.: Pour ce qui concerne le monitoring, c'est du " home made ". L'idée est venue suite à l'observation des émulateurs CPU des mes collègue " hardeux ". Pour la réalisation c'est un collgue qui s'en est charger, je ne fait qu'utiliser sa bibliothèque de fonction (ou plutôt réutiliser son code).