Was nervt euch so, während der Programmierung oder so allgemein

[Bummi]

Solange dieser Thread offen ist, können Sachen die sonst in anderen Thread auftauchen oder neue Threads bedingen würden an einer zentralen Stelle ignoriert werden.

[Codehunter]

Zitat:

Zitat von Bummi (Beitrag 1199546)

Solange dieser Thread offen ist, können Sachen die sonst in anderen Thread auftauchen oder neue Threads bedingen würden an einer zentralen Stelle ignoriert werden.

Schöner hätte ich es auch nicht ausdrücken können :roll:

[p80286]

Aktuell finde ich die Bemerkungen zu FF sogar hilfreich, weil das ein wenig den Horizont erweitert.
(der FF meine Lebenspartnerin ist arg bockig beim Einsatz von Flash, und ich hab noch kein Patentrezept)

Darum weiter so

K-H

[Codehunter]

Zitat:

Zitat von p80286 (Beitrag 1199559)

der FF meine Lebenspartnerin ist arg bockig beim Einsatz von Flash, und ich hab noch kein Patentrezept

Ich sehe es eigentlich eher so, dass Flash an sich bockig ist, nicht nur im Firefox. Unter Opera gibt es auch nicht selten Probleme dass das Plugin den ganzen Browser einfriert.

Jahrelang habe ich Flash per se gemieden so wie ich .Net gemieden habe. Nur gibt es mittlerweile Anwendungen die ich nützlich finde und die Flash voraussetzen. Ebenso wie es gute Anwendungen gibt, die .Net voraussetzen (CDBurner XP oder SyncToy). Also kommt man manchmal nicht mehr umhin die Frameworks zumindest einsatzbereit zu haben, wenn auch nicht immer in Gebrauch.

[implementation]

Sorry, sollte in PM.

[Codehunter]

Um der Sache mit den Bluescreens mal auf den Zahn zu fühlen: FF macht ja wie fast alle aktuellen Browser regen Gebrauch von Hardwarebeschleunigung. Sowohl in der 2D-Abteilung als auch beim JavaScript usw. Auch Flash an sich nutzt diverse Accellerators und wenn vorhanden auch die hardwareimplementierten Videotranscoder. Da kommt gleich ein ganzer Haufen von denkbaren Fehlerursachen zusammen.

Ich würde erstmal hergehen und die im FF installierten Plugins systematisch auf den Fehler hin abklopfen. Wenn man dann den Übeltäter gefunden hat schaut man nach, wovon der so alles Gebrauch macht.

Spontan würde ich auf die Abteilung Grafikkarte (inkl. Treiber) oder RAM tippen. Ich hatte schon Fälle, wo ein Speicherriegel defekt war und sich das nur bei einem einzigen Programm bemerkbar machte.

Tatsache ist, die NT-Basis von Windows ist inzwischen so solide, dass der Userspace (eigentlich ein Ausdruck aus der Unixwelt, aber ok) nicht normalerweise in der Lage ist, den Kernel abzuschießen. Normalerweise deshalb, weil ich es bei meinen LowLevel-Monitor-API-Experimenten letztens trotzdem geschafft habe aus einer Desktop-Anwendung heraus ohne Admin-Rechte den Grafiktreiber unter W7x64 zu plätten. An der Stelle tippe ich mal auf einen Bug seitens Windows. Da ich aber nicht weiß ob das dazu taugt einen Exploit draus zu machen habe ich das an Microsoft gemeldet und nicht weiter veröffentlicht.

Fakt ist: Seit gut 10 Jahren sind Bluescreens so selten geworden, dass sie (gefühltermaßen) zu 99,99% auf Hardwaredefekte und Treiberprobleme zurückzuführen sind und nicht auf Desktop-Anwendungen.

[Medium]

Zitat:

Zitat von Codehunter (Beitrag 1199626)

[...] trotzdem geschafft habe aus einer Desktop-Anwendung heraus ohne Admin-Rechte den Grafiktreiber unter W7x64 zu plätten.

Geht ganz einfach: Schreibe einen Shader der eine zu lange Zykluszeit pro Kerneldurchlauf hat (oder gar eine Endlosschleife), und Win7 meldet einen geschossenen Treiber. (WinXP wird blau.)

[Codehunter]

Zitat:

Zitat von Medium (Beitrag 1199628)

Schreibe einen Shader der eine zu lange Zykluszeit pro Kerneldurchlauf hat (oder gar eine Endlosschleife), und Win7 meldet einen geschossenen Treiber. (WinXP wird blau.)

Shader laufen über den Treiber im Kernelspace. Insofern gebe ich dir zwar recht dass es auf diesem Wege möglich ist, den Kernel zu stören aber es bleibt dennoch ein Kernelproblem. In meinem Fall war es definitiv eine reine Desktop-Anwendung.

[Medium]

Da hast du Recht. Ich kann mir aber gut vorstellen, dass wenn man mit weniger genutzten (und ggf. schlecht dokumentierten) Funktionen des Treibers arbeitet, da noch reichlich Spielraum für "Fehlbedienung" ist. Da müsste man aber fast schon überlegen, ob das dann nicht ein "Fehler" (eher Unsauberkeit) im Treiber ist, womit letztlich das Problem wieder im Kernelspace läge. Fein finde ich dabei nur, dass man seit Win7 bei sowas im laufenden Betrieb den Treiber neu gestartet bekommt, statt gleich komplett auf "Blue-Bottom" durchzusegeln :)

[Codehunter]

Zitat:

Zitat von Medium (Beitrag 1199648)

Da müsste man aber fast schon überlegen, ob das dann nicht ein "Fehler" (eher Unsauberkeit) im Treiber ist, womit letztlich das Problem wieder im Kernelspace läge. Fein finde ich dabei nur, dass man seit Win7 bei sowas im laufenden Betrieb den Treiber neu gestartet bekommt, statt gleich komplett auf "Blue-Bottom" durchzusegeln :)

Das kann man ja als einfacher Delphi-Entwickler schlecht feststellen. So weit wie manche Reverse-Engineers geht es bei mir noch lange nicht.

Wobei die Fähigkeit, den VGA-Treiber on the fly neu zu starten, schon XP prinzipiell beherrscht. Vielleicht nicht in allen denkbaren Szenarien aber z.B. wenn man den GDI-Speicher zugemüllt hat meldete sich XP nach einiger Zeit selbst und wollte den Treiber neustarten. Aber dieses Feature wurde anscheinend von den Treiberentwicklern nicht weiter unterstützt und so endet XP eben im Bluescreen.