MSI lost 'Unsupported Processor'-bsod in Windows op met biosupdate

MSI heeft een oplossing uitgebracht voor een blue screen of death met zijn LGA1700-moederborden op Windows 11. Het probleem werd veroorzaakt door een firmware-instelling met betrekking tot Intel Hybrid Architecture. De oplossing wordt uitgebracht via biosupdates.

MSI zegt de afgelopen weken samen met Microsoft en Intel de oorzaak van het probleem te hebben onderzocht. Volgens de fabrikant doet het probleem zich alleen voor met Intels dertiende generatie Core i9-processors en bepaalde versies van Windows 10 en 11. Het bedrijf brengt een nieuwe bios uit met een bijgewerkte microcode. Die is inmiddels beschikbaar voor de eerste moederborden. Het bedrijf komt komende week met biosupdates voor meer getroffen moederborden. Eind september moet de bijgewerkte bios beschikbaar zijn voor alle MSI-moederborden met Intel 600- of 700-chipset.

Berichten over de bsod's op bepaalde MSI LGA1700-moederborden kwamen in augustus naar buiten. Sommige gebruikers kregen te maken met een blue screen of death met de stopcode 'Unsupported_Processor'. Dat gebeurde na het installeren van bepaalde optionele updates in combinatie met bepaalde MSI-biosversies. Volgens MSI deden de problemen zich voor bij Windows 10 22H2-build 19045.3393. De bsod deed zich ook voor in Windows 11-builds 2221.2215 en 22000.2360.

De bijgewerkte biosversies zijn te vinden op de website van MSI. Gebruikers kunnen hun moederbordmodel opzoeken en vervolgens de bios downloaden. MSI noemt geen specifieke versienummers, maar raadt gebruikers aan om te zoeken naar releases uit september met een beschrijving die de 'Unsupported_Processor'-issue noemt.

Windows-versies die last hadden van 'Unsupported Processor'-bsod
OS Versie Preview Update-versie
Windows 11 22H2 (Build 2221.2215) KB5029351
Windows 11 22H1 (Build 22000.2360) KB5029332
Windows 10 22H2 (Build 19045.3393) KB5029331

Windows 11-BSOD Unsupported Processor

Door Daan van Monsjou

Nieuwsredacteur

06-09-2023 • 14:39

28

Reacties (28)

28
27
9
0
0
8
Wijzig sortering
Ik zag net een beta bios update voor men mobo.
Zolang ik geen problemen heb ga ik geen beta bios installeren.

AMI BIOS
7D91vH85(Beta version)
2023-09-05
9.76 MB
Description:
- Updated CPU uCode to fix "UNSUPPORTED PROCESSOR" issue caused unexpected BSOD.

Mijn windows versie: Windows 11 Version 22H2

[Reactie gewijzigd door Dennis__ op 22 juli 2024 23:28]

Als je geen 13900 processor hebt hoeft dat sowieso niet.
Dus ik ben ok met men 13700K.
als je geen i9 hebt dan hoeft dat niet nee.
Als probleem eigenlijk allen op Windows (na Windows update) voorkomt, waarom lost het moederbord fabrikant en niet Microsoft zelf? Of stond er een verkeerde microcode in BIOS van MSI, en update van Microsft heeft dat blootgesteld?
Omdat een probleem specifiek op Windows niet perse de schuld is van Windows...

Als windows in de microcode een comma verwacht en linux met een punt of comma overweg kan en de fabrikant levert de code aan met een punt, dan gaat het op windows dus stuk en op linux niet maar ligt het toch niet aan windows?

[Reactie gewijzigd door watercoolertje op 22 juli 2024 23:28]

Wauw. Dit brengt mij terug naar een probleem lang geleden...

Acer had vroeger een leuk probleem gecreëerd voor ons voor hun ingebakken Windows XP installaties voor een bepaalde lijn desktops én laptops in combinatie met hun moederbord/bios driver. Ze brachten eerst hun Intel (of AMD) machines uit met een Windows XP standaard Nederlandse installatie en kort daarna hun AMD (of Intel) machines (ik weet even niet meer de volgorde). Maar de 'standaard moederbord en bios drivers' stonden bij die laatste uitgebrachte PCs nog ingebakken op de eerste.

In eerste instantie leek het er op dat dit geen problemen gaf en het werkt ook voor een paar dagen zonder enkel probleem. Maar je kon daarna opeens een keer per dag, of om de paar dagen (geen idee wat de her produceer waarden waren, te lang geleden) een bluescreen krijgen met een foutcode die simpelweg zei dat een er een bepaalde instructie niet kon worden weggeschreven op de processor. Weet even niet of dat een AMD of Intel instructie was.

In de computerzaak waar ik toen werkte en die de desktops (en een enkele laptop) had verkocht met die installatie, hebben we echt een ellendelange tijd zitten troubleshooten want er waren 3 klanten teruggekomen die (uiteraard) niet blij waren. Want zelfs met een verse Windows XP installatie bleef het probleem terugkomen nadat je alle drivers er op had gezet, maar je kon niet zo veel zonder die drivers. Na 2 dagen het internet met obscure Windows reparatie fora te hebben afgezocht kwamen er meer mensen met hetzelfde probleem terug. Een Bios driver van Acer lostte het probleem uiteindelijk (deels) op maar duurde echt te lang voordat die verscheen op hun website.

Mooie tijden.
Het zou best kunnen dat ik daar ooit tegenaan gelopen ben. Mijn computer vertoonde ook dat gedrag ineens, na het eerst een hele tijd gewoon gefunctioneerd te hebben. Ik was daar zo ongelooflijk pislink over, dat ik uit pure nijd Ubuntu 7.04 (Feisty Fawn) over die WIndows XP heb geïnstalleerd die avond, om definitief niet meer terug te keren naar Windows. Nooit spijt van gehad.

Ik heb nog Windows op sommige laptops en PC's staan, maar ik start het praktisch nooit meer op. Ik ben zó "verLinuxt", dat ik het systeem ook niet meer mis of nodig vindt. En als Windows 10 vanaf 2025 niet meer ondersteund wordt, dan is het wat mij betreft voorgoed "bye bye" voor het systeem uit Redmond.
Het was een zeer populair Acer desktop model dat bij onwijs veel mensen in huis stond. Je had een AMD athlon versie en een vrijwel gelijkwaardige Intel versie.
Ik weet niet zeker meer welke van de 2 de problemen vertoonde, maar het was inderdaad bizar met geen/weinig gehoor vanuit Acer. Wat ik nog weet is dat ik de modellen naast elkaar uit elkaar haalde en verbaasd was dat het moederbord vrijwel 1 op 1 identiek was aan elkaar BEHALVE de socket waar de processor in ging.

Het was tevens een zeer goedkoop model met goede specs, want Acer en daarom erg populair.

En toen was het internet met geschikte drivers nog heel klein ;)
In mijn PC, van het merk "Legend" (toen nog onderdeel van NEC Computers, Inc.) had een AMD Athlon 2600XP processor. Dus het zou goed de Athlon geweest kunnen zijn (kan ik me voorstellen).
Ik dacht dat we af waren met BSOD sinds windows 10. maar echter vandeweek toevallig op me nieuwe amd systeem met windows 11 " Hypervisor Error "
Gaan we dit vaker krijgen als je drivers niet automatisch bijgewerkt worden?
Ach, al jaren geen bsod meer gezien; laatst wel nog een linux kernel panic - helemaal voorkomen kan je het niet maar als HW iets onverwachts doet (bios kan je daar ook wel onder scharen omdat het redelijk onderaan de stack zit en dus vrij low level is) en je OS de moed opgeeft ipv stug volhouden met alle risico’s die dat geeft kan je beter een keer een BSOD/panic accepteren….

Reboot en door :)
Op Windows heet de API call wat in een BSOD resulteert KeBugCheck (en KeBugCheck). De Windows kernel zelf is tegenwoordig bijna nooit meer de directe oorzaak van een BSOD, tenzij er een kritieke hardware failure is. Op de documentatie pagina's staat beschreven in welke omstandigheden dat aangeroepen mag worden: wanneer er geen andere oplossing is, en doorgaan data-loss kan betekenen. Helaas zijn er echter veel luie hardware fabrikanten en dus slechte drivers die daar maling aan hebben en om de haverklap KeBugCheck aanroepen, terwijl het geen kritieke fout is (*kuch kuch printer drivers in vroegere Windows versies*).
.oisyn Moderator Devschuur® @ThomasG6 september 2023 16:19
Helaas zijn er echter veel luie hardware fabrikanten en dus slechte drivers die daar maling aan hebben en om de haverklap KeBugCheck aanroepen
Ik vind het een beetje kort door de bocht om te stellen dat het dit altijd is. Er zullen ook zat drivers zijn waar gewoon bugs in zitten en dus crashen op kernelniveau => BSOD
Daar heb je gelijk in. Als er bijvoorbeeld een segfault in een kernel-component of driver optreed gooit de Windows kernel een BSOD, want kritieke fout en kan zorgen voor data-loss; de driver is immers al gecrasht. Vaak is de foutcode dan ook iets als PAGE_FAULT_.... Maar in dat geval blijft het dan nog steeds een slechte driver, want dat zou niet mogen gebeuren. Al kan dat natuurlijk ook komen door een fout in de Windows kernel zelf, maar die kans is tegenwoordig vrij klein.
Ik heb dus nog nooit een Linux kernel panic gezien. Niet bedoeld als superieur zijn, maar gewoon nog nooit gezien. Ik gebruik Linux maar ook Windows. Ook bij W10 en W11 nooit een BSOD gezien. In de tijd dat ik nog Apple had misschien 1 of 2 keer gezien in 10 jaar.
Linux is niet onfeilbaar, dat is geen enkel OS - tegenwoordig is alles vrij robuust (dat is Windows ook hoor)…maar rot/vol geheugen, hardware die de geest geeft (disk controllers willen wel eens sterven in een server), soms zelfs nog drivers/modules die niet meewerken, etc…kan gebeuren en is eigenlijk ook by-design want doordraaien in zo’n staat kan meer ellende opleveren omdat de situatie niet meer betrouwbaar is.

Mocht je ooit een kernel panic willen zien/testen voor de ervaring - je kan het ook triggeren door iets naar /proc/sysrq-trigger (dacht ik…??) te schrijven maar best even googelen :)
Dat is dus een totaal niet aan deze problemen gerelateerde melding.

En BSOD's zijn er natuurlijk helaas nog steeds, het is gewoon onmogelijk om die allemaal te voorkomen. Windows draait op miljoenen. zoniet tientallen miljoenen, verschillende combinaties van hardware en software (drivers). Het is letterlijk onmogelijk om elke situatie te voorkomen.

In dit geval lag het probleem dus ook niet aan Windows blijkt nu, maar aan de hardware (fout in het BIOS van MSI).

En het gaat hier dus niet om drivers, maar om een BIOS. Dat zijn twee wezenlijk verschillende zaken.

Dus als je de illusie hebt dat je nooit meer een BSOD zult krijgen, kan ik je bij deze alvast teleurstellen. Dat is simpelweg niet mogelijk.
maar zoals je aangeeft, heb je een AMD systeem, wat dus niks met dit probleem te maken heeft...
Dan toch opgelost.
Met ASUS moederborden kwam ik dit nog nooit tegen in de afgelopen 10 jaar!

Zulke fouten gebeuren nu eenmaal. Ondanks dit, MSI is en blijft een TOP leverancier als het om moederborden en Grafische kaarten gaat.
:-)
Ach ik had dan weer een asus bord die consistent crashte als een schijf uit slaapstand kwam. Dit is tot op heden nog steeds niet door asus opgelost en ik heb er uiteindelijk zelf een stukje register code voor gesmaakt waardoor dit geen probleem meer was. Dit heeft me 9+ maanden gekost om de oorzaak te vinden en je kan wel raden hoe vaak ik data kwijt geraakt ben en hoe hoor mijn frustratie zat.

Naderhand heb ik geprobeerd vie verschillende kanalen Asus te benaderen en ze op de hoogte te brengen van de oplossing maar Asus waste zijn handen in onschuld terwijl een bord met identieke chipset en specs van MSI naar die pc prima werkte. Ik heb ze zelfs de code voor het register opgestuurd en nog is er niets mee gedaan en dat terwijl ik het probleem op een ander identiek bord heb weten te reproduceren met een andere HDD en andere windows install.

Helaas zullen er altijd rare problemen blijven maar oplossen is beter als nooit oplossen en daardoor zal ik nooit meer een Asus bord kopen.

Reg entry voor wie geinteresseerd is :


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor]
"Type"=dword:00000001
"Start"=dword:00000000
"ErrorControl"=dword:00000001
"Tag"=dword:00000019
"ImagePath"=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\
52,00,49,00,56,00,45,00,52,00,53,00,5c,00,69,00,61,00,53,00,74,00,6f,00,72,\
00,2e,00,73,00,79,00,73,00,00,00
"DisplayName"="Intel AHCI Controller"
"Group"="SCSI Miniport"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters]
"BusType"=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port0]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port1]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port2]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port3]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port4]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Parameters\Port5]
"LPM"=dword:00000000
"LPMDSTATE"=dword:00000000
"DIPM"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\iaStor\Enum]
"0"="PCI\\VEN_8086&DEV_1E02&SUBSYS_84CA1043&REV_04\\3&11583659&0&FA"
"Count"=dword:00000001
"NextInstance"=dword:00000001



En ja je ziet het goed dit is een Intel controller maar alleen asus had problemen met de implementatie ervan.
Om dit zomaar op ASUS te steken vind ik wel straf!
Als dat een algemeen of veel voorkomende probleem zou zijn geweest onder gebruikers met hetzelfde MB, dan had ASUS er zeker iets aan gedaan met INTEL.

Waarschijnlijk is dat niet het geweest, dus is het begrijpelijk dat ze niet op uw vraag konden ingaan, omdat het probleem ergens in uw systeem is geweest en niet omwille van de MB van ASUS.

Dat jij nooit meer een ASUS MB zal kopen in de toekomst is uw volle recht, maar gezien de reden daarvoor uiterst onterecht jegens ASUS. 8)7
En nog iets; U mist de allerbeste Moederborden die u op de markt kan krijgen.
Maar geen nood; U hebt nog MSI en co.
Nou ja ik kende maar 1 ander persoon met hetzelfde bord en die had hetzelfde probleem en ook online was het probleem te vinden dus het was wel degelijk een Asus probleem. Mijn andere MSI bord had er geen last van. Is natuurlijk een kleine sample maar het probleem kwam toch echt voor bij meerdere Asus borden (zelfde type) op elke firmware.
Als je alles gelezen had had je ook kunnen zien dat ik het op een identiek systeem (moederbord, geheugen en cpu) getest heb en het probleem daar ook plaats vond ondank een andere windows. Mijn vermoeden is dat jet in de plug en play/hotplug code zat omdat deze borden vast harde schijven consistent als plug en play weer gaf wat niet uit te zetten was. In principe geen probleem op die icoontje rechtsonder in na dan) maar de problemen waren duidelijk. Ik kan niet anders dan consisteren dat het probleem in de bios zat omdat plug en play voor de HDD toch echt een bios functie betreft. Bij mijn MSI bord met zelfde chipset en Intel HDD controller was het geen probleem omdat daar HDD hotplug default uitgeschakeld was in tegenstelling tot het asus bord.

Verder is er NUL support geweest vanuit Asus wat ook zeer kwalijk is. Je moet wel heel raar en en wat mij betreft biased redeneren om daar dan niet Asus de schuld van te geven.
Je had het erbij kunnen zeggen dat het niet enkel om uw MB ging.

Ook ergens te begrijpen vanuit mijn positie maat, ik heb nooit problemen gehad met ASUS moederborden, en nooit defect gehad of iets in die aard.
Het zijn degelijk de beste hardware samen met grafische kaarten. Je betaald er ook iets meer voor dan andere merken.
Het is een software probleem, en ASUS is niet de beste op dat gebied, dat moeten wij eerlijk toegeven.

Laat het verleden voor wat het is, het was toen welletjes geweest.

Verder het beste gewenst :-)
met ASUS boarden heb je dan weer flipped chips...

https://www.youtube.com/watch?v=QdoB9p3LXVQ
Asus bm560m had ook BSODS met Windows 11. Is zeer recent een bios upgrade voor gekomen met de fixes.
Is goed.
Elke bedrijf maakt updates, fixes, patches ect.
Moet wel en is te begrijpen, mensen zijn niet foutloos, het behoort zelfs tot het onvermijdelijke.

Op dit item kan niet meer gereageerd worden.