Es sieht also so aus, als wenn nicht nur
cabach Probleme mit SuRun beim Windows-Start hat. :huh: Das macht es endlich nachvollziehbar.
Ich vermute, dass bei Dir auch "SuRun /SysmenuHook" abschmiert.
Der Code für die Hooks hat sich seit Ewigkeiten nicht groß verändert, der für das Tray-Symbol schon.
Der Programmablauf von "SuRun /SysMenuHook" ist so:
* Wenn "SuRun /SysMenuHook" schon läuft->EXIT
* TrayShowAdmin-Thread im Dienst starten
[indent]
* Pipe zum Dienst öffnen
* Daten senden
* warten, bis der Dienst antwortet
[indent]
Der Dienst
* schaut nach, ob Administratoren mit leeren Kennwörtern exisitieren und meckert evtl.
* startet einen Thread, der das SuRun-Tray-Symbol bedient
* setzt im "SuRun /SysMenuHook"-Prozess eine Variable, dass der Thread läuft
[/indent]
[/indent]
* soll für den Benutzer kein Tray-Symbol angezeigt werden, beendet sich "SuRun /SysMenuHook"
* System-Menü-Hook und ShellExecute Hooks installieren
* dann fragt "SuRun /SysMenuHook" in einer Endlos-Schleife ab:
[indent]
* Alle 10s: läuft der Dienst? Wenn nicht->Exit
* Soll Tray-Symbol angezeigt werden?
[indent]
Ja:
* Wird TraySymbol noch nicht angezeigt: Symbol erstellen
* Symbol, entsprechend des Benutzerstatus verändern
Nein:
* Wird TraySymbol noch angezeigt: Symbol entfernen
[/indent]
* Soll weder Symbol angezeigt, noch einer der Hooks verwendet werden? ->Exit
[/indent]
Der Thread im Dienst läuft in einer Endlos-Schleife:
* Warte 333ms auf Client-Prozess-Ende, wenn Client beendet, Thread Exit
* Lese aktives Fester aus Client-Prozess
* Hole Benutzernamen/Status vom aktiven Fenster
* Schreibe Benutzernamen/Status vom aktiven Fenster in Client-Prozess
Der einzige Punkt, an dem es knacken kann ist, wenn "SuRun /SysmenuHook" sich beendet während der Thread im Dienst dessen Speicher verändert... aber normal sollte Windumms da einen Crash verhindern.
Kannst Du mir einen DrWatson Crash-Dump von einem SuRun Absturz schicken?
Ich würde wirklich gerne wissen, wo das kracht!
