Det finns många anledningar till BSOD, men i den här artikeln kommer vi att överväga ett problem som uppstår på grund av en konflikt mellan installerade drivrutiner. Det kan bara vara installerad drivrutin eller skadad. Att fixa BSOD-problemet kan vara ganska enkelt om det bara är ett drivrutinsproblem och du vet vilken det är. Du kan installera om drivrutinen eller uppdatera den, gå tillbaka till gammal version eller bli av med programmet som installerade drivrutinen på din dator genom att fysiskt ta bort det. Problemet är att det inte alltid är möjligt att ta reda på vilken förare som är "boven", även efter att ha studerat all data från blåskärm. Men det finns en väg ut. Om du inte har mycket kunskap och erfarenhet, men det finns ett behov av att kontrollera drivrutiner, kan du använda det speciella verifieringsverktyget Verifier.exe som är inbyggt i operativsystemet för sådana fall. Den befintliga beskrivningen i Microsofts kunskapsbas presenteras med hjälp av komplexa tekniska termer som inte alltid är kända ens för erfarna användare. Därför presenterar den här artikeln en kort lista över manipulationer som krävs för att slutföra uppgiften. Kör drivrutinsverifieraren Efter att ha öppnat "Start"-menyn, skriv in frågan "Kör" i sökfältet och klicka på resultatet som visas högst upp. I fönstret som visas måste du ange kommandot " bekräftare” (utan citattecken) och bekräfta genom att klicka på ”Ok”.
Dialogrutan File Verification Manager visas. I den första dialogrutan måste du välja objektet "Skapa icke-standardiserade parametrar (för programkod)". Klicka på "Nästa".
Nästa steg är att välja individuella parametrar för att testa drivrutinen. För att göra detta kommer vi att utföra följande manipulationer: "Välj individuella parametrar från full lista" - "Ytterligare".
När du har slutfört stegen bör du få en dialogruta med en lista över testparametrar. Markera alla rutorna utom "Simulera resursbrist". Klicka på Nästa.
Det sista steget i denna del är att ge avsändaren ett kommando till automatiskt val osignerade förare. Välj "Välj automatiskt osignerade drivrutiner." Klicka på Nästa.
Det händer att chefen inte upptäckte osignerade drivrutiner. Använd sedan den selektiva förarkontrollfunktionen, som kommer att diskuteras senare. Arbeta med osignerade förare Om osignerade drivrutiner upptäcks kommer chefen att visa dem i form av en lista.
Dessa kan vara enhetsdrivrutiner eller programdrivrutiner. När osignerade drivrutiner har upptäckts behöver du inte stänga managern och klicka på knappen "Slutför". Låt oss först leta efter uppdaterade drivrutiner. Sök efter uppdaterade drivrutiner För att kontrollera måste du utföra följande steg: 1. Programdrivrutinen finns i listan. I det här fallet måste du besöka applikationstillverkarens webbplats för att söka efter uppdaterade drivrutiner. Om uppdaterad version drivrutinen saknas, försök att avinstallera programmet. Var inte rädd, du kan alltid installera den igen senare. Men detta kommer att vara en utmärkt kontroll: om kritiska fel inte längre uppstår, var orsaken den här applikationen. 2. Listan innehåller en enhetsdrivrutin. I det här fallet (om du har Windows Vista), starta uppdateringscentret och aktivera sökningen efter en ny drivrutinsfunktion. Om en ny drivrutin hittas, kör installationen. 3. Om uppdateringscentret inte hittade en ny drivrutin, titta på tillverkarens webbplats, det är troligt att den nya drivrutinen kommer att finnas där. Efter att ha uppdaterat drivrutinen eller applikationen, stäng skanningshanteraren (Avbryt-knappen), starta om och vänta tills operativsystemet laddas. Om kritiska fel har upphört har uppdatering av drivrutiner eller applikationer eliminerat dem. Ta bort drivrutiner Om det inte går att hitta nya drivrutiner kan du försöka ta bort drivrutinen. UPPMÄRKSAMHET! Om du tar bort drivrutinen slutar enheten att fungera. Efter omstart kommer operativsystemet att försöka installera drivrutinen från lagringen, men det är inte ett faktum att standarddrivrutinen duger. Om du inte är säker på behovet av att ta bort någon drivrutin bör du inte ta bort den. Starta Enhetshanteraren genom att göra följande: Start – Kör – devmgmt.msc- Stiga på. Att ha hittat nödvändig enhet, högerklicka på den och klicka på Egenskaper – Drivrutin – Avinstallera. Söker efter osignerade drivrutiner UPPMÄRKSAMHET! Efter att ha kontrollerat för osignerade drivrutiner kan det hända att systemet inte startar. Nedan följer en beskrivning av de åtgärder som vidtagits i denna situation. Om du inte är säker på att du vill ta bort drivrutinen och ändå fortsätta med skanningen, klicka på knappen Slutför i skanningshanteraren. När du ombeds välja en fysisk disk, välj den som operativsystemet är installerat på och klicka sedan på Slutför igen. Du kommer att se ett meddelande med texten: "Du måste starta om din dator för att ändringarna ska träda i kraft." Stäng tyst alla applikationer och starta om. Om systemet inte startar och en blå skärm visas med en beskrivning av felet, betyder det drivrutinen besvärlig hittades. När du har startat om datorn igen, innan du laddar operativsystemet, klicka på F8 verifier.exe/resetverifier.exe
Anpassad förarkontroll Starta om Driver Verifier Manager och utför de föregående stegen tills den punkt som visas nedan.
Välj "Välj förarens namn från listan". Nästa steg är fönstret för att välja drivrutiner att kontrollera. Du bör inte välja alla drivrutiner på en gång, eftersom operativsystemet kommer att reservera en ganska stor mängd resurser för skanning och kommer att spendera mycket tid på det. Det är bättre att upprepa verifieringsproceduren flera gånger, men med ett litet antal förare. Detta kommer att spara tid och resurser. Först av allt, låt oss kontrollera drivrutiner som nyligen har uppdaterats eller helt enkelt problematiska drivrutiner (drivrutin antivirusprogram, brandvägg, virtuell disk eller bilar). Låt nästa steg vara att kontrollera drivrutiner som inte är producerade av Microsoft. Kontrollera de återstående drivrutinerna 10-15 åt gången.
Välj nödvändiga förare och klicka på knappen "Klar". När du ombeds välja en fysisk disk, välj den som operativsystemet är installerat på och klicka sedan på Slutför igen. Ett meddelande visas som ber dig att starta om. Starta om din dator. Om en blå skärm med ett felmeddelande visas efter en omstart betyder det att drivrutinen som orsakade problemet har hittats. När du har startat om datorn igen, innan du laddar operativsystemet, klicka på F8 och välj "Kör in säkert läge" När du är inloggad klickar du på Start-knappen och skriver Kör/Sök verifier.exe/reset. Om inga problem uppstod och systemet startade i standardläge, orsakar inte osignerade drivrutiner problem och du måste kontrollera andra drivrutiner. Kör Driver Verifier Manager igen ( verifier.exe) och välj "Visa information om för närvarande verifierade drivrutiner."
Upprepa skanningen för alla återstående drivrutiner. Avslutar förarverifiering Om en kontroll av alla drivrutiner inte avslöjar orsakerna till kritiska fel, är problemet troligen inte med drivrutinerna. Problemet kanske inte är programvaran, utan hårdvaran på din dator. Troligtvis är dessa problem med hårddisken eller RAM-minnet. Det kan också vara så att strömförsörjningen inte har tillräckligt med ström för att säkerställa driften av alla enheter eller något annat problem i hårdvaran som inte kan fastställas genom att kontrollera drivrutinerna. Diagnostisera RAM och HDD.

En felaktig drivrutin kan orsaka många problem i din dator. Det främsta tecknet på att din dator har en felaktig drivrutin är en blå skärm av död, som ofta orsakas av att drivrutinen är inaktiverad.

I den här artikeln kommer vi att berätta hur du kan hitta en felaktig drivrutin och sedan uppdatera den eller helt ta bort den.

Ibland meddelar Windows användaren att en av drivrutinerna har misslyckats. Det händer dock att systemet inte kan upptäcka vad problemet är, så det visar inga felmeddelanden, varför det fungerar långsammare eller inte som krävs. I detta fall Driver Verification Manager(Driver Verifier) ​​skapar ytterligare belastning på systemdrivrutiner och försöker därigenom orsaka en krasch. Om en av drivrutinerna misslyckas, då Driver Verification Manager kommer att rapportera problemet med en blå skärm.

Varning

Innan användning Driver Verification Manager Observera att verktyget kan begränsa dig från att använda din egen dator. Eftersom den Driver Verification Manager utlöser en blå skärm av död när den upptäcker en felaktig drivrutin, detta kan orsaka stora problem vid uppstart av Windows.

Om du inte har ett sätt att komma in i Windows för att inaktivera drivrutinstestning, kommer datorn att köras i en "boot -> load -> crash" loop som är ganska svår att ta sig ur. Funktionen för automatisk reparation är ett av få alternativ för att få åtkomst till Windows, men det är bättre att undvika denna situation.

Innan du använder Driver Verifier, se till att du har minst en av följande nödutgångar:

• Du kan gå in i säkert läge. Gå in i felsäkert läge innan du startar Windows start görs vanligtvis genom att trycka på F8 upprepade gånger medan datorn startar. Men nya datorer startar upp så snabbt att du helt enkelt inte hinner trycka på F8 vid rätt tidpunkt.
• Har du skapat en systemåterställningspunkt före användning? Driver Verification Manager. Det är också lämpligt att ha en installation Windows disk så att du kan återställa din dator till fabriksinställningarna.

Hur man kör Driver Verifier Manager

Innan du börjar bruksanvisningen Driver Verification Manager, se till att du läser avsnittet "Varning" ovan. Den säger hur man undviker att Windows laddas i oändlighet.

När du är hundra procent säker på att du har en nödutgångsplan klickar du på " Windows-tangent + R" och gå in cmd i dialogrutan Kör", Klicka sedan " OK».

I kommandofönstret anger du:

bekräftare

I popup-fönstret väljer du " Skapa icke-standardparametrar (för programkod)", Klicka sedan " Ytterligare».

Du kommer att se en lista över alla tester du kan köra för att kontrollera dina drivrutiner. Välj alla tester från listan, bortsett från"Simulera slumpmässig resursbrist" och "Ytterligare DDI-efterlevnadskontroll", klicka sedan på " Ytterligare».

På nästa skärm väljer du " Väljaförarnamn från listan" och tryck " Ytterligare».

Här kan du välja vilka drivrutiner du vill testa. Om du inte vet vilken drivrutin som är felaktig, välj alla utom Microsoft eftersom de oftast fungerar utan fel.

När du trycker på " Redo" kommer Windows att uppmana dig att starta om din dator. Fortsätt att använda den som vanligt när datorn har slagits på. Om du får en blå skärm, var uppmärksam på felmeddelandet och starta om datorn.

När du har identifierat den felaktiga drivrutinen kan du inaktivera Driver Verification Manager ett av två sätt. Du kan öppna kommandotolken igen, ange kommandot bekräftare, och välj " Ta bort befintliga inställningar».

Du kan också öppna en kommandotolk och skriva:

Verifier /bootmode resetonbootfail

När du har inaktiverat Driver Verifier Manager, starta om din dator. Om datorn inte slås på, använd en av nödutgångarna som vi diskuterade i avsnittet "Varning".

Slutsats

Om du tror att en av drivrutinerna är felaktig, men inte kan lista ut vilken, då Driver Verification Manager kommer att vara en stor hjälpare.

Du bör dock vara beredd på möjligheten att datorn inte kommer att kunna slås på efter att du har testat drivrutinerna, så överväg att göra en säkerhetskopiering med nödsituation, till exempel, gå in i felsäkert läge eller kör en Windows-återställningspunkt.

Har du någonsin haft problem med drivrutiner på din dator? Hur lyckades du hitta den felaktiga föraren? Berätta för oss i kommentarerna nedan!

Verktyget Driver Verifier (verifier.exe) är utformat för att analysera problematiska drivrutiner när analys av minnesdumpar efter en BSOD inte tillåter att hitta den problematiska drivrutinen. Driver Verifier är en "livsräddare" i de mest problematiska situationerna.

Med Driver Verifier kan du:

förarstresstest (tillstånd med resursbrist simuleras);

kontroll av buffertspill;

kontroll över fel som uppstår på grund av felaktig drift vid en given IRQL;

I/O-felanalys;

upptäckt av dödlägessituationer osv.

Verktyget Driver Verifier är mycket användbart när:

administratören (användaren) har misstankar om att just denna drivrutin får systemet att krascha och han vill ytterligare kontrollera om så verkligen är fallet;

förarutvecklare vill testa sin drivrutin;

När man analyserar en dumpning efter en BSOD är det omöjligt att hitta den problematiska drivrutinen.

Ett av de svåraste fallen av att analysera minnesdumpar är när en förare av misstag skriver över data före eller efter slutet av bufferten den tilldelade. I sådana fall uppstår fel i OS-kärnan (till exempel visar analys av en dump efter en BSOD att felet inträffade i ntoskrnl.exe).

Låt oss se liknande fall på ett specifikt exempel. Med hjälp av NotMyfault-verktyget orsakar vi BSOD - "buffertspill".

Resultatet av dumpningsanalys med hjälp av windbg bifogas nedan.

Enligt dumpningsanalysen får vi:

1. Arg1: 00000007, försök att frigöra pool som redan var frigjord (ett försök gjordes att släppa en redan frigjord pool)

2. IMAGE_NAME: ntkrpamp.exe (kärnan i själva systemet har med detta att göra)

Det är med sådana fel som verifieraren kommer till undsättning.

Starta verifierare.

Välj "Skapa icke-standardparametrar". Välj sedan "Välj parametrar från listan".

Välj allt utom "Simulera resursbrist".

Välj sedan "Välj ej laddade drivrutiner för den här listan" och ange sökvägen till myfault.sys-drivrutinen, som finns i samma katalog som NotMyfault.exe-programmet.

Markera sedan drivrutinen och klicka på "Slutför". Efter detta måste vi starta om datorn.

Vi utför samma handlingar som i början. Kör NotMyfault.exe, välj "Buffer overflow" och klicka på "Crash". Som du märkte kanske en krasch inte inträffar omedelbart, eftersom vem och när som ska försöka arbeta med detta minne är okänt i förväg. Som du kan se på bilden nedan, tack vare verifieraren, kan systemet identifiera den problematiska drivrutinen.

Jag kommer att ge en analys med!analyze –v i windbg.exe av en minnesdump efter en BSOD.

Verifieringsprogrammet gör det så att drivrutinen som testas, istället för vanligt minne tillgängligt i kärnan, använder en speciell pool som är utformad för att upptäcka ett sådant fel. Tack vare detta kan du hitta drivrutinen som orsakar BSOD.

Om vi ​​tittar på resultatet av analysen ser vi följande.

1. DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) – detta är ett av felen som genereras av verifieraren

2. IMAGE_NAME: myfault.sys – drivrutinen som orsakade problemet.

Således, om analys av en minnesdump efter en BSOD inte tillåter dig att hitta "den skyldige drivrutinen", använd verifier.exe-programmet (installera alla kontroller, utom för brist på minne).

Det enklaste sättet att använda Driver Verifier (verifier.exe) är att köra den med följande parametrar:

verifier /standard /drivrutinsfilnamn

Verktyg Förare Bekräftare ingår i alla Windows-versioner, från och med Windows XP, och låter dig kontrollera drivrutiner, identifiera problematiska drivrutiner som orsakar blåskärm (BSOD- Blue Screen of Death) och spela in detaljerad information om den problematiska drivrutinen i en minnesdump för vidare analys. Verktyget utsätter de kontrollerade drivrutinerna för olika " stresstester", simulerar olika extrema förhållanden: brist på minne, I/O-kontroll, IRQL, dödläge, DMA-kontroller, IRP, etc. Dvs. situationer som sällan inträffar på produktiva system simuleras och förarens beteende övervakas. Syftet med verktyget är att identifiera situationer där en förare kan leda till en systemkrasch med BSOD.

Den körbara filen för Driver Verifier-verktyget anropas Bekräftare.ex och finns i katalogen %windir%\system32. Det finns två alternativ för att använda verktyget: från kommandoraden eller att använda GUI.

För att aktivera drivrutinsverifieringsläget i Windows 8, starta drivrutinsverifieringsverktyget genom att skriva

Bekräftare

Välj från uppgiftslistan Skapa anpassade inställningar (för kodutvecklare) och tryck Nästa.

Se till att alternativen är valda Standardinställningar, Framtvinga väntande I/O-förfrågningar Och IRP-loggning. Klick Nästa.

Välj nästa.

Sortera innehållet i tabellen genom att klicka på kolumnrubriken "Provider" och välj de du vill testa från listan över drivrutiner. I vårt exempel kommer vi att köra en kontroll för alla drivrutiner som inte är utvecklade av MicrosoftFöretag. Vi valde drivrutinerna: e1g6032e.sys (Intel) och lsi_sas.sys (LSI).

Notera. Tillgänglighet för drivrutiner digital signatur Microsoft indikerar att drivrutinen har testats på ett visst sätt för stabilitet och dess kod har inte ändrats sedan dess. Det är därför det inte rekommenderas eller används.

Allt du behöver göra är att klicka Avsluta och ett informationsfönster visas som säger att du måste starta om systemet för att ändringarna ska träda i kraft.

Råd. Förarverifieringsläge kan också aktiveras från kommandorad. Till exempel att köra Driver Verifier med standardinställningar för drivrutinen myPCDriver.sys kommer kommandot att se ut så här: verifier /standard /driver myPCDriver.sys

Efter omstarten startar systemet till drivrutinsverifieringsläge. Driver Verifier fungerar i bakgrund, utför olika typer av testning av utvalda drivrutiner för att identifiera fel. Använd din dator som vanligt och vänta på att BSOD ska visas. Om du vet vilka åtgärder som tidigare fick systemet att krascha, upprepa dem. Om en BSOD inträffar måste du kopiera minnesdumpfilen (som standard sparas den i katalogen C:\Windows\Minidump\*.dmp) och analysera den med Windbg eller motsvarande.

Viktig! Efter att ha aktiverat drivrutinsfelsökningsläget med Driver Verifier kommer detta läge att fungera tills det tvångsinaktiveras.

Om problemet inte återkommer inom 1-2 dagar kan vi med en viss grad av säkerhet dra slutsatsen att drivrutinerna som testas inte är orsaken till systemkraschen och att skanningsläget för dem kan inaktiveras.

Råd. Använda validatorn Windows-drivrutiner saktar ner Windows avsevärt, så det rekommenderas inte att ständigt arbeta i det här läget.

Du kan inaktivera Driver Verifier från kommandoraden:

Verifierare/återställ

Eller från det grafiska gränssnittet genom att välja Ta bort befintliga inställningar.

Om du inte kan logga in på systemet i normalt läge kan du inaktivera felsökningsläget från säkert läge.

Om systemet inte startar i felsäkert läge, försök att ta bort följande registernycklar genom att starta från en startdiskett:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

Du kan kontrollera den aktuella statusen för Driver Verifier-verktyget så här.

Vi varnar dig för att alla experiment med förare är farliga och kan skada systemet. Det är bättre att göra en säkerhetskopia av systemet i förväg och sedan inte korsa tummarna genom att ta bort en annan misstänkt drivrutin från Windows.

Och så fort de inte skäller Windows från Microsoft, kallar stackaren samtidigt långsam, glitchy och till och med instabil. Men ingen har bråttom att ge upp det, och i allmänhet är det osannolikt att de någonsin kommer att ge upp det. Därför, istället för att skälla på dåliga utvecklare och starta meningslösa lågor, skulle det vara bra att ta reda på varför, i själva verket, systemet är buggigt? Jag ska berätta en liten hemlighet. I de ökända skärmarna av död och instabilt arbete Windows i de allra flesta fall är det tredje parts drivrutiner som är skyldiga, och själva operativsystemet har absolut ingenting med det att göra. Nu kommer vi att berätta hur du upptäcker sådana drivrutiner och tar bort dem från systemet.

Drivrutinsdesigndefekter kan variera från krascher till Blue Screen of Death ( BSOD– Blue Screen of Death) och till nedgången av datorn och det konstiga beteendet hos vissa applikationsapplikationer som är helt orelaterade till föraren.

The Blue Screen of Death är anmärkningsvärt (utan någon ironi!) genom att det tydligt signalerar närvaron av ett allvarligt problem och ger ett tips om var man ska gräva. Ofta (men inte alltid) visas namnet på den "förolämpande" föraren direkt i det övre högra hörnet av dödens blå skärm. Men det kanske inte finns där, eller ännu värre, namnet på en helt orelaterade förare kan finnas där.

Till exempel en ganska vanlig grafikkortsdrivrutin Matrox G450 tenderar att förstöra grundläggande strukturer grafiskt delsystem Windows 2000 , vilket resulterar i att BSOD visar namnet på systemdrivrutinen win32k.sys, som implementerar en betydande del av USER- och GDI-funktionerna och som naturligtvis inte har något med det att göra. Så att tolka den blå skärmen av dödsläsningar är magi, intuition, vetenskap och konst - lite av allt.

Förutom drivrutinsfel kan blå skärmar av dödsfall också orsakas av hårdvarufel, till exempel en överklockad processor, felaktigt RAM-minne eller en sned kontroller. hårddisk, PCI-kort inte helt insatt i kortplatsen, lös kontakt i en av kontakterna, dålig strömförsörjning, svullen elektrolytkondensator på moderkort. Och den sistnämnda surrar av olika anledningar: på grund av överhettning från en närliggande processor, en brist på keramiska kondensatorer "inte rapporterad" av tillverkaren (som ett resultat av vilket RF-komponenten går genom elektrolyten och värmer upp den kraftigt), och slutligen , på grund av läckage av nyckeltransistorer i enhetens stabilisator. Därför måste vi, innan vi hugger ved, se till att järnet som vi sitter på är i fullt fungerande skick. Hur kan detta göras?

Showdown med järn

Blå skärmar av dödsfall orsakade av hårdvarufel är spontana, dyker upp oförutsägbart och oberoende av några specifika användaråtgärder. Applikationer börjar också ge kritiska fel på en mängd olika platser, och felkoder, adresser och annan information som utfärdas av systemet kommer att vara olika i alla fall! Förresten, drivrutiner som hanterar asynkrona förfrågningar från I/O-enheter, till exempel trådlösa nätverk, beter sig nästan exakt likadant. Blå skärmar av dödsfall orsakade av defekta förare uppstår vanligtvis när man utför en specifik uppsättning åtgärder och innehåller mer eller mindre konstant information.

För att ta bort alla misstankar från hårdvaran räcker det att ansluta en annan hårddisk till systemet och installera en ren Windows och jobba på det ett tag. Om dödens blå skärmar inte försvinner betyder det att hårdvaran verkligen är skyldig och att det är dags att ändra det. Att hitta defekta komponenter är ett ämne för en separat diskussion, som vi lämnar till nästa gång, men för nu, kavla upp ärmarna och ta tag i dessa lömska förare.

Ved utan certifikat går rakt in i eldstaden

Hela uppsättningen av verktyg som behövs för förarutveckling ( DDK– Driver Development Kit), distribuerar Microsoft det gratis tillsammans med den medföljande dokumentationen. Drivrutiner, ibland väldigt buggiga och instabila.

För att förhindra att ett sådant kaos inträffar, Microsoft I forntiden infördes ett förfarande för att certifiera förare för att uppfylla de krav som ställs på dem, varefter föraren får en digital signatur. Eller... den utfärdades inte, och den skickades för revision. Och även om certifiering bara är en formell procedur som inte garanterar frånvaron av fatala fel och utvecklingsfel, eliminerar den fortfarande några av de uppriktigt sagt "pionjär" förarna.

Helst bör endast digitalt signerade drivrutiner finnas kvar i systemet. Och även om en digital signatur inte är en försäkring, indikerar dess närvaro redan en viss nivå av utvecklingskultur. Drivrutiner utan en digital signatur är värre än ett svin och bör bli av med om möjligt (särskilt eftersom många av dem är skadlig programvara installerad av rootkits eller aggressiva försvarsmekanismer som tränger djupt in i systemet och orsakar dess instabilitet). Kort sagt, låt oss inte ägna oss åt demagogi, men låt oss försöka svara på en enkel fråga: hur skapar man en lista över förare utan en digital signatur?

Verktyget kommer att hjälpa oss med detta sigverif.exe, ingår i standardleveranssatsen operativ system och finns i WINNT\System32-katalogen. Vi startar den och ser en dialogruta. Klicka på knappen "Avancerat" och på fliken "Sök" ställer du in urvalskriterierna genom att flytta radioknappen från positionen "Meddela om avregistrerad prenumeration". systemfiler"(där den försvann som standard) till positionen "Sök efter andra filer som inte är digitalt signerade." Efter det, i "Sökalternativ", öppna rutan "Sök efter filer av följande typ" och välj "*.sys", och ange nedan sökmappen "C:\WINNT", och se till att markera "Inklusive undermappar” kryssrutan.

Egentligen, strängt taget, krävs inte att drivrutiner har sys-tillägget och är inte alltid begränsade till WINNT-katalogen, som finns i katalogerna för "sina" applikationer, och vissa applikationer lagrar till och med drivrutiner... i sig själva! Omedelbart efter lanseringen (eller när som helst), sparar de filen på disken i den aktuella eller temporära katalogen, laddar drivrutinen i minnet och... raderar den omedelbart från disken! Detta görs inte bara av skadliga virus, utan också av ganska respektabla program, till exempel några verktyg från den berömda Windows-undergrundsforskaren Mark Russinovich.

Därför, för experimentets renhet, skulle det inte skada oss att få en lista över förare som finns i det här ögonblicket i minnet och jämför dem med drivrutinerna på disken. Orden "för närvarande" är nyckeln, eftersom drivrutiner kan laddas ner/avlastas gratis utan att starta om operativsystemet. Det är lämpligt att utföra denna operation flera gånger genom att köra kommandoradsverktyget drivers.exe, som är en del av DDK, som kan laddas ner från Microsofts server. Startas utan några växlar med hjälp av ett linjekommando, verktyget drives.exe dumpar all information på skärmen, vilket inte är bra, eftersom det vanligtvis finns många förare i systemet och de inte får plats på skärmen. Religion tillåter oss dock att omdirigera utgångsströmmen till textfil(drivers.exe >filnamn.txt), kan öppnas av alla textredigerare- antingen med Word eller med ett anteckningsblock. Sedan återstår bara att välja det vertikala blocket (vilket Notepad inte tillåter) och få en lista med drivrutiner. Direkt från operativsystemets kärna!

Om minst en av dessa drivrutiner inte finns i C:\WINNT\-katalogen, kommer dess digitala signatur inte att verifieras! Naturligtvis lockar en sådan förare omedelbart uppmärksamhet, och vi har en rimlig fråga: var kommer den ifrån? Först skannar vi alla kataloger på disken; om den inte finns där, ställ in en brytpunkt på CreateFileW-funktionen i Soft-Ice och titta på argumenten som skickas till den. Förr eller senare kommer vi att stöta på vår buggydrivrutin, varefter vi bara kan titta på det nedre högra hörnet av Soft-Ice-skärmen, där namnet på processen som genererade den visas. För mer information, se boken "Tekniker för att felsöka program utan källtexter", en elektronisk kopia av vilken kan hittas på ftp- eller http-servern nezumi.org.ru, såväl som på vår disk. Och vi fortsätter att plåga nyttan sigverif.exe.

Efter att ha klickat på "OK", "Start", kommer en "termometer" att dyka upp på skärmen som visar framsteg, och hårddisken börjar prassla med alla dess huvuden som den har. Efter avslutat arbete kommer en lista över förare utan digital signatur att sammanställas och visas på skärmen.

Vissa hotheads föreslår, för att rena systemet från kätteri, att ta bort alla osignerade drivrutiner - då, säger de, kommer alla problem att försvinna. Hur kan detta göras? Den grovaste lösningen är att helt enkelt ta bort dem från disken via FAR eller Explorer (med administratörsrättigheter såklart!). Men konsekvenserna av en sådan operation kan vara mycket förödande, och det är bättre att högerklicka på drivrutinsikonen i Utforskaren, hitta tillverkarens namn i "Egenskaper", där du kan bestämma vilken typ av applikation/hårdvara som är installerad denna drivrutin och avinstallera den på ett civiliserat sätt. Det är sant att det finns ett "men" här.

Föraren är markerad i bilden nedan. g400m.sys, som följer med Matrox G450-kortet, och även om Matrox inte alls är ett svagt företag fick det ingen digital signatur (antingen gav inte Microsoft det, eller så ville Matrox själv inte bry sig). Naturligtvis, efter att ha tagit bort det från systemet, måste du glömma SVGA-läget. Du kan dock gå till Matrox hemsida och ladda ner den senaste versionen av drivrutinen (den är redan digitalt signerad). Bara här... både signerade och osignerade versioner innehåller många fatala fel, i synnerhet som ett resultat av vissa omständigheter, när man försöker byta till överlagringsläge, kraschar systemet in i BSOD, eftersom föraren försöker frigöra redan frigjort minne.

Förekomsten/frånvaron av en digital signatur i sig betyder alltså ingenting, och även om vi endast använder signerade drivrutiner ger detta oss inga garantier för stabilitet.

Det är här vi går vidare till den andra delen av artikeln, nämligen att testa förare under förhållanden nära strid.

Vi ger veden ett rejält prov

DDK innehåller ett underbart verktyg Förare Bekräftare, vilket skapar de svåraste förhållandena för förare, på gränsen till extrem och självmord, där sannolikheten för misslyckande är maximal, och namnet på den defekta föraren bestäms med högsta noggrannhet (även om den inte lider på grund av utvecklingsfel, men förstör datastrukturen för andras förare).

Det är viktigt att notera det Förare Bekräftare– Det här är ingen medicin, utan bara ett diagnostiskt verktyg. Det kommer fortfarande inte att rädda dig från misslyckanden (tvärtom, det kommer att öka deras intensitet med ett par storleksordningar), men det kommer att hjälpa till att identifiera den "luriga" föraren med en tillräcklig grad av tillförlitlighet.

Så vi startar verifier.exe, vi ser fönstret Förare Bekräftare Chef, gå till fliken Inställningar och flytta radioknappen till läget Verifiera alla förare, varefter vi trycker på knappen "Önskad inställning", som ställer in följande verifieringstyper:

• Särskild slå samman– drivrutinerna som testas kommer att tilldelas ett speciellt minnesområde för tilldelning, som inte fungerar särskilt snabbt, men som kan upptäcka de flesta typer av förstörelse av sin egen och andras data.

• Tvinga IRQL kontroll. IRQL är nivån för avbrottsbegäran. Det vanligaste misstaget som drivrutinutvecklare gör är att försöka komma åt minnet på en IRQL-nivå där personsökningshanteraren inte fungerar. Och om den önskade sidan plötsligt visar sig vara vräkt till disk, kommer systemet att förvandlas till en blå skärm med inskriptionen "IRQL_LESS_OR_EQULAR". Genom att tvinga fram detta läge tvingas drivrutinssidorna att spolas till disken så att designdefekten uppträder 100 % av gångerna.

• Låg resurs simulering Det är användbart att installera det för att se hur drivrutinen kommer att bete sig i händelse av en katastrofal brist på systemresurser, men du behöver inte göra detta, men det är bättre att lämna kryssrutan Poolspårning (övervaka korrekt hantering av minnet slå samman). Inmatnings-/utgångsfel (I/O-verifiering) utgör en obetydlig del av alla fel, så placeringen av denna kryssruta är i allmänhet helt okritisk.

När du har valt inställningarna klickar du på knappen "Apply" och startar om, som vi föreslår.

Omedelbart efter att uppstarten börjar kommer systemet att sakta ner märkbart, vilket är som det ska vara, eftersom kärnan utför många fler kontroller än vanligt. När fel upptäcks blinkar en blå skärm med förarnamnet och annan information som är användbar för utvecklare, men värdelös för oss. Allt vi kan göra är att uppdatera drivrutinen till det mesta senaste versionen eller vägra att använda programmet (hårdvaran) som använder det. Egentligen har vi lite fler alternativ för att tända vått ved, men mer om det senare.

Du kan ta reda på verifieringsstatusen när som helst genom att köra verifier.exe. Fliken Förarstatus listar statusen för alla upptäckta förare med en förklaring av den aktuella situationen. Laddad status betyder det denna förare har laddats ner och verifierats av minst, en gång (men kanske inte helt, det vill säga inte alla delar av föraren hann träna). Statusen Unloaded betyder att drivrutinen har laddats, verifierats (eventuellt delvis) och avladdats av systemet/programmet som använder den eller på egen begäran. Det senare är särskilt typiskt för förare som blivit över från utrustning som togs bort genom att på barbarisk vis dra ut expansionskortet ur kortplatsen, det vill säga utan att utföra avinstallation. Den överlevande föraren skannar bussen, försöker hitta "dess" hårdvara, misslyckas med sökningen och laddar sedan av sig själv från minnet, förresten, saktar ner systemstarten (ibland mycket avsevärt) och kommer i konflikt med andra förare. Moral: utrustning måste tas bort från systemet enligt alla regler! Men inte alla avlastade status är ett tecken på en onormal situation, och innan du tar bort en förare med en sådan status måste du ta reda på vilken typ av ren detta är och var den kom ifrån i första hand.

Statusen Never Loaded indikerar att den här drivrutinen ännu inte har laddats, vilket betyder att den inte har kontrollerats, därför måste du vänta innan du startar olika program som kan förknippas med det. Vissa drivrutiner (särskilt felaktigt avinstallerade) laddas dock inte och kontrolleras därför aldrig.

Efter att ha arbetat med systemet i hårdkontrollläge under en tid (från flera timmar till flera dagar), kommer vi att identifiera nästan alla defekta drivrutiner som vi tidigare led av och skriva ner deras namn på ett papper.

Du kan återställa systemet till normalt läge (det vill säga utan ytterligare kontroller som tär på prestanda) med samma verifierare. Vi återgår till fliken Inställningar, flyttar alternativknappen till läget Verifiera valda förare (ingen drivrutin ska väljas), klicka på "Återställ alla", sedan på "Använd" och starta om. Allt! Systemet arbetar nu med normal hastighet, men utan kontroller.

Vad ska man göra med fuktig ved?

Men egentligen, vad kan du göra med en defekt drivrutin? Hackare som vet hur man håller en debugger i sina händer, om de har tillräckligt med ledig tid, kan demontera den (lyckligtvis är drivrutiner vanligtvis små i storlek), hitta ett fel och komma på ett sätt att fixa det, men... Detta är för tidskrävande.

Att slänga drivrutinen (tillsammans med hårdvaran/programmet som använder den) är inte heller ett alternativ. Även om det är känt att blå skärmar av döden bär skulden Ljudkort främling kinesisk tillverkare värd $20, då har vi en mycket stark motivation att ersätta den med något mer värdigt. Men detta är strängt taget redan klart för alla och ytterligare kommentarer behöver inte.

Men inte alla vet att ett stort antal krascher och blå skärmar av dödsfall beror på att en drivrutin som utvecklats (och testats) i en enprocessormiljö är installerad på en dubbelprocessormaskin. Med "dual-processor" menar vi här både en riktig plattform med två stenar och Hyper-Threading/multi-core processorer. Känd (och bekräftad) stor mängd tester) det hemdator två processorer är helt värdelösa, eftersom det i de allra flesta applikationer praktiskt taget inte finns någon ökning i prestanda.

Därför, om systemet är instabilt och av en eller annan anledning är det omöjligt att bli av med den defekta drivrutinen, kan du försöka komma in i BIOS-inställningarna och förvandla din "virtuella dubbelprocessor" -maskin till en enprocessor . En liknande effekt kan uppnås genom att öppna filen boot.ini (på datorer med Windows NT/2000/XP den finns i rotkatalogen logisk enhet, som systemet är installerat på) och lägg till /ONECPU-nyckeln till den, starta sedan om i hopp om att felen försvinner.

Lista 1

Exempel på en typisk boot.ini-fil

timeout=30

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS

Lista 2

Vi konfigurerar systemet så att det bara använder en processor av alla tillgängliga

timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Pro" /fastdetect /SOS /ONECPU

Men på Windows Perspektiv det finns ingen boot.ini-fil, och även om det är möjligt (tillfälligt) att konfigurera dess startinställningar med hjälp av särskild nytta, Microsoft planerar att helt överge detta kryphål, så att endast BIOS Setup kommer att finnas kvar. Men vad gäller Perspektiv, när de byter till det, kommer drivrututvecklare förmodligen att ha skaffat flerprocessormaskiner (eftersom det helt enkelt inte kommer att finnas några andra kvar till försäljning) och kommer att testa sina skapelser i en multiprocessormiljö.

En annan subtil punkt. Kom ihåg att vi sa ovan att det vanligaste misstaget som görs av drivrutinutvecklare är att komma åt urtagbart minne på IRQL-nivå där personsökningshanteraren inte fungerar, och om den begärda sidan inte finns i minnet inträffar en krasch? Den självklara lösningen här vore att öka random access minne till den volym vid vilken praktiskt taget inga sidor kastas till disk. Med nuvarande minnespriser har nästan alla råd att köpa ett par nya minnesstickor. Men det finns en mer tillgänglig (och mer elegant) lösning på problemet. Om parametern DisablePagingExecutive, som finns i nästa registergren HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement, är lika med ett (noll som standard), kommer kärnkraftskomponenter inte att förebyggas. Därför startar vi helt enkelt "Registerredigeraren", ändrar denna omhuldade parameter och startar om (ändringarna träder i kraft först efter en omstart), i hopp om att detta kommer att hjälpa till att lösa problemet med misslyckanden.