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

[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 von Codehunter:

[...] 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 von Medium:

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 von Medium:

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.

[Delphi-Laie]

So, das nächste "Ding". Im Produzieren immer neuer Ärgernisse ist die Redmonder Truppe wahrlich Weltspitze.

Kann jemand bestätigen, daß Windows 7 beim Einstöpseln von USB-Sticks gelegentlich minutenlang auf diesen "umherrödelt", um dann immer, also auch in den Fällen, in denen dieses minutenlange Gerödel unterbleibt, zu behaupten, daß "eventuell ein Problem mit einigen Dateien auf diesem Gerät bzw. Datenträger" bestehe und dann die Datenträgerüberprüfung geradezu aufdrängelt wird (zum Glück kann man aber auch ohne fortfahren)?

Sogar dann, wenn ich diese "Datenträgerübertragung" starte und dann den USB-Stick woanders (oder sogar nur an diesem Windows 7?) benutze, ihn immer brav erst erfolgreich abmelde, bevor ich ihn entnehme, diese Problembehauptung kommt dann auf Windows 7 wiederum so sicher wie das Amen in der Kirche. Einen meiner beiden USB-Sticks, die ich hauptsächlich benutze, hat NTFS, und den "mag" mein Windows 7 besonders, d.h., der ist es, auf dem umhergerödelt wird. Der andere mit FAT 32 wird nicht "peinlich befragt", aber auch dieser hat angeblich "evtl. Probleme".

Dieses Verhalten beobachtete ich vorher noch nie - weder mit Windows 98, ME, 2000 noch XP (von Vista verschonte ich meine Computer und mich mich aus gutem Grunde bis heute).

Herrjemine, es hat doch alles funktioniert. Was zum Teufel mußte Winzigweich da nur wieder rummachen und das "verschlimmbessern"?

Wenn wenigstens dieses minutenlange, nicht abbrechenbare (verkürzbare) Gerödel nicht wäre....

[Memnarch]

So ich springe mal ebend zurück zum Thema shader und abknallen des Treibers durch zu lange laufzeit:

Zitat von Medium:

Zitat von Codehunter:

[...] 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.)

Jenachdem womit du das machst, musst du es erstmal unbewusst schaffen.

HLSL, GLSL:
Nutzen jeweils automatisches Loopunrolling. Sieht eine schleife "verdächtig aus" ended dass so:
http://s7.directupload.net/images/130124/cr6ql93u.png
Du kannst diese begrenzung umgehen, aber nur bewusst, über tags die mitteilen dass x durchläufe erwartet werden.

Bei OpenCL siehts etwas anders aus. Das performt unroll wohl nur auf wunsch. KA was da so unbewusst durch die Pipeline rutscht.

Und mal erlich:
EGal wie sicher du dein system machst. Wenn es jemand darauf angelegt hat, bekommt er es kaputt.

Kleiner tipp:
ERstellt mal eine form, klatscht en button drauf, und setzt button.width auf 10000000. Das war so ebend euer desktop. Es dauert je nach PC bis sich euer Windowmanager davon "erholt".

Bis es soweit ist könnt ihr z.B einen Taskmanager beunwdern, der lediglich den Form-Rand aber keinen inhalt ehr hat und andere späße.
Aber vorher alles speichern

edit: EY wieso werden bilder in URLs umgewandelt

[mkinzler]

Zitat:

edit: EY wieso werden bilder in URLs umgewandelt

Hänge das Bild einfach an den Beitrag an; ist eh besser, man weiss ja nie, wie lange das externe Bild auf dem anderen Server existiert

[OrNEC]

Dass Embarcadero keine Personal Edition auf den Markt bringt!