Heute stelle ich Ihnen die neue Funktion von Windows 7 / Windows Server 2008 R2 vor – Konsolenhost (ConHost.exe).
Ob als normale Benutzer oder Unternehmensadministratoren, wir werden Konsolenanwendungen mehr oder weniger in unseren täglichen Windows-Anwendungen sowie Betriebs- und Wartungsprozessen verwenden. Die Konsolenanwendung verfügt über keine Benutzeroberfläche. Wir müssen Eingabe- und Ausgabevorgänge über die Eingabeaufforderung ausführen (CMD, dies ist kein DOS, viele Leute sind verwirrt).
Denken wir also darüber nach: Mit welchen Konsolenanwendungen ist Windows ausgestattet?
Zu den typischsten gehören tatsächlich cmd.exe, nslookup.exe und telnet.exe.
In früheren Windows-Versionen wurden alle Anwendungen, die nicht-GUI-Aktivitäten darstellten (d. h. Konsolenanwendungen), über den Systemprozess Csrss.exe koordiniert, wenn sie auf dem Desktop ausgeführt werden wollten. Wenn eine Konsolenanwendung Zeichen empfangen muss, ruft sie kleine „Konsolen-APIs“ in Kernel32.dll auf, damit Kernel32 LPC zum Aufruf von CSRSS generieren kann. Zu diesem Zeitpunkt überprüft und verifiziert CSRSS die Eingabewarteschlange des Konsolenfensters und gibt die Ergebnisse des Zeichenmodus zur Zuordnung über Kernel32 an die Konsolenanwendung zurück. Der Nachrichtenverarbeitungsmechanismus von Konsolenanwendungen in frühen Windows-Versionen ist in der folgenden Abbildung dargestellt:
Dieser Verarbeitungsmechanismus hat zu einem Problem geführt: Selbst wenn eine Konsolenanwendung im Kontext eines normalen Benutzers ausgeführt wird, wird Csrss.exe immer mit den Berechtigungen des lokalen Systemkontos ausgeführt. Daher kann es in einigen Fällen vorkommen, dass von „bösen Jungs“ entwickelte Malware durch die Ausführung von Csrss.exe mit lokalen Systemkontoberechtigungen mehr Privilegien erhält. Dieser Angriffsmodus wird Shatter Attack genannt.
Im Zeitalter von Win7 und Windows Server 2008 R2 werden alle Konsolenanwendungen zur Ausführung in einen neuen Kontextprozess ConHost.exe gestellt, und ConHost (Konsolenhost) und Konsolenprogramme werden im gleichen Sicherheitsstufenkontext ausgeführt, anstatt sie auszugeben eine LPC-Nachrichtenanforderung an CSRSS zur Verarbeitung sendet, fordert es stattdessen ConHost an. Daher wird jeder Versuch einer Anwendung, eine Nachrichtenanforderung auszunutzen, um eine automatische Rechteerweiterung herbeizuführen, fehlschlagen. Die folgende Abbildung ist ein schematisches Diagramm des neuen Mechanismus, der in Windows 7 und Windows Server 2008 R2 verwendet wird:
ConHost ersetzt eine dauerhafte Änderung in der Art und Weise, wie E/A von Konsolenanwendungen verarbeitet wird. Benutzer können Windows nicht über die Registrierung oder Gruppenrichtlinie zwingen, zum Konsolenverhalten im „Legacy-Modus“ zurückzukehren. Daher müssen Benutzer Anwendungen vor dem Upgrade auf Windows 7 oder Windows Server 2008 R2 gründlich testen. Bitte vergessen Sie nicht, dass die meisten Funktionen einiger Anwendungen zwar über die GUI implementiert werden, die Daten jedoch weiterhin stapelweise über die Konsole oder andere funktionale Schnittstellen im Hintergrund verarbeitet werden. Daher ist es unbedingt erforderlich, vor der Migration oder Nivellierung umfassende Anwendungsfunktionstests durchzuführen.
Wenn eine Anwendung unter Windows 7 nicht normal verwendet werden kann, sollten wir sie zunächst mit Administratorrechten testen und erneut ausführen, um festzustellen, ob das Problem auftritt. Tatsächlich können wir dann Process Monitor verwenden, um zu überwachen, ob die Zugriffsrechte der Anwendung auf Dateien oder die Registrierung bestehen sind normal. Wenn die Anwendung nach der Behebung der oben genannten Probleme immer noch nicht normal ausgeführt werden kann, sollten Sie darüber nachdenken, den ISV oder seinen Entwickler zu kontaktieren.
Wenn eine Anwendung abstürzt, ist die entsprechende Crash-Dump-Datei für Entwickler und ISVs am hilfreichsten, um den Kern des Problems zu finden. Wenn die Anwendung nicht mehr reagiert, können Sie versuchen, ADPlus zu verwenden, um sie und den zugehörigen ConHost.exe-Prozess-Dump abzurufen. Konsolenanwendungen können viele Unterprozesse der Windows-Konsole gemeinsam nutzen. Wenn der Benutzer beispielsweise Telnet über das CMD-Fenster startet, wird Telnet.exe zu einem Unterprozess von Cmd.exe. In diesem Fall verarbeitet der ConHost.exe-Host Nachrichteninstanzen sowohl des übergeordneten Prozesses als auch des untergeordneten Prozesses. Mit dem Process Explorer können wir bestätigen, welche Prozesse ConHost.exe verarbeitet:
Sie können auch die Funktion „Wartekette analysieren“ im Ressourcenmonitor von Windows 7 verwenden, um den Anwendungsprozess des ConHost.exe-Prozesses anzuzeigen:
Vergessen Sie nicht, die Anwendung vor der Migration vollständig zu testen!