Wieso crasht DirectX(-Spiel) Windows?

[Mona Sax]

Beim Spielen von MaxPayne2 stürzt freezt mir das System. Jetzt frag ich mich, wie ein Spiel überhaupt das Windows-System freezen kann, schließlich ist es auch nur ne Applikation und MS gibt ja damit an, das ab W2k nur noch die Anwendung, aber nicht das System crashen darf.

Hi Bill, you're a f*ckin Liar!

[SavageX]

Bill lügt (diesesmal) nicht. Es sind entweder die Treiber, die vom Spiel zum Wahnsinn getrieben werden, oder an der Hardware ist was faul.

[Monger]

Entweder sind es Treiberbugs, oder das Spiel umgeht alle Schnittstellen, und führt irgendwelche unmittelbaren Hardwarezugriffe durch, was z.B. bei EAX notwendig ist.
In solchen Fällen hat dann auch das Betriebssystem keine Chance mehr.

[Coda]

Entweder sind es Treiberbugs, oder das Spiel umgeht alle Schnittstellen, und führt irgendwelche unmittelbaren Hardwarezugriffe durch, was z.B. bei EAX notwendig ist.
Das ist auch für EAX nicht notwendig und außerdem im Userspace eines Protected-Mode-Betriebssystem auch nicht möglich.

[Monger]

Das ist auch für EAX nicht notwendig und außerdem im Userspace eines Protected-Mode-Betriebssystem auch nicht möglich.

Echt? Ich dachte, das wäre der Grund weshalb EAX so ohne weiteres erstmal nicht unter Vista ging, bis halt Creative ihren OpenAL Wrapper so weit hatte.

[Grestorn]

Echt? Ich dachte, das wäre der Grund weshalb EAX so ohne weiteres erstmal nicht unter Vista ging, bis halt Creative ihren OpenAL Wrapper so weit hatte.

DirectSound unter XP hatte eine Schnittstelle, über die der Treiber Module einhängen konnte, die HW-Features nutzten. Der Zugriff selbst erfolgt aber trotzdem immer über den Treiber, wie bei allen Komponenten unter Windows. Kein User-Porgramm und somit auch kein Spiel hat die Möglichkeit, direkt auf Hardware zuzugreifen, es sei denn, das Spiel installiert selbst einen Treiber.

[Coda]

Echt? Ich dachte, das wäre der Grund weshalb EAX so ohne weiteres erstmal nicht unter Vista ging, bis halt Creative ihren OpenAL Wrapper so weit hatte.
Das hast du falsch verstanden. Vista unterstützt nur keine hardwarebeschleunigten DirectSound-Treiber mehr und deshalb gibt's darüber auch kein EAX.

[Gast]

DirectSound unter XP hatte eine Schnittstelle, über die der Treiber Module einhängen konnte, die HW-Features nutzten. Der Zugriff selbst erfolgt aber trotzdem immer über den Treiber, wie bei allen Komponenten unter Windows. Kein User-Porgramm und somit auch kein Spiel hat die Möglichkeit, direkt auf Hardware zuzugreifen, es sei denn, das Spiel installiert selbst einen Treiber.

Tja, dann frag ich mich, wieso Windows dann überhaupt abstürzen kann. Die Treiber sind getestet. Kann ja nicht angehen, das man für jedes Game nen anderen Treiber installiert. Dann sollen die Hanseln doch gleich welche ins Spiel einbauen, mit denen es 100% lief.

[Grestorn]

Tja, dann frag ich mich, wieso Windows dann überhaupt abstürzen kann. Die Treiber sind getestet. Kann ja nicht angehen, das man für jedes Game nen anderen Treiber installiert. Dann sollen die Hanseln doch gleich welche ins Spiel einbauen, mit denen es 100% lief.

Ein Crash (Bluescreen) kann durch fehlerhafte Treiber oder durch defekte Hardware auftreten. Keines von beiden lässt sich ganz ausschließen.

Gerade bei Treibern ist es völlig unmöglich sämtliche Situationen und Zustände zu testen.

[Coda]

Ist übrigens bei jedem Betriebssystem so.

[Demi@Gast]

Ist übrigens bei jedem Betriebssystem so.

Nein. Es gibt auch Systeme die lassen ihre Treiber nicht auf Ring 0 laufen.

[Grestorn]

Nein. Es gibt auch Systeme die lassen ihre Treiber nicht auf Ring 0 laufen.
Ach? Interessant. Vorallem wie diese Treiber dann auf ihre Hardware zugreifen.

Zumindest Teile des Treiber MÜSSEN auf Ring 0 laufen. Und das ist auch in Windows nicht anders.

[Gast]

Ach? Interessant. Vorallem wie diese Treiber dann auf ihre Hardware zugreifen.


Garnicht, wie das ja eigentlich auch unter Windows normal ist. Das DDK schottet den Treiber auch von der HW ab. Du kannst unter Windows nicht dirkekt auf die HW zugreifen. Der HW Zugriff ist vom HAL gekapselt. Das ist der ganze Sinn und Zweck vom HAL, damit sowohl das OS und die Treiber auch auf andere Plattformen portiert werden können. (Windows lief früher auch mal auf Alpha ua.)
Wenn ein Treiber mit der HW kommunizieren will, muss er seine Daten über die DDK Schnittstellen verschicken. Dass bei Windows Kernel-Mode Treiber im Ring 0 laufen, hat Performance-Gründe. Bei Systemen, wo alles im Usermode läuft, kommt es wohl eher auf absolute Ausfallsicherheit an, anstatt auf Performance. Zumindest denke ich mal, dass das der andere Gast meint.

[Demi@Gast]

Ach? Interessant. Vorallem wie diese Treiber dann auf ihre Hardware zugreifen.

Zumindest Teile des Treiber MÜSSEN auf Ring 0 laufen. Und das ist auch in Windows nicht anders.

Schau dir mal QNX Neutrino RTOS an.

Die lassen die Treiber sogar vollständig im User Space laufen. Ein Hardware defekt killt dir maximal den einen Treiberprozess.

Vista geht ja auch dazu über vermehrt Treiber in den User Space zu verlagern. Zum Beispiel für USB Geräte.

[Grestorn]

Garnicht, wie das ja eigentlich auch unter Windows normal ist. Das DDK schottet den Treiber auch von der HW ab. Du kannst unter Windows nicht dirkekt auf die HW zugreifen. Der HW Zugriff ist vom HAL gekapselt. Das ist der ganze Sinn und Zweck vom HAL, damit sowohl das OS und die Treiber auch auf andere Plattformen portiert werden können. (Windows lief früher auch mal auf Alpha ua.)
Wenn ein Treiber mit der HW kommunizieren will, muss er seine Daten über die DDK Schnittstellen verschicken. Dass bei Windows Kernel-Mode Treiber im Ring 0 laufen, hat Performance-Gründe. Bei Systemen, wo alles im Usermode läuft, kommt es wohl eher auf absolute Ausfallsicherheit an, anstatt auf Performance. Zumindest denke ich mal, dass das der andere Gast meint.

Es ist egal, ob man über eine HAL oder direkt auf die HW zugreift: Wenn man HW Register ändern kann, kann man auch den Rechner zum Absturz bringen.

Jede Komponente die HW Zugriff hat, ist kritisch für die Systemstabilität. Das lässt sich nicht vermeiden.

[Gast]

Es ist egal, ob man über eine HAL oder direkt auf die HW zugreift: Wenn man HW Register ändern kann, kann man auch den Rechner zum Absturz bringen.


Du kannst aber doch nicht direkt auf die Register zugreifen, das ist alles abstrahiert von Windows. Wenn du nicht irgend einen Fehler hast, also ein Fehler-Code oder unvorhergesehenes Ereignis, dann stürzt im besten Fall eben nur der User-Mode Prozess des Treibers ab, den man wieder neu starten könnte. Wenn dieser aber im Kernel-Mode läuft, war's das dann.

[Grestorn]

Du kannst aber doch nicht direkt auf die Register zugreifen, das ist alles abstrahiert von Windows. Wenn du nicht irgend einen Fehler hast, also ein Fehler-Code oder unvorhergesehenes Ereignis, dann stürzt im besten Fall eben nur der User-Mode Prozess des Treibers ab, den man wieder neu starten könnte. Wenn dieser aber im Kernel-Mode läuft, war's das dann.

Es ist doch wurscht ob ich direkt oder indirekt auf die Register zugreife. Ein falscher Wert im falschen Register, und die Kiste steht.

[Gast]

Es ist doch wurscht ob ich direkt oder indirekt auf die Register zugreife. Ein falscher Wert im falschen Register, und die Kiste steht.

Wenn du deine HW falsch programmierst, wird es i.d.R. irgendwelche Fehler-Codes geben, die man auswerten kann und ggf. das Gerät neu initialisieren kann. Die ganze Problematik hat doch weniger etwas mit der reinen Kommunikation mit der HW zu tun, sondern dass Treiber selbst auch viel softwareseitige Logik implementieren, die eben mal fehlerhaft sein kann.

[Grestorn]

Wenn du deine HW falsch programmierst, wird es i.d.R. irgendwelche Fehler-Codes geben, die man auswerten kann und ggf. das Gerät neu initialisieren kann. Die ganze Problematik hat doch weniger etwas mit der reinen Kommunikation mit der HW zu tun, sondern dass Treiber selbst auch viel softwareseitige Logik implementieren, die eben mal fehlerhaft sein kann.

Es geht in der Diskussion darum, dass ein fehlerhafter Treiber einen Systemcrash verursachen kann. Und dies ist nun mal ein Fakt sobald ein Treiber Zugriff auf HW-Register hat.

Ein Treiber für ein USB Gerät wird normalerweise keinen Crash verursachen können, da er eben KEINEN Zugriff auf HW-Register hat. Er implementiert ja nur ein Daten-Protokoll, und nutzt dazu lediglich den Basis-Treiber für den USB Anschluss.

Ein solcher Basis-USB Treiber, der die HW-Register anspricht um Werte auf den USB Bus zu legen und von ihm zu lesen, kann aber problemlos die gesamte Kiste crashen. Das liegt in der Natur der Sache, und da ist die Architektur des Betriebssystems völlig wurscht.

[Coda]

Die lassen die Treiber sogar vollständig im User Space laufen.
Zumindest der Portzugriff muss doch in Ring 0 laufen. Da ist es natürlich aber unwahrscheinlich dass man etwas verpfuscht, aber dennoch genauso gut möglich. Gut, das ist dann bei dem OS wohl nicht mehr von den IHVs.

Du kannst aber doch nicht direkt auf die Register zugreifen, das ist alles abstrahiert von Windows.
Naja. Streng genommen kann im Ring 0 der Treiber von sich aus das ganze OS ersetzen ;)

[Demi@Gast]

Zumindest der Portzugriff muss doch in Ring 0 laufen. Da ist es natürlich aber unwahrscheinlich dass man etwas verpfuscht, aber dennoch genauso gut möglich. Gut, das ist dann bei dem OS wohl nicht mehr von den IHVs.

Nein du kannst gezielt für einzelne User Space Prozesses Ports und Speicherbereiche freigeben. Es gibt ja einen Hacktreiber für Windows der alle Ports für alle Prozesse freigibt.

[Coda]

Stimmt, da war mal was. Danke für's auffrischen ;)