WMI schmeißt random Exceptions

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    WMI schmeißt random Exceptions

    Ich hab zum Testen etwas geschrieben:

    VB.NET-Quellcode

    1. Dim sb As New StringBuilder
    2. Try
    3. Dim mos As New ManagementObjectSearcher()
    4. mos.Query = New ObjectQuery("select * from Win32_Battery")
    5. sb.AppendLine("WMI-Akkutest")
    6. sb.AppendLine("Query: select * from Win32_Battery")
    7. sb.AppendLine("------------")
    8. Dim moc As ManagementObjectCollection = mos.Get()
    9. If moc.Count > 0 Then
    10. For Each mo As ManagementObject In moc
    11. For Each a In ar
    12. Try
    13. sb.AppendLine(a & ": " & mo.GetPropertyValue(a).ToString)
    14. Catch ex As Exception
    15. sb.AppendLine("Bei " & a & " hats geknallt, und zwar so: " & ex.Message)
    16. End Try
    17. Next
    18. Next
    19. Else
    20. sb.AppendLine("Query fehlgeschlagen. Besitzt dieser Computer einen eingelegten Akku? Besitzt er überhaupt einen Akku?")
    21. End If
    22. sb.AppendLine("Test 4 erfolgreich.")
    23. Catch ex As Exception
    24. sb.AppendLine("Test 4 fehlgeschlagen.")
    25. sb.AppendLine(ex.Message)
    26. End Try
    27. Using outfile As New StreamWriter("craptestic4.txt")
    28. outfile.Write(sb.ToString())
    29. End Using
    30. If File.Exists("craptestic4.txt") Then
    31. Process.Start("craptestic4.txt")
    32. End If

    Als Ergebnis kam dann (auf nem Laptop natürlich) dies raus:
    Spoiler anzeigen
    WMI-Akkutest
    Query: select * from Win32_Battery
    ------------
    Availability: 2
    Bei BatteryRechargeTime hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    BatteryStatus: 2
    Caption: Interner Akku
    Chemistry: 6
    Bei ConfigManagerErrorCode hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei ConfigManagerUserConfig hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    CreationClassName: Win32_Battery
    Description: Interner Akku
    Bei DesignCapacity hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    DesignVoltage: 12464
    DeviceID: SMPNz4518RMDGDLAN123456789ABCDEbq20z4518RMDGDLAN123456789ABCDE
    Bei ErrorCleared hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei ErrorDescription hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    EstimatedChargeRemaining: 98
    EstimatedRunTime: 71582788
    Bei ExpectedBatteryLife hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei ExpectedLife hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei FullChargeCapacity hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei InstallDate hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei LastErrorCode hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei MaxRechargeTime hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Name: bq20z4518RMDGDLAN123456789ABCDE
    Bei PNPDeviceID hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    PowerManagementCapabilities: System.UInt16[]
    PowerManagementSupported: False
    Bei SmartBatteryVersion hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Status: OK
    Bei StatusInfo hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    SystemCreationClassName: Win32_ComputerSystem
    SystemName: ZBOOKPRO7
    Bei TimeOnBattery hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Bei TimeToFullCharge hats geknallt, und zwar so: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
    Test 4 erfolgreich.

    Warum schmeißt WMI nur bei einigen Einträgen ne Exception und bei anderen nicht?
    Versuchs mal ohne Try-Catch. Dann siehst Du Dir in der IDE die Variablen an und guckst, was Nothing ist. WMI schmeißt ja nicht die Exception, sondern das Programm, das versucht mit Nothing irgendwas zu machen.

    Ich vermute mal, dass für einige "mo.GetPropertyValue(a)" einfach keine Einträge vorhanden sind.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Ach so, das ist ne List (Of String), die alle Propertynamen von Win32_Battery enthält. Also Availability etc.
    Edit: cl.ly/CVNK <- Kann jemand mit nem Laptop dieses Programm auf besagtem Laptop mal ausführen und alle drei Tests ausführen?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Samus Aran“ ()

    Die "--------Test1---------" habe ich eingefügt
    Dateien
    • Ergebnis.txt

      (309,04 kB, 152 mal heruntergeladen, zuletzt: )
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Jo, danke. :)
    Irgendwie scheint es bei .ToString immer Exceptions zu hageln, bei den beiden anderen Varianten wird immer ne komplette XML-Fassung ausgegeben (oder mehrere, jeder dieser XML-Blöcke ist identisch), allerdings fehlen bei den exceptionwerfenden Einträgen die Werte. :huh:
    Liegt daran, dass Nothing zurückgegeben wird.
    .ToString funktioniert da einfach nicht. Dim Bla As String = Nothing.ToString wird zwar vom Compiler angenommen, bringt aber einen Laufzeitfehler.

    Wegen XML: Ich tippe mal auf Try-Catch.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    naja, TryCatch verursacht (nicht direkt) Fehler, sondern es verhindert nur, dass du die Fehler gleich angezeigt bekommst, wenn sie auftreten.
    Naja, wenn du deine Fehler lieber aus einer Log-Datei raussuchst, statt sie gleich beim debuggen anzugugge - jedem das seine.

    Allerdings treten u.U. natürlich Folgefehler auf (die dann auch geloggt werden? - fiel Fergnügen)