1. Cookies optimieren die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklärst Du dich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen
    Information ausblenden
  2. Willkommen im Forum von DIGITAL FERNSEHEN - dem führenden Portal für digitales Fernsehen, Medien und Entertainment. Wenn du hier neu bist, schau dich ruhig etwas um und melde dich an, um am Forengeschehen teilnehmen zu können.
    Information ausblenden

Bluescreen beim Streamen mit SFU

Dieses Thema im Forum "d-box 1 und d-box 2" wurde erstellt von schoniede, 15. April 2007.

  1. schoniede

    schoniede Junior Member

    Registriert seit:
    15. März 2005
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Anzeige
    Hallo Leute!

    Ich habe ein ziemlich lästiges Problem, welches ich kurz schildern möchte.
    Seit ca. einem halben Jahr habe ich auf meinem Rechner (Win XP Home, SP 2 ,ständige Win-Updates) den SFU zum Streamen mit NFS installiert, was anfangs auch - bis auf gelegentliche Ruckler - ganz gut funktionierte. Seit etwa Jahresanfang kommt es aber beim Streamen von TS-Streams, mp3-files oder Bilddateien in unregelmäßigen Abständen immer wieder zu Windowsabstürzen mit einem Bluescreen. Die Fehlermeldung lautet etwa wie folgt:
    "Driver irql not less or equal. Stop 0X...D1, tcpip.sys adress F660332F(dieser Wert ist immer unterschiedlich) base at F65FD000, Datestamp 444775d3".
    Ich habe im Bios - wie in der Fehlermeldung auch empfohlen - das shadowing deaktiviert. Ich habe eine andere Netzwerkkarte (D-Link DFE-530Tx) und einen aktuelleren Netzwerktreiber installiert, den Arbeitsspeicher getestet, ihn auf 1 GB erweitert und die tcpip.sys mit einem Patch auf 50 halboffene Verbindungen hochgesetzt. Nichts hat geholfen. Der Absturz kommt häufiger beim Streamen von TS-Files und seltener bei mp3- oder Bilddateien. Er ist auch beim Lesezugriff häufiger als beim Schreiben. Beim Schreiben von TS-Streams auf die Festplatte läuft der Rechner z.T. 2 Stunden oder mehr stabil. Beim Lesen von TS-Streams kommt der Absturz z.T. schon nach wenigen Minuten oder auch erst sehr viel später.
    Ich vermute, dass irgendein Win-Update ggf. etwas an der tcpip.sys verändert hat, kann das aber nicht genau nachvollziehen. Auch die Log-Datei des Nfs-Server gibt keine Auskunft.
    Ich weiß nun wirklich nicht mehr weiter. Vielleicht kann mir jemand helfen.

    Vielen Dank im Voraus.

    schoniede:(
     
  2. foo

    foo Wasserfall

    Registriert seit:
    5. Januar 2002
    Beiträge:
    9.435
    Zustimmungen:
    40
    Punkte für Erfolge:
    58
    Technisches Equipment:
    d-box II - Neutrino
    NAS200
    AW: Bluescreen beim Streamen mit SFU

    Könnte ein RAM Fehler sein.
    Du solltest dringend mal Deinen Speicher auf Fehler überprüfen. Dieses Tool ist geeignet: http://www.memtest.org/
    Ich hatte mal genau das gleiche "Driver irql not less or equal" - bei mir war es ein defekter Speicherriegel.
     
  3. schoniede

    schoniede Junior Member

    Registriert seit:
    15. März 2005
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Bluescreen beim Streamen mit SFU

    Vielen Dank für die schnelle Antwort. Ich habe den Arbeitsspeicher zwar bereits getestet, aber nicht mit dem von Dir empfohlenen Tool. Ich werde mal den Test durchführen. Vielleicht ergibt sich dann eine Lösung. Ich melde mich.

    schoniede
     
  4. schoniede

    schoniede Junior Member

    Registriert seit:
    15. März 2005
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Bluescreen beim Streamen mit SFU

    @foo
    Ich habe jetzt mit dem memtest86 alle möglichen Varianten des RAM-Tests durchgeführt. Alle Riegel weisen keinen Fehler auf. Auffällig ist aber, dass der Absturz sofort nach dem Lese- oder Schreibezugriff auf die Platte erfolgt, wenn ich nicht alle drei Speicherplätze belegt habe. Sind alle belegt, wobei egal ist, ob mit 256 kB (2X) und 512 kB (1x) oder umgekehrt, läuft das Streamen von Files erstmal ohne Probleme. Der Absturz (bereits beschriebener Bluescreen mit identischer Fehlermeldung - s.o.) kommt dann früher oder später ohne nach außen erkennbarem Anlass.
    Ich habe immer noch die tcpip.sys in Verdacht, da die auch in der Fehlermeldung beschrieben ist. Kommt vielleicht neben dem ja wohl auszuschließenden RAM-Fehler noch ein andere Hardwaredefekt in Betracht, da das Streamen mit dem NFS-SFU zunächst einige Monate nach der Installtion ja gut funktioniert hat.
    Hat noch jemand eine Lösung, die Erfolg bringen könnte? Ich bin jedenfalls ratlos.

    Vielen Dank für Eure Unterstützung im voraus!

    schoniede
     
  5. casper100

    casper100 Wasserfall

    Registriert seit:
    16. September 2004
    Beiträge:
    7.900
    Zustimmungen:
    1
    Punkte für Erfolge:
    46
    AW: Bluescreen beim Streamen mit SFU

    Die tcpip.sys regelt eigentlich nur die Anzahl der gleichzeitigen Verbindungen.
    Und das auch erst seit dem SP2.

    "Driver irql not less or equal" deutet mehr auf ein Hardware Problem hin.
    Netzwerkkarte, Modem/Router, LAN-Kabel
    Hast du irgendwas an der Hardware verändert?

    Um zu testen ob es an der Verbindungsbegrenzung liegt kannst du entweder die tcpip.sys patchen, wie das geht steht hier. --> Klick oder händisch Klick

    Das Verbindungslimit kann man auch mit XPAnitspy aufheben.

    Wenn's vorher gefunzt hat sollten wir erstmal eingrenzen wo das auf einmal herkommt.
     
  6. foo

    foo Wasserfall

    Registriert seit:
    5. Januar 2002
    Beiträge:
    9.435
    Zustimmungen:
    40
    Punkte für Erfolge:
    58
    Technisches Equipment:
    d-box II - Neutrino
    NAS200
    AW: Bluescreen beim Streamen mit SFU

    Wenn die Belegung der RAM Speicherbänke eine Rolle für die Abstürze spielt, würde ich eigentlich schon von einem RAM Fehler ausgehen, denn solange das Board damit prinzipiell klarkommt, kann es den Windows Anwendungen ja egal sein, wo ein Speichermodul steckt. Hast du den Test wirklich gründlich durchgeführt? Dauert dann auch mal gut ne Stunde.
    Leider sagt das Tool auch nicht aus, dass der Speicher nicht defekt ist, wenn kein Fehler auftritt, es sagt nur, dass er definitiv defekt ist, wenn ein Fehler auftritt.
     
  7. schoniede

    schoniede Junior Member

    Registriert seit:
    15. März 2005
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Bluescreen beim Streamen mit SFU

    Erstmal vielen Dank für Eure Antworten.

    @foo
    Ich hatte ursprünglich 2x256 kB RAM installiert. Damit lief der NFS-Server mehrere Monate gut.
    In der letzten Woche habe ich den Speicher um einen neuen Riegel (512 kB) erweitert.
    Alle Riegel habe ich einzeln und z.T. zusammen mit Memtest86 jeweils bis zu knapp 2 Stunden nach den default-Einstellungen getestet. Am Schluss des Tests kam jeweils die Meldung "no errors". Gestern habe ich den neuen 512 kB-Riegel beim Händler noch einmal gegen einen anderen neuen umgetauscht und um einen weiteren neuen 512-kB-Riegel ergänzt. Beide neuen 512-kB-Riegel habe ich noch einmal mit memtest86 getestet und: "no errors". Bei Einsatz nur dieser beiden fehlerfreien neuen 512-kB-Riegel gab es beim Lesezugriff den sofortigen Absturz. Am TV konnte nicht einmal mehr die Tonspur des TS-Streams ausgewählt werden. Gleiches bei der mp3-Liste, dort wurde nicht einmal nach Auswahl eines bestimmten MP3-Ordners die Liedauswahl am TV angezeigt. Erst als ich einen dritten Riegel (alter und getesteter 256-kB-Riegel) in den letzten Steckplatz eingebaut habe, funktionierte die Auswahl und das Abspielen des TS-Streams zunächst wie früher.
    Nach meiner Meinung können so viele - auch neue - Riegel, die ohne Fehler gestetet wurden, nicht alle fehlerhaft sein. Könnte vielleicht das Mainboard einen Knacks mitbekommen haben?
    Gibt es vielleicht einen präzisieren Test für das RAM und andere Hardwarekomponenten (z.B. Mainboard)? Der Zusammenhang zwischen der Belegung der Steckplätze und den "sofortigen" Abstürzen macht mich da etwas stutzig.

    @casper100
    An der Hardware habe ich vor dem Auftreten der Probleme nichts verändert. Wie in meinem ersten Beitrag beschrieben, habe ich nach dem Auftreten der Abstürze auch die Netzwerkkarte ausgewechselt und den Treiber aktualisiert. Allerdings war die "neue" Karte auch gebraucht und vom gleichen Typ (D-Link, wie beschrieben). Ob der Treiber tatsächlich aktueller war, konnte ich nicht genau klären. Beide Veränderungen hatten aber keinen Einfuss auf die Fehlerart und -häufigkeit.
    Ich habe mir kürzlich eine zweite D-Box (auch aktuelles YADI-Image) zugelegt, die jetzt im Arbeitszimmer steht. Bei Zugriff von dieser Box sind die gleichen Abstürze zu beobachten, wie bei Zugriff mit der ersten Box. Damit wären wohl einzelne Netzwerkabel zu den Boxen und die dort eingebauten Karten als Fehlerquelle auszuschließen.
    Jetzt habe ich mir von einem Bekannten eine Linksys-Netzwerkkarte geliehen und werde diese mal testen. Vielleicht bringt es was.
    Ich hatte mir XPAntispy schon zuvor heruntergeladen. Wo wird dort im Programm das Verbindungslimit in der tcpip.sys aufgehoben?

    Zuerst werde ich jetzt die Linksys-Karte testen und die tcpip.sys anpassen. Mal schaun. Ich melde mich wieder. :winken:

    schoniede
     
  8. foo

    foo Wasserfall

    Registriert seit:
    5. Januar 2002
    Beiträge:
    9.435
    Zustimmungen:
    40
    Punkte für Erfolge:
    58
    Technisches Equipment:
    d-box II - Neutrino
    NAS200
    AW: Bluescreen beim Streamen mit SFU

    okay, das hast Du schon sehr gründlich gemacht und umfassend getestet wie ich lese. Von einem Speicherfehler würde ich nun auch nicht mehr ausgehen.
    Was hast Du denn für ein Board? Evtl. hat der Memory Controller (bzw. North Bridge) auf dem Board einen Knacks? Aber ehrlich gesagt ist das jetzt auch nur raten, da das einzig handfeste bzw. überprüfbare der Speicher gewesen wäre, aber der scheint in der Tat nicht direkt das Problem zu sein.
    Ein Board kann man leider ja auch nicht so schnell mal tauschen wie andere Komponenten, aber der Zusammenhang mit den Speicherbänken würde irgendwie in diese Richtung deuten...

    Da fällt mir ein: Hast Du auch den richtigen Speicher gekauft? Ich meine da gibt es ja auch Unterschiede bezüglich timing/Latenzen etc. Mit den alten Riegeln lief er ja gut nur mit den neuen nicht. Dabei müssen die Speicherriegel nicht unbedingt defekt sein, aber vielleicht nicht ganz kompatibel / passend? Prinzipiell ist zwar alles genormt, aber ...
    Hast Du mal geschaut, ob es für Dein Board vielleicht ein Bios Update gibt? Du kannst auch mal schauen, ob die Memory Timings im BIOS richtig eingestellt sind, bzw. vielleicht funzt der Autodetect nicht vernünftig und Du musst das per Hand einstellen.
     
    Zuletzt bearbeitet: 17. April 2007
  9. schoniede

    schoniede Junior Member

    Registriert seit:
    15. März 2005
    Beiträge:
    26
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Bluescreen beim Streamen mit SFU

    Ich habe ein P4VXAD+ mainboard mit Award BIOS. Beim Austausch des 512-MB-Riegel habe ich den User´s Guide mit zum Händler genommen und der hat mir danach zwei "DDR DIMM PC2700/333 MHz memory module" (je 512 MB) verkauft. Im User´s Guide ist beschrieben, dass der memory bus mit 100, 133 oder 166 MHZ getaktet werden kann. Wenn der Prozessor über ein 100 MHZ-Bus arbeitet, können DDR200, DDR266 oder DDR333 RAM-Riegel eingesetzt werden. Die Riegel werden beim Bios-check erkannt und auch unter XP sind sie augewiesen. Die alten 256 MB-Riegel sind mit "PC2100 DDR - P32M648HGD-75A" beschriftet.
    Das mit dem memory-timings bzw. dem autodetect müsstest Du mir näher erläutern. Das Bios-Update habe ich bisher gemacht, da dieses wohl nicht ganz ungefährlich ist. Mir ist auch nicht ganz klar, welches Update richtig ist. Es gibt da wohl eine ganze Reihe. Vielleicht sind zunächst einige Einstellungen im BIOS hilfreich.

    schoniede
     
  10. casper100

    casper100 Wasserfall

    Registriert seit:
    16. September 2004
    Beiträge:
    7.900
    Zustimmungen:
    1
    Punkte für Erfolge:
    46
    AW: Bluescreen beim Streamen mit SFU

    XP Antispy:

    Internet Explorer --> Maximal mögliche Verbindungen zu einem HTTP-Server auf 10 erhöhen