Microsoft tut mir leid. Sie meinten nur das Beste, aber kommunizieren es nicht. Vielleicht sollte ich es versuchen.
Der AsIo Treiber ist sehr bekannter und sehr alter Treiber, den es in vielen Versionen gibt. In Kurzfassung: ihr wollt diesen Treiber nicht und ihr braucht ihn nicht.
Microsoft stellt sich auf den Kopf, riskiert euren Ärger, und hat mindestens 3 Sicherungen eingebaut, damit ihr nicht versehentlich diesen Treiber geladen bekommt. Fragt ihr euch da gar nicht wieso?
Problem Nummer 1: Der alte von 2012 ist SHA1-signiert. Tatsächlich gibt es seit einiger jüngerer Zeit ein Verbot, SHA1-signierte Treiber zu laden. SHA1 wurde als zu schwach eingestuft. Es geht kategorisch nicht mehr auf modernen Windows Systemen.
Neuere Versionen des gleichen Treibers (AsIo) sind aber SHA256 signiert. Es ist sowieso heller Wahnsinn, zu versuchen, einen 2012 Treiber auf einem 2025 OS laufen zu lassen!
Problem Nummer 2: der AsIo Treiber bedeutet im Grunde wörtlich "Asus I/O", aber in Wirklichkeit vor allem eines: ein Treiber, der einen (schon lange nicht mehr geheimen) IOCTL Code implementiert, den man als Usermode User/Programm rufen kann, und damit im Kernel nach Belieben herumlesen und schreiben kann. Asus benutzt diesen (schon seit Dekaden nicht mehr geheimen) IOCTL Code, um mit seinen Apps auf IO Space zuzugreifen. Nicht so nette Leute oder Malware benutzen es dazu, um Admin zu werden und andere schreckliche Dinge zu tun, wie sich im Betriebssystemskern einnisten. Die Existenz eines installierten AsIo-Treiber ist ein gefundenes Fressen für Angreifer um sich auf dem System persistent einzurichten.
Der AsIo Treiber wurde von Asus so programmiert, den Lese- und Schreibzugriff zu ermöglichen, das ist eine Hauptfunktion. Kein Programmierfehler. "It's not a bug, it's a feature", aus Asus Sicht.
Die neuesten Versionen von AsIo sind womöglich ein bisschen abgeschwächt, sodass der User oder das Programm Admin-Rechte braucht, um den (schon lange nicht mehr geheimen) Code loszuschicken und im Kernel rumzuschreiben und ihn zu ändern. In so einem Stadium lässt Microsoft es Asus durchgehen, solange die Kernisolierung nicht auch noch aktiviert wurde.
Problem Nummer 3: die Kernisolierung wacht darüber, dass der Betriebssystem nicht verändert wird. Der AsIo-Treiber erlaubt aber genau das. Da würde es auch keine Rolle spielen, wenn man Admin ist. Deswegen darf Microsoft gar nicht erst erlauben, dass der AsIo Treiber geladen wird. Würde jemand den AsIo Treiber installiert haben und versuchen, die (nicht mehr geheimen) IOCTL Codes zu verwenden, um geschützte Betriebssystems-Seiten zu schreiben/zu editieren, dann würde es einen hässlichen Security Failure Blue Screen geben. Die Kernisolierung killt das ganze Betriebssystem, analog so wie das Betriebssystem normalerweise ein Fehler-verursachendes Programm killen würde, bei jedem Versuch, auf geschützte Betriebssystems-Seiten zu schreiben.
Problem Nummer 4: Damit es keinen solchen "Unfortunate Accident" gibt, gibt es noch zusätzlich eine Sicherung über eine (unabhängig von der Kernisolierung) geführte "verbotene Treiberliste". Sie ist aktiv auch ohne Kernisolierung. (Aber der User kann es abschalten, zum Beispiel, wenn er den AsIo Treiber oder RWEverything benutzen möchte, um im Kernelspeicher rumschreiben zu dürfen. Das tut er dann auf eigene Verantwortung.) Microsoft pflegt in die "verbotene Treiberliste" alle Treiber und Rootkits rein, die so ein absichtliches RW Primitiv zum lesen und Schreiben in den Betriebssystems implementieren, und es Kraft ihrer Autorität als OEM/Firma mit einem (eigentlich) unzulässig verwendeten Zertifikat signieren. Vereinfacht, alle "Tunichtgut" Treiber sowie echte Kernel-Malware werden da kontinuierlich reingepflegt. Die verbotene Treiberliste ist öffentlich einsehbar, an mehreren Stellen, (z.B. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules#vulnerable-driver-blocklist-xml , es gibt aber auch ein github repo... wie man sieht ist der asio Treiber mehrerer Generationen darauf). Die genauen Gründe, wieso ein Treiber auf die verbotene Liste gesetzt wurde, unterscheiden sich sehr und stehen dort (meines Wissens nach) nicht. (Das kann man jedoch googeln, wenn einen ein bestimmer Treiber, wie der AsIo, interessiert.) (Außerdem gibt es eine offizielle Seite, auf der man Tunichtgut-Treiber melden kann, mit Angabe eines eben solchen Grundes, wie z.B. "der Treiber implementiert lesen und schreiben per IOCTL Code auf den Kernel", und Microsoft schaut sich das dann an, und nimmt ihn dann auf oder nicht.)
Warum Hersteller überhaupt solche Treiber schreiben, und dann selbst signieren, ist ein bisher ungelöstes Problem für Microsoft und ihnen ein Dorn im Auge.
Die Kernisolierung ist nicht nur deswegen entstanden aber auch.
Außerdem hat Microsoft noch das Problem, dass sie nicht so gerne den Herstellern ins Gesicht sagen oder öffentlich zugeben, dass das gar nicht gut ist, obwohl man sicher annehmen kann, dass sie es den Herstellern hinter den Kulissen sagen, diese es aber partiell einfach ignorieren, weil es eben bequem ist, der eigenen App zu erlauben, im Kernel herumzuschreiben, und die Intelligenz nicht in den Kernel verlagern zu müssen.
Kurz gesagt, Microsoft will sich mit den Herstellern nicht anlegen, aber trotzdem die Benutzer schützen, was bisweilen zu einer merkwürdigen Situation führt.
Am besten lebt ihr ohne Asio Treiber. Er ist für kein System notwendig, aber für diverse Mätzchen gut, z.B. bunte LEDs ansteuern.