Prozesse - mal wieder ein Prozeßbetrachter (und mehr)

[Delphi-Laie]

Hallo Delphianer!

Hiermit stelle ich mal wieder ein kleines Programm vor, und zwar zum Anzeigen von Prozessen, Modulen, Threads, Fenstern und Kindfenstern ("ChildWindows"). Derlei Programme gibt es ja viele....


Die Idee war, die 4 Schnappschüsse:

- Prozeßschnappschuß (CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS,0)),
- Modulschnappschuß (CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, Prozeßnummer)),
- Threadschnappschuß (CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, Prozeßnummer)) und
- Heap- und Heapblockschnappschuß (CreateToolHelp32Snapshot(TH32CS_SNAPHEAPLIST, Prozeßnummer))

mit den 3 Fensterenumerationen:

- EnumWindows,
- EnumThreadWindows und
- EnumChildWindows

so (sinnvoll) miteinander zu verknüpfen, daß sich ein - auf Basis der damit abrufbaren Informationen - in sich relativ geschlossenes Abbild des laufenden Windows ergibt (unter Hinzufügung weniger anderer Dinge, die mit ausgegeben werden). Dabei findet - im Gegensatz z.B. zum Taskmanager oder ProcessExplorer - keine Intervallaktualisierung beim primären Fenster mit der Prozeßausgabe statt (Abfrage nur beim Programmstart), die anderen Dinge werden erst zur Laufzeit (nach Aufruf) vom Program (Fragender) bzw. vom System (Befragter) abgefragt.

Aufrufe der von den Prozessen ableitbaren Objekte (die stehen in den Titelzeilen der Fenster) erfolgen über Doppelklick auf die jeweilige Zelle des jeweiligen StringGrids.

Der prozeß(nummer)bezogene Threadschnappschuß funktioniert bei mir leider "irgendwie" nicht: Es werden, egal bei welcher Prozeßnummer als Aufrufparameter, grundsätzlich immer alle Threads des Systems augegeben, deshalb habe ich diesen über einen prozeßnummerselektiven Threadschnappschuß bei der Ausgabe modelliert.

Weiterhin, auch das war anzupassen, gibt es anscheinend keinen Befehl "EnumProcessWindows". Dieser läßt sich m.E. folgendermaßen modellieren:

- Threadschnappschuß; bei allen Threads, die zum jeweiligen Prozeß gehören (prozeß(nummer)bezogene Threadselektion), erfolgt ein anschließendes EnumThreadWindows
oder
- EnumWindows, wobei nur alle zum jeweiligen Prozeß gehörenden Fenster ausgegeben werden, also prozeßnummernselektive Fensterauflistung (analog der prozeßnummernselektiven Threadauflistung)

Einfacher ist wohl letzteres, das ich deshalb umsetzte.

Das Programm kann z.B. auch als Alternative verwendet werden, um Routinen bzw. konkret die o.g. aufgerufenen Funktionen in eigenen Programmen zu testen. Weiterentwicklungen des Programmes (z.B. Prozesse terminieren oder Eigenschaften editieren o.ä.) sind nicht geplant.

Leider vergaß ich, die Units rechtzeitig zu selbsterklärenden Bezeichnungen umzubenennen, und der Aufwand dazu wäre jetzt zu groß (fehlersensitiv). Die Stringrids auf den jeweiligen Formularen geben folgendes aus:

Form1: Prozesse
Form2: Module
Form3: Threads
Form4: Fenster
Form5: Kindfenster ("ChildWindows")
Form6: Heapblöcke
Form7: Heaps
Form8: Module32 (nur 64 Bit)
Form9: Prozessorenaffinitäten


Viele Grüße

Delphi-Laie


Edit: Neue, geringfügig fehlerbereinigte und vor allem etwas erweiterte Version hochgeladen. Das Programm erweiterte ich um den vierten Schnappschuß, den Heapschnappschuß (dürfte ein Novum in den deutsch(sprachig)en Delphi-Foren sein). Dieser ermöglicht die Auflistung der Heaps und der Heapblöcke. Ergebnisse liefert der/das bei mir aber nur unter Windows ME, nicht jedoch 2000, XP & Vista, also wohl generell nicht unter NTx, dafür aber wohl generell unter 9x. Also, leider ein wenig zu spät dafür, aber wen's interessiert.... Auch wenn ich dafür wahrscheinlich virtuell gesteinigt werde: Es hat es mich interessiert, dieses Programm auch unter Delphi 2.0 zum Laufen zu bringen, mit Erfolg! Bis daß in den Pfadangaben der Laufwerksbuchstabe fehlt, hält mein D2-Compilat taper und wacker mit seinen späteren, natürlich aufgeblähteren Konkurrenten mit.

Edit 2: Stringgrids der nichtaktiven Formulare nunmehr grau. Kleine Fehlerkorrektur.

Edit 3: 1. Automatische Spaltenbreitenanpassung des Stringgrids zur Laufzeit; 2. Die eigentlich erst ab Delphi 4 verfübare Funktion "GetWindowModuduleFileName" in alle Versionen dieses Programmes integriert (durchweg konsistente Ergebnisse erhält man damit aber nur unter Windows 9x/Me), 3. Datentypkonvertierungsfehler für Delphi-Versionen >3 behoben (Heapnummern können unter Win 9x/ME negativ sein).

Edit 4: Automatische Spaltenbreitenanpassung ausgeweitet; Fehler beseitigt.

Edit 5: Automatische Spaltenbreitenanpassung fehlerbereinigt.

Edit 6: Im D2-3-Quelltext und in den Compilaten vergessenes GetWindowModuleFileName ergänzt.

Edit 7: Privileg für (exklusiven?!) Zugriff auf Ring-0- bzw. Kernel(modus)prozesse für dieses Programm angefordert bzw. implementiert (und wieder stand ein Quelltext Luckies dabei Taufpate). Damit ist es nunmehr möglich, auch in den systemnahen bzw. Systemprozessen die Module zu enumerieren, jene Prozesse und deren Threads zu beenden und/oder deren Priorität zu ändern.

Edit 8: Funktionsaufruf GetWindowModuleFileName durch GetWindowModuleFileNameA ersetzt, weil unter Windows ME GetWindowModuleFileName nicht gefunden wird, obwohl es in der DLL enthalten ist (und das Programm deshalb leider mit einem Fehler abbricht). Auch Delphi (4) mogelt diesbezüglich wahrscheinlich aus dem gleichen Grunde und nimmt genau die gleiche Substitution in der Windows-Unit vor.

Edit 9: Subtile Darstellungsfehler behoben; Turbo-Delphi-Compilat hinzugefügt.

Edit 10: Diverse Fehler (Threadprioritätensetzung, Darstellung und Modulanzahlanpassung) behoben.

Edit 11: Sehr viele kleine Fehler behoben. Das Turbo-Delphi-Compilat scheint fehlerhaft zu sein, denn es kann die Heaps unter Windows ME nicht darstellen (weil es das Delphi-4-Compilat jedoch schafft, nehme ich einen Fehler in der Exe-Datei an). Die interne Fehlersuche ist leider nicht möglich, weil Turbo-Delphi nicht auf diesem Windows laufen kann.

Edit 12: Lazarus-32- & -64-Bit-Version (jeweils inkl. Quelltexten) hinzugefügt.

Edit 13: ProcessVersion und ModuleFileName hinzugefügt. Viele kleine Fehlerkorrekturen.

Edit 14: Privileganforderung zum Start nunmehr optional mit Ergebnismitteilung. Prozeßliste läßt sich jetzt mit F5 aktualisieren. Wenige kleine Korrekturen.

Edit 15: Kleine Korrekturen.

Edit 16: Spaltenbreitenanpassung(en) der Stringgrids und Größenanpassung(en) der Formulare an die Stringgrids nunmehr in Prozedur(en) zentralisiert. Viele kleine Detailkorrekturen.

Edit 17: Kleinen Darstellungsfehler in der Lazarus-Version behoben.

Edit 18: Prozessoren- bzw. Prozessorkernaffinitäten für Prozesse und Threads sowie Threadidealprozessorzuordnung (alles für Mehrprozessor-/-prozessorkernsysteme) hinzugefügt. Viele Fehlerbehebungen.

Edit 19: Spalte für Prozeßeigentümer und Gruppe hinzugefügt (ist nicht für 9x/ME, sondern im Zusammenhang mit der hier benutzten Prozeßenumeration, die es nicht für Windows NT gibt, erst ab Windows 2000 verfügbar und wird auch deshalb erst ab diesem Windows auch augegeben, ansonsten wird die Spalte ausgeblendet) Ausgabe für Module32 beim 64-Bit-Lazaruskompilat (logischerweise nur bei 64-Bit-Windows verfügbar und wird auch erst bei 64 Bit ausgegeben, ansonsten wird auch diese Spalte ausgeblendet) in die letzte Spalte verschoben.

Edit 20: Subtilen Fehler in der Lazarus-Variante (Quelltext) bzw. den Lazarus-Varianten (32- & 64-Bit-Compilat) bei der Ausgabe der Prozeßeigentümer (wenn Ermittlung derselben nicht erfolgreich war) beseitigt.

Edit 21: Fehler, die bei mehr als zwei Prozessor(kern)en bei den Prozessorzuordnungsfunktionen auftraten, (hoffentlich) beseitigt.

Edit 22: Fehler im Zusammenhang mit inzwischen beendeten Prozessen behoben: Beim Klick auf die Modul- oder Threadanzahl inzwischen beendeter Prozesse reagiert das Programm jetzt ohne Fehlermeldung.

Edit 23: Mehrere kleinere Fehlerbehebungen, vor allem in der Lazarus-Version.

Edit 24: Zusätzliche Anzeige der 32 Bit bei 32-Bit-Prozessen (auf der Grundlage der IsWow64-Funktion) in der 64-Bit-Version (Lazaruskompilat) hinzugefügt.

Edit 25: Titelzeile des Hauptformulars um F5-Hinweis ergänzt.

Edit 26: Unterschiedliche Quelltexte für verschiedene Delphiversionen zu einem Quelltext für alle Delphiversionen (außer 1) zusammengeführt und vereinheitlicht.

Edit 27: Quelltexte überarbeitet, infolgedessen compiliert die Lazarus-Variante jetzt komplett im FPC-Modus. XE2-Quelltexte und Compilate (32 & 64 Bit) hinzugefügt. Die Erkennung der 32-Bit-Prozesse unter 64 Bit funktioniert jetzt auch mit den 32-Bit-Compilaten.

Edit 28: Wegen eines XE2-Fehlers bei der Mehrzellenauswahl in Stringgrids, der beim Lunathema erscheint, den Drawingstyle auf gdsClassic geändert (Voreinstellung war gdsThemed).

Edit 29: XE2-32-Bit-Compilat neu erstellt - ist nunmehr ohne den "CPU-Bug".

Edit 30: Durch Entfernen derr Laufzeittypinformationen (RTTI) (außer in der Unit System) konnte die Größe der XE2-Compilate um ca. 30% verringert werden.

Edit 31: Mehrere (Kind-)Fenstereigenschaften im Enum(Child)Windows hinzugefügt, außerem etliche kleine Fehler entfernt.

Edit 32:
- absolute Spaltenadressierungen in den Stringgrids durch Konstanten ersetzt. Damit können die spaltenbezogenen Reihenfolgen der Anzeigen in den Stringgrids durch einfaches Ändern der Konstanten selbst gewählt werden (in den Quelltexten der jeweiligen Units).
- Anzahl der anzeigbaren Fenstereigenschaften wesentlich erhöht (s. auch Windowstyles und extended Windowstyles in MSDN).
- Korrekturen bei den Prozessorzuordnungen und Vorzugsprozessorwahl der Threads
- etliche Detailkorrekturen

Edit 33:
- Die Zeilen aller Stringgrids können jetzt anhand der Einträge ("Schlüssel") einer beliebigen Spalte sortiert werden.
- Korrekturen bei den Heapblöcken und Hepas

Edit 34: Heapblockzählung jetzt auch im Hauptformular korrekt. Heapfenster inkl. Heapblockanzahl und Möglichkeit der Heapblockausgabe. Kleine Korrekturen.

Edit 35: Die Zuordnung Prozessoren zu Prozessen bzw. Threads ist jetzt über ein zusätzliches Formular flexibler möglich. Etliche Fehlerkorrekturen.

Edit 36: Die Childwindows können nunmehr auch direkt aus der Prozeß- und der Threadliste aufgerufen werden. Weiterhin werden die Childwindows mit dem Parentprozeßhandle ausgegeben. Wiederum Fehlerkorrekturen.

Edit 37: Neben dem Handle (Edit 36) wird bei den Childwindows nun auch der Name und der Klassennname des Parentwindows ausgegeben.

Edit 38: Fenster werden jetzt daraufhin geprüft (und das Ergebnis ausgegeben), ob sie einem (nicht)reagierenden ("hängenden") Programm angehören (ab Windows 2000).

Edit 39: Fehler, die auftraten, wenn man auf die Heaps oder Heapblöcke eines inzwischen beendeten Prozesses klickte, beseitigt.

Edit 40: 3 weitere Prozeßgrößen auf der Basis der NTQueryInformationProcess-Funktion (und weiterer Funktionen), die den P(rocess) E(nviroment) B(lock) auslesen, hinzugefügt. Die Idee stammt von Codeproject. Ein ganz herzlicher Dank geht an Zacherl, der mir in dieser Diskussion entscheidend half, das für 64 Bit zu portieren.

Edit 41: Funktion "IsAdmin" hinzugefügt, auf NTx erfolgt auf ihrer Basis nun Prüfung auf Administrationsstatus und auf Grundlage ihres Ergebnisses die Nachfrage, ob maximale Privilegien angefordert werden sollen, optional. Weiterhin wird nur noch angezeigt, wenn die maximalen Privilegien nicht erreicht werden.

Edit 42: Startergonomie weiter verbessert (vereinfacht), Fehler in iswow64-Funktion behoben.

Edit 43: Startergonomie der XE2-Compilate verbessert, so wird jetzt auch unter UAC-Betriebsprogrammen (ab Vista) korrekt ermittelt, ob das Programm Administrationsrechte hat. Ein Dank geht an diese Diskussion.

Edit 44: Die 64-Bit-Versionen zeigen nun auch die 32-Bit-Module der 32-Bit-Programme/-prozesse an.

Edit 45:
- Modulefilenames (von GetWindowModuleFileName) entfernt, da überflüssig,
- der Exitcode sowie die Anzahl GUI-Objekte, Userobjekte und der Prozeßhandles werden in der Prozeßtabelle für jeden Prozeß angezeigt,
- das Prozessorenzuordnungsformular zeigt nunmehr an, für welchen Prozeß und / bzw. Thread es derzeit gültig ist,
- die Funktion "IsAdmin" funktioniert jetzt auch bei den Lazarus-Compilaten,
- die Prozeßnamen (exe-Dateien) stehen jetzt links in einer fixierten Spalte,
- bessere Is(UserAn)Admin-Funktion aus diesem Beitrage (Dank an Nico!) und
- verbesserte Ergonomie bei der Zuweisung des Vorzugsprozessors.

Edit 46: Quelltextüberarbeitung in Unit 1 und 3 sowie kleine Fehlerbehebungen.

Edit 47: Kleine Fehlerbeseitungen.

Edit 48: Die Lazarusversion kann jetzt im FPC- und im Delphimodus kompiliert werden.

Edit 49:
- der Fortschritt beim Zählen der Heapblöcke kann jetzt grob visuell verfolgt und dieses Zählen auch abgebrochen werden
- diverse Fehlerbeseitigungen

[toms]

Hallo

Der Prozessname sollte in der 2.Spalte stehen, damit man nicht ganz nach rechts scrollen muss.

[Delphi-Laie]

Zitat von toms:

Hallo

Der Prozessname sollte in der 2.Spalte stehen, damit man nicht ganz nach rechts scrollen muss.

Ist quelltextoffen, kannst Du Dir gern so einrichten (sind eigentlich nur Spaltenüberschriften und Indizes zu verändern bzw. zu vertauschen und die Spaltenbreiten anzupassen). Unter 9x/ME (letzteres nutze ich immer noch auf diversen Computern) liefert er allerdings den Namen inkl. Pfad, so daß man dann auch schieben müßte, nämlich einen Spaltentrenner, deshalb habe ich es ganz nach rechts verfrachtet.

Mein Blick gestern in das MSDN (zu spät, Asche auf mein Haupt!) zeigte, daß einige Einträge der Schnappschüsse gar nicht mehr belegt sind und deshalb immer Null zurückliefern. Naja, sollte vollständig sein. Den Heapschnappschuß habe ich weder über Heap32 noch über Heap32list hinbekommen, aber der ist ja wohl auch der unwichtigste von allen und wurde in den großen Delphi-Foren noch nicht einmal thematisiert.

[Dezipaitor]

Nimm einfach ExtractFileName für den einzelnen Dateiname ohne Pfad.

[Delphi-Laie]

Danke, aber diese Funktion kenne ich und ignorierte sie absichtlich: Das Programm soll so sein, wie es ist.

Mit Gruß

[Fridolin Walther]

Ist die inkonsistente Anzeige nicht irreführend? Falls jemand wirklich die Anwendung auf NT und 9x nutzen mag, wird er sich schnell (berechtigt) fragen, wieso die 9x Variante mehr Informationen bietet als die NT. Man kommt unter NT zwar auch an den vollen Pfadnamen des Executables (Modulliste), aber schön ists irgendwie nicht. Solltest Du meiner Ansicht nach wirklich überarbeiten und den vollständigen Pfad auch unter NT ermitteln.

[Delphi-Laie]

Zitat von 0xF30FC7:

Ist die inkonsistente Anzeige nicht irreführend? Falls jemand wirklich die Anwendung auf NT und 9x nutzen mag, wird er sich schnell (berechtigt) fragen, wieso die 9x Variante mehr Informationen bietet als die NT.

Diese Frage kann ich gleich an Mikroweich weiterleiten....

Zitat von 0xF30FC7:

Man kommt unter NT zwar auch an den vollen Pfadnamen des Executables (Modulliste), aber schön ists irgendwie nicht.

Nein, aber auf der anderen Seite stört es mich sooo sehr nun auch wieder nicht. Mir ging es darum, die Ergebnisse der o.g. Schnappschüsse und der o.g. Enumerationen zu präsentieren und das zusätzliche "Rumgemache" zu begrenzen (und wenn, dann vor allem in die Ermittlung weiterer Informationen zu investieren, hier in IsEnabled und IsVisible). Der Pfad ist doch auch unter NTx ermittelbar, dann aber eben im Modulschnappschuß. Sicher könnte ich das in den Prozeßschnappschuß integrieren, aber ein Ergebnis des Modulschnappschusses in den Prozeßschnappschuß integriert, ist doch auch ein klein wenig "gemogelt".

[Fridolin Walther]

Zitat von Delphi-Laie:

Diese Frage kann ich gleich an Mikroweich weiterleiten....

In irgend einem MS Blog hab ich mal ne Begründung für die unterschiedliche Verhaltensweise gesehen. Weiß aber nicht mehr wo ...

Zitat von Delphi-Laie:

Nein, aber auf der anderen Seite stört es mich sooo sehr nun auch wieder nicht. Mir ging es darum, die Ergebnisse der o.g. Schnappschüsse und der o.g. Enumerationen zu präsentieren und das zusätzliche "Rumgemache" zu begrenzen (und wenn, dann vor allem in die Ermittlung weiterer Informationen zu investieren, hier in IsEnabled und IsVisible). Der Pfad ist doch auch unter NTx ermittelbar, dann aber eben im Modulschnappschuß. Sicher könnte ich das in den Prozeßschnappschuß integrieren, aber ein Ergebnis des Modulschnappschusses in den Prozeßschnappschuß integriert, ist doch auch ein klein wenig "gemogelt".

Ist nicht so als wäre es übermäßig kompliziert den Dateinamen zu ermitteln:

Delphi-Quellcode:

  function GetProcessFilename2k(PID: DWord): WideString;
  var hProc: Cardinal;
    Buffer: PWideChar;
  begin
    //MAX_PATH under NT is 32767 wchars + 1 for terminating 0 wchar
    GetMem(Buffer, 32768 * 2);
    hProc := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, PID);

    if hProc <> 0 then
    begin
      if GetModuleFileNameExW(hProc, 0, Buffer, 32768 * 2) <> 0 then Result := Buffer
      else Result := '';

      CloseHandle(hProc);
    end;

    FreeMem(Buffer, 32768 * 2);
  end;

Ich behaupte auch, der Code wird dadurch nicht unübersichtlicher. Das Programm erhält aber signifikant mehr Usability.

[Delphi-Laie]

Entgegen meiner ersten Aussage spendierte ich meinem Programm doch funktionale Erweiterungen:

- Möglichkeit der Prioritätensetzung und des Beendens der Prozesse und Threads des Usermodus' („Ring 3“?!).
- Möglichkeit des Beenden von Fenstern und Kindfenstern („ChildWindows“)

sowie einige kleine Detailverbesserungen/-korrekturen. Das Beenden wird allerdings nicht überprüft, sondern nur die zurückgegebene Information über das (manchmal nur angeblich erfolgreiche, also nicht immer tatsächliche) Beenden ausgewertet.

Vielleicht gelingt es mir zudem noch, den ersten Punkt auf den Kernelmodus („Ring 0“?!) auszuweiten.

Edit: Noch einmal geringfügig verbesserte und fehlerbereinigte Version hochgeladen.

[Delphi-Laie]

Da kein Delphi momentan 64-Bit-Compilate erzeugen kann, 64 Bit jedoch für die volle Funktionalität dieses Programmes unter 64-Bit-Windows nötig sind (z.B. werden die Module fremder Prozesse unter 64 Bit von einem 32-Bit-Programm nicht ermittelt), migrierte ich dieses mein Projekt in wochenlanger mühsamer Arbeit nach Lazarus (von wegen 1:1-Übersetzbarkeit). Ergebnis sind ein 32- und ein 64-Bit Compilat, welche ich inkl. Quelltexten hier zur Verfügung stelle.

Lazarus ist nach meiner Beobachtung tendenziell weniger fehlertolerant als Delphi, so daß diese Arbeit auch viele (kleine) Fehler in den Delphi-Quelltexten offenbarte.

Hinzu kam auch noch eine Spalte für 32-Bit-Module (Ergebnisse sind nur unter 64 Bit möglich), ich konnte allerdings noch kein Programm finden, das welche benutzt.

Für die volle Funktionalität empfielt sich, das Programm als Administrator bzw. mit Administratorrechten auszuführen. Damit kann man auch in den Systemprozessen und -threads fast nach Belieben schalten und walten, d.h. Prioritäten verändern oder sogar Prozesse bzw. deren Threads (gewaltsam) beenden (die Privilegien dafür holt sich das Programm zum Programmstart). Zu meinem Erstaunen läßt sich damit sogar Windows 6.1 („7“) zum Absturz bringen.

Das 32-Bit-Compilat funktioniert im übrigen auch und sogar unter Windows ME.

Wochen-, ja monatelange Ein-Mann-Projekte können kaum fehlerfrei sein, zumal man dabei nur sein eigener Korrektor ist bzw. sein kann. Fehlerberichte sind mithin mit Dank willkommen!