Probleme sind schon vorprogrammiert....
Sagt Dir der Begriff NX(NoExecute)-Feature etwas? Dies propagiert AMD bei seinen 64-Bittern als Schutzschild gegen Computerviren.
Dieser "Hacker-Blocker" soll Dein System vor den allseits beliebten Buffer-Overflows schützen. Es soll also verhindern, das Schädlingsprogramme Code im Stack-, Header- oder Datenbereich einschleusen und somit auch ausführen können, da Programme seit dem 386 mit variablen, virtuellen Speicheradressräumen arbeiten, um sich nicht durch feste Bezugsadressen in die Quere zu kommen-eigentlich praktisch, aber dieses hin und her springen ist ein Einfalltor...
Da im 32 Bit Speicheradressraum keine Bits mehr frei waren (diese "avaiable Bits benutzen mittlerweile diverse Betriebssysteme) hat AMD dieses Sicherheitssystem in den 64-Bit Longmode bzw. den PAE (Physical Adress Modus) für Server verlegt um Kompatibilitätsproblemen vorzubeugen.
Das SP2 richtet PAE nun standardmäßig ein, auch wenn Du über weniger als 4 GByte RAM verfügst (dies ist ja die adresssierbare Grenze für 32 Bitter).
Eigentlich schön, aber da PAE ja eigentlich für Server entwickelt wurde, ist auch nur typische Serverhard- & Software in der Lage damit umzugehen. Keiner der aktuellen normalen Desktop & Mobile-Chipsätze kann damit umgehen, auch die neuen Chipsätze Grantsdales/Alderwood von Intel nicht, da einfach schlichtweg die Adressleitungen dafür fehlen. Als OS benötigt man etwa ein sündhaft teures Windows Datacenter Server Edition...
Doch zurück zum Kern der Sache:
unsere Wald- und Wiesen Hardware ist also mitnichten PAE-konform. Das gilt nicht nur für die Hardware, das OS und die Software sondern auch für genau, das, was beim PC schon immer zickte und bis heute neben Windows die Fehlerquelle schlecht hin ist: die Treiber!
Es kann also nur eine einzelne Komponente oder alles zusammen, was da so in Deinem Rechner lebt, zicken machen.
Bei ersten Tests stürzte ein Rechner bei dem Spiel ProEvolution Soccer ab - schuld war die unkonforme Grafikkarte bzw. ihr Treiber.
Ein allheilmitte ist dieses NX-Feature zudem auch nicht: den Buffer-Overflow kann das Konzept nämlich in Wirklichkeit allein nicht verhindern, es sorgt lediglich dafür, daß die CPU innerhalb des Strings, der einen Überlauf auslöst, keinen eingeschmuggelten Code ausführt. Der Überlauf könnte aber sehr wohl statt dessen einen Sprung irgendwo ins Codesegment bewirken, den NX nicht abfangen kann.
So lassen sich also mit genügend krimineller Energie und Ideenreichtum doch mal wieder irgendwelche Türen öffnen, wenigstens jedoch eine fatale Schadwirkung durch gezielten B-Overflow verursachen...
Abhilfe würde hier eine zusätzliche Verwürfelung der Ladeadressen wie bei Linux oder OpenBSD solch gezielte Einsprünge erheblich erschweren oder, mit etwas Glück, u.U. sogar unmöglich machen - doch so etwas hat MS (noch) nicht vorgesehen...
Sorry, wenn ich etwas ausgeufert bin und es zu technisch geworden ist.
Abschließend sei noch erwähnt, daß über dieses Schutzkonzept bis jetzt nur die 64-Bit Prozessoren von AMD, also der Athlon 64, Athlon FX, Opteron sowie eventuell der in Kürze erscheinende Duron-Nachfolger Sempron (hier wenn aber nur die Sockel 754-Version, die übrigens über keinen 64-Bit Mode verfügt), bieten.
Falls Du einen solchen Kern nicht Dein Eigen nennst: auch Intel, Via und Transmeta wollen es einführen. Intel wohl mit dem nächsten Prescott-update.
Wenn Du also demnächst aufrüstest fängt eventuell der Ärger an.
Falls Du oder generell alle hier eine Hilfestellung benötigen, wie man NX-kompatibel macht oder abschaltet - womit dann natürlich der Schutz verloren geht - meldet Euch bei mir oder antwortet auf diesen Post.
Unter http://www.heise.de/ct/ftp/04/16/106/
könnt ihr ein Tool downloaden, das künstlich BO's verursacht und dann seht ihr, wie Euer System reagiert.
Es gibt aber noch mehr Problemquellen vielleicht schaffe ich es ja noch auf die eine oder andere hinzuweisen...wie ich's etwa schon zur Wurm&Filescharingdrossel getan habe.
Hoffe lieber @Jack es war für Dich interessant
Greets to all,
TIE
MAY THE FORCE BE WITH U:drksd: