XProfan

- Seite 3 -

Dieter Zornow

@Andeas,
Der Taskmanager zeigt sie weiter ganz normal unter Anwendungen an.

Aber nicht unter Prozesse - und darum geht es bei der Sache. Besten Dank - was da wohl bei meinem Sohn nicht stimmt...

Dieter Zornow

Das Verhalten mit deinem Tool ist auch reproduzierbar. Du überschreibst durch deine Hooks einen Speicherbereich und wenn dort gerade ein Programm ist oder diesen benutzt, stürzt es ab deshalb denke ich nicht ungefährlich das ganze.

Auch das sollte man überdenken...

25.03.2007 ▲

Frank
Abbing

Ich benutze nun eine neue Technik, die sicherer ist. Im übrigen werden nur 5 Bytes überschrieben, aber mit sinnvollen Werten, sodass deine Programme dadurch nicht ins Schleudern geraten. Kann ja nicht sein, das mein Programm überall richtig funktioniert, nur bei dir nicht, oder? Zumal du die gleiche Konfiguration besitzt wie ich.
Teste bitte mal die neue Version, hier im Anhang:

WhichDlls.zip	4 kB

Hochgeladen:	26.03.2007

Ladeanzahl:
		Herunterladen

Frank Abbing

Kann ja nicht sein, das mein Programm überall richtig funktioniert, nur bei dir nicht, oder? Zumal du die gleiche Konfiguration besitzt wie ich.

Vorsicht Frank! Genau das könnte meiner Meinung nach sein. Bei den meisten APIs schließe ich das aus, LoadLibrary wird aber bereits bei der Initialisierung des Programmes benutzt - zur gleichen Zeit, wie auch der Hook geladen wird. Ich persönlich könnte mir vorstellen, dass es Situationen gibt, wo Windows beim Multithreading innerhalb einer Anwendung geade das erste Byte abgearbeitet hat, wenn der Hook geladen wird. Wird dann wieder mit der Abarbeitung des ersten Threads fortgesetzt, will dieser Thread dann beim zweiten Byte weitermachen .- da steht aber jetzt kein sinnloser Opcode mehr, sondern etwas anderes, was aber als Opcode (falsch) gewertet wird.

Ob das passiert könnte unter anderem davon abhängen, wie viele Treads auf einem Rechner laufen - die Wahrscheinlichkeit, das da aber überhaupt irgendwas passiert , ist bei der Anzahl an geänderten Bytes aber extrem klein.

Hallo Frank...

Mit dem letzten Download etwas weiter oben gibt es unter Windows2000 bei mir jetzt keine Probleme mehr.

Dieter
Zornow

Hallo Frank,

deine letzte Version läuft besser, es gibt keine Abstürze mehr, nur die Funktionen sind
immer noch nicht richtig. Ich bekomme jetzt in der Box aber den Programmpfad gezeigt, war vorher nicht. Aber immer noch Verweis auf die psapi.dll und nur darauf.
Programmpfad --> psapi.dll.
Ich denke dass jedes System anders ist durch verschiedene Treiber usw. Ich habe auch die meisten Updates nach SP2 installiert und aus Sicherheitsgründen einige Funktionen gesperrt wie den Hintergrundübertragungsdienst. Die sollten aber nichts mit deinem Tool zu tun haben. Im übrigen haben ja noch nicht so viele getestet, um ein represantives Ergebnis zu haben.

Gruß

Dieter

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

Frank
Abbing

Aber immer noch Verweis auf die psapi.dll und nur darauf.
Programmpfad --> psapi.dll.

Den Pfad ermittle ich natürlich per API. Ist eben das Ergebniss, welches mir Windows als ausführenden Pfad zurück gibt.

Könntest du vielleicht mal einen Screenshot hier posten?

Dieter
Zornow

Hier der Screenshoot

whichdlls.jpg	66 kB

Hochgeladen:	26.03.2007

Ladeanzahl:
		Herunterladen

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

Jörg
Sellmeyer

Jetzt wollte ich gerade loben, da ist Firefox beim Klick auf Speichern abgeschmiert. Ich hatte vorher WhichDll laufen.
Die Piepserei der Profanprogramme ist aber auch schon sehr massiv im Vergleich zu anderen Programmen. Der XProfEd piep z.B. ununterbrochen.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Frank
Abbing

Ob das passiert könnte unter anderem davon abhängen, wie viele Treads auf einem Rechner laufen - die Wahrscheinlichkeit, das da aber überhaupt irgendwas passiert , ist bei der Anzahl an geänderten Bytes aber extrem klein.

Jetzt wollte ich gerade loben, da ist Firefox beim Klick auf Speichern abgeschmiert. Ich hatte vorher WhichDll laufen.

Wie Andreas schon sagte, die Möglichkeit besteht, ist aber gering. Mal sehen, ob ich einen der Wait-APIs auf LoadLibrary() anwenden kann.
Allerdings passiert das bei mir bei allen API-Monitor-Programmen immer mal wieder.

Hier der Screenshoot

Danke!
Es wird wirklich immer nur diese Dll geladen? Seltsam, mein Tool greift direkt den Parameter ab, den ein Programm bei LoadLibrary angibt.

Die Piepserei der Profanprogramme ist aber auch schon sehr massiv im Vergleich zu anderen Programmen. Der XProfEd piep z.B. ununterbrochen.

Das habe ich auch nur bei Profan-Programmen beobachtet. Auch wenn Roland versucht, das etwas herunter zu spielen: Normal ist das nicht und die Geschwindigkeit muss darunter leiden. Hab mir schliesslich angesehen, wie LoadLibrary arbeitet...

RGH

Jörg Sellmeyer

Die Piepserei der Profanprogramme ist aber auch schon sehr massiv im Vergleich zu anderen Programmen. Der XProfEd piep z.B. ununterbrochen.

Das liegt daran, daß Franks Tool nicht protokolliert, wann eine DLL tatsächlich geladen wird, sondern nur die Aufrufe der API-Funktion LoadLibrary. LoadLibrary lädt eine DLL aber nur, wenn sich diese DLL noch nicht im Speicherraum des aufrufenden Programmes befindet, ansonsten wird nur ein Windowsinterner Zähler hochgezählt. Zitat aus der Microsoft API-Hilfe:

Wenn im Aufruf von LoadLibrary ein DLL-Modul angegeben ist, das bereits im Adressraum des aufrufenden Prozesses zugeordnet ist, gibt die Funktion einfach ein Handle für die DLL zurück und erhöht den Verweiszähler des Moduls.

Dieses Hochzählen kostet natürlich keine nennenswerte Zeit (zumindest nicht, wenn kein Programm läuft, das die LoadLibrary-Aufrufe abfängt ;) ).

LoadLibrary kostet nur dann Zeit, wenn eine DLL nicht im Speicher ist. Möchte man im Programm also eine API-Funktion aus einer DLL, die nicht eh schon mit Windows geladen wird, mehrmals aufrufen, sollte man die DLL vorher mit UseDLL() laden. Weitere Aufrufe über External (oder der mit DEF definierten Funktion), kosten dann kaum Zeit, wobei External ein wenig schneller sein sollte.

Siehe dazu auch in der XProfan-Hilfe: 28.7 - Zur Verwendung von DLLs

Noch einen Tick schneller ginge es mit dem statischen Linken einer DLL: Dann wird die DLL am Anfang des Programmes geladen und die Einsprungadressen aller benötigten Prozeduren einmalig ermittelt. Im weiteren Verlauf sind nach nur noch die entsprechenmden CALL-Funktionen aufzurufen. Diese Methode wählt z.B. David iF im XPSE, um das Programm zu optimieren. (Der Grund für den leichten Tempovorteil: GetProcAdress wird für jede verwandte Funktion nur einmal aufgerufen.)

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Frank
Abbing

Dieses Hochzählen kostet natürlich keine nennenswerte Zeit (zumindest nicht, wenn kein Programm läuft, das die LoadLibrary-Aufrufe abfängt ).

Das Abfangen kostet keine Zeit. Die paar Assemblerfunktionen auch nicht. Wenn du den Piepton abstellst, wird nur Zeit für den Eintrag in die Listbox verbraucht.

Das Hochzählen ist ein Durchforsten der systemen Handlelisten. Da wird mitunter einiges an Speicher durchgesehen.

Das Hochzählen ist ein Durchforsten der systemen Handlelisten. Da wird mitunter einiges an Speicher durchgesehen.

Stiimt so nicht ganz. Wirf mal einen Blick mit MWatch auf die Kernelhandles eines Prozesses. Ich könnte mir vorstellen, dass da GetProcAdress unter Umständen viel mehr Zeit verbraucht.