Es ist Richtlinie bei Microsoft, dass interne Windows-Funktionen möglichst komplett in DLLs vorliegen sollen statt als EXE-Dateien, um eine optimale Wiederverwendbarkeit durch andere Programme zu ermöglichen. Will man diese Funktionen direkt ausführen, benötigt man die Hilfe eines Host-Prozesses, da man DLLs nicht direkt starten kann. Aus Benutzersicht ist dies rundll32.exe, für Windows-Dienste erfüllt svchost.exe die entsprechende Funktion. Auch diese liegen überwiegend in Form von DLLs vor; svchost.exe ist der Host-Prozess, mit dessen Hilfe sie ausgeführt werden.

Energiesparmodus und Ruhezustand sind unter Windows 7 gut dazu geeignet, das System nur noch nach bestimmten Updates, Service-Pack-Installationen oder anderen Systemeingriffen jemals neu starten zu müssen. Wegen einer Arbeitspause hingegen – auch über Nacht – muss man es nicht mehr herunterfahren. Es „schlafen zu schicken“ genügt vollkommen und man hat es folglich bei Bedarf nach dem Aufwecken auch sehr viel schneller wieder zur Verfügung, als wenn man es erst komplett starten müsste.

In einer Serie von TechNet-Videos zum Einsatz von MDOP können sich Administratoren kurze Walkthrough-Beiträge zur effektiven Verwendung der darin enthaltenden Tools anschauen. Interessant ist insbesondere ein ca. 1½-minütiger Beitrag darüber, wie man Crash Analyzer und Computer-Management-Tools aus dem DaRT aus zur Analyse und Behebung von BSODs verwendet.

Das Microsoft Diagnostics and Recovery Toolset (DaRT) ist Bestandteil des Microsoft Desktop Optimization Pack (MDOP). Als solches ist es nur für Software-Assurance-Kunden zugänglich. Separat erwerben kann man es leider nicht, was seinen geringeren Bekanntheitsgrad gegenüber dem schon als legendär zu bezeichnenden Winternals ERD Commander von Winternals erklären mag, aus dem es hervorging. Viele DaRT-Bestandteile tragen auch heute noch das ursprüngliche ERD-Commander-Branding. TechNet- und MSDN-Abonnenten können DaRT ebenfalls ausprobieren, wie dies für das gesamte MDOP der Fall ist.

An sich muss bei Windows 7 nicht mehr groß zwecks Systembeschleunigung herumoptimiert werden, wie dies vor 10-15 Jahren auf schwacher Hardware üblich war. Für die Mehrzahl der Client-Systeme trifft zu, dass zumindest lokal immer genug Rechenleistung zur Verfügung steht, so dass selbst ein nicht optimal laufendes System immer schnell genug ist, um praktisch alle Benutzeranforderungen ohne Frustrationserlebnisse zu bedienen. Gibt es Verzögerungen und die Produktivität beeinträchtigende Wartezeiten, liegt dies heutzutage eher die Netzwerkkonnektivität und langsamen Datenströmen als am lokalen System.