Mithilfe von WMI zu erkennen, welches Gerät verursacht ein Win32_DeviceChangeEvent

Ich habe einige code schreiben, der erkennt, hinzufügen und entfernen von USB-Geräten, und ich habe mit dem folgenden WMI code zum registrieren für das Gerät ändern Benachrichtigungen:

watcher = new ManagementEventWatcher(query);
watcher.EventArrived += new EventArrivedEventHandler(DeviceChangeEventReceived);
watcher.Start();

Dies ist der hf-code:

void DeviceChangeEventReceived(object sender, EventArrivedEventArgs e)
{
   foreach (PropertyData pd in e.NewEvent.Properties)
   {
      Log.Debug("\t" + pd.Name + ":" + pd.Value + "\t" + pd.Value.GetType());
   }
}

Dies ist großen und ganzen, es funktioniert für alle USB-Gerät einstecken oder entfernen aus dem system. Das problem, dass ich habe ist, wie erkenne ich das das Gerät speziell, die Ursache der Ereignisse?

Anderer Stelle in meinem Programm, ich bin halten Sie eine Liste der aktuell verbundenen Geräte, die mich am meisten interessiert, so dass, wenn ein Gerät-entfernt event durch kommt, kann ich überprüfen, dass die Liste gegen WMI mit "select * from Win32_PnPEntity" oder einige andere ähnliche Abfrage. ABER, dies ist eine sehr ungenaue und umständliche Art und Weise der Ermittlung des Geräts, das entfernt wurde. Das zusätzliches problem ist, ich habe keine Möglichkeit, genau zu sagen, was Gerät Hinzugefügt wurde, es sei denn, ich cache die gesamte Liste der Win32_PnPEntity vor der Zeit, und tun, wirklich tolle Vergleiche/Validierungen.

Übersehe ich etwas offensichtliches hier? Wie Verbinde ich das Gerät ändern Sie Ereignisse zu einem bestimmten Gerät?

UPDATE: ich habe noch nicht eine ideale Lösung für dieses problem, aber das was ich mache, ist die Aufrechterhaltung einer Liste der aktuell verbundenen Geräte (von der ich interessiert bin) in Erinnerung, und jedes mal, wenn ein Ereignis behandelt wird (siehe oben), habe ich die Abfrage der Win32_PnPEntity, um zu sehen, ob die Geräte, die ich gespeichert habe in meinem angeschlossenen Geräte in der Liste sind noch immer verbunden. Dies ist eine sub-optimale Lösung, denn es scheint nur seltsam, dass ich kann nicht alle spezifischen Geräte-Identifikation Informationen aus dem Ereignis, das angibt, "device change-Ereignis". Scheint SEHR seltsam, dass diese info nicht verfügbar ist. Seufzer

InformationsquelleAutor warriorpostman | 2011-03-11
  1. 15

    Okay, nach einigen weiteren Untersuchung und Experimentieren, habe ich herausgefunden, dass ich muss eine andere WMI-Abfrage, um mein problem zu lösen, das ist die Zuordnung eines Geräts "change" - Ereignis mit einem bestimmten Gerät. In diesem Fall, ich brauche zu finden, was zu sein scheint konventionell bezeichnet in WMI als "TargetInstance".

    So, ich habe folgende WMI-Abfrage-code anstelle

                ManagementEventWatcher watcher;
            string queryStr =
                "SELECT * FROM __InstanceCreationEvent " +
                "WITHIN 2 "
              + "WHERE TargetInstance ISA 'Win32_PnPEntity'"

            watcher = new ManagementEventWatcher(queryStr);
            watcher.EventArrived += new EventArrivedEventHandler(DeviceChangeEventReceived);
            watcher.Start();

    Also der Unterschied hier ist, dass die __InstanceCreationEvent hat eine Eigenschaft namens "TargetInstance", das ist GENAU das, was ich suchte. Ich warf die TargetInstance Eigenschaft einer ManagementBaseObject (das ist der Typ "Win32_PnPEntity" (gemäß der ISA-Klausel in der Abfrage oben), und Voila! Ich bekomme das spezifische Gerät, das erstellt wurde.

    Es immer noch irgendwie verwirrt mich, wie meine ursprüngliche Abfrage "Select * from Win32_DeviceChangeEvent" wäre hilfreich, um überhaupt jemand, da es keine zusätzlichen Informationen zur Verfügung gestellt, nachdem ein generisches event-Benachrichtigung ausgelöst wird. So oder so, diese neue Abfrage eine deutlich sauberere Lösung zu meine problem. WMI scheint ziemlich mächtig, aber das finden der richtigen Abfrage zu verwenden kann schwierig sein, und erfordert etwas Experimentieren.

    • Dieses nette Antwort tatsächlich funktioniert, aber es gibt leider einen Nachteil. Benutzer sollten sich bewusst sein, dass dies ist ein polling query (der Hinweis ist "in 2", und "innerhalb" ist nicht optional, für diese Abfrage). Es erfordert die CPU ständig poll, und dies kann gesehen werden als eine erhebliche CPU-Last (in meinen test über ~5% auf einem quad-core-system, also wirklich über 20% von einem single-core, mit zwei Abfragen mit "in 1") in der WmiPrvSE.exe service. Diese Ereignisse kommen auch nicht überraschend, dass etwa 1-2 Sekunden nach dem entsprechenden Win32_DeviceChangeEvent, so gibt es eine erhebliche Verzögerung in der Berichterstattung.
    InformationsquelleAutor warriorpostman
Schreibe einen Kommentar