Zitat von
Delphi Star:
Delphi-Quellcode:
if WaitForDebugEvent(OUTPUT_DEBUG_STRING_EVENT,INFINITE)=true then
showmessage('test');
Was ist daran falsch
Keine Ahnung. Probier es aus, ob es klappt. Allerdings sagt die Doku zu dieser
API eindeutig:
The WaitForDebugEvent function waits for a debugging event to occur in a process being debugged.
Ich entnehme dem, daß ich den Prozess vorher als Debugger unter meine Knute zwingen muß.
(Speziell an w3seek
Ich habe mir soeben mal die Implementation von Windows 2000's kernel32!OutputDebugString() angeschaut. Dabei ist mir aufgefallen, daß theoretisch auch wenn der Prozess nicht debuggt wird dieser String in eine MMF geschrieben wird. Zusätzlich werden 2 Ereignisse geöffnet und mglw. signalisiert. Und mit einem
Mutex wird der Zugriff auf die MMF gesperrt (dieser scheint intern der Kernel32 zu gehören - zumindest kennt die Kernel32 sein
Handle und öffnet ihn nicht explizit innerhalb der Funktion).
Die MMF heißt: "DBWIN_BUFFER"
Die Ereignisse heißen: "DBWIN_DATA_READY" und "DBWIN_BUFFER_READY"
Wie kompatibel (mit Windows 9x) und vorigen/späteren NT-Versionen ein solches Vorgehen ist, bleibt dahingestellt. Wenn eine tiefere Analyse erwünscht ist, kann ich die u.U. noch nachliefern. Aber auch kernel32!OutputDebugString() ruft ntdll!DbgPrint() auf, welches wiederum ntdll!DebugPrint() aufruft, welches wiederum ntdll!DebugService() aufruft, welches den Aufruf über SYSENTER bzw. INT 2Eh über die SSDT in den Kernelmode weiterleitet. Da ich keine Zeit habe, kann ich die auch nicht sagen, wie der Service-Index auf eine Kernelmodefunktion mappt. Zumindest gleicht sich der Code o.g. Funktionsaufrufe im Kernel- und im Usermode wie ein Ei dem anderen (NTOSKRNL.EXE vs. NTDLL.DLL).
PS: Das alles war ein sehr oberflächliches Anschauen des Codes. Könnte also Fehler in der Beschreibung enthalten.