Archiv der Kategorie: Quirks

Systemdienste vom Typ Kernel Driver auflisten und Spezialfall npcap

Das Auflisten von Systemdiensten ist mit der PowerShell eigentlich sehr einfach, doch wie sooft lauern auch kleine „Stolperfallen“. Insbesondere der Netzwerkdienste npcap, der u.a. von Wireshark verwendet wird, fällt so richtig aus der Rolle und kann einem „gestressten“ Admin Nerven und vor allem Zeit kosten.

Eigentlich ist alles ganz einfach. Ein

Get-Service
listet alle vorhanden Systemdienste auf, die Eigenschaft ServiceType gibt an, ob es sich um einen prozessbasierten Dienst oder einen „Kernel Service“ handelt.

Der folgende Aufruf gibt für den Dienst npcap (der über Nmap isntalliert wird) auch die korrekte Bezeichnung zurück.

Get-Service npcap | Select-Object Name, ServiceType

Npcap wird als Dienst vom Typ „KernelDriver“ ausgegeben.

Die erste „Überraschung“ entsteht beim Gruppieren aller Dienste nach der ServiceType-Property.

Get-Service | Group-Object ServiceType

Der Grund für die Überraschung: „KernelDriver“ erscheint nicht als Gruppenname, wird also nicht abgefragt. Der Dienst ist auch in keiner der Gruppen enthalten. Stattdessen erscheinen als Gruppennamen Zahlen wie 224, 208 oder 240, bei denen es sich um zusammengesetzte Zweierpotenzen handelt (eventuell setzt sich der Wert für ServiceType bei einigen Diensten aus mehreren Zahlenwerten zusammen – dafür spricht, dass für den ServiceType dieser Dienste bei einer WMI-Abfrage per Win32_Service als „Unknown“ eingetragen wird).

Es bleibt mysteriös, denn die folgende Abfrage gibt nichts zurück;

get-service npca*

Auf einmal gibt es keinen Dienst mit dem Namen npcap mehr (der Platzhalter funktioniert natürlich beim Name-Parameter von

Get-Service
). Dies könnte eventuell mit der Art und Weise zu tun haben, wie npcap in der Registry unter HKey_Local_Machine\System\CurrentControlSet\Services eingetragen wurde.

Eine Abfrage der Systemdienste funktioniert etwas besser per WMI:

Get-CimInstance Win32_SystemDriver -Filter "Name='npcap'"

Hier ist auch die Verwendung von Platzhaltern kein Problem:

Get-CimInstance Win32_SystemDriver -Filter "Name like'npca%'"

Warum aber ein get-service npca* nichts zurückgibt, bleibt im Moment ein (weiteres) ungelöstes Rätsel (genauso, dass sich der Dienst auf meinem PC mit Windows 8.1 nicht starten lässt).

Seltsame PowerShell-Phänome (Teil 45)

Manchmal kann das Arbeiten mit der PowerShell nervig oder faszinierend sein. Je nachdem, ob eine Anforderung unbedingt umsetzen möchte, oder man viel Zeit hat sich mit besonderen „Phänomen“ zu beschäftigen. Das folgende, eigentlich ganz simple Phänom befindet sich bei mir im Moment noch in der Kategorie ungelöst.

Ausgangspunkt ist das Abfragen der Inhalte einer PowerPoint-Datei über die DocumentFormat.OpenXml-Assembly aus dem Open XML SDK.

Die Anforderung ist die Ausgabe aller Slides bzw. deren Ids. Auch wenn die folgende Vorgehensweise nicht die Richtige ist, sollte doch ein konsistentes Verhalten resultieren.

Der folgende Befehl sollte alle „Abkömmlinge“ vom Typ „SlideId“ holen

@($presentationPart.Presentation.Descendants()).Where{$_.GetType().Name -eq "SlideId"}

Die Abfrage gibt aber nichts zurück. Es funktioniert, wenn anstelle des -eq-Operators der -match- oder -like-Operator verwendet wird:

@($presentationPart.Presentation.Descendants()).Where{$_.GetType().Name-match "SlideId"}

Die Rückgabe besteht aus einem Objekt vom Typ SlideIdList und mehreren Objekten vom Typ SlideId. Irgendetwas scheint an dem Vergleich nicht zu stimmen.

Eigentlich sollte Where{} nur die Objekte liefern, die vom Typ „SlideId“ sind. Da es aber auch ein Objekt gibt, das vom Typ „SlideIdList“ ist, funktioniert der Vergleich mit dem eq-Operator nicht und es werden beim Vergleich mit „SlideId“ keine Objekte zurückgegeben.

Kurios ist, dass der folgende Vergleich funktioniert:

@($presentationPart.Presentation.Descendants()).Where{$_.GetType().Name-match "SlideId"}.ForEach{$_.GetType().Name -eq "SlideId"}

Diese Abfrage gibt für jeden Typnamen = „SlideId“ mit dem eq-Operator ein $true zurück. Es muss also „irgendwie“ mit dem Umstand zu tun haben, dass das erste Objekt vom Typ SlideIdList ist, die übrigen vom Typ SlideId und mit dem, was durch die Array-Konvertierung der Rückgabe von Descendants() (eine generische Collection) entstanden ist.

Da ich keine Lust habe, einen schönen Sonntagnachmittag mit der Lösung zu verbringen, gebe ich an dieser Stelle auf und bin gespannt, wann ich eine Erklärung für dieses (im Grunde natürlich vollkommen unwichtige) Phänom erhalte. Apropos unwichtige Kleinigkeit: Hätte sich Clifford Stoll irgendwann Ende der 80er Jahre nicht über eine Abrechnungsdifferenz von wenigen Cents gewundert, wäre er nicht einem der größten Hacker-Einbrüche in den USA auf die Spur gekommen.

Kleiner Fix für PScribo

PScribo von Ian Brighton ist ein Modul, das ich nach wie vor gerne verwende und weiterempfehle. Auch wenn der Versionsstand immer noch < 1.0 ist, scheint das Projekt noch aktiv zu sein (https://github.com/iainbrighton/PScribo/pulse).

Unter einem deutschsprachigen Windows erschienen zuletzt „jede Menge“ Fehlermeldungen. Eine Variable $Location war nicht definiert. Der Grund war, dass im Modulverzeichnis das Unterverzeichnis „de-De“ nicht vorhanden ist. Nachdem ich das Verzeichnis angelegt und die Psd1-Datei aus dem en-Us-Verzeichnis dort hinein kopiert hatte, lief es wieder durch.