Archiv für June, 2007

links for 2007-06-30



 

Eingetragen unter: del.icio.us


kommentieren June 30th, 2007

links for 2007-06-29


 

Eingetragen unter: del.icio.us


kommentieren June 29th, 2007

links for 2007-06-22



 

Eingetragen unter: del.icio.us


kommentieren June 22nd, 2007

links for 2007-06-21


 

Eingetragen unter: del.icio.us


kommentieren June 21st, 2007

links for 2007-06-20



 

Eingetragen unter: del.icio.us


kommentieren June 20th, 2007

links for 2007-06-18


 

Eingetragen unter: del.icio.us


kommentieren June 18th, 2007

links for 2007-06-17



 

Eingetragen unter: del.icio.us


kommentieren June 17th, 2007

links for 2007-06-16



 

Eingetragen unter: del.icio.us


kommentieren June 16th, 2007

links for 2007-06-12



 

Eingetragen unter: del.icio.us


kommentieren June 12th, 2007

links for 2007-06-11


 

Eingetragen unter: del.icio.us


kommentieren June 11th, 2007

links for 2007-06-09



 

Eingetragen unter: del.icio.us


kommentieren June 9th, 2007

Der Meister der Masken

In der filmhistorischen Ecke geht es heute um einen Verwandlungskünstler par excellence - den großen Lon Chaney.

Bei Lon Chaney handelt es sich quasi um den ersten Horrorfilm-Star, den das amerikanische Kino hervorbrachte.
Alonzo Chaney hatte taubstumme Eltern, was bedeutete, dass er sich seit seiner Kindheit verstärkt mimisch ausdrücken musste. Er hatte nur eine kurze Kindheit, denn als er 10 Jahre alt war, wurde seine Mutter krank und der kleine Lon musste für sie sorgen. Sein älterer Bruder John arbeitete beim Theater und mit ca. 15 Jahren begann Lon ebenfalls mit dem Theaterspiel. Sein Bruder hörte kurz danach auf, Lon jedoch blieb Zeit seines Lebens Schauspieler. Einige Zeit später heiratete er und bekam einen Sohn - Creighton Tull Chaney, später bekannt als Lon Chaney jr. Moch später wurde die Ehe geschieden und er heiratete ein zweites Mal.

Seine ersten Sporen im Filmgeschäft verdiente er sich 1912, wo er fortan zum festen Ensemble der Universal City Studios gehörte. Hier begann seine weltberühmte Karriere als der wandlungsfähigste Künstler seiner Zunft. Chaney spielte damals wirklich alles, Menschen jeder Nation und jedes Typs. Und jeder der ihn sah, glaubte wirklich einen Chinesen, einen Griechen, einen Bösewicht, einen Behinderten zu sehen.

Sein erster Horrorfilm war The Glory of Love, in dem er den verrückten Inhaber eines Wachsfigurenkabinetts spielte. In einem anderen Film A Blind Bargain übernahm er gleich zwei Rollen und spielte einen Wissenschaftler und einen buckligen Affenmenschen, womit er den Grundstein zu seiner weltweiten Karriere legte.
Seine Gage war mittlerweile von $ 5 am Tag auf $ 10 000 im Monat gestiegen.

Das nächste Highlight in Chaneys Karriere war The Hunchback of Notre Dame, für den er jeden Tag allein 4 1/2 Stunden lang als Quasimodo geschminkt wurde und einen 36 kg schweren Gummibuckel auf dem Rücken herumschleppte.

1924 drehte er mit dem vor Jahren aus Schweden eingewanderten Regisseur Victor Sjöström den Film He Who Gets Slapped / Der Mann, der die Ohrfeigen bekam, der die damaligen Zuschauerrekorde brach und höchste Einspielergebnisse einbrachte.

The Phantom of the Opera 1924/25 von Universal gedreht, wurde sein berühmtester Film.
Chaney - der hinter den Kulissen gern das Sagen übernahm, vertrug sich jedoch nicht mit Regisseur Rupert Julian, der daraufhin nach 10 Wochen durch Regisseur Edward Sedgwick abgelöst wurde, welcher besser mit Chaney harmonierte.
Der Kameramann Virgil Miller, der lange Jahre mit Lon Chaney zusammen arbeitete, schilderte in den 70er Jahre seine Arbeit mit dem berühmten Lon Chaney.
Zitat:

Ich habe Jahre mit Lon an der einen oder anderen Maske experimentiert. Es war eine Herausforderung, weil er mir eine scheinbar kaum zu lösende Herausforderung stellte. "Virg", sagte er, "mach, daß ich schrecklich aussehe und abstoßend, aber mach gleichzeitig, daß das Publikum mich liebt." Er wollte immer geliebt werden. Ich glaube, im Phantom ist dieser Wunsch wirklich in Erfüllung gegangen.

Für die Darstellung des Phantoms hob Chaney seine Nase an, erweiterte die Nasenlöcher, zog die Mundwinkel mit scharfen Klammern herunter und stopfte sich Zelluloidscheiben in den Mund, um die Wangenknochen mehr auszuprägen…

Mit seinem Förderer, dem berühmten Irving Thalberg war Chaney inzwischen zu MGM gewechselt und setzte dort seine Zusammenarbeit mit dem ebenfalls bekannten Regisseur Tod Browning fort, (der u. a. mit dem Film Freaks Berühmtheit erlangte). Der Dreh des Films The Unknown brachte die Beiden, die schon bei Universal zwei Filme zusammen gedreht hatten, wieder zusammen.

Mit der Zeit machten sich jedoch seine selbstquälerischen Masken, bei denen er seinen Körper immer neuen Torturen aussetzte, um glaubhaft zu wirken, gesundheitlich negativ bemerkbar. Er musste - bedingt durch die Linsen, die er sich immer einsetzte, um Blinde zu spielen, eine Brille tragen, er bekam Rücken- und Halsschmerzen und im Jahre 1929 eine Lungenentzündung. Kurz danach wurde Kehlkopfkrebs bei ihm diagnostiziert.
Am 26.08.1930 starb Lon Chaney. Er wurde 47 Jahre alt.

Im Jahr 1957 entstand ein biografischer Film über Lon Chaney mit dem Titel Man of a Thousand Faces / Der Mann mit den 1000 Gesichtern unter der Regie von Joseph Pewney, in dem James Cagney in der Hauptrolle den großen Lon Chaney verkörperte.

Im Jahr 2000 drehte dann Regisseur Kevin Brownlow Lon Chaney: A Thousand Faces mit Kenneth Branagh in der Hauptrolle.

Zu Lon Chaneys berühmter Wandlungsfähigkeit ist eine treffende Anekdote überliefert:
Charlie Chaplin schlendert zusammen mit einem anderen Schauspieler den Hollywood Boulevard entlang. Da kriecht plötzlich eine Spinne über den Rinnstein. Chaplins Begleiter will sie gerade zerteten, da sagte Chaplin: "Halt, Nein. Vielleicht ist es Lon Chaney in einer seiner Masken!"

Der Meister des Make-Up ist heute weitgehend vergessen, vor achtzig Jahren jedoch, war sein Name in aller Munde. Aber vielleicht denkt der eine oder andere Leser einmal an ihn, wenn er das nächste Mal eine Spinne vorbeikrabbeln sieht…


 

Eingetragen unter: Film, Eselkult, Medien, Kunst


kommentieren June 8th, 2007

links for 2007-06-08


 

Eingetragen unter: del.icio.us


kommentieren June 8th, 2007

links for 2007-06-06



 

Eingetragen unter: del.icio.us


kommentieren June 6th, 2007

Das Geheimnis eines Bluescreens

Da es - wie ich hoffe - doch einige User ernsthaft interessiert, einmal hinter das Geheimnis eines Bluescreens zu schauen, habe ich mich entschlossen, ein How-To betreffs Bluescreens und ihrer Analyse zu schreiben. Das Material lehnt sich dicht an einen Artikel aus einer c’t des Jahres 2004 an, indem die gesamte Vorgehensweise sehr gut beschrieben wird.

Zuallererst sollte man sich von dem Gedanken freimachen, ein BSOD sei etwas schlechtes. Erscheint ein Bluescreen, dann heisst das, das das Betriebssystem festgestellt hat, das es sich momentan in einem Zustand befindet, in dem es nicht mehr sicher weiterarbeiten kann. Jede noch folgende Aktion könnte größeren Schaden nach sich ziehen, weshalb das System sich folgerichtig kontrolliert selbst herunter fährt.

Ich empfehle deshalb auch im Fall eines völligen Einfrierens des Systems selbst einen Bluescreen hervorzurufen, anstatt per Reset-Schalter oder ähnlichen Experimenten das System noch mehr zu schädigen.

Die Voraussetzungen dafür sind ganz einfach einzurichten:

- in der Registry zum Schlüssel

HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\i8042prt\Parameters

navigieren
- dort einen neuen DWORD-Wert mit dem Namen CrashOnCtrlScroll einrichten und diesem den Wert 1 zuweisen
-Neustart

Nach dem Neustart kann jederzeit ein Bluescreen ausgelöst werden, indem man die rechte Strg-Taste gedrückt hält und zweimal auf Rollen drückt (die mittlere Taste in der Dreiergruppe über dem Cursor-Block, die auch manchmal mit Scroll oder ScrlLock beschriftet ist.

User, die noch keinen Bluescreen zu Gesicht bekommen haben, sich aber über einen manchmal aus heiterem Himmel erfolgenden Neustart des Systems wundern, sind (unwissentlich) Microsofts honigsüßen Worten auf den Leim gekrochen, das es unter XP keine Bluescreens mehr gäbe.
Diese Aussage ist insofern korrekt, als das die Bluescreens einfach versteckt wurden. Sollte ein Ereignis wie ein plötzlicher scheinbar unmotivierter Neustart auftreten, dann sollte man unter folgendem Pfad nachschauen und wenn man an einer Bluescreen-Analyse interessiert ist, die Optionen wie folgt einstellen

Rechtsklick auf Arbeitsplatz/Eigenschaften/Erweitert/Starten und Wiederherstellen/Einstellungen/Systemfehler

Hier gibt es drei wichtige Optionen:

"Automatisch Neustart durchführen" - sollte deaktiviert sein.
(Ist es aktiviert, kommt es eben zu einem Neustart, ohne dass ein Bluescreen gezeigt und die CPU angehalten wird)

"Debuginformatioen speichern" - hier ist standardmäßig das "kleine Speicherabbild" ausgewählt, was jedoch für eine Analyse des BSOD nicht ausreicht. Hier sollte "Kernelspeicherabbild" eingestellt werden. Ein "vollständiges Hauptspeicherabbild" ist so groß wie der komplette Hauptspeicher plus ein paar zusätzliche MB, bringt jedoch keine Vorteile.

"Vorhandene Dateien überschreiben" - sollte aktiviert sein, da andernfalls Windows einfach kein Speicherabbild schreibt, wodurch man den Fehler dann auch nicht analysieren kann. Resultierend daraus sollte man nach einem BSOD und dem Neustart des Systems den erstellten Memory-Dump entweder umbenennen oder durch Kopieren sichern.

Damit ist der erste Teil der Analyse-Vorbereitung abgeschlossen.

Zur Sicherheitsarchitektur von XP gehört es, dass ein x-beliebiges Programm Windows nicht zum Absturz bringen kann, da dieses im sogenannten User-Mode (auch "Ring 3") genannt in einem eigenen virtuellen Adressraum läuft und nicht auf den Adressraum anderer Programme oder gar der Hardware zugreifen kann.
Ein Bluescreen kann nur entstehen, wenn Code im Kernel-Mode (auch "Ring 0" genannt) etwas tut, was er nicht darf.Das können Gerätetreiber, oder der Mikrokernel selbst sein. Im "Ring 0" teilen sich alle Treiber einen gemeinsamen Adressraum und können sich deshalb auch gegenseitig Schwierigkeiten machen.

Soviel zur Theorie.

Zeigt das System nun einen Bluescreen, bekommt man schon ein paar wichtige Informationen geliefert, die man allerdings interpretieren muss.

(dieser Bluescreen gehört nicht zur später folgenden Analyse. Ich habe ihn nur benutzt, um die nächsten Zeilen besser darstellen zu können)

Jeder Bluescreen liefert eine Zeile, die mit STOP beginnt, worauf sich eine
achtstelllige Hexadezimal-Zahl anschließt. Diese Zahl gibt einen ersten Hinweis auf den Fehler, wenn sie richtig interpretiert wird.

Oft steht ausserdem noch eine Zeile in der Art

BAD_POOL_HEADER

IRQL_NOT_LESS_OR_EQUAL

oder ähnliches dabei. In vielen Fällen kann man mit dieser Zeile und etwas Googelei (besser ist Scroogelei) schon im Netz Hinweise auf den Übeltäter und Lösungsvorschläge finden.
Oft hat man allerdings auch Pech.

Genau dann brauchen wir das beim BSOD erstellte Speicherabbild, das normalerweise unterhalb WINDOWS als MEMORY.DMP erstellt wurde.

Microsoft bietet uns nun ein Werkzeug an, um das Speicherabbild zu analysieren - den Debugger WinDbg (ca. 15,8 MB), der von Microsoft heruntergeladen werden kann. Allerdings nützt der Debugger allein wenig, man braucht auch noch so genannte Symboldateien, die jedoch im vollen Umfang ca. 195 MB groß sind. Die sind allerdings nicht zwingend komplett notwendig, vereinfachen aber das Verfahren, wenn sie komplett auf der Platte liegen, was bei ordentlichen DSL-Anschlüssen kein größeres Download-Problem darstellen dürfte. Allerdings erkennt der Debugger mitunter nach der Installation der Symboldateien diese nicht richtig und bringt ständig eine Fehlermeldung; deshalb bevorzuge ich auch eher die Methode des selektiven Downloads bei Bedarf wie folgt.
Wer die Symbole nicht komplett downloaden will, kann den Debugger so einrichten, dass er nur die Symboldateien aus dem Netz lädt, die gerade gebraucht werden. Das funktioniert folgendermaßen:

- WinDbg installieren
- irgendwo nach Belieben einen neuen Ordner anlegen
- im WinDbg den Menübefehl File Symbol Path wählen und in das Eingabefeld eintragen:

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

wobei statt "C:\Symbols" der neu erstellte Ordner eingetragen werden muss. Dort speichert WinDbg die heruntergeladenen Symbole. Ich nehme dafür WINDOWS\SYMBOLS, wie man sieht.

Jetzt lädt man das beim Bluescreen erstellte Speicherabbild mit File/Open Crash Dump, woraufhin sich zwei Fenster mit den Titelzeilen Command und Disassembly öffnen. Das letztere kann man gleich wieder schließen, da es uns nichts nützt. In neueren Versionen des WinDbg öffnet sich dieses Fenster in der Regel nicht mehr mit, bei älteren Versionen war das jedoch der Fall.
Im Command-Fenstersind jetzt schon ein paar wichtige Informationen zu sehen:

- die Zeile, die mit Probably caused by: beginnt (was soviel heisst wie: "vermutlich verursacht von:") meldet einen Dateinamen, der in den meisten Fällen schon ein Treffer ist. Handelt es sich hier um eine Datei mit der Endung .sys dann lohnt es sich, zu untersuchen, woher sie stammt. (Wir nehmen hier im Beispiel mal an, es ist eine Datei namens i8042prt.sys)

- die zweite interessante Zeile beginnt mit BugCheck und enthält eine Hexadezimalzahl und weitere kryptische Angaben in Klammern. Und siehe da - es handelt sich hier um dieselbe Zahl, die nach dem STOP-Befehl auf dem Bluescreen auftauchte.

Wir sind also auf dem richtigen Weg und müssen jetzt in Erfahrung bringen, was uns diese Zahlen eigentlich sagen wollen.
Nächster Schritt:

- unten im Comand-Fenster hinter "kd>" den Befehl

!analyze -v

eingeben. Es erscheint eine Menge an Informationen, wobei wir uns auf die ersten Zeilen konzentrieren.Die Art des aufgetretenen Fehlers wird durch einen aus Großbuchsataben und Unterstrichen gebildeten Namen wie MANUALLY_INITIATED_CRASH angezeigt, verbunden mit einer (zu) kurzen Beschreibung des Fehlers. Um dazu ausführlichere Informationen zu erhalten, kopieren wir diesen Namen und fügen ihn in der Eingabezeile hinter dem Befehl ".hh" wieder ein, was dann so aussieht:

.hh MANUALLY_INITIATED_CRASH

Dieser Befehl startet die WinDbg-Hilfe, in der der Name automatisch gesucht und ausführlichere Angaben dazu angezeigt werden. Sehr oft findet man hier auch Lösungsansätze und Tipps wie der Fehler zu eliminieren ist. Steht dort, dass defekte Hardware die häufigste Fehlerursache ist, dann sollte man das Ernst nehmen.

Bei den Informationen, die der "!analyze -v"-Befehl ausgibt interessieren uns ausserdem noch die Zeilen unter der Überschrift STACK_TEXT:.
Dort steht eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte der jeweiligen zeile steht der Name des zuständigen Moduls und dahinter, durch ein + oder ! abgetrennt die Adresse innerhalb des Moduls. Wenn hier in den ersten paar Zeilen ein anderer Modulname als nt steht, dann ist dieses Modul zumindest schon mal schwer verdächtig.

mit dem Befehl

!thread

bekommt man eine weitere Ausgabe. Enthält diese die Überschrift IRP List, dann nimmt man die Adressen aus der ersten Spalte der Liste und gibt sie mit dem Befehl !irp ein. Das sieht dann z. B. so aus:

!irp ffabccd8

Daraufhin erhält man weitere Verdächtige, nämlich den Inhalt des so genannten I/O Request Packets, das an dieser Adresse im Speicher liegt. Das Packet enthält immer auch die Namen der an dieser Ein/Ausgabe beteiligten Treiber.

Weiter gehts. Wir sind fast fertig.

Den weiter oben zuerst herausgekitzelten Modul-Namen, in der Zeile, die mit Probably caused by: beginnt (i8042prt.sys), benutzen wir nun für die End-Analyse.

Wir geben den Befehl lm v ein, gefolgt vom Modulnamen ohne die Endung .sys, dafür hängen wir jedoch ein m davor. Das Ganze sieht dann so aus:

lm v mi8042prt

Jetzt sollten wir in der Ausgabe den kompletten Dateinamen mit Pfad der Treiberdatei und Herstellernamen bekommen. Ist das nicht der Fall, dann probieren wir den Befehl

!devnode 0 1

der uns eine Liste aller geladenen Gerätetreiber ausgibt. In dieser Liste suchen wir wieder den Modulnamen (ohne Endung) (über die Funktion Edit/Find in der Menüleiste)
In dem Eintrag, in dem er hinter Service Name erscheint, interessiert uns der Instance Path. Diesen notieren wir uns.

Und damit hat die schwere Geburt fast ihr Ende gefunden.

Wir starten wieder regedit und gehen in den Pfad

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum

und von dort aus weiter genau entlang des eben notierten Pfades.Und hier verrät uns endlich der Eintrag DeviceDesc, um was für ein Gerät oder Treiber es sich bei dem wahren Übeltäter handelt.

Fertig!

Hat man die den Fehler auslösende Komponente dann identifiziert, sollte man sich z. B. im Gerätemanager noch ein paar weitere Infos zum Treiber besorgen, wie Hersteller, Versionsnummer usw. und sich dann auf die Suche nach einem neuen Treiber machen. Manchmal hilft auch eine einfache Neuinstallation des bewußten Treibers, bzw. eine Systemwiederherstellung oder das Zurückspielen eines vorher angelegten Images, um den früheren Zustand vor der Veränderung, die den Fehler ausgelöst hat, wieder herzustellen. Natürlich kann man sich - mit diesen gesammelten Angaben bewaffnet - auch auf in die Weiten des Netzes begeben, um eine intensive Internet-Recherche zur Fehlerbeseitigung zu betreiben. Sollte es sich um defekte Hardware handeln, dann wäre wohl ein Austausch das passende Procedere.

Ich gebe zu, das Ganze ist kein Kinderkram, aber einen richtigen Computerfreak sollte es schon mal reizen, solche Geheimnisse zu erforschen und zu entdecken, anstatt nur mit den Schultern zu zucken, wenn ein BSOD auftaucht.

Übrigens, wer keinen Bluescreen mehr sehen will, kann auch die Farbe ändern und hat dann eben einen RSOD oder GSOD.

Dazu braucht nur folgendes:

- im WINDOWS-Ordner zur SYSTEM.INI navigieren und diese wie folgt editieren:
Nach [386Enh] folgende Einträge hinzufügen:

MessageTextCOLOR=X
MessageBackCOLOR=X

Das X einfach durch die Nummer der gewünschten Farbe ersetzen:

Black = 0
Blue = 1
Green = 2
Cyan = 3
Red = 4
Magenta = 5
Yellow/Brown = 6
White = 7
Grey = 8
Bright Blue = 9
Bright Green = A
Bright Cyan = B
Bright Red = C
Bright Magenta = D
Bright Yellow = E
Bright White = F

Wobei ich 7 und F nicht ernsthaft in Erwägung ziehenn würde. Denn weisse Schrift auf weissem Grund, das erinnert mich irgendwie an die ostfriesische Nationalflagge…

Viel Spaß und gutes Gelingen.


 

Eingetragen unter: Software, Technik


1 Kommentar June 5th, 2007

links for 2007-06-05


 

Eingetragen unter: del.icio.us


1 Kommentar June 5th, 2007

links for 2007-06-04


 

Eingetragen unter: del.icio.us


kommentieren June 4th, 2007

links for 2007-06-03


 

Eingetragen unter: del.icio.us


kommentieren June 3rd, 2007

links for 2007-06-02


 

Eingetragen unter: del.icio.us


kommentieren June 2nd, 2007

links for 2007-06-01



 

Eingetragen unter: del.icio.us


kommentieren June 1st, 2007


Kategorien

TV-Tips

Links

Neueste Einträge

letzte Kommentare

Archiv

Kalender

June 2007
M T W T F S S
« May   Jul »
 123
45678910
11121314151617
18192021222324
252627282930  

Meta





Wir sind die Kunden!