Hallo Kay,

ich habe SuRun einmal deinstalliert und dann nach einem Neustart neu installiert. Insgesamt: Der Explorer stürzte ab, nachdem ich mich über die Systemsteuerung vor dem Neustart als SuRunner eintrug. Nach erfolgtem Neustart hing sich der Explorer auf. Als ich mich einmal als UAC-Admin (kein SuRunner) eingeloggt habe, stürzte auch dort der Explorer ab. Das passierte allerdings nicht, als ich mich mit einem anderen UAC-Admin (ebenfalls kein SuRunner) eingeloggt habe.

So, wie es aussieht, tritt das Problem nur nach der SuRun-Installation auf. Bis jetzt habe ich jedenfalls nach den oben genannten "Anfangsschwierigkeiten" keine Probleme gehabt.

Das "Login-Problem" mit der Verzögerung vom Klick auf den Benutzernamen bis zum Erscheinen der Passwort-Eingabe ist höchstens etwas störend, scheint aber keine Einschränkung zu bedeuten. Wenn man sich abmeldet und wieder anmeldet, tritt diese Verzögerung übrigens nicht auf.
Das sollte nicht drin stehen! (Ist in meinem Win7 auch nicht drin.)
Testweise habe ich den Eintrag mit Autostarts ausgetragen. Etwas verändert hat sich anscheinend dadurch nicht. (Aber Du sagtest selbst, dass der Eintrag eigentlich nichts bewirken sollte.) Seltsam, wie er bei mir in die Registry gelangt sein könnte...

Ich habe diesmal etwas genauer über den "Testablauf" Buch geführt. Im ZIP-File findest Du das "Protokoll" inklusive der Windows-Report-Absturzdateien (falls Du damit etwas anfangen kannst).

http://n.ethz.ch/~kraftst/download/SuRun.zip
Hab alles hier genau so probiert.
Ich bekomm's einfach nicht nachvollzogen :'(
(Das GPF in "SuRunExt.dll_unloaded" kenne ich allerdings von früheren Versionen in Verbindung mit x64)
Alles klingt nach dem IAT-Hook:
* Wenn Du "Direkt in Programme einhängen..." deaktivierst, ist das Problem dann weg?
* Führst Du evtl. SuRun*.exe im Kompatibilitätsmodus zu XP oder im virtuellen Modus aus?
Stefan wrote:Als ich mich einmal als UAC-Admin (kein SuRunner) eingeloggt habe, stürzte auch dort der Explorer ab. Das passierte allerdings nicht, als ich mich mit einem anderen UAC-Admin (ebenfalls kein SuRunner) eingeloggt habe.
Defektes Konto?
Ich habe das ".dll_unloaded" verursacht GPF Problem mal näher untersucht. (Das scheint ab Windows Vista mehrere Produkte zu betreffen) SuRunExt scheint auf Fuktionen in Windows DLLs zuzugreifen, die noch nicht geladen/initialisiert sind. SuRunExt macht bei der Dll Initialisierung (DllMain) "nicht empfohlene Sachen" und die gehen z.B. bei Stefan schief. Die Reihenfolge, in der Windows DLLs in einen Prozess lädt und initialisiert, ist von System zu System verschieden. Deshalb kann ich bei mir den Fehler auch nicht finden.

Eine generelle Lösung für die Dll-Hölle gibt es IMHO nicht. Ich kann nur versuchen, am wenigsten falsch zu machen.

In der beiliegenden Beta habe ich die Hook-Initialisierung in einen eigenen Thread ausgelagert, der versucht zu warten, bis alle Dlls geladen sind, bevor er die Hooks initialisiert. Dadurch wird sicher gestellt, das SuRunExt in der "DllMain" nur empfohlene Dinge tut. Beim Entladen von SuRunExt wird darauf geachtet, dass der Init-Thread beendet ist (max. 1s warten, dann terminieren) und alle IAT-Hooks werden wieder zurückgesetzt.

Allerdings hat das auch Nachteile:
* Die Initialisierung ist langsamer und die Automagie "erwischt" keine früh vom Prozess gestarteten Programme.
* Das Beenden des Prozesses dauert u.U. 1s, wenn die Initialisierung noch nicht durch ist, SuRunExt aber wieder entladen wird.

Das ganze ist hoffentlich kompatibel und performant genug, um nicht aufzufallen.

SuRun 1.2.0.9 Beta 6 vom 12.10.2009
* FIX: SuRuns IAT-Hooks werden immer in einem separaten Thread gesetzt, um GPFs in SuRunExt.dll_unloaded zu verhindern.
* FIX: In den SuRun Einstellungen wird in Windows 7 "'SuRun Explorer' hier" immer deaktiviert und ausgegraut dargestellt.
Hallo Kay,

ich habe SuRun jetzt 3 Mal de- und wieder installiert. Nach der Installation habe ich mich immer im erscheinenden SuRun-Fenster als SuRunner eingetragen. Einmal habe ich das Einhängen deaktiviert, zwei Mal habe ich es drin gelassen. Explorer-Abstürze habe ich trotz diverser Neustarts nicht beobachten können.
Führst Du evtl. SuRun*.exe im Kompatibilitätsmodus zu XP oder im virtuellen Modus aus?
Gerade eben gesehen: Die InstallSuRun.exe wird bei mir im Kompatibilitätsmodus XP SP2 gestartet (ich kann nicht sagen, warum, das scheint Win7 automatisch bestimmt zu haben). Das bedingt wohl den Eintrag unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify.
Defektes [UAC-Admin-]Konto?
Glaube ich nicht, denn abgesehen von dem einem Mal habe ich mich immer problemlos als UAC-Admin einloggen können. Außerdem meldete Windows ja, dass es mit der SuRunExt.dll zusammenhing.

So, ich werde gleich die neue Beta ausprobieren.
Ich habe die neue Beta 6 installiert und das System 3 Mal gestartet. Es ist nichts ungewöhnliches passiert. Das "Login-Problem" besteht weiterhin, ist aber nicht so ernst.
Das ganze ist hoffentlich kompatibel und performant genug, um nicht aufzufallen.
Eine Verzögerung habe ich bemerkt: Nach der Passworteingabe verschwindet ja der Login-Schirm. Beim zweiten und dritten Mal schien es danach etwas länger zu dauern, bis die Symbole auf dem Desktop erscheinen etc., d.h. der Desktop richtig geladen ist. Aber abgestürzt ist nichts. (Und da mein System von der Power sowieso nicht recht repräsentativ ist...)
In der beiliegenden Beta habe ich die Hook-Initialisierung in einen eigenen Thread ausgelagert...
Beeindruckend, wie Du immer wieder Lösungen aus dem Hut zauberst! :-)
Es ist schon wieder passiert. Verflixt! Beim Einloggen meldete Windows, dass der Explorer abgestürzt ist und neu gestartet werden muss.

Der einzige Unterschied war, dass ich diesmal beim Booten einen USB-Stick angeschlossen habe. Ich habe gerade eben wieder einen Neustart durchgeführt und dabei den USB-Stick eingesteckt, doch jetzt ist nichts passiert...

Fehlerbucket , Typ 0
Ereignisname: APPCRASH
Antwort: Nicht verfügbar
CAB-Datei-ID: 0

Problemsignatur:
P1: Explorer.EXE
P2: 6.1.7600.16385
P3: 4a5bc60d
P4: SuRunExt.dll_unloaded
P5: 0.0.0.0
P6: 4ad3431a
P7: c0000005
P8: 10004da0
P9:
P10:

Soll ich wieder die Reportdatei hochladen?
Nein, das brauchst Du nicht.
Ich habe SuRun so verändert, dass SuRunExt die Exception abfängt und den Init-Thread neu startet.
Muss noch ein paar Tests machen.

Das Problem mit der Initialisierung von Dlls ist so alt, wie Windows selbst.

Dlls werden erst in den Speicher geladen und dann wird die Hauptroutine (DllMain) aufgerufen. Jede Dll kann so grundlegende Daten initialisieren, Viren installieren... was man so braucht. ;-)

Wenn eine Dll (A) von einer anderen (B) abhängig ist, wird (B) vor (A) initialisiert. Das ist einfach. ;-)

Wenn (B) aber auch von Funktionen (A) benutzt, kann man nicht genau sagen, welche Initialisierungs-Reihenfolge richtig ist. (A) und (B) werden zunächst geladen und dann irgendwie initialisiert. Wenn nichts passiert ist alles OK. Es kann höchstens vorkommen, das (A) eine Funktion von (B) benutzt, deren Daten noch dummes Zeug sind.

Seit Vista scheint Microsoft allerdings andere Wege zu gehen.
Wenn man eine Funktion aus einer Dll benutzt, die noch nicht initialisiert worden ist, scheint es eine Schutzrechtverletzung zu geben... Die, die Du siehst.

SuRunExt fängt die jetzt ab und startet die Initialisierung neu.

Hoffentlich geht es damit.
Es hat etwas gedauert.

IAT-Hook-Stabilitäts-Tests mache ich immer, indem ich von Windows die SuRunExt.Dll per "AppInit_DLLs" in alle (auch administrative) Prozesse injizieren lasse und dann alles mögliche, das bei mir installiert ist, starte/benutze... Und das in mindestens drei virtuellen Maschinen und meinen Produktivrechnern. Bisher ist dabei (aus o.g. Gründen) immer irgendwann etwas schief gelaufen, in der beiliegenden Beta das erste Mal nicht. :-D

Ich hoffe, dass das "IAT-Hook"-Problem nun endgültig Geschichte ist und die Implementation der neuen Features gemacht werden kann.

SuRun 1.2.0.9 Beta 7 vom 18.10.2009
* FIX: Die Initialisierungs-Routinen von SuRunExt.Dll haben nun einen Exception-Filter. Der fängt Zugriffsverletzungen ab und terminiert und startet den Initialisierungs-Thread neu. Das sollte endgültig Fehler in SuRunExt.Dll_unloaded verhindern.
7 Tage später
Hallo Kay,

ich habe mich seit etwas längerem nicht gemeldet, und leider habe ich es noch nicht systematisch getestet, aber:
Das Problem scheint behoben zu sein. :) Wenn man das Problem an meinem Computer reproduzieren kann, dann wohl durch einen angesteckten USB-Stick beim Booten oder Einloggen (was ich weiter oben erwähnt habe).
Wenn man unter Windows 7 das Passwort eingegeben hat, erscheint ja "Willkommen" (oder ähnlich) mit dem kreisenden blauen Kreis (was früher die Sanduhr war). Beide Male (mit eingestecktem USB-Stick) blieb der Bildschirm dabei ein oder zwei Sekunden stehen, was ich dahingehend interpretiere, dass die Zugriffsverletzung abgefangen wurde. Dafür spricht auch, dass sich danach das Sicherheitscenter beschwerte, Avira würde nicht laufen (was es aber tat): Dieses Problem trat hin und wieder auch nach den Explorer-Abstürzen mit den alten Betas auf.
Somit gibt es keine Explorer-Abstürze mehr, aber bei eingestecktem USB-Stick beim Booten eine Sicherheitscentermeldung, die man durch De- und Reaktivieren von Avira sofort wieder los wird (und ohne USB-Stick scheint SuRun nichts mehr abfangen zu müssen, weil das Einloggen problemlos klappt).

Vielen Dank nochmals! :)
Hallo Stefan,

ich "experimentiere" hier seit einer Woche mit einer Beta 7 als "Spezialversion" rum, die in jeden Windows Prozess injiziert wird. Bisher habe ich keinerlei Auffälligkeiten und meine zwei Windows XP Rechner, mein Vista Notebook und Windows 7 (auf einem der XP-Rechner) laufen absolut stabil und klaglos.

Vielleicht habe ich durch den Exception-Filter endlich eine 100% stabile IAT-Hook-Dll gebastelt. (Man darf halt nicht "abstürzen", wenn man "abstürzt" ;-))

Ich poste diese SuRun-Variante der Beta 7 hier, damit Experimentierfreudige diese auf realen Rechnern ausprobieren und berichten, falls etwas nicht funktioniert.

Sollte es keine Schwierigkeiten geben, werde ich die Option wieder aktivieren, sich in administrative- und Systemprozesse einzuhängen. Dann kann SuRun auf allen Systemen Hardware automatisch administrativ installieren, wenn administrative Prozesse Programme starten, diese mit eingeschränkten Rechten ausführen und von Diensten gestartete Programme mit gehobenen Rechten starten.

WICHTIG: Sollte (wider Erwartens) die beiliegende Beta ein System so lahm legen, dass es nicht mehr hochfährt, braucht man ein zweites Boot-Medium oder irgend etwas, mit dem man SuRun.exe und SuRunExt.dll aus dem Windows Verzeichnis löschen kann.

Auf allen Systemen, auch Vista und Windows 7, muss nach Installation/Deinstallation der Rechner neu gestartet werden, weil SuRunExt.dll in jeden Prozess injiziert wird.

SuRun 1.2.0.7 Beta 7a vom 27.10.2009
* SuRunExt wird per "AppInit_Dlls" in alle Prozesse injiziert.
11 Tage später
Hallo Kay,

I noticed some additional strings have been included in SuRun.
If you like me to update the Dutch translations, then please feel free to send me the latest files.

Stephan
Hi Stephan, :-D

I wanted to contact you after the rebuild of SuRuns Dialogs is done. You did the last translations so fast and I did not want to exploit that kindness frequently ;-) There will be huge changes in the Program Settings and "Start As Admin..." dialogs to allow a per program automagic "Run as".

But if you can't wait ;-) just take the latest beta or version 1.2.0.8 and ResEdit Unicode and send me the changed resources.

...while I'm writing: SuRun now is on SourceForge I could include you as developer if you like. So you can check in/out resources as you wish.
Hi Kay!

As StepahnP, let know the lines for new translation in Spanish.
Thanks!

Diego Vazquez
Kay,
Is there any timeline to the rebuild of the dialog structure?
It'd help me decide whether to give it a go now, or to wait a little while until the translation environment is more comfortable.
Stephan
Hallo Kay,

unter Windows 7 kann man bei "Windows Update > Einstellungen ändern" einen Haken bei "Allen Benutzern das Installieren von Updates auf diesem Computer ermöglichen" setzen - ausser, wenn SuRun installiert ist, dann muss das über die SuRun-Einstellungen erfolgen, und das Kästchen bei Windows Update ist ausgegraut. (Es wird auch darauf hingewiesen, dass "einige Einstellungen ... vom Systemadministrator verwaltet" werden.)
Deinstalliert man SuRun, so bleibt das Kästchen allerdings weiterhin ausgegraut (und ist deaktiviert). Ich denke nicht, dass das beabsichtigt ist, oder? (Aber wer möchte SuRun schon deinstallieren... ;) )
In diesem Zusammenhang habe ich einen anderen Verdacht: Auch wenn das Kästchen "Empfohlene Updates auf die gleiche Weise wie wichtige Updates bereitstellen" aktiviert ist, scheine ich diese nicht mehr zu erhalten. Ich glaube, dass mir vor der SuRun-Installation die Installation von Silverlight angeboten wurde, jetzt nicht mehr.
Aus Testgründen habe ich im Moment eine ältere Version des Grafikkartentreibers installiert. Windows Update bietet mir nun nicht an, einen neueren zu installieren, obwohl das Windows Update vor der SuRun-Installation getan hat (wie ich meine). Könnte SuRun auch mit diesem Problem zusammenhängen?
Ich vermute mal, er verwendet hier die entsprechende Gruppenrichtlinie bzw. den korrespondierenden Registry-Eintrag.

Die Einstellungen, die per Richtlinie gesetzt werden finden sich unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\

Schau doch einfach mal da rein, vielleicht bringt das eine Erleuchtung. Wenn nichts anderes hilft, müßte vielleicht SuRun diese Optionen lernen und die Registry-Keys dafür setzen. Dann kann man es allerdings nur noch per SuRun, per ActiveDirectory oder per Richtlinieneditor ändern.

Ach ja, das wäre überhaupt noch eine Möglichkeit, das ganze ohne Editiererei in der Registry einzugrenzen. Öffne doch mal den Editor für lokale Gruppenrichtlinien (einfach nach "Gruppenrichtlinie" im Startmenü suchen) und setze dort unter "Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Windows Update" die Einstellung "Empfohlene Updates über automatische Updates aktivieren" auf "Aktiviert". Danach einmal auf der Kommandozeile "gpupdate /force" ausführen, das erzwingt die sofortige Aktualisierung der Einstellungen (meist geht das ohne Neustart).

Da gibts übrigens auch noch einige andere interessante Optionen, die man nicht alle per "normalem" GUI erreicht. Es lohnt sich, da mal drüberzuschauen, wenn man Windows Update "feintunen" will.

Wenn dann das Problem weg ist, dann deaktiviert der von SuRun gesetzte Eintrag nicht nur das eine Häkchen, sondern auch die anderen Einstellungen, diese können dann nur noch per Gruppenrichtlinie geändert werden. Würde mich nicht wundern, ich hatte mit Gruppenrichtlinien schon so manches mal meinen Spaß.

<EDIT> Ich hab' das eben mal probiert. SuRun setzt augenscheinlich die Registry-Einträge, die sonst per Richtlinie gesetzt werden. Es ist also anzunehmen, daß hier einige unerwartete (und eigentlich sinnlose, aber das ist man von Microsoft ja gewohnt...) Abhängigkeiten existieren und die Option deshalb nicht mehr funktioniert. Ich habe die Installation für empfohlene Updates bei mir jetzt mal per Richtlinie aktiviert, mal sehen, was er mir anbietet. </EDIT>
StephanP:1257841712 wrote: Is there any timeline to the rebuild of the dialog structure?
I'm (almost) a year late now ;-)
StephanP:1257841712 wrote: It'd help me decide whether to give it a go now, or to wait a little while until the translation environment is more comfortable.
I'd suggest to wait a while until I implemented the features.
I think of changing the confirmation dialogs less aggressively, so that they only contain a "More..." button that opens the settings dialog of the users program list... But all that is not even started yet.
Stefan wrote:unter Windows 7 kann man bei "Windows Update > Einstellungen ändern" einen Haken bei "Allen Benutzern das Installieren von Updates auf diesem Computer ermöglichen" setzen - ausser, wenn SuRun installiert ist, dann muss das über die SuRun-Einstellungen erfolgen, und das Kästchen bei Windows Update ist ausgegraut.
Hab's auch gerade gesehen.
Bin am Suchen, woran das liegt.
trekkie22 wrote: Die Einstellungen, die per Richtlinie gesetzt werden finden sich unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\
SuRun setzt in diesem Zweig "ElevateNonAdmins"=0 und in "SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" "NoAutoRebootWithLoggedOnUsers"=0.

Dadurch vermutet Win7 zu Recht, das ein altes Tool die Update-Einstellungen ändert und graut das Feld aus.

Diese Schlüssel sind in Win7 offensichtlich woanders, da muss ich bei Gelegenheit mal nachsehen.

Sind in den SuRun Einstellungen "Windows Updatebenachrichtigungen für alle Benutzer (sofern automatische Updates aktiv sind)." und "Keinen automatischen Neustart nach der Installation von Windows Updates durchführen" aktiviert, funktioniert das vorerst.
Impressum, Datenschutz