XProfan

- Página 3 -

Dieter Zornow

@Andeas,
Der Taskmanager zeigt ellos más bastante normal bajo Anwendungen a.

Aber no bajo Prozesse - y por lo tanto es en Sache. Besten Dank - qué como wohl en mi Sohn no stimmt...

Dieter Zornow

Das Comportamiento con deinem Tool es auch reproduzierbar. Usted überschreibst por deine Hooks una Speicherbereich y si hay gerade una Programa es oder esta benutzt, stürzt lo de deshalb denke Yo no ungefährlich todos.

Auch el debería uno überdenken...

25.03.2007 ▲

Frank
Abbing

Yo benutze nun una neue Technik, el sicherer es. Im übrigen voluntad sólo 5 Bytes überschrieben, aber con sinnvollen Werten, sodass deine Programas dadurch no en el Schleudern geraten. Kann sí no ser, el mein Programa überall correcto funktioniert, sólo en dir no, oder? Zumal du el gleiche Konfiguration besitzt Yo.
Teste Por favor, veces el neue Versión, hier en el Anhang:

WhichDlls.zip	4 kB

Hochgeladen:	26.03.2007

Ladeanzahl:
		Descargar

Frank Abbing

Kann sí no ser, el mein Programa überall correcto funktioniert, sólo en dir no, oder? Zumal du el gleiche Konfiguration besitzt Yo.

Vorsicht Franco! Exactamente el podría meiner Meinung después de ser. En el meisten APIs schließe Yo el de, LoadLibrary se aber ya en Initialisierung des Programmes benutzt - a gleichen Tiempo, como el Hook geladen se. Yo persönlich podría me vorstellen, dass lo Situationen son, wo Windows beim Multithreading innerhalb uno Anwendung geade el erste Byte abgearbeitet ha, si la Hook geladen se. Wird entonces otra vez con el Abarbeitung des ersten Hilos fortgesetzt, voluntad dieser Hilo entonces beim zweiten Byte weitermachen .- como es aber ahora kein sinnloser Opcode mehr, pero de otra manera, qué aber como Opcode (falso) gewertet se.

Ob el passiert podría bajo anderem su abhängen, como viele Treads en una Rechner laufen - el Wahrscheinlichkeit, el como aber überhaupt algo passiert , es en Anzahl a geänderten Bytes aber extremo klein.

¡Hola Franco...

Mit el letzten Descargar algo más oben hay bajo Windows2000 en me ahora no Problemas mehr.

Dieter
Zornow

¡Hola Franco,

deine letzte Versión se ejecuta mejor, lo son no Se bloquea mehr, sólo el Características son
siempre todavía no correcto. Yo bekomme ahora en el Box aber el Programmpfad gezeigt, war vorher no. Aber siempre todavía Verweis en el psapi.dll y sólo darauf.
Programmpfad --> psapi.dll.
Yo denke dass cada Sistema anders es por verschiedene Treiber usw. Yo habe auch el meisten Updates después de SP2 installiert y de Sicherheitsgründen algunos Características gesperrt como el Hintergrundübertragungsdienst. El debería aber nichts con deinem Tool a tun haben. Im übrigen haben sí no tan viele getestet, en una represantives Ergebnis a haben.

Saludo

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 siempre todavía Verweis en el psapi.dll y sólo darauf.
Programmpfad --> psapi.dll.

Den Pfad ermittle Yo natürlich por API. Ist eben el Ergebniss, welches me Windows como ausführenden Pfad zurück son.

Könntest du tal vez veces a la Screenshot hier puesto?

Dieter
Zornow

Hier el Screenshoot

whichdlls.jpg	66 kB

Hochgeladen:	26.03.2007

Ladeanzahl:
		Descargar

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 Yo quería gerade loben, como es Firefox beim Clic en Guardar abgeschmiert. Tuve vorher WhichDll laufen.
El Piepserei el Profanprogramme es aber auch ya muy massiv en el Vergleich a otro Programmen. Der XProfEd piep z.B. ununterbrochen.

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

Frank
Abbing

Ob el passiert podría bajo anderem su abhängen, como viele Treads en una Rechner laufen - el Wahrscheinlichkeit, el como aber überhaupt algo passiert , es en Anzahl a geänderten Bytes aber extremo klein.

Jetzt Yo quería gerade loben, como es Firefox beim Clic en Guardar abgeschmiert. Tuve vorher WhichDll laufen.

Como Andreas ya sagte, el Möglichkeit besteht, es aber gering. Tiempo sehen, si Soy un el Wait-APIs en LoadLibrary() anwenden kann.
Aunque passiert en el me en allen API-Monitor-Programmen siempre veces otra vez.

Hier el Screenshoot

Gracias!
Lo se wirklich siempre sólo esta Dll geladen? Seltsam, mein Tool greift direkt el Parámetro de, el una Programa en LoadLibrary angibt.

El Piepserei el Profanprogramme es aber auch ya muy massiv en el Vergleich a otro Programmen. Der XProfEd piep z.B. ununterbrochen.

Das Yo auch sólo en Profano-Programmen beobachtet. Auch si Roland intenta, el algo herunter a spielen: Normal es el no y el Geschwindigkeit muss darunter leiden. Hab me schliesslich angesehen, como LoadLibrary arbeitet...

RGH

Jörg Sellmeyer

El Piepserei el Profanprogramme es aber auch ya muy massiv en el Vergleich a otro Programmen. Der XProfEd piep z.B. ununterbrochen.

Das liegt daran, daß Franks Tool no protokolliert, wann una DLL tatsächlich geladen se, pero sólo el Aufrufe el API-Función LoadLibrary. LoadLibrary lädt una DLL aber sólo, si se esta DLL todavía no en el Speicherraum des aufrufenden Programmes befindet, ansonsten se sólo una Windowsinterner Zähler hochgezählt. Zitat de el Microsoft API-Ayuda:

Wenn en el Aufruf de LoadLibrary una DLL-Modul angegeben es, el ya en el Adressraum des aufrufenden Prozesses zugeordnet es, son el Función simplemente una Handle para el DLL zurück y aumenta el Verweiszähler des Moduls.

Dieses Hochzählen kostet natürlich no nennenswerte Tiempo (zumindest no, si kein Programa se ejecuta, el el LoadLibrary-Aufrufe abfängt ;) ).

LoadLibrary kostet sólo entonces Tiempo, si una DLL no en el Speicher es. Möchte uno en el Programa also una API-Función de uno DLL, el no eh ya con Windows geladen se, mehrmals aufrufen, debería uno el DLL vorher con UseDLL() invitar. Weitere Aufrufe encima Externo (oder el con DEF definierten Función), costo entonces kaum Tiempo, wobei Externo una wenig más rápido ser debería.

Siehe dazu auch en el XProfan-Ayuda: 28.7 - A Verwendung de DLL

Noch una Tick más rápido ginge lo con el statischen Linken uno DLL: Dann se el DLL al Anfang des Programmes geladen y el Einsprungadressen aller benötigten Prozeduren einmalig ermittelt. Im más Progreso son después de sólo todavía el entsprechenmden CALL-Características aufzurufen. Diese Método wählt z.B. David IF en el XPSE, en el Programa a optimieren. (Der Grund para el leichten Tempovorteil: GetProcAdress se para jede verwandte Función sólo una vez aufgerufen.)

Saludo
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 no nennenswerte Tiempo (zumindest no, si kein Programa se ejecuta, el el LoadLibrary-Aufrufe abfängt ).

Das Abfangen kostet no Tiempo. El pocos Assemblerfunktionen auch no. Wenn du el Piepton abstellst, se sólo Tiempo para el Eintrag en el Listbox verbraucht.

Das Hochzählen es una Durchforsten el systemen Handlelisten. Como se mitunter einiges a Speicher durchgesehen.

Das Hochzählen es una Durchforsten el systemen Handlelisten. Como se mitunter einiges a Speicher durchgesehen.

Stiimt así no bastante. Wirf veces a la Blick con MWatch en el Kernelhandles uno Prozesses. Yo podría me vorstellen, dass como GetProcAdress bajo Umständen viel mehr Tiempo verbraucht.