Uff, dazu muss ich mich etwas aus dem Fenster lehnen. Es ist weniger
ein nicht gebacken bekommen, als viel mehr
ein nicht mehr machen dürfen oder
sollen. Die Hersteller müssen sich auf das Betriebsystem, dessen De-Installations APIs/Funktionen und dem ganzen Drum und Dran verlassen können. Das endet sonst in einer Sisyphusarbeit, wenn auf alle Eventualitäten reagiert werden müsste - JE Treiber und JE Betriebsystemversion!
Und genau diese Eventualitäten sind das Problem. Da könnten sich Fehler in die Registry oder im Dateisystem eingeschlichen haben. Sei es durch Programmierfehler (auch durch Dritte wie ein Browser oder ein Texteditor), durch
Bit flipping oder eben Systemabstürze (Schwankungen im Stromnetz). Die De-/Installation ist vereinfacht ausgedrückt eine Bedienungsanleitung, die i.d.R. APIs/Funktionen des Betriebsystems nutzen und zum Teil auch selber Hand anlegen (wenn denn umbedingt nötig). Sicher hat jeder schon mal die Erfahrung gemacht, dass ein bestimmter Problemfall nicht in der Bedienungsanleitung enthalten war. In dem Fall kann man seine Anpassbarkeit/Erfahrung/Denkfähigkeit nutzen und bereits erlerntes Wissen und Können anwenden, um das Problem selber zu lösen. Darunter fällt, sich beim Support zu melden oder einen Spezialisten einzuschalten. Eine De-/Installation kann das nicht. Die spuhlt stumpf die Anweisungen ab, die in 99,9% der Fälle funktionieren MUSS.
So und DDU ist das Ergebnis von einer jahrelangen Sisyphusarbeit, die sehr viel mehr von Hand erledigt, statt sich auf das Betriebsystem zu verlassen. Das ist wie so ein FAQ oder ein Wikipedia für alle bisher bekannten Fälle. Da wird auch sicherlich mehr gemacht, als normalerweise nötig wäre. Aber ungewöhnliche Fehler können dazu führen, dass verwaiste Treiberreste, die i.d.R. überhaupt keine Probleme verursachen würden (Registrieeinträge etc), plötzlich sehr wohl ein Problem darstellen und leider nur über 10 Ecken als solches erkannt würden, die man nur mit viel Zeit und Hirnschmalz finden würde. Also werden auch solche Dinge von DDU ggf. pauschal gelöscht/geradegebogen und garnicht erst die Frage stellen zu müssen (keine Ahnung, ob DDU so arbeitet - ich nehme das einfach mal Pi*Daumen so an und habe das hier bewusst auf ein "stumpfes" Löschen von Resten heruntergebrochen. Da passiert sicher sehr viel kluges Zeug).
In Einzelfällen könnte auch DDU das Problem nicht lösen. Aber danach hast'e halt nicht mehr 100 verschiedene sondern nur noch 5 Stellen, wo das Problem noch sein könnte. Es spart also auch bei der Fehlersuche durchaus Zeit. Oder du weißt aus Erfahrung: wenn DDU das Problem nicht löst, dann jetzt ein Plattmachen vllt. der schnellste Weg.
Diese ganzen Eventualitäten willste nicht in jedem Setup haben, denn sonst müsste das jedes Mal in Gänze getestet werden. Denn auch das Behandeln solcher Eventualitäten kann unter irrwitzigen Umständen selber Schäden anrichten. Stichwort Angriffsfläche. Das ist das selbe Problem mit Sicherheitsfeatures, die die Angriffsfläche leider auch erhöhen.
Aus dem Grund ist DDU kein fester Bestandteil einer jeden Treiberde-/Installation, sondern ein für sich alleinstehendes Tool, dass man bei vollbesitz seiner Denkfähigkeit einsetzt - wenn es mal nötig erscheint.
Hint: ich kenne mich nicht im Detail mit DDU aus. Habs natürlich auch mal benutzt. Hier steckt potenziell viel Halbwissen drinne. Mir gings mehr um die Beschreibung der Komplexität und dem Umgang mit Komplexität bei der Programmierung. Je mehr Fälle berücksichtig werden, desto komplexer und desto mehr potenzielle Probleme. Das ganze würde sich noch multiplizieren, wenn jedes Setup ihr eigenes Troubleshotting-Süppchen kochen würde. Wer viel anbietet, kann im Zweifel nichts richtig. Dann lieber zum Spezialisten - z.B. DDU