Microsoft geeft 'black screen of death' toch zijn traditionele 'blue' terug

Microsoft gaat de 'black screen of death' toch weer 'blue' maken in Windows 11. Microsoft wijdt er in de update notes geen andere tekst aan dan dat het daarmee 'weer zo is als bij voorgaande Windows-versies'.

Al sinds Windows 1.0 was het Windows-crash-scherm blauw, maar met ingang van Windows 11 besloot Microsoft de kleur van het scherm te wijzigen naar zwart. De update die die wijziging terugdraait, wordt nu geïntroduceerd in zijn Beta en Release Preview-kanalen voor het os. Dat betekent dat de wijziging naar alle waarschijnlijkheid niet lang op zich laat wachten voordat hij naar de releaseversie komt.

Hoewel een kleur niet van veel gevolg is, is dit element van de interface zeer oud en bekend. In Windows 1.0 werd de kleur gebruikt op de achtergrond bij meldingen van een 'Incorrect DOS version'. In Windows 3.1 werd het de achtergrondkleur voor systeemcrashes en introduceerde de ontwikkelaar ook de datadump die helpt om de oorzaak van de crash te achterhalen. In 2012, bij de komst van Windows 8, voegde Microsoft de verdrietige smiley toe en sinds 2016 is er de QR-code. Insider-builds van Windows 10 en 11 hebben overigens een groene achtergrondkleur voor hun crash-schermen.

De zwarte BSOD, straks in de wieg gesmoord

Reacties (109)

[Ethirty]

Als Microsoft nu ook de bluescreens wat duidelijker maakt, zodat het vinden van het daadwerkelijke probleem ook mogelijk wordt, dan ben ik blij.

In de meer dan 20 jaar dat ik met deze blauwe schermen in aanraking ben gekomen heeft er maar een handjevol daadwerkelijke richting de oorzaak gewezen. De rest was te generiek om er ook maar iets zinnigs mee te doen.

[GertMenkel]

Wat zou je voor informatie willen zien? NT4, Win2k en Windows XP dumpte alle informatie inclusief CPU-registers, maar ik geloof niet dat iemand daar ooit wat aan heeft gehad.

Op het moment dat er een bugcheck plaatsvindt heeft Windows de context die de meeste mensen zoeken niet. Het weet niet per se welke driver of welke hardware het probleem veroorzaakte dus het kan ook niet gaan wijzen. De meeste BSOD's die ik in de kernel zelf gehad heb, bleken later toch driverproblemen te zijn, en een of twee Intel-netwerkdriverbluescreens bleken veroorzaakt te zijn door een bug in een stuk software dat ik gebruikte om netwerkstatistieken te verzamelen. Als Windows in die gevallen gaat wijzen naar "ik denk dat dit hem is", heb je daar welgeteld helemaal niks aan.

Wil je het probleem zelf oplossen (aannemende dat het probleem dus vaker voorkomt) dan kun je de minidump door een debugger als windbg gooien, WhoCrashed draaien die dat automatisch doet of via de command line kd gebruiken om de nodige data te extraheren. Dit is bij consistente crashes makkelijker als je een full memory dump aanzet (in plaats van de minidump die standaard gemaakt wordt). Ik doe dit meestal bij consistente bluescreens en ik kan je vertellen dat de een of de drie keer bij mij de stack kapot is en er een stuk willekeurig geheugen werd uitgevoerd, daar kun je helemaal niks mee. Dat kan slecht RAM, een instabiele overclock, een slecht moederbord, een slechte PSU, een schrijfcorruptie of een softwarefout in elke mogelijke driver zijn.

Een BSOD is een last resort. Tenzij je wat kennis hebt van hoe Windows-kernel kún je er helemaal niks mee. Er wordt voor zover ik weet nog altijd een STOP-code weergegeven die je kunt opzoeken op MSDN (in het voorbeeld SESSION1_INITIALIZATION_FAILED, een handmatige bugcheck die verder alleen de response code van een interne API logt) maar als je het daarmee niet redt, is de kans dat je het zelf op kunt lossen gewoon heel klein. Daarom stuurt Windows dit soort dingen naar MS, zodat ze bij veel soortgelijke crashes iemand de fout met een debugger kunnen laten nalopen en een update kunnen verspreiden (of een fabrikant vragen om hun driver te fixen).

Zie ook de kernel panics bij Linux: je krijgt een stack trace, een registerdump, een geheugendump en soms zelfs een gedeeltelijke decompilatie van de laatste instructie die gefaald is. Heb ik daar wat aan als eindgebruiker? Nee, niet echt eigenlijk. Ik kan Googlen naar de driver waar de bug in leek te zitten (wat lang niet altijd de driver met de bug is, zoals wanneer de heap kapot is) en ik kan met de assembly misschien proberen te redeneren welke regel code het geweest moest zijn, maar ik ben geen kerneldeveloper, ik heb geen toegang tot de binary blobs die sommige hardware nodig heeft en het zou mijn taak als gebruiker niet moeten zijn om dit op te lossen, hooguit om het te rapporteren.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 15:25]

[dasiro]

het proces dat de BSOD triggerde zou al veel helpen, dan heb je tenminste al een concreet aanknopingspunt. Daarom nog niet de oorzaak (zoals bvb hardware of wat dat proces aan het doen was)

[GertMenkel]

"Het proces" bestaat niet echt, aangezien de STOP-code eigenlijk altijd uit de kernel komt. Je kunt kernelthreads noemen maar die hebben alleen een nummer dat verdwijnt zodra de PC uit is.

De manier waarop de kernel is opgebouwd zorgt ervoor dat één operatie tien drivers door kan gaan voordat hij klaar is, dus er is ook niet echt "een driver" die je kan noemen. Je kunt neerzetten welke module de code bevatte die crashte, maar dan kom je snel uit in de memory allocator of het file system of de thread scheduler van Microsoft.

Voor je alle nuttige context hebt verzameld, zit je eigenlijk al bijna op een volledige crashdump. Zelfs als een driver zelf een bugcheck aanroept, is het maar de vraag of dat komt omdat er een bug in zit of omdat er een onmogelijke situatie plaatsvindt doordat iemand loopt te klooien met geheugen.

Als zoiets zichtbaar wordt aan je eindklanten, moet je je uiterste best doen om te verzekeren dat die informatie ook klopt. Als de info niet klopt, gaat de gebruiker bij de verkeerde partij klagen, en die partij gaat ongetwijfeld bij jou klagen dat ze incorrecte klachten ontvangen. Laat de informatie dan weg, iedereen die er wat nuttigs mee kan, kan het zelf wel uitzoeken.

WhoCrashed is een mooi tooltje dat ik aan zou raden als je zelf een poging wilt wagen. Dikke kans dat daar ntoskrnl uit komt rollen bij jouw bluescreens, wat meestal dus helemaal niks zegt, maar af en toe kan het een mooi startpunt zijn om een onderzoek te beginnen. Het is vanwege bovenstaande alleen heel belangrijk om je te realiseren dat de crashende module vaak niet de boosdoener is (in mijn gevallen kwam het vaker voor dat het een false positive was dan niet...)

Oh, als laatste zou ik iedereen met bluescreens willen aanraden te checken of overclocks of XMP aan staan. Zelfs als je er zelf vanaf bent gebleven, heb je fabrikanten/PC-bouwzaken die hun PC's out of the box overclocken en dat heeft echt een serieuze impact op de stabiliteit. Ik zat halverwege de drivercode van een Realtek-netwerkkaart in OllyDbg voordat ik eraan dacht om de overclocks een keer uit te zetten, en het had eigenlijk direct effect. Soms is de makkelijke weg de beste weg.

[dasiro]

laat ik het dan anders stellen: wat voor nut heeft het tonen van enige info whatsoever? Ik zeg vaak tegen eindgebruikers dat het probleem oplossen gemakkelijker en sneller is dan het uit te leggen en probeer daar zo weinig mogelijk technische details bij te gebruiken, omdat dat de situatie alleen nog maar complexer maakt.

Mij lijkt het dat alles wat in de scheduler wordt geduwd terug te traceren zou moeten zijn, want uiteindelijk wordt er ook ergens een resultaat verwacht, zijnde output naar de requester.

[GertMenkel]

Een foutmelding "er ging wat mis" zonder enige context is ook stom (zie zo'n beetje iedere mobiele telefoon tegenwoordig),dus enige context is op zich wel praktisch. Mocht je steeds dezelfde stopcode gebruiken, dan kun je in elk geval ergens beginnen.

Alles te traceren maken zou kunnen, maar dat gaat ten koste van flexibiliteit en performance. Je moet dan drivers compartmentaliseren, isoleren en forceren dat ze geen systeemgeheugen kunnen aanpassen of systeemfuncties hooken. Drivers schrijven wordt daarmee zeer lastig. Ook voorkomt het niet dat programma's met assembly en hacks interne Windows-API's misbruiken om het oude gedrag te herstellen. Je moet daarnaast nog rekening houden met dingen als DMA voor data transfers die mis kunnen gaan, dus zelfs met een geïsoleerde structuur is het erg lastig om alles duidelijk te houden. Zelfs met dat model kan de instructiepointer alsnog in het geheugen van een willekeurige module terechtkomen bij een beschadigde geheugenmodule, willekeurige bitflip, overclock of bij een geladen deeltje uit de ruimte.

Ik denk niet dat het praktisch mogelijk is om op kernel-niveau code uit te voeren zonder dat je de traceerbaarheid flink opoffert.

Windows is wel met iedere release steeds meer code in user mode gaan draaien (user mode kernel drivers zijn er bijvoorbeeld al voor sommige grafische drivers, maar voor performanceredenen wordt het lang niet altijd gedaan). Ik denk dat die aanpak een stuk beter is. Het effect is dat gebruikers hooguit een popup krijgen ("printerdriver is gecrasht") en lang niet zoveel BSODs tegenkomen. Ik denk dat Microsoft er beter aan doet om die aanpak uit te breiden dan om de attributie en traceerbaarheid van device drivers te verbeteren met API-wijzigingen (en daarmee incompatible drivers voor oudere apparaten).

Het zou leuk zijn geweest als hier dertig jaar geleden meer aandacht aan besteed was bij het ontwerp van Windows NT. Helaas kon het toen niet uit om diverse redenen, en met Windows Vista hebben we gezien wat voor bende je krijgt als je grote breaking changes aan de API toebrengt...

[dasiro]

Ik kijk ernaar als second line inhouse support, maar heb met de huidige situatie niet genoeg info of kennis (geef ik gerust toe) om dit efficiënt te troubleshooten. De OEM helpt daar sowieso al niet bij en daar hebben we gewoon geen third line voor. Om dan een (kostbaar) ticket ervoor te laten openen bij Microsoft is al helemaal overdreven en in de tijd dat je ermee verspilt heb je de machine al lang opnieuw gedeployed, maar dat is een workaround en geen solution.

Keuzes van 30 jaar geleden kan je nu niet meer als oorzaak gaan aanduiden. Dat was een tijdperk waarin permanent connectivity amper of nergens bestond en wat er dan gedaan werd of tegen moest worden beschermd stelde naar huidige normen niets voor. Ondertussen hebben ze al verschillende keren de manier waarop drivers en software werken aangepast of vernieuwd. Ja je krijgt minder BSOD's, maar ze zijn er niet duidelijker op geworden en dat was origineel mijn vraag

[souplost]

De GUI is nog steeds verweven met de kernel. Daarom wordt het ook wel eens spaghetti code genoemd. Waarschijnliujk de reden dat het na 30 jaar nog steeds zo veel crasht i.t.t. Linux dat nooit crasht. Zelfs niet als alle geheugen of disk is opgesoupeerd.
Het een en ander zie je ook af aan de hoeveelheid disk en RAM gebruik bij een minimale installatie.

[Immutable]

Had voorheen altijd blue screens of death. Heb nu een nieuwe PC met ECC geheugen. Gek genoeg tot nu toe nog nooit een blue screen of death gezien.

[Waah]

Komt omdat ze momenteel zwart zijn
Geen zorgen, ze komen weer terug

Maar mee eens, heb eigenlijk nooit meer BSOD's. Zwart óf blauw. En dat met een oude Intel 2600K en DDR3 ram.

Windows, hoeveel men er over klaagt, is echt stabieler dan ooit. In Windows Vista klaagden we over alle crashes, met Windows 11 gaat het om de plek van de taakbalk. Dat spreekt al boekdelen volgens mij

[Xander2]

Die situatie van random onbetrouwbare BSOD's wordt voor een groot deel door RAM gecreëerd wat minder stabiel is dan geadverteerd.

Het is mooi dat we eindelijk richting ECC als standaard gaan.

[Anoniem: 734539]

Denk dat hij doelt op de manier hoe WhoCrashed dit aantoont, dit geeft vaak al meer een richting aan dan een algemene crashcode waarbij het volledig giswerk is. Zo heb ik ooit de oorzaak van een BSOD teruggevonden via WhoCrashed, dat terwijl de BSOD zelf enkel de algemene error-code aangeeft.

Daarbij wordt volgens mij een computer standaard automatisch opnieuw gestart na een BSOD, dus het gros van de gebruikers heeft niet eens de tijd om de error-code op te lezen, laat staan om een hele tekst op te lezen.

Persoonlijk zou mijn voorkeur een "Meer informatie" knopje zijn, waarin het op een soortgelijke manier als WhoCrashed wordt aangegeven waar het mogelijk door komt.

Instabiele overclocks komen helaas met regelmaat voor bij het selecteren van XMP, dat heb ik op mijn machine helaas ook moeten ondervinden onder specifieke omstandigheden, zoals het uitpakken van een zwaar gecomprimeerd bestand. Bij regulier gebruik, gamen e.d. kwam dit niet naar voren, MEMTEST gaf ook geen fouten aan, dus heb dit ook pas heel laat ontdekt, had verder namelijk geen issues.

De oorzaak bleek te zijn dat de voltage die het XMP-profiel gaf gewoonweg een stap te laag was, na dit een stukje omhoog te zetten (wel in veilige range uiteraard), na MEMTEST te draaien en vervolgens hetzelfde bestand uit te pakken ging dit goed.

[Cybergamer]

Daar heb je https://www.resplendence.com/whocrashed voor. Het is alleen jammer dat je er een externe app voor nodig hebt.

[Ge Someone]

of BlueScreenView waarmee je soms een clue uit de memory dumps kan halen.

[ocwil]

Of WinDbg met een vervolgens een paar commando's

[ikt]

Het enige wat tussen 7 en 8->11 is veranderd, is dat de argumenten van de stopcode nu niet meer worden weergeven.

Op zich eigenlijk ook prima, want met die argumenten kun je eigenlijk helemaal niets als je niet de driver hebt geschreven.

Daarbuiten bevat het dezelfde informatie - welk type stopcode is het, en welke module heeft die veroorzaakt (als het een non-Microsoft module is). Als geavanceerde gebruiker kun je dan prima het bestandsnaam opzoeken en de driver proberen te updaten - daarbuiten valt óók voor de meest geavanceerde gebruikers weinig te doen.

Windows maakt nog steeds een memory dump en dát is waar ontwikkelaars naar kijken. Die hebben ook de symbols zodat bijvoorbeeld Windbg de stack trace zinvolle context geeft, zodat die gewoon goed te analyseren is. Die 4 extra (32 of 64 bit) getallen die sinds Windows 8 weg zijn, hebben eigenlijk nooit enige nut gehad.

[GertMenkel]

Het probleem is natuurlijk dat de module niet de echte oorzaak hoeft te zijn. Als je Realtek driver de heap molt en vervolgens je AMD-driver de regie krijgt na een interrupt, crasht de AMD-driver maar is dat alleen verwarrend. Ook kan het zijn dat Microsoft hun API kapot heeft gemaakt waardoor drivers zich raar gaan gedragen, dan kun je drivers updaten zoveel je wilt maar blijft het probleem bestaan.

Ook zal bij defecte hardware de crash natuurlijk in willekeurige drivers voorkomen, en daar vindt je ook niets meer.

Sommige foutcodes zijn al duidelijk genoeg, zoals die in het voorbeeldplaatje hierboven. Dat is een Microsoftspecifiek ding, geen zin om daar nog meer aan toe te voegen. Bij sommige codes met meer context zou je misschien meer info willen hebben (zoals bij een kritiek apparaat dat offline gaat of een watchdog die verloopt, dan wil je een identifier hebben eigenlijk).

Ik vind het eigenlijk wel verstandig om deze informatie alleen te tonen aan gebruikers die er ook wat mee kunnen. Je kunt nog steeds WhoCrashed over de logs heen gooien, maar de onwetende gebruiker zal niet meer met een boze vinger wijzen naar "stomme Microsoft/Nvidia/AMD/Cyrix" als daar geen aanleiding voor is. Dat levert alleen maar reputatieschade en gebikker tussen twee supportafdelingen op.

Die vier getallen zijn overigens wel heel nuttig bij sommige STOP-codes (maar bij veel andere ook weer niet). Als je de documentatie leest, kunnen die getallen je soms precies vertellen wat er misgaat. Andere keren zijn ze alle 4 0 en dan kun je ze net zo goed weglaten.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 15:25]

[karelvandongen]

Ik heb ook wel eens gehad dat het kwam door antivirus, doordat ik naar juiste dll kon verwijzen, was het binnen een paar dagen gefixed. En ik heb ook al gehad dat na bugcheck, het een onderdaal van edge bleek, en ik daardoor er zeker kon zijn dat het toepassen van een update het probleem zou moeten fixen, en inderdaad deed. Daarom is het voor de iets beter onderlegde ict'er een minidump een erg nuttig instrument.

[Anoniem: 25604]

＼(^0^)人(^0^)／ Van zo'n antwoord word ik nou oprecht blij en een beetje geïnformeerder. Top reactie! Heel wat anders dan de standaard kreten "mijn Linux-Computer crasht nooit ¯\_(ツ) _/¯", "Ik heb een Apple... echt... ik heb een Apple... heb ik al gezegd dat ik een Apple heb? (ツ゚)_¡" of "Ik ben een heel slimme, ervaren en objectieve computerdeskundige enne... ik weet waar ik over praat en ik heb echt verstand van het gebruiken van Youtube-filmpjes om bijvoorbeeld memorytimings en voltages aan te passen... (het liefst bij mijn (groot)ouders natuurlijk, mijn persoonlijke OTA-straat...)... man man man... wat een (boot)problemen en stoperrors geeft die Windows..."

[Reactie gewijzigd door Anoniem: 25604 op 22 juli 2024 15:25]

[grizzlywilde]

Bedankt voor de tip rondom WhoCrashed. Ik kende die app nog niet. De laptop van mijn vrouw crashed regelmatig zonder BSOD en Informatique wil/kon er niets aan doen, dus ik ga dit zeker even proberen.

[goarilla]

Bwaa als je de Minidumps door WinDbg haalt heb je toch vaak een idee welk toestel/driver
kuren heeft. En als dat dan steeds opnieuw gebeurd heb je bevestiging ... Ook voor systemen met schijnbaar willekeurige crashes heeft me dat toch een paar keer wijzer doen worden. Ik heb zo ooit een toestel gehad dat geheugenproblemen gaf (memtest86+) na pas 10+ uren testen - iets wat ik dus nooit zomaar doe. Maar doordat de Minidumps crashtten op allerlei verschillende drivers maar ongeveer rond hetzelfde geheugenadres heb ik de geheugentests toch een nachtje laten draaien en inderdaad de volgende dag had ik een lijst van geheugenfouten in die dinstincte regio. Ik was op dat moment Eureka-tetisch. Er was al heel veel tijd gekropen in die machine en het begon ondertussen toch echt wel op m'n heupen te werken.

[vanDee898]

Het is ook niet de bedoeling dat de gebruiker hier iets mee doet of kan. Dit is een debug scherm is, in de api heet dit ook een bug check, https://docs.microsoft.co...rpreting-a-bug-check-code

[bytemaster460]

Het idee van zo'n bluescreen is juist dat het ontstaat door een onverwachte gebeurtenis. Het systeem weet dus niet wat er aan de hand is, anders had het het kunnen ondervangen. Daarom krijg je een hoop data van de status van processor en geheugen zodat je zelf op zoek moet naar de oorzaak.

[SoloH]

Ik heb er al 1 gehad. Er stond wel wat info bij welk proces schuldig was enzo. Niet dat ik het ben gaan uitzoeken :-)

[Marctraider]

Dan moet elk hardware onderdeel aparte module/chip hebben die autonoom buiten het OS (Ook na een kernel crash o.i.d.) om de dingen realtime kan checken op integriteit e.d.

Zo makkelijk gaat dat echt niet, en zelfs al was dit geimplementeerd is het vaak nog onmogelijk om het exacte probleem te localizeren. Zeker bij hardware issues is de combinatie van hardware failure en gedraaide code waarbij het mis gaat zo random dat dit gewoon ondoenlijk is.

[Reactie gewijzigd door Marctraider op 22 juli 2024 15:25]

[rjmno1]

ik heb met windows 11 een red screen of dead gekregen, niet gekeken wat het was.Maar toen was wel win 11 in beta fase.

[PieterjanDC]

Ik zou er roze van gemaakt hebben, maar ze hebben toch blijkbaar liever blauw...

[Anoniem: 25604]

Kan nieiet!! Bij VMWare ESX hebben ze de PSOD al ingepikt. "P" staat daar weliswaar voor Purple... maar toch.

[Anoniem: 454358]

in win10 heb ik nog nooit een bsod gehad, dat was bij 7 nog wel anders. (laat staan nog oudere versies)

[geoffrey.vl]

Als je daarmee wil zeggen dat het niet veel meer voor valt...
Ik had het onlangs voor bij het nieuw installeren van een pc, toen was het vermoedelijk een driver die moeilijk deed. Mocht wel opnieuw beginnen...
Op m'n werk PC gebeurt het eens om de zoveel maanden. Letterlijk "out-of-the-blue", tijdens het uitvoeren van taken die ik honderden keren per dag doe.

Verder on-topic: het lijkt somt "nieuwe verkoops manager nieuwe kleurtjes". De OS developers bij MS hebben er achterliggend waarschijnlijk ondertussen een instelling van gemaakt

[Anoniem: 454358]

Als je daarmee wil zeggen dat het niet veel meer voor valt...

Nee, ik zeg daarmee dat ik het niet meer ben tegengekomen. Thuis niet, en op de zaak niet. Maar ik ben dan ook geen sysadmin met moeilijke hard- en software. Meer dan een standaard pc met win 10, Firefox en office wordt eigenlijk niet gebruikt.

[Anoniem: 25604]

Psssstt... Niet zo eerlijk man... slecht voor je rep. "Everybody is a SysAdmin, DomainAdmin, Linuxgoeroe nowadays!"

[Lethalis]

Ik heb Hyper V geïnstalleerd op een AMD Ryzen laptop. It failed. Miserably.

Overigens ook op Windows 11. Dus heb zowel de blauwe als zwarte variant gezien van de BSOD.

[Reactie gewijzigd door Lethalis op 22 juli 2024 15:25]

[jimshatt]

Had je virtualisatie wel ingeschakeld in de BIOS?

[Lethalis]

Uiteraard... het uitzetten in de bios is vervolgens ook de enige manier om Windows weer op te starten

Is een AMD probleem..

[SoloH]

Ik ook niet, maar na installatie van 11 heb ik er wel weer 1 gehad. Had iets te maken met VR

[hooibergje]

Moet je maar eens tegelijk een virtual machine in VMware en een andere in Virtual Box draaien.
In Windows 7 ging dat keihard mis. Zal in 10 ook nog wel eens een dingetje kunnen zijn.

Het is dan ook wel een behoorlijk ongebruikelijk scenario, dus whatever...

[GertMenkel]

Ik weet niet hoe het zat in 7, maar in 10 zou dit geen crash moeten veroorzaken. Windows draait zelf namelijk al een gedeelte van het systeem in een VM als je dat aanzet (wel zo goed voor de veiligheid, zou ik aanzetten als je het kunt) dus conflicten met virtualisatiesoftware zijn als het goed is meegenomen in Windows tegenwoordig.

Eén van de twee sowieso wel moeten klagen dat er al een hypervisor draait, dus de twee zouden nooit tegelijkertijd een VM kunnen starten in normale modus. Ik weet dat virtualbox ook Hyper-v als backend kan gebruiken, misschien VMWare ook, ik dat geval kun je ze namelijk naast elkaar draaien zonder probleem. Zo niet zou je de VMWare hypervisor kunnen gebruiken en virtualbox kunnen forceren om de supertrage software-emulatie te doen als je écht wilt dat het werkt.

[Krimglas]

Moderne windows versies zijn dan ook enorm robuust. Als je op een bestaand systeem BSOD's krijgt mag je er vaak al van uitgaan dat er een hardwareprobleem is.

[Higaphix]

Fun fact:

Windows Vista had een 'Red screen of death'. Dit is bij Windows 7 weer blauw geworden

[Reactie gewijzigd door Higaphix op 22 juli 2024 15:25]

[wildhagen]

Dat Red Screen of Death was alleen in de beta-builds van Windows Vista, later werd dat zwart (in de beta), en in de produktieversie was die weer gewoon blauw

Four Red Screens of Death are known: One appears in early beta versions of Windows Vista, but it later became a black screen. Another appeared in Windows 98 beta builds and is caused by Advanced Configuration and Power Interface (ACPI). It also appears on the Atari Jaguar System if there is a loading cartridge error or a pirated cartridge is detected, marked by the sound of a roaring jaguar and a red Atari Jaguar logo on a screen that changes color from black to red. And the last one is the PlayStation 2's Red Screen of Death, it is very similar to the PS2 startup screen, except after the startup, a red screen appears with a message saying "Please insert a PlayStation or PlayStation 2 format disc." The sound at the start of the Red Screen is actually a low pitched version of PS2 menu screen with a creepy whistle and then the ambient sounds like the menu. This error can be obtained by inserting a non-compatible disc/game disc e.g, a PC disc and later Xbox 360 discs with the new banner.

Zie https://en.wikipedia.org/wiki/Screen_of_death

Maar er zijn zoveel kleurtjes "Screen of Death": blauw, zwart, rood, geel, groen, paars en wit, zie bovenstaande pagina

[Reactie gewijzigd door wildhagen op 22 juli 2024 15:25]

[Anoniem: 25604]

Nu begrijpt hij eindelijk waarom hij zo'n afkeer van Vista heeft gekregen. Vergeten uit β te komen en de releasebuild te installeren...

[Reactie gewijzigd door Anoniem: 25604 op 22 juli 2024 15:25]

[tedades]

Voor uitleg waarom er ooit voor gekozen om het crash scherm blauw te maken:
https://youtu.be/KgqJJECQQH0?t=779
Het kleuren schema op de MIPS RISC machine van de ontwikkelaar had deze kleuren combinatie en ook zijn code editor (SlickEdit). Het crash scherm was daardoor consistent met de ontwikkel ervaring.

[bussie66]

Wat interesseert die kleur nou?

Kan me de laatste BSOD niet herinneren.

Win10 is hier super-stabiel.

[phpnuker]

Win 10 is inderdaad super-stabiel bij mij ook.

[Jim80]

Wel vriendelijk van MS dat term BSOD dus altijd van toepassing is geweest, of het nu Black of Blue was

[Nijl]

Ik dacht altijd dat je die kleuren zelf kon instellen ..

[wildhagen]

In Windows 10 en 11 kan dat (volgens mij) inderdaad niet meer, maar in oudere versies kan het wel degelijk, is ook een artikel over te vinden bij Microsoft: https://techcommunity.mic...ith-one-click/ba-p/723977

Dit werkte in ieder geval tot en met Windows 7, versie 8/8.1 weet ik niet eerlijk gezegd.

[themadone]

Ja top, mag ik dan ook rechtermuisknop op de taakbalk > task manager weer terug?

Iets met muscle memory....

[Carlos0_0]

https://www.stardock.com/products/start11/

Startdock heeft het in zijn applicatie terug gebracht, ik kan weer rechts klikken op de taakbalk voor taskmanager.
Mijn pc doet nu ook tenminste met updates weer een shutdown(Als ik kies voor update & shutdown), in plaats van een reboot en shutdown(Dus dat die de update volledig verwerkt).

Ik heb ook start menu van windows 10 terug wat ik fijner vond, en in uitgebreide pakket kan je ook andere dingen weer terug zetten zoals ribbon van de verkenner enzo.

[Reactie gewijzigd door Carlos0_0 op 22 juli 2024 15:25]

[ScoeS]

Control Shift Escape

[GekkePrutser]

Ik gebruik altijd WindowsToets + X, daarmee kan je ook direct naar de device manager en meer handige troubleshooting dingen

[qbig1970]

Rechts-klik op Start ook

[MeNTaL_TO]

Dan had je maar jaren geleden moeten aanleren om CTRL-Shift-ESC te gebruiken (of begin er nu mee)
Sinds Windows 11 weet ik ook het verschil tussen Windows-TAB en ALT-TAB

[goarilla]

Wat is er mis met Win-R "taskmgr" ENTER of Ctrl-Alt-Del, selecteer task manager ?

[SpoekGTi]

Soms lastig als je 3 lagen diep in een remote omgeving zit

[themadone]

Inderdaad, vooral dan zijn sneltoetsen niet altijd je beste vriend.

En het is niet alsof er geen rechternuis menu is, zit alleen een gare optie in die je naar het geweldige nieuwe settings gebeuren brengt....

[Blokker_1999]

Te veel werk

[goarilla]

Mja met ctrl-shift-escape moet je rechterhand de oostkust van je keyboard verlaten om helemaal naar het meest uiterst irritante N-W plekje af te reizen. Dat vind ik dan weer te veel werk. En ja Ik heb kleine handen . En als het echt stoort: shortcut maken naar taskmgr.exe/process explorer/process hacker op je desktop en shortcut key naar keuze erop zetten.

[Whatts]

Ook met kleine handen moet ctrl+shift+escape lukken met enkel de linkerhand
(je hebt er zelfs maar 2 vingers voor nodig, duim voor ctrl+shift en middelvinger voor esc)

[Reactie gewijzigd door Whatts op 22 juli 2024 15:25]

[goarilla]

Ja nipt maar met (te) grote kans op kramp en mistoetsen .

[Anoniem: 221563]

Die doet kennelijk niet hetzelfde volgens de oorspronkelijke programmeur van taskmanager.

Als je een vastlopende taskmanager hebt dan kun je via ctrl+shift+Esc een nieuwe instance starten. Als dit niet lukt omdat de huidige is vastgelopen zal hij de vastgelopen taskmanager na een seconde of 10 stoppen en de nieuwe starten. Kortom, die zou het ‘altijd’ moeten doen. Ook wanneer alles hangt.

[goarilla]

Ach zo, ja dat is inderdaad een belangrijke nuance. Alhoewel ik het onlogisch zou vinden om bij ctrl-alt-del, een knop die niet afgevangen kan worden door normale userland software, ook niet diezelfde speciale taskmgr invocatie te lanceren.

[Marve79]

ctrl-shift-esc is zo lastig met 1 hand. Krijg er kramp in m'n vingers van.

[GewoonWatSpulle]

Duim en wijsvinger? Je duim laat je Ctrl en Shift toen ik een normale vlakke hand manier en dan met je wijsvinger de Esc knop?

[Anoniem: 211516]

Rechter muis knop is makkelijker...

[JapyDooge]

Success daarmee in een remote sessie

[L0g0ff]

Toetscombinaties is leuk voor op eigen desktop. Maar als je via rdp over een windowed remote desktop manager (zonder keyboard capture aan) dan is een rechtermuisknop op de start wel echt handig.

Dat klinkt misschien als een ver van je bed show. Maar mijn halve werkdag bestaat uit beheer op deze manier.

En je kunt keyboard capture wel aanzetten. Maar dan mis je weer eigen shortcuts zoals prntscrn en snel kunnen schakelen naar je eigen lokale tooling.

[Jron667]

ik heb de task manager aan de taakbalk vastgemaakt, scheelt een klik.

[Mailootje]

Dan druk je op het windows logo rechtermuis knop en dan taskmanager... Is verplaatst is ook niet veel moeite neem ik aan?

[SunnieNL]

Als je nou rechts klikt op je taakbalk op het Windows logo, dan staat die er ook…

[IrBaboon79]

Bekend muscle memory issue.. Maar hij zit onder de start knop dus een beetje verplaatsen en muscle memory is weer enigszins tevreden...

[gaskabouter]

Mijn wereldbeeld is hersteld

Action successfully failed

[Reactie gewijzigd door gaskabouter op 22 juli 2024 15:25]

[WhatsappHack]

Action successfully failed

Task failed successfully*

[Anoniem: 25604]

Action successfully failed

Niet waar hoor... \( ت)/ \_( ت)_/ \( ت)/

[Reactie gewijzigd door Anoniem: 25604 op 22 juli 2024 15:25]