Hallo liebe SuRunner!

Ich nutze seit langer Zeit den Process Explorer (PE) von Sysinternals als Ersatz für den Task-Manager. Als ich vor einem halben Jahr auf SuRun stieß - einen herzlichen Dank für das Tool! - dachte ich, dass es eine schöne Möglichkeit wäre, PE beim Task-Manager-Aufruf immer gleich mit Admin-Rechten zu starten, so dass auch die System-Tasks im vollen Umfang angezeigt würden.

Leider erweist sich PE in 64-Bit-Umgebungen bezüglich der Registrierung als Task-Manager-Ersatz etwas zickig. Wenn man den entsprechenden Registry-Eintrag mit einem SuRun-Zusatz modifiziert, ändert PE beim Beenden den Eintrag, indem das Programm sich wieder selbst als Task-Manager-Ersatz einsetzt.

Es gibt jedoch einen Workaround: Die ausführbare PE-Datei [m]procexp.exe[/m] entpackt und startet in 64-Bit-Umgebungen eine gesonderte Datei, nämlich [m]procexp64.exe[/m]. Beim Beenden wird die 64-Bit-Exe wieder gelöscht. Wenn man diese jedoch noch zur Laufzeit präserviert und später als Ersatz für die ursprüngliche PE-Exe verwendet, besteht das genannte Problem mit der automatischen Registry-Modifikation nicht mehr.

So sieht (bei mir) der Registry-Eintrag mit der 64-Bit-Exe aus: 
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
"Debugger"="\"C:\\Windows\\SuRun.exe\" \"C:\\Program Files (x86)\\Sysinternals\\procexp64.exe\""
Die entsprechenden Schritte kann man vielleicht ein, zwei Mal noch händisch erledigen. Das Dumme ist, dass bei jedem Programm-Update des PE der Vorgang wiederholt werden muss. Deswegen habe ich die Batch-Datei [m]procexp_prepare.cmd[/m] erstellt, die einem die Arbeit abnimmt.

Aktuelle Batch-Datei-Version: 1.1.2 vom 5.2.2014 (Info: siehe Beitrag #10)

Anwendung:
* Kopiere [m]procexp.exe[/m] zusammen mit [m]procexp_prepare.cmd[/m] in das Verzeichnis, aus dem der Process Explorer zukünftig gestartet werden soll.
* Führe [m]procexp_prepare.cmd[/m] einmal mit Admin-Rechten aus (z. B. mit SuRun ;-) ).

Damit dieses sowieso schon lange Posting nicht ganz und gar ausufert, habe ich nicht alle Feinheiten des Warumsoundnichtanders beschrieben. Natürlich mache ich das auf Anfrage gerne noch.

Grüße
Gerby

P.S.: Falls das Thema hier (im Erweiterungen-Bereich) fehl am Platze sein sollte, darf es natürlich verschoben werden.
mal probiert die zugriffsrechte in der regestry zu sperren?
so könnte man das automatische umschreiben verhindern. (nicht getestet)

man könnte ja auch nach einem featurerequest fragen um dieses problem dauerhaft zu lösen.

hab grad auch damit rumgespielt, troz hinzufügen der adminregeln für:
- taskmgr.exe
- procexp.exe
- PROCEXP64.exe
startet der Process Explorer nicht administrativ...

...übrigens: der taskmanager selber startet auch nicht administrativ, troz regel.
also Kay, kannst du mal bitte da mal schauen?

p.s.
nettes script
in deine loop-schleife würde ich ein zähler mit ping-wait einbauen,
damit das script nicht im ungünstigsten fall sich zu tode loop-wartet...
kleine tipps:
- verwende :: statt REM als kommentar (script wird dadurch schneller verarbeitet, MS design-fehler :D)
- goto :sprung lässt sich besser lesen als goto sprung
- reinigungsarbeiten würde ich auch zu beginn des scrips erledigen, falls das script unterbrochen wurde (absturz z.b.)

p.p.s.
ich schreibe zwar gern featurerequest & bugreports and deverse autoren,
aber an mircosoft bzw. an seine unterabteilungen habe ich es noch nicht gewagt. :D
versuche es mal den regestry-bug zu melden, vielleicht wird man überrascht und es klappt. :P

(die 4 downloads war ich, bzw. mein browser... 'tschuldigung... :D )
Nettes Script, Danke! :-)

@Mik: WinLogon startet direkt den "Debugger", deshalb fängt SuRun das nicht ab.
5 Tage später
Hi Mik (ich nehme da mal die Kurzform) und Kay!

Danke für Euer Feedback.

Mik, mir ist jetzt nicht ganz klar, ob Du bereits tatsächlich bei MS eine Anfrage eingereicht hast. Ansonsten könnte ich natürlich auch im Sysinternals-Forum mal was reinsetzen. Zu dem Thema mit dem Debug-Eintrag in der Registry habe ich dort noch nichts weiter gefunden.

Dieser Tage gibt's bei mir wenig Zeit für Computer-Dinge. Ich werde eventuell am kommenden Wochenende mich wieder um SuRun, ProcessExplorer, Batches & Co. kümmern können.

Gruß
Gerby
ein eigenes forum für die tools ist natürlich perfekt, nichts anderes hätte ich auch nicht gesucht... :P

/o.t. meine kurzform ist übrigens 'mic' (klein)
das .c. übernimmt hier die k-dominanz,
aber außer mir weis das eh keiner... XD
21 Tage später
Hi!

Ich habe die Batch-Datei ein wenig verbessert. Der Dateianhang beim ersten Posting ist nun neu (procexp_prepare.cmd 0.9.2).

Zum einen wird procexp64.exe nun nicht mehr umständlich rumkopiert sondern einfach temporär mit Schreibschutz versehen. Dann kann's auch nicht mehr vom Mutterprozess (procexp.exe) gelöscht werden.

Zum anderen sind die Batch-Kosmetik-Anregungen von mic eingeflossen. Das Aufräumen im Vorfeld halte ich für nicht wichtig, da eher wenig bis gar kein Müll vom Batch erzeugt wird. Notfalls muss man halt manuell aufräumen.

Einen Thread zur Handhabung des Registry-Eintrags durch den Process Explorer habe ich noch nicht im Sysinternals-Forum angelegt. Es ist halt doch ziemlich spezifisch, was wir hier mit SuRun treiben. Und außerdem klappt's ja mit der Batch-Datei auch so.

Gruß
Gerby
ein Jahr später
sieht ja richtig nett aus...
aus kompatibilitätsgründen sollte man sich fragen,
ob man das script von surun abhänig machen will?
oder nicht doch lieber ein paar admin recepte einbaut.

wie das ausarten kann, wenn man versucht kompatibel zu sein,
kannst du bei mein reinigungsscript sehen. http://forum.gleitz.info/showthread.php?43966
die hälfte des scripts ist nur für windows-rezepte... XD

es ist zwar nicht das sauberste script, aber es erfüllt seinen zweck...^^
Frohe Ostern!

Mit der Version 1.1.0 der Batch-Datei reagiere ich auf eine Änderung im Process Explorer in Version 15.3. Dieser versucht nicht mehr, die 64-Bit-Ausgabe bei der Ausführung im selben Verzeichnis abzulegen, sondern verwendet dafür nun das TEMP-Verzeichnis.

Wie immer liegt die neue Batch-Datei dem ersten Posting als Anhang bei. Sie funktioniert nicht mit Versionen des Process Explorer bis v15.23.

Falls sich jemand wundert: Die Version 1.0.0 der Batch-Datei gab es nicht wirklich (= 0.9.2).

Soweit zu diesem kleinen Osterei - aber kein Aprilscherz!

Grüße
Gerby
ein Jahr später
Hi!

Noch ein kleines Update, dass die Möglichkeit eines Hängers minimieren soll. Ich habe dazu die Pause nach dem Kopieren von procexp64.exe um eine Sekunde erhöht und die Pause beim Warten auf das Beenden von Process Explorer in der Schleife nach vorne verschoben.

Gruß
Gerby
Moinmoin!

Vor einiger Zeit (eigentlich kurz nach dem letzten Release 1.1.0 der Batch-Datei) hatte ich noch ein paar "Debug-Funktionen" eingeimpft, nämlich die Darstellung der einzelnen Schritte während der Abarbeitung. So konnte ich besser auf Fehler reagieren, weil das Batch hier ab und zu hakte.

Außerdem hatte ich noch eine zusätzliche Pause nach dem Kopiervorgang eingebaut.

Aus aktuellem Anlass (PE in der neuen Version 16.0) kam das Batch hier wieder zur Anwendung und funktionierte auch mit dem aktuellen PE. Deswegen nun als Nachtrag aus dem letzten Jahr die Version 1.1.1 der Batch-Datei.
Eine Antwort schreiben…
Impressum, Datenschutz