PC-HELP.CZ

To co vám teď popíšu, se mi ještě nestalo a nerozumím tomu. Pokud mi někdo z vás poskytne radu, která to vyřeší, je borec. O co jde:
Když potřebuji zazipovat nějaké soubory, tak si je v daném adresáři označím, kliknu na ně pravou myší, vyberu WinZIP a pak Add to ZIP file. Spustí se WinZIP, napíšu název nového archivu a jeho umístění, potvrdím a archiv ZIP se vytvoří. Takto to bylo až donedávna (asi dva týdny pozpátku), dnes už ne. Dnes se to chová tak, že po spuštění WinZIPu se mi nezobrazí nabídka na zadání jména archivu, ale rovnou to skočí do BSOD. Opakoval jsem to třikrát po sobě a vždy na stejném místě BSOD. Pokud však otevřu nejprve WinZIP a z jeho prostředí nastavím stejné soubory k archivaci, tak mi to proběhne bez problémů!(?). V BSOD se vypisuje chyba 0x000000C4, která je však zavádějící, protože na stránkách Microsoftu je to vysvětleno chybným ovladačem pro USB skenery HP (což nemám připojené), ale také i jiným (?) softwarem. Prolezl jsem spoustu počítačových fór, googlil jsem jak strhaný, ale kloudnou odpověď jsem nenašel. Reinstaloval jsem WinZIP a nepomohlo to. V počítači nemám žádné breberky, volného místa mám do aleluja. Mám podezření, že mi to začalo dělat po aktualizacích z minulého měsíce, ale nevím už teď přesně, zda to bylo před anebo po aktualizacích. Dnes proběhly další aktualizace, ale příčina stejná (úmyslně jsem to zkoušel). Mám Win7 Ultimate 32-bit řádně aktivované. V posledních týdnech jsem neinstaloval ani neaktualizoval žádný ovladač, žádný nový HW. K dispozici mám sice zálohu z 6.9. (tzn. jeden den před zářijovými aktualizacemi), ale to by byla až krajní varianta. Setkal jste se někdo s něčím podobným? Potřebuji zjistit příčinu. Díky za podnětné nápady.

K tomu aby se někdo mohl stát borcem, nejprve potřebujeme nějaké detailnější informace.
Zde bude třeba minimálně minidump ze složky Windows\Minidump. Všechny soubory které tam najdeš, upni na http://www.leteckaposta.cz.
Chyba STOP 0x000000C4 (DRIVER_VERIFIER_DETECTED_VIOLATION) znamená, že máš spuštěný Driver Verifier, který za běhu systému kontroluje různé operace, které provádějí ovladače a v tomto případě narazil na ovladač, jehož rutina dělá nějakou obecnou chybu. Který ovladač to je, zjistím z minidumpu.
Pravděpodobně to bude nějaký ovladač filtru souborového systému.

Nějaké obecné rady ohledně BSOD jsou většinou k ničemu, jelikož jeden druh chyby může nastat z tisíce různých důvodů. Je třeba se alespoň podívat na zásobník jádra, na hodnoty registrů CPU v době pádu, na paměťové fondy, nevyřízené IRP pakety atd. Někdy je k odhalení problému třeba plného výpisu paměti jádra, jelikož ,minimum informací zapsaných minidumpu prostě nestačí.

Ano, tento verifier mám spuštěný, minidump jsem si rozkódoval, protože to používám u kámošů. Pravda - toto jsem zapoměl napsat. Takže BlueScreenView mi hlásí, že chybu způsobil ovladač ntoskrnl.exe (což vypadá na reinstal systému) a textový popis chyby DRIVER_VERIFIER_DETECTED_VIOLATION.

S tvým dovolením bych si ten minidump osobně otevřel v debuggeru, neboť obsahuje mnohem více důležitých informací, než zobrazí BlueScreenView. Už jen první ze chtyř parametrů předávaný v době havárie rutině KeBugCheckEx, která mimo jiné zobrazuje BSOD, v tomto případě velmi upřesňuje typ chyby.
Jestli je těch nimidumpů více, upni je všechny.

Jen pro informaci ntoskrnl.exe je image soubor jádra operačního systému a to z 99,9% nechybuje.

OK, je tam. A díky.

No, je to programátorská chyba v ovladači ehdrv.sys (Eset)
Tento ovladač volá systémovou službu NtOpenFile prostřednictvím rutiny ZwOpenFile a jako parametr jí předává adresu paměti (zřejmě datového bufferu), která leží v oblasti user mode paměťového prostoru. To se považuje za oslabení bezpečnosti operačního systému.
Driver Verifier tedy toto zachytí jako chybu a zastaví operační systém. Pokud v nastavení Verifieru vyloučíš ovladač ehdrv.sys ze seznamu kontrolovaných ovladačů, s největší pravděpodobností se BSOD přestane objevovat.
Pak můžeš informovat vývojáře Esetu, že by si to měli dát dopořádku.

Děkuji, fakt jsi borec. Akorát nevím, zda bych to měl ESETu napsat. To víš - nedotknutelný programátor, renomovaná firma, cizí země ...
Ale tu výjimku si tam buď doplním, anebo ten verifier deaktivuji. Ještě jednou díky.

Prostě jim pošli ten minidump a napiš, že nástroj Verifier v jejich ovladači ehdrv.sys zachytil chybu při volání ZwOpenFile.
Jo a Verifier deaktivuj, docela dost to zpomaluje systém. Spouští se pouze v případě problémů.

OK, přesvědčil jsi mě. Pošlu jim to a uvidím, jakým způsobem mi vynadají, že se jim pletu do řemesla. Pokud bude nějaká odezva, tak ji tady uvedu, proto příspěvek ještě neuzavírám.

Určitě dej vědět. V nejhorším případě mi Eset nasadí psí hlavu
Ono se to totiž za některých okolností použít dá, není to ale dobré řešení.
Většinou se data kopírují z bufferu ležícím v user mode adresovém prostoru do pomocného bufferu v kernel mode prostoru a naopak.
Verifier to při bezpečnostní kontrole každopádně považuje za chybu, což je dobře, protože při volání Zw rutin v režimu jádra systém neprovádí kontroly parametrů. Pak jsou zachyceny případné programátorovy překlepy.

Takže Driver Verifier jsem deaktivoval a hned jsem vyzkoušel stejnou operaci v WinZipu a tentokráte to proběhlo v pořádku. Tu zprávu jsem ESETu odeslal i s přílohou dumpu, dostal jsem automatickou odpověď o přijetí zprávy, takže uvidím, co bude dál. Jednou jsem jim již psal ohledě dotazu na odinstalaci jejich produktu (uváděl jsem to i v tomto fóru) a v odpovědi byli docela rychlí - asi za hodinku jsem měl odpověď. Takže uvidíme teď ...

(Protože příspěvek doplňuji po dlouhé době, tak toto píšu jako samostatnou odpověď.)

Protože mi přátelé ze Slovenska dosud žádnou odpověď nezaslali, rozhodl jsem se k radikálnímu kroku - jejich produkt jsem odinstaloval a nainstaloval Aviru (na kterou mám půlroční legální licenci). A jako naschvál, při odinstalování ESETu se systém opět dostal do BSOD! Možná jsem udělal dobře, možná ne, uvidím časem. Akorát doufám, že stejná BSOD se mi neobjeví příště. To by pak byl v tom ESET nevinně.