Dienste und PID?

[Mattze]

Hallo,

ich lasse mir die Dienste mit EnumServicesStatusEx auflisten.
Dabei habe ich festgestellt, dass einige Dienste den Status "wird ausgeführt" haben, aber keine PID zu ermitteln ist.
Weder die, die mit EnumServicesStatusEx kommt, noch mit Queryservicestatusex. Als PID wird 0 zurückgeliefert (z. B. beim Dienst ACPI).

Wie ist sowas überhaupt möglich?

Wie kriege ich raus, ob ein Dienst 32Bit oder 64Bit ist?

Mit IsWow64Process kriegt man das nur über die PID.
Wenn nun aus welchen Gründen auch immer keine PID existiert, wie mach ich das dann?
(Siehe oben oder Dienste mit dem Status "beendet".)

Gruß
Mattze

[Luckie]

Kann es sein, dass dir die Rechte fehlen? Einen Prozess ohne PID kann es nicht geben.

[Mattze]

Hallo Michael,

eben! Der Meinung bin ich eigentlich auch.
SeDebugPrivilege habe ich mir natürlich gleich zu Anfang des Programmes gegeben.
Wenn die nicht irgendwo wieder kassiert werden, habe ich also eigentlich die entsprechenden Rechte.
(Zumindestens funktioniert für Prozesse mit alles - in TProcessEntry32 über CreateToolhelp32Snapshot, Processfirst, Processnext...).
Bei Diensten kriege ich fastnimmer die PID 0 (in einem array von TEnumServiceStatusEx(-es) über EnumServicesStatusEx.)
Bei Diensten, deren Status "beendet" oder "deaktiviert" ist, würde ich das ja noch verstehen - obwohl ich von denen natürlich auch gerne die Bit-Breite wüsste. (Wie?)
Aber, da sind auch Dienste wie ACPI, AFD...

Ob das schon damit zusammenhängt, dass das ein 32Bit-Programm in einer 64-Bit-Umgebung ist?

Also, ich weiß da nicht weiter...
(Ich habe es z. Bsp. auch mal über die Prozessliste versucht (siehe oben). Aber da tauchen die Dienste (auch wenn sie eine PID haben) nicht auf.)
Ich finde von 490 Diensten gerade 7 64er und 3 32er.
(Allerdings sind über die Hälfte "beendet". Trotzdem,der Rest "wird ausgeführt", es wird aber trotzdem keine PID ermittelt.)

Gruß
Mattze

[Luckie]

Zitat:

Ob das schon damit zusammenhängt, dass das ein 32Bit-Programm in einer 64-Bit-Umgebung ist?

Das wird es sein, denke ich mal. aber ich glaube, es gibt einen Möglichkeit. Nur bin ich, was 64-Bit angeht nicht ganz Firm.

[Mattze]

Hallo,

na-ja, ganz sicher bin ich mir da nicht.
Ich habe das für Prozesse gemacht und kriege auch mit meinem 32Bit-Programm (Delphi 7 pro) unter Win 7 pro 64 alle möglichen Daten für 32Bit- und 64Bit-Prozesse, die PID eingesschlossen.
(Siehe meine Anfrage zu VirtualQueryEx, gleich hier.)

Mich wundert auch, dass die Dienste nicht in der Prozessliste erscheinen (bis auf ganz wenige Ausnahmen).
Für mich ist der Prozess der übergeordnete Begriff und umfasst alles, was zurzeit auf dem Computer läuft. (Also auch Programme und Dienste. Zumindestens für Programme gilt das auch - siehe Taskmanager.)

Na ja, und die Frage bleibt: Wie kriege ich die Breite (32 oder 64) für einen Dienst, für den ich keine PID habe, der aber in der Serviceliste - mit EnumServicesStatusEx - aufgezählt wird?
Das müsste dem System ja dann durchaus bekannt sein!

Gruß
Mattze

[Namenloser]

Das ist ziemlich sicher ein Rechte-Problem. Dienste laufen nicht unter deinem Benutzer sondern unter dem privilegierten SYSTEM-User. Deswegen hat dein Programm als normaler User-Prozess keinen Zugriff darauf. Starte dein Programm mal als Administrator, dann könnte es gehen.

Der Task-Manager zeigt die Prozesse von anderen Benutzern ja auch erst an, wenn du ihn im Administrator-Modus startest.

[Luckie]

Aber teilweise bekommt er ja die PID, wenn ich ihn richtig verstanden habe.

[Mattze]

Hallo Namenloser,

1. Ich bin Administrator.
2. Das Programm wird (sowieso) immer als Administrator ausgeführt. (Es zeigt noch eine riesige Menge Infos vom System mehr an. Alles was ich so in den letzten Jahren irgendwo im Netz oder meinem Kopp gefunden habe. Reine Spielerei und Bastelei! Da ist es durchaus wahrscheinlich, dass für das Eine oder Andere Admin-Rechte gebraucht werden.)
3. Siehe Luckie. Für EvtEng kriege ich eine PID und, da es auch in der Prozessliste ist, eine Breite von 64Bit.
Für VMNetDHCP das gleiche, nur 32Bit.
Ein paar, ganz wenige, gibt es schon, bei denen es klappt!
Und, wenigstens die genannten dürften System-Prozesse sein. Also,soooo einfach scheint es leider nicht zu sein.

Gruß
Mattze

[Namenloser]

Ich tippe trotzdem auf ein Rechteproblem. Vielleicht haben die Dienste, bei denen es geht, irgendein Flag aktiviert, das die anderen nicht haben, oder umgekehrt (UiAccess oder sonstwas). Hast du auch mal die UAC komplett deaktiviert? Nur um diese Fehlerquelle auszuschließen. Die UAC führt nämlich auch manchmal zu komischem Verhalten, das einen ganz schön in die Irre führen kann.

Auch interessant wäre, was passiert, wenn dein Programm (bzw. die entsprechende Routine) ebenfalls als Dienst läuft.

[Mattze]

Hallo Namenloser,

auch die UAC usw.ist deaktiviert.
Sicher, ein Flag kann man nie ganz ausschließen.
Das wäre aber komisch, wenn es ausgerechnet ein paar System-Dienste nicht gesetzt hätten!

Es bleibt natürlich trotzdem die Frage, wie ich ohne PID an die Breite eines Dienstes rankomme.

Gruß
Mattze

[HolgerX]

Hallo..

Viele Dienste, gerade Systemdienste werden als Sub-Dienst mit svchost gestartet. Diese Dienste können in deiner Enum zwar einzeln aufgelistet sein, haben aber keine PID, weil nur der Main-Dienst (svchost) eine bekommt.

Somit müsstest Du wohl nach einem anderen Weg suchen, um weitere Infos zu bekommen.

Vielleicht gibs ja eine API hierfür, den Tools wie der ProzessExplorer zeigen ja auch mehr Infos.

[Mattze]

Hallo,

der process explorer macht das nur für Prozesse. Da ist das "kein Problem". Das kriege ich auch, vielleicht sogar noch mehr - soweit man mit 32Bit im 64er System rumwerkeln kann.

Wie gesagt, das Problem sind die Dienste...

Ich habe gerade im Taskmanager nachgesehen. Tatsächlich!!! Viele Dienste haben auch da keine PID.
Die Dienste, die da eine haben, haben auch bei mir eine.

Also, wenn MS selber da nicht mehr liefert...
Nun ja, schaun mer mal, was man da noch so machen kann...

Gruß
Mattze

[Luckie]

Wozu brauchst du die PID denn?

[Zacherl]

Zitat:

Zitat von Mattze (Beitrag 1310601)

Ich habe gerade im Taskmanager nachgesehen. Tatsächlich!!! Viele Dienste haben auch da keine PID.

Das sind die Dienste, die zur Zeit nicht laufen :D EnumServicesEx gibt dir auch eine Liste aller Services. Darunter auch die inaktiven oder deaktivierten. Das musst du filtern, wenn du nur die Laufenden haben willst.

[Mattze]

Hallo,

wozu die PID?
Das ist genau das "Wozu" meiner Anfangsfrage.
Ich möchten rauskriegen, ob der Dienst nun 32- oder 64-Bit-breit ist.
Bei Prozessen nehme mich dazu IsWow64Process. Dazu muss man zuerst mal
OpenProcess machen und dazu braucht man die PID.
Ich wollte nun probieren, ob das bei Diensten vielleicht genauso funktioniert.

Übrigens habe ich eben noch ein Problem gesehen.
Über EnumServicesStatusEx und GetServiceExecutablePath kriegt man den Pfad der Dienste-Datei.
Wie üblich ist der oft %Systemroot%\System32\drivers\[Dienstdatei]. (Z. Bsp. c:\Windows\system32\drivers\cdrom.sys) Unter XP mag das auch noch gestimmt haben.
Unter Win 7 pro stimmt das nicht mehr! (Immer???)
(Z. Bsp.: Die Cdrom.sys liegt in:
C:\Windows\System32\DriverStore\FileRepository\cdr om.inf_amd64_neutral_0b3d0d1942ab684b\cdrom.sys
und
C:\Windows\winsxs\amd64_cdrom.inf_31bf3856ad364e35 _6.1.7601.17514_none_bdcf6151ba66f48b\cdrom.sys)
Also, man kann nicht mal so einfach die Dienste-Datei untersuchen nach 32 oder 64Bit.

Also, ich bin nun erst mal am Ende meiner Ideen angekommen.
Wie kriege ich denn nun die richtige Datei?

Gruß
Mattze

[Zacherl]

IsWow64Process funktioniert definitiv auch bei Services. Dass du für bestimmte Services keine PID bekommst, liegt wie gesagt daran, dass der entsprechende Service momentan nicht ausgeführt wird.

Musst du denn auch für inaktive Services ermitteln können, ob es sich um einen 32 oder 64 Bit Prozess handelt? Bzw. was genau ist das Problem mit GetServiceExecutablePath? Konnte dir da nicht ganz folgen.

Für laufende Prozesse kannst du den Pfad hiermit bestimmen:
http://www.delphipraxis.net/160046-d...ermitteln.html

[Luckie]

Sys Dateien sind ja auch eigentlich Treiber und keine Dienste.

[Mattze]

Hallo,

vielen Dank für die schnelle Antwort. Das mit dem 64Bit-Pfad werde ich probieren.

Müssen muss ich das eigentlich alles nicht, aber wissen möchte ich es doch gern.
Ich möchte soviele Infos wie möglich zu Prozessen und Diensten bekommen.
Einfach aus dem Interesse heraus, was denn alles machbar ist.
Und man kriegt auch ein bisschen Gefühl dafür, wie man mit den API-Funktionen, speziell, wenn man sie selber einbauen muss, umzugehen hat.
Und da das bei Prozessen geht und Du schreibst, dass das IsWow64Process auch bei Diensten klappt, möchte ich das gerne machen...

Wie gesagt, selbst bei beendeten Diensten, die Windows ja noch in der Liste der Dienste angibt, bin ich der Meinung, dass Windows durchaus weiß, ob 32- oder 64Bit.

Ich probiere weiter...

Nun, das mit den sys-Dateien ist schon klar. Nur, das Windows eben wie beschrieben den (falschen) Ort der Cdrom.sys in der Diensteliste angibt zum Dienst Cdrom.
Als Typ sagt Windows sogar: Gerätetreiber. Trotzdem: Diensteliste!!! (EnumSERVICESStatusEx)

Gruß und schönen Abend
Mattze

[Mattze]

Hallo Zacherl,

im Grunde gießt Du Wasser auf meine Rumreitermühlen.
Du betonst zwar "laufende Prozesse", aber...
Da Windows die Dienste ja auch mal startet, muss es doch auch ohne PID wissen, wo die wirklich sind.
(Bei Prozessen muss Windows ja auch vor dem Start - also auch ohne PID - wissen, wo er sie herholen soll.)
Und, z. Bsp., das will ich eben auch wissen.
Ob das undokumentiert ist?

Übrigens WMI mit W32_SystemServices gibt (im 64er System?) auch den "falschen" Pfad aus!
Für cdrom.sys als auch C:\Windows\system32\drivers.

Gruß
Mattze

[Zacherl]

Ja klar, die Prozesspfade hat das System selbstverständlich. Ich werde das gleich selbst mal testen. Bei mir zumindest liegt die cdrom.sys allerdings an genau der genannten Stelle (C:\Windows\system32\drivers\cdrom.sys).

Mein nicht optimierter, auf die Schnelle zusammengeschusterter Testcode:

Delphi-Quellcode:

procedure PrintServicePaths(IncludeDrivers, IncludeInactive: Boolean);
type
  ENUM_SERVICE_STATUSW = record
    lpServiceName: LPWSTR;
    lpDisplayName: LPWSTR;
    ServiceStatus: SERVICE_STATUS_PROCESS;
  end;
  PENUM_SERVICE_STATUSW = ^ENUM_SERVICE_STATUSW;
var
  SvcMgr,
  Svc: SC_HANDLE;
  SvcType,
  SvcState,
  SizeNeeded,
  ServiceCount: DWord;
  Services,
  Service: PENUM_SERVICE_STATUSW;
  I: Integer;
  Config: PQueryServiceConfigW;
begin
  SvcMgr :=
    OpenSCManager(nil, nil, SC_MANAGER_CONNECT or SC_MANAGER_ENUMERATE_SERVICE);
  if (SvcMgr <> 0) then
  try
    SvcType := SERVICE_WIN32;
    if (IncludeDrivers) then
    begin
      SvcType := SERVICE_WIN32 or SERVICE_DRIVER;
    end;
    SvcState := SERVICE_ACTIVE;
    if (IncludeInactive) then
    begin
      SvcState := SERVICE_STATE_ALL;
    end;
    if not EnumServicesStatusExW(SvcMgr, SC_ENUM_PROCESS_INFO, SvcType,
      SvcState, nil, 0, @SizeNeeded, @ServiceCount, nil, nil) then
    begin
      if (GetLastError <> ERROR_MORE_DATA) then
      begin
        RaiseLastOsError;
      end;
    end;
    GetMem(Services, SizeNeeded);
    try
      if not EnumServicesStatusExW(SvcMgr, SC_ENUM_PROCESS_INFO, SvcType,
        SvcState, PByte(Services), SizeNeeded, @SizeNeeded, @ServiceCount,
        nil, nil) then
      begin
        RaiseLastOsError;
      end;
      Service := Services;
      for I := 0 to ServiceCount - 1 do
      begin
        WriteLn(Format('[%4d] %s', [Service^.ServiceStatus.dwProcessId,
          Service^.lpServiceName]));
        Svc :=
          OpenService(SvcMgr, Service^.lpServiceName, SERVICE_QUERY_CONFIG);
        if (Svc <> 0) then
        try
          if not QueryServiceConfig(Svc, nil, 0, SizeNeeded) then
          begin
            if (GetLastError <> ERROR_INSUFFICIENT_BUFFER) then
            begin
              RaiseLastOsError;
            end;
          end;
          GetMem(Config, SizeNeeded);
          try
            if not QueryServiceConfig(Svc, Config, SizeNeeded, SizeNeeded) then
            begin
              RaiseLastOsError;
            end;
            WriteLn('  Path: ' + Config^.lpBinaryPathName);
          finally
            FreeMem(Config);
          end;
        finally
          CloseServiceHandle(Svc);
        end else RaiseLastOsError;
        Inc(Service);
      end;
    finally
      FreeMem(Services);
    end;
  finally
    CloseServiceHandle(SvcMgr);
  end else RaiseLastOsError;
end;

Erhalte für laufende Prozess wie erwartet eine PID, für Treiber und inaktive Prozesse 0. Die Pfade habe ich stichprobenartig überprüft und die stimmen auch soweit.

[Mattze]

Hallo Zacherl,

toll! Vielen Dank! Das werde ich morgen gleich mal ausprobieren.

Mit der cdrom.sys ist ja komisch.
Bei meinem Win 7 pro 64 ist der drivers-Ordner (C:\Windows\System32\drivers) fast leer.
Da liegen ganze 4 Sachen drin und eine davon ist noch eine Readme.txt (Was hat die da zu suchen?).

Gruß
Mattze

[Dalai]

Kann es sein, dass du im falschen Verzeichnis schaust, weil du %SystemRoot%\system32 mit %SystemRoot%\Sysnative bzw. %SystemRoot%\SysWow64 verwechselst? Siehe Wow64.

MfG Dalai

[Mattze]

Hallo Dalai,

nein, das ist es nicht.
Ich weiß inzwischen, was es ist und muss mich da vor allen Dingen bei Zacherl sehr entschuldigen.
Die 1. Hälfte ist mir sehr peinlich, die 2. Hälfte beruhigt mich aber und die 3. Hälfte (!!!) stellt gleich die Frage, wieso das so ist.

Ich benutze seid vielen Jahren meinen eigenen Ersatz-Explorer (EE). Soweit ich mich erinnere, gab es damit noch nie Probleme.
Nun bin ich aber durch Zacherls Hinweis, dass bei ihm alles da ist, misstrauisch geworden und habe heute Nacht mal den Window Explorer (WE) gestartet. Alles da unter drivers!!!
Ich habe nun auch andere EEs probiert - das gleiche Problem!
Es scheint ein 2*32Bit-Problem zu sein!!!
Die ausprobierten EEs sind auch 32Bit breit und können es alle nicht.
64Bit EEs habe ich zwar noch nicht probiert, aber da bin ich sicher, dass es kein Problem ist.

Ich kann mir allerdings nicht vorstellen, was da sooo unterschiedlich ist und was man dagegen machen könnte.
Vielleicht hat ja jemand eine Idee!

Gruß
Mattze

[Zacherl]

Zitat:

Zitat von Mattze (Beitrag 1310868)

Ich kann mir allerdings nicht vorstellen, was da sooo unterschiedlich ist und was man dagegen machen könnte.
Vielleicht hat ja jemand eine Idee!

Dalai hat schon das richtige Stichwort gegeben :) Wenn du in deinem 32 Bit Ersatzexplorer in das C:\Windows\System32 Verzeichnis navigierst, landest du in Wirklichkeit (vollkommen transparent) aber in C:\Windows\SysWow64.
Das System lenkt Zugriffe von 32 Bit Prozessen auf den System32 Ordner automatisch nach SysWow64 um, damit Dlls und andere Resourcen ohne viel Aufwand vom Programm geladen werden können. System32 und SysWow64 enthalten zum Großteil die selben Dateien, nur dass in System32 alles für 64 Bit - und im SysWow64 alles für 32 Bit kompiliert ist. Bei den Treibern macht es keinen Sinn eine 32 Bit Version beizulegen, da der Kernel sowieso nur 64 bit Kompilate laden kann.

In deinem eigenen Programm kannst du dieses Verhalten über die Wow64DisableWow64FsRedirection API deaktivieren (nur für den aufrufenden Thread, wenn ich mich recht erinnere).

[Mattze]

Hallo Zacherl,

vielen Dank für den Tipp. Nun muss ich bloß noch rauskriegen, wo ich das Disablen und Enablen am besten einbaue. (Bisher habe ich es noch nicht hinbekommen...)

Das kommt davon, wenn man zu lange auf ausgetretenen Pfaden (32Bit) bleibt und der Zug schon kräftig weitergefahren ist (64Bit).

Nun ja, aber 900,-€ für XE2 pro ist natürlich eine Stange Geld und die Starter macht auch keine 64Bit. (Außerdem wäre das so oder so für mich zu wenig!)

Gruß
Mattze