Názory k článku
Microsoft oznámil zvýšení požadavků na kvalitu ovladačů hardwaru od OEM výrobců

fascinujici, a tahle soucasna komplexni rigidni kontrola trva roky https://xcp-ng.org/blog/2025/10/10/signed-windows-pv-drivers-now-available/ nebo asi jak pro koho...

tam bude hlavně otázka, jestli v době, kdy ten program WHQL vznikal, šlo některý věci vůbec na straně MS testovat. chápu správně, že by sis představoval, že "někdo" v MS dostane zapojení hardwaru, zdrojáky ovladačů, a bude analyzovat jestli to někde nebloudí v cyklech a jestli je to napsaný efektivně? to přece není realistický.
dělá se to sadou automatizovanejch testů, což ale samozřejmě dokáže podchytit jen scénáře, který někoho napadly a vymyslel, jak je automatizovaně provést a vyhodnotit. dělat to ručně by bylo šílenství.
navíc je potřeba si uvědomit, že to je hardware úplně jinýho výrobce, a je především JEHO odpovědnost, aby to fungovalo správně. stejně jako VÚMV a ostatní obdobný úřady stanoví povinná kritéria, která auto musí splnit aby smělo na silnice, ale už neřeší jestli se ti pohodlně sedí a kolik to žere. to je totiž problém TVŮJ a homologačních měření.
a fakt hodně pochybuju, že si při výběru auta necháváš od jeho výrobce předložit zdrojáky firmwaru řídicích jednotek a všech systémů, schémata, a pevnostní výpočty ke zhodnocení, jestli si to auto koupíš. a i kdyby ti něco z toho někdo dal d oruky, že by ses obtěžoval to projít, a že bys tomu byť jen přibližně rozuměl. ani v tý automobilce totiž NIKDO nerozumí na tom autě VŠEMU. protože to dávno nejde.

Realita te automobilky je, ze casto nikdo v ni konkretni veci nerozumi.
Jednotku A dodal dodavatel X a firmware do ni subdodavatel Y.
Co znamena chyba K? Nevime.
Kdo je autor FW, nevime.
S kym o tom mam jednat? To je politicky problem...

A proto za správnou funkci nese odpovědnost a ručí za ni JEJÍ DODAVATEL. Pak automobilce stačí dokumentace komunikačního rozhraní.

Tohle je problem i u mnohem jednodussich veci - napr dnesni SSD - at se zeptate kohokoliv koho logo na produktu objevite (nand/radic/tis­tak/firmware/o­em/distributor/pro­dejce), vsichni od toho daj ruce pryc ze "my nic".

Bohuzel moderni doba tolerovala az prilis dlouho "prostredniky" co vam neco domluvi a za nic nemuzou - viz financne poradenstvi, pojistovaci agenty, maklere a jakekoliv smelinarske domlouvani sluzeb a zbozi.

Je skoda, ze prime jednani - a prima odpovednost se jaksi uz nenosi.

VÚMV ale uz neexistuje. Byl premenen v ceskou pobocku TÜV.

Proboha, kdo napsal ten nesmysl "[d]osud, aby byl ovladač uznán jako vyhovující, stačilo, že během testování nezpůsobil katastrofální havárii systému vedoucí k BSOD"? To ty zprávičky nikdo ani elementárně nekontroluje?

Abych to uvedl na pravou míru. Součástí WHQL certifikace jsou testy pomocí Windows Hardware Lab Kit. V dokumentaci najdete, co se konkrétně testuje. Například u grafické karty je mezi testy validace memory managementu, chování scheduleru, preempce, TDR (Timeout Detection & Recovery), atd. Celkem jde o 2814 testů, včetně renderování s kontrolou shody výsledných bitmap proti referenčním, a desítek stress testů s trváním od desítek minut po hodiny.
https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/device-graphics-tests

A ano, ty testy se vyvíjejí a přidávají se nové. Například ke 24.12.2022 těch testů grafické karty bylo "jen" 1902.
https://web.archive.org/web/20221224153618/https://learn.microsoft.com/en-us/windows-hardware/test/hlk/testref/device-graphics-tests

To co Robin Seilera Ian LeGrow sdělili světu se týkalo mimo jiné sbírání více dat o chování driverů v telemetrii (nejen BSOD, ale i stabilita, výkon, dopad na teploty), dalších testů, odstraňování starých a špatných driverů z Windows Update katalogu, update architektury některých driverů, lepší analýza pádu driveru po odeslání hlášení z klientského systému, důkladnější ověření identity autorů driveru atd.

Když jsme u toho, má někdo informace o tom, jak probíhají obdobné testy a sběr dat o reálném chování driverů u jiných platforem? Třeba jaká je metodika pro testování driverů zahrnutých do linuxového kernelu, a jak distra sbírají, analyzují a dále zpracovávají informace o pádech systémů? Celkem by mě zajímalo srovnání s tím, co dělá Microsoft. Berte to jako námět na článek.

Jsou to tvrzení citovaná z těch článků na PCW a WinLatest.

OK, našel jsem ten nesmysl v linkovaném článku na windowslatest.com:
"For decades, the benchmark for driver quality was shockingly low. Microsoft relied almost entirely on Windows Error Reporting (WER) telemetry and crash dump files to evaluate whether an original equipment manufacturer (OEM) had delivered a good product."

Což je naprostý nesmysl. Driver NEJPRVE prošel plným WHQL testováním, a POTÉ se pomocí telemetrie sbírala data o tom, jestli v reálném světě nezpůsobuje problémy se stabilitou (i to až od WinXP/Vista). Jenže autor Abhijith M B asi nevěděl o čem je řeč, takže si z toho vybral jen tu druhou část, kterou přetavil do toho nesmyslu výše.

Problém je v tom, že internet je veliký a plný nesmyslů. Přitom i prostý dotaz na Google mezi prvními linky vyhodí odkaz na Wikipedii na WHQL Testing, a tam je See also link na article o Windows Hardware Lab Kit.
https://en.wikipedia.org/wiki/WHQL_Testing

Kdyz se to tak uzasne testuje, tak by me zajimalo, japa to tak prijde, ze treba aktuelne HP stahlo biosy, uplne vsechny, ktery uz byly publikovany v podobe driveru pres windows update, (a jejihz obsahem jsou ty veledulezity 23 klice), protoze kdyz se to flashlo, tak ti nebozaci ktery dopustili bitlocker ... uz nemeli ani system ani data.

Jinak receno, netestuje se vubec nic. Jen zvasty.

Máte nějaký zdroj k tomuto incidentu? Já vím o tom, že upgrade BIOSu může způsobit vyhodnocení situace jako změny HW, což znamená, že uživatel musí vložit BitLocker Key. Stalo se mi to před mnoha lety, když byl BitLocker ještě výjimkou. Systémy s Windows edice Pro přicházejí s BitLockerem vypnutým, a když ho uživatel zapne, tak je mu velmi důkladně řečeno, že si má BitLocker Key schovat na bezpečném místě, samozřejmě mimo ten šifrovaný systém. Pokud klíč nemá, tak může po havárii HW nebo SW skončit se zašifrovanou krabicí, ke které nemá klíč. Edice Home místo toho používají Device Encryption, což je BitLocker který ukládá klíč online do Microsoft Accountu, odkud si uživatel může snadno vytáhnout. Hint: tohle se někdy může hodit :)
https://account.microsoft.com/devices/recoverykey

Jo a našel jsem, že některé stroje od HP mohou při aplikaci nových 23 keys spadnout do reboot loopu, a k tomu celkem triviální řešení.
https://support.hp.com/ee-en/document/ish_14914515-14914500-16

Pokud jde o testování BIOSu, tak se testuje System.Fundamen­tals.* a System.Client, což zahrnuje spoustu věcí spojených s BIOSem, včetně některých které řeší update firmwaru. Jenže Windows update je distribuční mechanismus, a mohou přes něj v jistých případech jet i aktualizace výrobců HW, které neprošly skrz WHQL.

To "Jinak receno, netestuje se vubec nic. Jen zvasty." je... Unáhlené zobecnění, nebo žvást? Nechť si laskavý čtenář sám vybere :)

Hash bios / firmware je soucast TPM measures. Tzn. jeho upgrade z principu vzdy zpusobi to, ze to pujde do recovery modu.

Ono to bude složitější. Pokud BitLocker používá TPM (což je u Win11 snad už povinné), tak se používají Platform Configuration Registers. Za běžných okolností jde o PCR7 (a 11), který se s updatem firmwaru typicky nemění. Pokud nelze použít PCR7 (PCR7 binding not possible), tak se použijí PCRs 0, 2, 4 a 11, což zahrnuje verzi firmwaru, option ROMs a nevím co ještě. To nejspíš update firmwaru nepřežije bez vložení recovery key. A u legacy strojů s BIOSem se údajně používá jen PCR 0. Ale k tomu přidejme, že firmware update tool může (a měl by) zakázat BitLocket do následujícího bootu. Po bootu se opět aktivuje, a tím se provede resealment. Pokud je to takto provedeno, mělo by se to obejít bez vkládání Recovery Key. Uff, slušný guláš.

https://www.reddit.com/r/SCCM/comments/1sss33g/hp_bios_updates_april_softpaq_versions_got_removed

Osobne tu mam napriklad +- 20ks identickych 840 G8 ... a nektere maji neexistujici ... 1.24.01

HP aktuelne nabizi ...

01.23.00 Rev.A
63.7 MB
Jan 9, 2026

A jediny zpusob jak se to na ty notesy mohlo dostat neni ani od HP, protoze ty HP nesmysly na nich nejsou, je to z MS update. Nastesti ani jeden z tech notesu bitlocker nema, a nikdy mit nebude!

Zjevne to nekdo pred zverejnenim peclive kontroloval ... pokud neco totiz po instalaci nefunguje vubec, tak neprobehla ani naprosto zadna kontrola. Nebavime se o nejaky okrajovy exatr uber specielni konfiguraci kterou ma jeden z miliardy ze? Bavime se o necem, co se lidem snazi soudruzi z MS natlacit i proti jejich vuli.

A jak se krasne ukazuje kazdy mesic uz nekolik let, veci to tak leda asolutne rozbiji.

“Systémy s Windows edice Pro přicházejí s BitLockerem vypnutým”

Tady by se hodilo upřesnění. U vydání Windows Pro je BitLocker ve výchozím stavu vypnutý, pokud se nepřihlásíte microsoftím účtem. Pokud při počátečním nastavení počítače vytvoříte uživatele přihlášením k účtu MS, BitLocker se zapne.

P.S. "sbírání více dat o chování driverů v telemetrii"

Jako že v TÉ telemetrii, která je pomalu největším zlem na planetě, je vydávána za bezuzdné špehování, a hromada lidí si ji powershelovými skripty porůznu postahovanými z internetu vypíná?

Ptám se pro kamaráda, nemá v té věci ještě úplně jasno (sarkasmus).

Jj, přesně v té telemetrii, která je takovou katastrofou, že umožňuje například vypouštět aktualizace ve vlnách, a zastavit je pokud systémy po její aplikaci mají problémy.

Z hlediska autora SW je telemetrie celkem zásadní věc, zvlášť pokud je SW široce rozšířený. Bez ní musí výrobce spoléhat na hlášení uživatelů na support, což v případě self-supported systémů nefunguje, nebo může pročítat vlákna na Redditu, ze kterých není jasné, jestli má problém pět uživatelů z miliardy (často z důvodů nesouvisejících s aktualizací), nebo třeba každý druhý. Z hlediska uživatele chápu obavu ze šmírování.

"Z hlediska uživatele chápu obavu ze šmírování."
To já bych klidně rozlišil telemetrii a šmírování. Jenomže ono je velké pokušení, když už ta data můžu mít, tak proč jich nemít víc a nevyužít je o něco lépe. Třeba taková kamera v obrazovkách v 1984, nebyla to také jen neškodná telemetrie, která měla například zjistit, jestli divák při povinné rozcvičce správně cvičí? :-)

Pokud jde o ovladače, potěšilo by mne, kdyby jednou fungující hardware (scanner od Canonu) po jedné takové aktualizaci Windows 10 nepřestal fungovat. Tehdy ještě pomohlo přeinstalovat původní ovladač, jenže po další aktualizaci už to nestačilo. Jakože už je čas, koupit si nový skener? Jenže proč, když ten stávající fungoval bezvadně? To měl Canon špatně napsané ovladače, takže je museli zablokovat?

Když ono se zdá, že rozlišovat mezi telemetrií a šmírováním je něco, o co ta nejhlasitější většina křiklounů nemá moc zájem. Navíc telemetrie - nebo třeba Microsoft Account - není problém, pokud a dokud funguje západní společnost. Přece nejde o Čínu, kde mají firmy povinnost pracovat v jakémkoliv trestním řízení a vyhovět jakémukoliv požadavku tajných služeb. Máme právní stát, nezávislé soudy... Jenže obojí, zvláště v USA, oslabuje. BTW u mobilních aplikací telemetrii v podstatě nikdo neřeší, a v jejím rámci se sbírá v podstatě každý klik uživatele v aplikaci.

S Canonem mám osobně špatnou zkušenost. Driver pro Windows 7 nefungoval ve Windows 8, ale výrobce jaksi polooficiálně vydal očesanou verzi driveru. Ten fungoval s chybami, ale ve Windows 10 už ani ten nešlo nainstalovat. Vůbec mi nevyhovuje, když výrobce vydává nové modely šíleným tempem, a ukončuje jejich podporu po pár letech takovým způsobem, že už nejsou ani drivery. Vzpomínám na podobné problémy s jiným HW, který nebudu jmenovat, a pro který jsme u nás z nějakých důvodů psali vlastní drivery (na základě dokumentace od výrobce). Než jsme driver napsali a otestovali, uplynulo cca půl roku. Výrobce v mezičase často model už zaříznul a přišel s novým.

"To já bych klidně rozlišil telemetrii a šmírování. Jenomže ono je velké pokušení, když už ta data můžu mít, tak proč jich nemít víc a nevyužít je o něco lépe."

Což je přesně to, čeho je plnej internet, a po čem za těch skoro 30 let nikdo nedokázal najít ani stopu. Buď je to schovaný naprosto dokonale za kvantovou teleportací nevyžadující přenos přes žádný rozhraní šmírovanýho stroje, nebo jsou všichni ti hledači naprosto neschopní.
Každý soudruh si může vybrat podle vlastního gusta a politické orientace.

A model ovladačů se tuším zrovna k 1:1.2026 měnil, protože dosavadní model umožňoval podstrčení kódu. Nemluvě o tom, že "dobrou zkušenost" s Canonem máš jako jeden z mála. Jejich lumpárny kolem inkoustu a falešnýho hlášení zničení tiskový hlavy krátce po záruce jsou dneska už doslova legendární.

24. 5. 2026, 21:52 editováno autorem komentáře

Microsoft mozna udelal chybu, ze BSOD mela uz od zacatku vypadat jinak. Pokud nastala chyba v ovladaci, melo tam byt jasne napsane ze "ovladac od fy X zpusobil chybu". V tu chvili by lidi jasne videli ze za to muze vyrobce notebooku a ne mrkvosoft, a vic by chapali ze si koupili spatny stroj.

Jak se pozná, že konkrétní kernel modul "způsobil chybu", když adresový prostor je sdílený a každý může zapsat kamkoliv?

Hm, jo, tady nevim. Nerozumim jak tyhle veci s ovladaci funguji. Ok, jestli to nejde, tak holt nezbyva nez ze to mrkvosoft vezme na sebe, a mel ovladace testovat mnohem lip, a resit to mnohem driv.

Odkud se veme nazev toho souboru v ty kupe hnoje kterou to vybleje na disk? Mnohem vetsi problem je ze se tim ty widle nechaj sejmout.

A jestli nekdo prave ovladace setrvale rozbiji, tak opet predevsim MS. Oni muzou za to, ze neexistuje zadnej zpusob jak zafixovat verzi ovladace.

Uz sem tu treba nekde psal, aktualne plati, ze vsechny realtekovy ovladace pro USB sitovky s verzi zacinajici 4mistnym cislem jsou nefunkcni. Sit se opakovane odpojuje, nerekne si o Ipcka ... a MS presne tyhle ovladace vsem vsude cpe. Jediny co s tim muzes delat je po kazdy aktualizaci ty nefunkcni ovladace odmazat a vymenit za funkcni ... uzasnej postup ze? Predevsim pro kazdyho bfu.

u USB síťovek s čipy realteku je hlavní problém v tom, že spousta OEM výrobců tam dává čipy s továrními nebo dokonce prázdnými identifikátory. je to známo už spoustu let a projevuje se to právě tak, že to nefunguje buď vůbec, nebo funguje vždycky jen jedna a víc různých kusů se detekuje jako ta první přidaná (klidně i několik různých verzí čipu), a pokud je jich současně připojeno víc, funguje buď jen jedna, nebo žádná; leckdy přestanou s novými verzemi ovladačů fungovat úplně všechny. a nikoli, není to chyba MS, ten ty USB síťovky nevyrábí, jen distribuuje ovladače dodané buď realtekem, nebo jednotlivými OEM.
v minulosti se to povedlo i Dellu u dokin, které nové stály klidně 10 tisíc (protože thunderbolt a PD až 200W). a většinou je velký problém ten síťový čip dostat do funkčního stavu, takže pak na dokině funguje třeba jen USB hub a HDMI výstup, někdy čtečka karet, a někdy třeba jen ten hub.
proto se snažím kupovat jen ASIXy nebo s realtekem nějakou prověřenou značku, kde se to neděje.

Pokud si nepremazate zasobnik a slapnete nekam vedle tak se to da poznat stejne jako na Linuxu.
V minulosti ale velkou cast BSOD zpusobovala chyba: "Prislo mi IRQ cislo xy a zadny ovladac se k nemu nehlasi".

22. 5. 2026, 13:28 editováno autorem komentáře

a to je chyba windows? jeden by čekal, že to je chyba ovladače, kterej při instalaci ten HW nakonfiguroval a nastavení vzápětí nebo náhodně při běhu zapomněl.

Důvodů, proč může kernelový driver způsobit BSOD, je řada. Pokud jde o paměť, tak jde nejčastěji o přístup na špatnou adresu, mimo adresní prostor kernelu. Ale je řada dalších důvodů. Například pool header / pool guard corruption. Při obsluze přerušení smí také driver používat jen subset API, a nemá přístup ke stránkované paměti, s tím že obojí se dá detekovat. Špatná rekurze může způsobit přetečení zásobníku. Atd., atd. Tady je poměrně bohatý seznam bug check codes.
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2

Ono to je v dumpech, ktere se pri BSOD vytvari...

Mno, v dumpech si to BFU neprecte a tudiz nepochopi ze za to nemuze mrkvosoft.

Jizliva poznamka, ze to meli udelat pred 20 lety, je jiste na miste. Ovsem v kontextu toho, ze linux je na tom obvykle s vydrzi na baterku a problemy s uspavanim hure, nez Wibdouzy to troch ztraci lesk ;-)

No nevim, problémy s výdrží baterie ve spánku se objevují od chvíle, kdy si Microsoft prosadil tu krokotinu jménem connected standby. A od té chvíle to ani na jednom z těch systémů nefunguje dobře, prakticky na ničem. Nicméně Linux mi narozdíl od Dellího notebooku s oficiálním systémem nezůstal po uspání běžet s větrákem puštěným na plno a mohutného vytápění místnosti teplem.

Mě se to nestává na Dellech ani na strojích od Lenovo. Komu se to stává, může zkusit workaround: nejprve odpojit notebook od napájení, a až poté zavřít víko.

Na Dellech se to deje uplne bezne (u nas na tom bezi cely korporat a zna to temer kazdy). Workaround ktery tady lidi pouzivaji je hibernace. Pokud chceme videt pohar poloplny, tak se da rict ze v zime je to vytapeni batohu vlastne feature :)

Tyjo, Laele, nemuzu si nez rypnout - vis ze jsem cekal ze zrovna tobe se ta chyba vyhne? Z meho okoli ji pozoroval kazdy s windowsama, i lidi v diskuzich tady na rootu uz ji x-krat probrali, ale tobe se vyhne. Tobe se tak vyhybaji vsechny mrkvosofti chyby, ze to hranici se zazrakem :)

22. 5. 2026, 14:00 editováno autorem komentáře

v tom vyhnutí není sám. mě se historicky stala jednou, slovy jednou. a pak ještě jednou kolegovi s lenovem. což už samo o sobě docela silně ukazuje na to, že problém je buď v ACPI (a pak by se to mělo dít doslova kždýmu a na čemkoli), nebo v ovladačích specifickejch pro hrardware. ale pak to nemůže bejt chyba windows.

Workaround jsem nezkoušel, ale stejně pochybuju, že naučím ženu to napřed odpojovat od napájení a pak až to vypínat... Takže holt se nezbývá asi než smířit s tím, že náklady za nevhodně vybraný systém v korporátu ponesu z vlastní kapsy :-)

Možná by pomohlo nastavit hibernaci jako akci při zavření víka, pokud hibernace funguje spolehlivě.
Bude to mít trochu pomalejší start, ale to jsem vyhodnotil jako přijatelnou cenu za vyšší spolehlivost.

23. 5. 2026, 06:52 editováno autorem komentáře

To nebude nevhodně vybraným systémem, ale problémem nějakého driveru nebo aplikace. A samozřejmě se to dá diagnostikovat.

powercfg /sleepstudy /output sleepstudy.html
powercfg /energy /output energy.html

Z výstupu by mělo být jasné, co je špatně. Nicméně v korporátu by tohle mělo řešit IT oddělení, ne uživatel. Zvláště pokud má problém větší počet uživatelů.

Jo, jak rikas, je to kokotina, a vzdycky musim manzelcin firemni notebook vytahnout ze zasuvky, aby konecne prestal hucet a topit pres zavrene viko.