Prozessstop automatisch erkennen

1. offizieller Beitrag

    Hallo zusammen, sry falls diese Frage schonmal gestellt wurde, aber arbeite mich gerade erst in AutoIt rein und hab auf anhieb nichts brauchbares im Web gefunden.

    Wie kann ich mit AutoIt erkennen ob ein prozess gestoppt wurde oder noch läuft ? Ich muss gerade ein Errorhandling bei einer automatischen Installation einer Software erstellen.
    Da ich aber nicht die 10000 möglichen Fehler einzeln behandeln möchte dachte ich an einen prozessstop.
    Das wäre dann zum Beispiel, wenn ein Fehler auftritt, ein Errorfenster erscheint und dann die installation oder sagen wir "der prozess" ohne manuellen Benutzereingaben, was ich vermeiden möchte, stehen bleibt.

    Wäre nett wenn mir da jemand helfen könnte.

    Lg Andy

    Ok, um es jetzt nochmal zu vereinfachen.

    ich brauche eine Möglichkeit, zu erkennen ob ein Prozess stillsteht oder nicht, um dann darauf zu reagieren. Am besten sollte die "erkennung" während meines ganzes Skriptes laufen. Hat da jemand eine Lösung für. ich such mir hier nen Wolf und hab keine Lust mir hier x workarounds zu schaffen!

    Lg Andy

    • Offizieller Beitrag
    Zitat

    Ich muss gerade ein Errorhandling bei einer automatischen Installation einer Software erstellen.
    Da ich aber nicht die 10000 möglichen Fehler einzeln behandeln möchte dachte ich an einen prozessstop.

    Der Prozess stoppt doch nicht, wenn ein Fehlermeldungsfenster auftaucht!?

    peethebee

    Ok stoppen ist der falsche Ausdruck, ich dachte eher an stillstehen. ;)

    Ne was ich einfach meine ist, dass wenn ich eine Installation automatisiere, dann jedoch zum Beispiel im Laufe der Zeit ein button oder ähnliches hinzukommt. Dann "könnte" es passieren das mein Skript nicht mehr vernünftig weiterläuft und die eigendlich automatisierten Fenster auf eine manuelle Eingabe warten. Das meine ich mit "stillstehen".
    Und ich suche nun eine möglichkeit um genau das zu erkennen, um darauf mit einem exit oder sogar nen Installationabbruch zu reagieren.

    Ich hoffe es ist jetzt klarer geworden, wo mein problem liegt ;)

    Lg Andy

    • Offizieller Beitrag

    Ja, aber das ist nicht einfach... Wenn du die Installtion sauber automatisierst (ControlClick, besser noch Silent-Parameter), dann überlebt sie in der Regel auch Updates (außer den Wechsel des Installationsprogrammes an sich) :).
    Veränderungen der Installation könnte man über WinGetClassList erkennen, wenn es unbedingt sein muss...

    peethebee

    Ich habe mit ControlClick auch gearbeitet und ein Update hat es auch schon überlebt ;)
    Nur wenn zum Beispiel im Daily Built aus irgendeinem grund an einer bestimmten stelle en Error erzeugt wird und dieses dann aufpoppt, dann ist dieser fehler nicht zwingend mit controllclick abgehandelt(wenn es zum beispiel ein error ist den ich noch nie hatte). Somit würde die Installation stillstehen trotz Controlclick.
    Ich hab jetzt 3 Möglichkeiten meines Wissenstands nach, was zur Abhilfe möglich wäre.

    1. Einfach in den Code alle Errorfenster die im Laufe der Zeit vorkommen einzeln anzuhandeln. ( Ein Alptraum eines jedes Entwicklers )

    2. Die Dauer der einzelnen Fenster messen und Winwait großzügig aufs nächste fenster warten, ansonsten halt abbruch ( Funktioniert zwar ist allerdings alles anderes als eine schöne und vor allem sicherer Methode - Offene Bausteile auf die ich verzichten möchte ;) )

    3. Die Methode die ich suche, nämlich das erkannt wird, dass die Installation stillsteht und sich ohne manuelle Benutzereingaben nichts mehr tut ( der eigendlich einzig richtige weg, nur weiß ich da nicht wie ich das umsetzen kann)

    Vielleicht gibt es auch noch andere Möglichkeiten, ich bin für Vorschläge offen. Meine Erfahrung mit AutoIt ist nahezu 0, daher wäre ich für weitere Tipps sehr dankbar.

    jetzt schau ich mir aber erstmal "WinGetClassList" an, danke schonmal :)
    lg Andy

    Es geht um unsere Client Software im Unternehmen. Ich nutze AutoIt um am Ende des Built prozesses eine automatische testinstallation zu machen, damit unser built manager im falle eines fehlerhaften builds direkt erkennen kann wo der fehler liegt und was los ist :P

    Gibt es denn keine allgemeine Lösung um stillstehende Prozesse zu erkennen ?

    Ja damit würde ich dann eine abwandlung der zweiten methode oben nutzen, diese ist zwar nicht optimal aber funktioniert. Ich denke ich werde wohl nicht darum herumkommen dies so zu verwenden.

    Klar der installationsvorgang und der Kopiervorgang dauern natürlich länger, dass muss ich berücksichtigen :)

    Aber danke schonmal für die ratschläge !
    Wenn dir noch was brauchbares einfällt wäre ich dankbar für weitere Tipps.

    Danke und Lg Andy

    • Offizieller Beitrag

    Vielleicht bringt es dir was die Prozesseigenschaften auszuwerten.
    Mal ein Bsp. für die ersten 5 Durchläufe, die Daten aller Prozesse im 2 Sekunden-Takt:

    Spoiler anzeigen
    [autoit]

    $strComputer = "."
    $objWMIService = ObjGet("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & $strComputer & "\root\cimv2")
    $objRefresher = ObjCreate("WbemScripting.SWbemRefresher")
    $colItems = $objRefresher.AddEnum _
    ($objWMIService, "Win32_PerfFormattedData_PerfProc_Process").objectSet
    $objRefresher.Refresh
    $str = ''

    [/autoit] [autoit][/autoit] [autoit]

    For $i = 1 to 5
    For $objItem in $colItems
    $str &= "Caption: " & $objItem.Caption & @LF
    $str &= "Creating Process ID: " & $objItem.CreatingProcessID & @LF
    $str &= "Description: " & $objItem.Description & @LF
    $str &= "Elapsed Time: " & $objItem.ElapsedTime & @LF
    $str &= "Handle Count: " & $objItem.HandleCount & @LF
    $str &= "ID Process: " & $objItem.IDProcess & @LF
    $str &= "I/O Data Bytes Per Second: " & $objItem.IODataBytesPersec & @LF
    $str &= "I/O Data Operations Per Second: " & $objItem.IODataOperationsPersec & @LF
    $str &= "I/O Other Bytes Per Second: " & $objItem.IOOtherBytesPersec & @LF
    $str &= "I/O Other Operations Per Second: " & $objItem.IOOtherOperationsPersec & @LF
    $str &= "I/O Read Bytes Per Second: " & $objItem.IOReadBytesPersec & @LF
    $str &= "I/O Read Operations Per Second: " & $objItem.IOReadOperationsPersec & @LF
    $str &= "I/O Write Bytes Per Second: " & $objItem.IOWriteBytesPersec & @LF
    $str &= "I/O Write Operations Per Second: " & $objItem.IOWriteOperationsPersec & @LF
    $str &= "Name: " & $objItem.Name & @LF
    $str &= "Page Faults Per Second: " & $objItem.PageFaultsPersec & @LF
    $str &= "Page File Bytes: " & $objItem.PageFileBytes & @LF
    $str &= "Page File Bytes Peak: " & $objItem.PageFileBytesPeak & @LF
    $str &= "Percent Privileged Time: " & $objItem.PercentPrivilegedTime & @LF
    $str &= "Percent Processor Time: " & $objItem.PercentProcessorTime & @LF
    $str &= "Percent User Time: " & $objItem.PercentUserTime & @LF
    $str &= "Pool Nonpaged Bytes: " & $objItem.PoolNonpagedBytes & @LF
    $str &= "Pool Paged Bytes: " & $objItem.PoolPagedBytes & @LF
    $str &= "Priority Base: " & $objItem.PriorityBase & @LF
    $str &= "Private Bytes: " & $objItem.PrivateBytes & @LF
    $str &= "Thread Count: " & $objItem.ThreadCount & @LF
    $str &= "Virtual Bytes: " & $objItem.VirtualBytes & @LF
    $str &= "Virtual Bytes Peak: " & $objItem.VirtualBytesPeak & @LF
    $str &= "Working Set: " & $objItem.WorkingSet & @LF
    $str &= "Working Set Peak: " & $objItem.WorkingSetPeak & @LF
    ConsoleWrite( $str & @CRLF & @CRLF)
    $str = ''
    Sleep (2000)
    $objRefresher.Refresh
    Next
    Next

    [/autoit]

    Edit:
    Evtl. bringt dich ja das Auflisten der Threads/ ~status weiter.
    Auflisten kannst du so:

    Spoiler anzeigen
    [autoit]

    $objDictionary = ObjCreate("Scripting.Dictionary")
    $strComputer = "."
    $objWMIService = ObjGet("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & $strComputer & "\root\cimv2")
    $colProcesses = $objWMIService.ExecQuery("Select * from Win32_Process")

    [/autoit] [autoit][/autoit] [autoit]

    For $objProcess in $colProcesses
    $objDictionary.Add ($objProcess.ProcessID, $objProcess.Name)
    Next

    [/autoit] [autoit][/autoit] [autoit]

    $colThreads = $objWMIService.ExecQuery ("Select * from Win32_Thread")

    [/autoit] [autoit][/autoit] [autoit]

    For $objThread in $colThreads
    $intProcessID = Int($objThread.ProcessHandle)
    $strProcessName = $objDictionary.Item($intProcessID)
    ConsoleWrite( $strProcessName & @TAB & $objThread.ProcessHandle & _
    @TAB & $objThread.Handle & @TAB & $objThread.ThreadState & @CRLF)
    Next

    [/autoit]

    Haben die Fehlermeldungen irgendwelche besonderen Eigenschaften?
    z.B. gleiche Stellen im Titel, im Text ... die in der Installation sonst nicht vorkommen

    Die meisten schon, da im Title immer Info steht und im Text irgendwo "Error" oder "Fehler" auftaucht war das recht einfach diese abzufangen.
    Das mit dem Stillstand war etwas spannender, da das script aber heute fertig werden muss, hab ich erstmal den sicheren aber unschönen Weg mit WinWait genommen.

    Ich schau mir aber gleich mal den Code von BugFix an, vielleicht find ich da ja was schöneres heraus :)