Deci, aveți un ecran albastru recurent al morții și, ca multe BSoD-uri, se datorează faptului că un șofer rău este de vină. Cu toate acestea, ecranul nu vă oferă informațiile corecte, fie pentru că nu conține deloc drivere, fie pentru că listează un driver de sistem care acționează ca fals.
Driver Verifier este un utilitar gratuit inclus cu toate versiunile de Windows din Windows XP. Verifică literalmente fiecare dintre driverele de pe computer până când întâlnește problema care a provocat problema, creând intenționat același ecran albastru, dar apoi scriind informațiile într-un fișier jurnal, ajutându-vă să identificați problema.
Rulați șoferul șoferului
Dacă utilizați foarte mult același ecran albastru și doriți să vă activați și să îl remediați, iată cum să utilizați Driver Verifier.
- Faceți clic pe buton start
- Faceți clic pe „ A executa "...
- introduce CMD și apăsați Introduce.
- În fereastra nouă introduceți verificator și apăsați Introduce.
Pe Windows Vista și 7:
- Faceți clic pe buton start
- introduce CMD în casetă și faceți clic Introduce.
- În fereastra nouă introduceți verificator și apăsați Introduce.
Pe Windows 8 și 8.1:
- Apăsați tasta Windows + X
- Faceți clic pe „ Linia de comandă "(" Administrator ") (Windows PowerShell (Administrator) în Windows 8.1)
- În fereastra nouă introduceți verificator și apăsați Introduce.
Toate versiunile Windows:
- Asigurați-vă că selectați personalizarea setărilor personalizate (pentru dezvoltatorii de cod) .
- Faceți clic pe „ Mai departe" .
- Selectați " Selectați setări personalizate "din lista completă .
- Faceți clic pe „ Mai departe" .
- Deselectați modelarea sistemelor cu resurse reduse și solicitări I / O de așteptare ... (Acestea două cauzează sarcini de lucru inutile pe computerul dvs.) Asigurați-vă că toate celelalte sunt selectate.
- Dublu click " Mai departe" .
- Selectați " Selectați numele driverului "din listă .
- Faceți clic pe „ Mai departe" .
- Selectați toți driverele de pe acest ecran, cu excepția celor care spun Microsoft Corporation sub Furnizor. Este foarte puțin probabil ca un driver Microsoft să provoace această problemă.
- Faceți clic pe „ Terminat " .
Notă. Dacă nu puteți finaliza pașii de mai sus, deoarece ecranul albastru continuă să apară, vă rugăm să încercați mai întâi să descărcați pe.
În acest moment, trebuie să reporniți computerul. Apoi încercați să apelați BSoD din nou făcând ceea ce ați făcut înainte. Windows pune o povară suplimentară asupra driverelor pentru a vă ajuta. Dacă nu puteți reproduce BSoD, încercați să porniți computerul peste noapte. De îndată ce BSoD reapare, reporniți computerul și citiți fișierul Minidump.
Citirea unui fișier dump
Driver Verifier va porni, va apărea ecranul albastru și va scrie un fișier jurnal. Acest fișier jurnal se află la C: \\ Windows \\ Minidump \\. Citiți-l și veți vedea care driver provoacă această problemă. Încercați să căutați numele driverului pentru a vedea ce componentă hardware utilizează computerul dvs.
Deci, cum o citiți? Aveți nevoie de un instrument de depanare pe care îl puteți descărca de la Microsoft.
ȘI . Descărcați SDK-ul, instalați-l, selectați Instrumente de depanare și deselectați orice altceva.
Rețineți că instrumentele de depanare pentru versiunile anterioare de Windows nu mai sunt disponibile; va trebui să trimiteți fișierul dump către un tehnician Microsoft pentru analiză.
După instalare, găsiți-l pe ecranul de pornire. Se numește windbg (x64). Rulați-l.
- Faceți clic pe „ Fişier" , apoi " Open crash " .
- Schimba cu C: \\ Windows \\ Minidump \\ și deschideți fișierul .dmp conținut în interior.
- Uită-te la partea de jos a fișierului rezultat, unde linia spune „ Probabil cauzată de „ ... Acesta este un bun indiciu al șoferului care cauzează problema.
Remediați șoferul
Actualizați driverul asociat cu acest hardware:
- Faceți clic pe buton start
- Click pe Panou de control
- Faceți clic pe „ Treceți la vizualizarea clasică "
- Dublu click Sistemul
- Mergi la fila „Echipament”
- Click pe manager de dispozitiv
- Faceți clic pe „ Actualizați driver-ul ".
Pe Windows Vista și 7:
- Faceți clic pe buton start
- Click pe Panou de control
- Dublu click manager de dispozitiv
- Găsiți dispozitivul care cauzează problema
- Faceți clic dreapta pe el
- Faceți clic pe „ Actualizați driver-ul ".
Pe Windows 8 și 8.1:
- Apăsați tasta Windows + X
- Click pe Panou de control
- Vazut de icoane mici
- Click pe manager de dispozitiv
- Găsiți dispozitivul care cauzează problema
- Faceți clic dreapta pe el
- Faceți clic pe „ Actualizați driver-ul ".
Sau utilizați aplicația noastră pentru a evita confuzia cu Driver Verifier. Driver Reviver actualizează automat toate driverele existente pe computerul dvs. și este deosebit de bun pentru actualizarea driverelor ineficiente precum acesta la cea mai recentă și cea mai bună versiune.
După remedierea problemei driverului, veți dori să dezactivați Driver Verifier.
Dezactivați verificatorul driverului
După ce ați terminat de utilizat Driver Verifier, veți dori să îl dezactivați, deoarece este destul de greu pe computerul dvs. în timp ce rulează.
Pe toate versiunile Windows:
- Lansați din nou Driver Verifier utilizând pașii de mai sus.
- Selectați " Ștergeți setările existente " .
- Faceți clic pe „ Terminat " .
- Reporniți computerul din nou.
Vă rugăm să păstrați acest articol marcat ca referință viitoare, astfel încât ori de câte ori aveți un ecran albastru, să puteți remedia problema. De asemenea, consultați interactivul nostru și introduceți numele bug-ului dvs. pentru mai multe sfaturi despre cum să abordați ecranul albastru al morții. Mult noroc!
8021Una dintre cele mai probabile cauze ale unui ecran albastru de deces este șoferii care funcționează incorect. Puteți determina cauza exactă a eșecului analizând fișierul de dump după BSOD, dar nu este întotdeauna cazul. În unele cazuri, nu este posibil să se determine sursa problemei, chiar și cu cea mai aprofundată analiză a haldelor. În astfel de situații, vă poate ajuta un utilitar Windows standard conceput pentru testarea avansată a driverelor.
Lucrând în fundal, acesta monitorizează nu numai funcționarea driverelor, ci și simulează diverse "Stresant" situații, de exemplu, lipsa memoriei RAM. Informații obținute în timpul testării "Adăugat la" pentru a arunca fișierul DMP... Driver Verifier vă permite să analizați erorile I / O, să controlați depășirile de tampon, să identificați erorile din mecanism IRQL etc. Într-un cuvânt, programul vă permite să identificați situațiile în care un conducător auto poate duce la un accident de sistem BSOD.
Specificitatea utilității nu exclude deloc utilizarea acestuia de către utilizatorii obișnuiți. Oricine poate crea un raport cu ajutorul său, este o altă problemă să te ocupi de decodarea acestuia. Dar nimeni nu cere acest lucru de la utilizatorii obișnuiți, în ceea ce privește depozitul primit, atunci analiza acestuia poate fi încredințată pe umerii profesioniștilor, după ce a cerut ajutor la un forum computerizat bine cunoscut.
Notă importantă: înainte de a utiliza utilitarul, este foarte recomandat creați un punct de restaurare a sistemului sau o copie de rezervă completă. În Windows 8 și 8.1, va trebui, de asemenea, să activați modul încărcare sigură... Acest lucru este necesar în cazul unor erori neașteptate în timpul funcționării Driver Verifier. Acest lucru vă va permite să porniți, să dezactivați modul de testare și să reveniți la sistem.
Puteți rula utilitarul cu comanda verificator.
În următoarea fereastră Dispatcher, marcați parametrii pentru testare (toate pot fi selectate pentru completare).
Nu puteți lăsa nimic în a treia fereastră.
În a patra fereastră, utilitarul va oferi selectarea unui grup de drivere pentru testare.
În mod implicit, toți driverii nesemnați sunt selectați ca incluși în grupul de risc, dar puteți specifica și dvs. driverele bifându-le în a cincea fereastră a Managerului de scanare.
Totul este. După repornirea computerului, modul de verificare a driverului va fi activat. În tot acest timp, computerul poate fi folosit ca de obicei, până în momentul în care apare BSOD... După aceea, copiați fișierul dump din director C: / Windows / Minidump și trimiteți-l pentru analiză. Poate dura puțin mai mult pentru a porni un computer cu testarea driverului activată, așa că nu vă alarmați. Asta este normal. După primirea tuturor datelor, modul de depanare trebuie dezactivat manual, selectând elementul din interfața grafică a utilitarului. „Ștergeți parametrii existenți”.
Utilitarul Driver Verifier (verifier.exe) este conceput pentru a analiza driverele cu probleme, atunci când analiza depozitelor de memorie după BSOD nu permite găsirea driverului cu probleme. Driver Verifier este un „salvator” în cele mai problematice situații.
Cu Driver Verifier, puteți:
testul de stres al șoferului (simulează lipsa resurselor);
controlul depășirii bufferului;
control asupra erorilor care apar în timpul funcționării incorecte la un anumit IRQL;
analiza erorilor de intrare-ieșire;
depistarea situatiilor de impas etc.
Driver Verifier este util atunci când:
administratorul (utilizatorul) are suspiciuni că acest driver determină blocarea sistemului și dorește să verifice suplimentar dacă acest lucru este efectiv;
dezvoltatorii de șoferi care doresc să-și testeze șoferul;
când analizați o descărcare după BSOD, nu puteți găsi un driver problematic.
Unul dintre cele mai dificile cazuri de analiză a depozitelor de memorie este atunci când un driver suprascrie eronat datele înainte sau după sfârșitul bufferului alocat de acesta. În astfel de cazuri, erorile apar în nucleul sistemului de operare (de exemplu, analiza dump-ului după BSOD arată că eroarea a apărut în ntoskrnl.exe).
Să vedem un caz similar cu un exemplu specific. Folosind utilitarul NotMyfault, numim BSOD - „Buffer overflow”.
Rezultatul analizei de descărcare de gestiune folosind windbg este în atașamentul de mai jos.
Conform analizei de depozitare pe care o obținem.
1. Arg1: 00000007, încercarea de a elibera un bazin care a fost deja eliberat (a existat o încercare de a elibera o piscină deja eliberată)
2. IMAGE_NAME: ntkrpamp.exe (chiar nucleul sistemului are legătură cu acest lucru)
Cu astfel de erori, verificatorul vine în ajutor.
Rulați verificatorul.
Selectăm „Creați parametri non-standard”. Apoi, selectați „Selectați parametrii din listă”.
Selectăm totul, cu excepția „Simulează lipsa resurselor”.
Apoi selectăm „Selectați driverele descărcate în această listă” și specificăm calea către driverul myfault.sys, care se află în același director cu programul NotMyfault.exe.
Apoi marcăm driverul și facem clic pe „Finish”. După aceea, trebuie să repornim computerul.
Efectuăm toate aceleași acțiuni ca la început. Rulați NotMyfault.exe, selectați „Buffer overflow” și apăsați „Crash”. După cum ați observat, blocarea poate să nu apară imediat, deoarece cine și când va încerca să lucreze cu această memorie nu se cunoaște în prealabil. După cum puteți vedea în imaginea de mai jos, datorită verificatorului, sistemul poate identifica driverul problemei.
Permiteți-mi să vă fac o analiză folosind! Analizați -v în windbg.exe pentru a arunca memoria după BSOD.
Programul de verificare face ca driverul care este verificat, în loc de memoria obișnuită disponibilă în kernel, să utilizeze un pool special conceput pentru a detecta o astfel de eroare. Datorită acestui fapt, puteți găsi driverul care duce la BSOD.
Dacă ne uităm la rezultatele analizei, vedem următoarele.
1.DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) - aceasta este una dintre erorile generate de verificator
2. IMAGE_NAME: myfault.sys - șoferul care a dus la problemă.
Astfel, dacă analiza memorării după BSOD nu permite găsirea „driverului vinovat”, utilizați programul verifier.exe (instalați toate verificările, cu excepția lipsei de memorie).
Cel mai simplu mod de a utiliza Driver Verifier (verifier.exe) este să îl rulați cu următorii parametri:
verificator / standard / nume driver fișier driver
Vizualizări post: 1 042
Vă avertizăm că orice experiment cu șoferii este periculos și poate deteriora sistemul. Este mai bine să faceți o copie de rezervă a sistemului în avans și apoi să nu încrucișați degetele, eliminând un alt driver suspect din Windows.
Și de îndată ce nu se certă Windows din Microsoft, numind săracul în același timp tocilar și buggy și chiar instabil. Abia acum nimeni nu se grăbește să renunțe la ea și, în general, este puțin probabil să renunțe vreodată la ea. Prin urmare, în loc să-i certăm pe dezvoltatorii săraci și să aruncăm o flacără fără sens, ar fi bine să ne dăm seama: de ce, de fapt, sistemul este buggy? Lasă-mă să-ți spun un mic secret. În ecranele notorii ale morții și ale muncii precare Windows în marea majoritate a cazurilor, sunt de vină driverele terțe, iar sistemul de operare în sine nu are absolut nimic de-a face cu el. Acum vă vom spune cum să găsiți astfel de drivere și să le eliminați din sistem.
Defectele în proiectarea șoferului pot fi de o natură foarte diferită: de la căderea în ecranul albastru al morții ( BSOD - Blue Screen of Death) și încetinirea computerului și comportamentul ciudat al unor aplicații care nu au nicio legătură cu driverul.
Ecranul albastru al morții este remarcabil (fără nici o ironie!) Prin faptul că semnalează în mod clar prezența unei probleme grave și oferă un sfat de unde să sapă. Adesea (dar nu întotdeauna) numele șoferului „vinovat” este afișat direct în colțul din dreapta sus al ecranului albastru al morții. Cu toate acestea, este posibil să nu fie acolo sau, și mai rău, numele unui șofer complet străin poate fi acolo.
Deci, de exemplu, un driver destul de comun de pe o placă video Matrox G450 tinde să distrugă structurile subiacente ale subsistemului grafic Windows 2000 , în urma căruia numele driverului de sistem este afișat în BSOD win32k.sys, care implementează o parte semnificativă a funcțiilor USER și GDI și care, desigur, nu are nimic de-a face cu aceasta. Deci, interpretarea mărturiei ecranului albastru al morții este magie, intuiție, știință și artă - puțin din toate.
În plus față de defectele conducătorului auto, ecranele albastre ale morții pot fi cauzate și de defecțiuni de fier, de exemplu, un procesor overclockat, memorie RAM defectă, un controler de hard disk stricat, un card PCI care nu este complet introdus în slot, lipsă de contact într-unul dintre conectori, o sursă de alimentare defectă, placa de baza. Iar acestea din urmă sunt suflate din diverse motive: din cauza supraîncălzirii de la un procesor din apropiere, a lipsei condensatoarelor ceramice, „nepotrivite” de către producător (în urma căreia componenta RF trece prin electrolit și îl încălzește puternic), în cele din urmă, datorită scurgerii tranzistorilor cheie în nod stabilizator. Prin urmare, înainte de a tăia lemnul, trebuie să vă asigurați că fierul pe care ne așezăm este complet intact. Cum se poate face acest lucru?
Confruntare cu fier
Ecranele albastre ale morții cauzate de defecțiuni hardware sunt de natură spontană, apar în mod imprevizibil și independent de orice acțiuni specifice ale utilizatorului. Aplicațiile încep, de asemenea, să genereze erori critice în multe locuri diferite, iar codurile de eroare, adresele și alte informații furnizate de sistem vor fi diferite în toate cazurile! De altfel, driverele care gestionează cereri asincrone de la dispozitive I / O, cum ar fi rețelele fără fir, se comportă în același mod. Ecranele albastre ale morții cauzate de șoferii defecți, de regulă, apar atunci când se efectuează un anumit set de acțiuni și conțin informații mai mult sau mai puțin constante.
Pentru a elimina toate suspiciunile din hardware, conectați doar un alt hard disk la sistem, instalați o virgină Windows și lucrează la el o vreme. Dacă ecranele albastre ale morții nu dispar, atunci, într-adevăr, fierul este de vină și este timpul să-l schimbăm. Găsirea componentelor defecte este un subiect pentru o conversație separată, pe care o vom lăsa pentru data viitoare, dar deocamdată, răsucindu-ne mânecile, vom aborda îndeaproape acești șoferi insidioși.
Lemn de foc fără certificat direct în focar
Întregul set de instrumente necesare dezvoltării driverului ( DDK - Driver Development Kit), Microsoft distribuie gratuit împreună cu documentația însoțitoare. Șoferii, uneori foarte buggy și instabili.
Pentru a preveni un astfel de haos, Microsoft încă din vremuri străvechi, a introdus o procedură de certificare a șoferilor pentru respectarea cerințelor impuse acestora, după care se eliberează șoferului o semnătură digitală. Sau ... nu a fost emis și a fost trimis spre revizuire. Și, deși certificarea este doar o procedură formală care nu garantează absența erorilor fatale și a defectelor de dezvoltare, totuși filtrează unii dintre driverii „pionieri”.
În mod ideal, numai driverele semnate digital ar trebui păstrate pe sistem. În timp ce o semnătură digitală nu este o poliță de asigurare, prezența sa indică deja un anumit nivel de cultură a dezvoltării. Șoferii fără semnătură digitală sunt mai răi decât o pisică cu o pisică în geantă și ar trebui să fie aruncați ori de câte ori este posibil (mai ales că multe dintre ele sunt programe rău intenționate instalate de rootkit-uri sau mecanisme de apărare agresive care pătrund adânc în sistem și provoacă instabilitatea acestuia ). Pe scurt, nu va genera demagogie, dar vom încerca să răspundem la o întrebare simplă: cum să facem o listă de șoferi fără semnătură digitală?
Utilitatea ne va ajuta în acest sens. sigverif.exe, inclus în setul de livrare standard al sistemului de operare și situat în directorul WINNT \\ System32. O lansăm și vedem o casetă de dialog. Apăsați butonul „Avansat” și în fila „Căutare” configurați criteriile de selecție mutând butonul radio din poziția „Notificați despre fișierele de sistem nesemnate” (unde a stagnat în mod implicit) în poziția „Căutați alte fișiere nesemnate cu semnătură digitală”. După aceea, în „Căutare parametri” deschideți caseta „Căutați fișiere de tipul următor” și selectați „* .sys”, iar mai jos indicăm folderul pentru căutarea „C: \\ WINNT”, asigurați-vă că bifați caseta „Inclusiv subfoldere”.
De fapt, strict vorbind, driverele nu trebuie să aibă extensia sys și nu sunt întotdeauna limitate la directorul WINNT, fiind în directoarele aplicațiilor „lor”, iar unele aplicații stochează chiar și driverele ... în interiorul lor! Imediat după pornire (sau în orice alt moment) salvează fișierul pe disc în directorul curent sau temporar, încarcă driverul în memorie și ... îl șterge imediat de pe disc! Nu numai că virușii rău intenționați fac acest lucru, ci și programe destul de respectabile, precum unele utilitare ale celebrului explorator Windows Mark Russinovich.
Prin urmare, pentru puritatea experimentului, nu strică deloc să obțineți o listă de drivere aflate în prezent în memorie și să le comparați cu driverele aflate pe disc. Cuvintele „în acest moment” sunt esențiale, deoarece încărcarea / descărcarea driverelor se poate face gratuit fără a reporni sistemul de operare. Este recomandabil să efectuați această operațiune de mai multe ori rulând utilitarul de linie de comandă drivers.exe inclus în DDK, care poate fi descărcat de pe serverul Microsoft. Lansat fără niciun comutator de linie de comandă, utilitarul drives.exe aruncă toate informațiile de pe ecran, ceea ce nu este bun, deoarece există de obicei o mulțime de drivere în sistem și nu se potrivesc pe ecran. Cu toate acestea, religia ne permite să redirecționăm fluxul de ieșire către un fișier text (drivers.exe\u003e \u200b\u200bfile-name.txt), care poate fi deschis de orice editor de text, fie el Word sau notepad. Apoi rămâne doar să selectați blocul vertical (ceea ce nu permite blocnotesul) și să obțineți o listă de drivere. Chiar de la nucleul sistemului de operare!
Dacă cel puțin unul dintre aceste drivere lipsește în directorul C: \\ WINNT \\, atunci semnătura sa digitală nu va fi verificată! Firește, un astfel de șofer atrage imediat atenția și avem o întrebare rezonabilă: de unde vine? Mai întâi, scanăm toate directoarele de pe disc; dacă nu este acolo, setați un punct de întrerupere pentru funcția CreateFileW a Soft-Ice și priviți argumentele care i-au fost transmise. Mai devreme sau mai târziu vom întâlni driverul nostru de buggy, după care rămâne doar să ne uităm la colțul din dreapta jos al ecranului Soft-Ice, unde este afișat numele procesului care l-a generat. Pentru mai multe detalii, consultați cartea „Tehnică de depanare a programelor fără cod sursă”, a cărei copie electronică poate fi găsită pe serverul ftp- sau http nezumi.org.ru, precum și pe discul nostru. Și continuăm să chinuim utilitatea sigverif.exe.
După ce faceți clic pe „OK”, „Start”, un „termometru” va apărea pe ecran, afișând progresul progresului, iar hard disk-ul va începe să foșnească cu toate capetele pe care le are doar. La finalizarea lucrării, o listă de drivere fără semnătură digitală va fi compilată și afișată pe ecran.
Unii hoth sugerează, pentru a curăța sistemul de erezie, să elimine toți driverele nesemnate - apoi, spun ei, toate problemele vor fi eliminate. Cum se poate face acest lucru? Cea mai crudă soluție este să le luați și să le ștergeți de pe disc prin FAR sau Explorer (desigur, cu drepturi de administrator!). Dar consecințele unei astfel de operații se pot dovedi a fi foarte dezastruoase și este mai bine, făcând clic dreapta pe pictograma driverului din explorator, să găsiți numele producătorului în „Proprietăți”, prin care puteți determina ce aplicație / hardware a instalat acest driver și îl puteți dezinstala într-un mod civilizat. Adevărat, există un „dar” aici.
Șoferul este evidențiat în figură. g400m.sys, care vine cu cardul Matrox G450 și, deși Matrox nu este deloc o companie fragilă, nu a primit o semnătură digitală (fie Microsoft nu a dat-o, fie Matrox în sine nu a vrut să se deranjeze). Firește, după ce îl scoateți din sistem, va trebui să uitați de modul SVGA. Cu toate acestea, puteți accesa site-ul web Matrox descărcând cea mai recentă versiune de driver (este deja semnată digital). Abia acum ... atât versiunile semnate, cât și cele nesemnate conțin multe erori fatale, în special, ca urmare a anumitor circumstanțe, când se încearcă trecerea la modul de suprapunere, sistemul se blochează într-un BSOD, deoarece driverul încearcă să elibereze memoria deja eliberată.
Astfel, prezența / absența unei semnături digitale nu înseamnă în sine nimic și chiar dacă folosim doar drivere semnate, acest lucru nu ne oferă nicio garanție de stabilitate.
Aici ne întoarcem la a doua parte a articolului, și anume, testarea șoferilor în condiții apropiate de luptă.
Aranjăm un test real pentru lemn de foc
DDK include un utilitar minunat Conducător auto Verificator, care creează cele mai severe condiții pentru șoferi, limitându-se la extrem și la sinucidere, în care probabilitatea eșecului este maximă, iar numele șoferului defect este determinat cu cea mai mare precizie (chiar dacă din cauza unor defecte de dezvoltare nu suferă el însuși, ci distruge structura datelor șoferilor altor persoane).
Este important să rețineți că Conducător auto Verificator nu este un medicament, ci doar un instrument de diagnosticare. Încă nu vă va salva de eșecuri (dimpotrivă, le va crește intensitatea cu câteva ordine de mărime), dar vă va ajuta să identificați șoferul „șmecher” cu un grad suficient de fiabilitate.
Deci, rulăm verifier.exe, vedem fereastra Conducător auto Verificator Administrator, accesați fila Setări și mutați butonul radio în poziția Verificați toate driverele, apoi apăsați butonul „Setare preferată”, care setează următoarele tipuri de verificare:
- Special bazin - driverelor verificate li se va aloca o zonă de memorie specială pentru alocare, care nu funcționează foarte repede, dar este capabilă să detecteze majoritatea tipurilor de daune propriilor date și ale altor persoane.
- Forta IRQL control. IRQL este nivelul de solicitare a întreruperii. Cea mai frecventă greșeală pe care o fac dezvoltatorii de drivere este încercarea de a accesa memoria la un IRQL în care managerul de swap nu funcționează. Și dacă pagina necesară este brusc împinsă pe disc, sistemul se va transforma într-un ecran albastru cu inscripția „IRQL_LESS_OR_EQULAR”. Forțarea acestui mod împinge forțat paginile driverului pe disc, astfel încât defectul de dezvoltare să apară în 100% din cazuri.
- Scăzut resursă simulare Este util să-l instalați pentru a vedea cum se va comporta șoferul în caz de lipsă catastrofală de resurse de sistem, dar acest lucru poate fi omis, dar mai bine este lăsată caseta de selectare Urmărire pool (urmărirea corectitudinii manipulării pool-ului de memorie). Erorile de verificare I / O reprezintă o parte nesemnificativă a tuturor erorilor, astfel încât poziția acestei casete de selectare este, în general, complet lipsită de critică.
După ce ați terminat alegerea setărilor, faceți clic pe butonul „Aplicați” și, după cum ni se sugerează, reporniți.
Imediat după pornirea boot-ului, sistemul încetinește semnificativ, ceea ce ar trebui să fie, deoarece nucleul efectuează mult mai multe verificări decât de obicei. Când sunt găsite erori, un ecran albastru de moarte clipește cu numele șoferului și alte informații utile pentru dezvoltatori, dar inutile pentru noi. Tot ce putem face este să actualizăm driverul la cea mai recentă versiune sau să nu mai folosim programul (hardware) care îl folosește. De fapt, avem ceva mai multe opțiuni pentru a începe lemne de foc brute, dar mai multe despre asta mai târziu.
Puteți afla starea de verificare în orice moment executând verifier.exe. Fila Stare șofer listează stările tuturor driverelor detectate, cu o explicație a situației actuale. Starea Încărcat înseamnă că acest driver a fost încărcat și testat cel puțin o dată (dar, poate, nu complet, adică nu au fost procesate toate părțile driverului). Starea de descărcare pregătește ca driverul să fi fost încărcat, verificat (posibil parțial) și descărcat de sistemul / programul care îl utilizează, sau din proprie voință. Acesta din urmă este valabil mai ales pentru driverele rămase de pe hardware care au fost eliminate prin tragerea barbară a cardurilor de expansiune din slot, adică fără a efectua dezinstalarea. Șoferul supraviețuitor scanează autobuzul, încercând să găsească hardware-ul „său”, se întrerupe cu căutarea și apoi se descarcă din memorie, apropo, încetinind încărcarea sistemului (uneori foarte semnificativ) și intră în conflict cu alți șoferi. Moral: echipamentul trebuie scos din sistem conform tuturor regulilor! Cu toate acestea, nu orice stare descărcată este un semn al unei situații anormale și, înainte de a îndepărta un șofer cu un astfel de statut, trebuie să vă dați seama ce fel de ren este și de unde provine.
Starea Never Loaded indică faptul că acest driver nu a fost încă încărcat, ceea ce înseamnă că nu a fost testat, prin urmare, trebuie să așteptați, lansând diferite programe care pot fi asociate acestuia. Cu toate acestea, unele drivere (în special cele incorect instalate) nu sunt încărcate și, în consecință, nu sunt verificate niciodată.
După ce am lucrat cu sistemul în modul de verificare dură pentru o perioadă de timp (de la câteva ore la câteva zile), vom identifica aproape toți șoferii defecți de care am suferit mai devreme și le vom scrie numele pe o bucată de hârtie.
Puteți readuce sistemul în modul normal (adică fără verificări suplimentare care consumă performanță) folosind același verificator. Reveniți la fila Setare, mutați butonul radio în poziția Verificați driverele selectate (nu trebuie selectat niciun driver), faceți clic pe „Resetare toate”, apoi pe „Aplicare” și reporniți. Tot! Sistemul rulează acum la viteză normală, dar fără verificări.
Ce să faci cu lemnul brut?
Dar, într-adevăr, ce se poate face cu un șofer defect? Hackerii care știu să țină depanatorul în mâini, dacă au suficient timp liber, îl pot dezasambla (deoarece driverele sunt de obicei de dimensiuni mici), pot găsi o eroare și pot veni cu o modalitate de a o remedia, dar ... aceasta este o cale care consumă mult timp.
De asemenea, aruncarea driverului (împreună cu hardware-ul / programul care îl folosește) nu este o opțiune. Deși, dacă se știe că o placă de sunet de 20 USD de la un producător chinez necunoscut este de vină pentru ecranele albastre ale morții, atunci avem o motivație destul de puternică să o înlocuim cu ceva mai demn. Dar acest lucru, de fapt, este clar pentru toată lumea și nu are nevoie de comentarii suplimentare.
Dar nu toată lumea știe că un număr mare de blocări și ecrane albastre ale morții se datorează faptului că un driver dezvoltat (și testat) într-un mediu cu un singur procesor este instalat pe o mașină cu procesor dual. Prin „procesor dual” aici înțelegem atât o platformă reală cu două pietre, cât și procesoare Hyper-Threading / multi-core. Se știe (și este confirmat de un număr mare de teste) că două procesoare sunt absolut inutile pentru un computer de acasă, deoarece practic nu există o creștere a performanței pe marea majoritate a aplicațiilor.
Prin urmare, dacă sistemul este instabil și nu puteți scăpa de driverul defect dintr-un motiv sau altul, puteți încerca să intrați în BIOS Setup, transformând mașina dvs. „cu două procesoare virtuale” într-una cu un singur procesor. Un efect similar poate fi obținut prin deschiderea fișierului boot.ini (pe computerele cu Windows NT / 2000 / XP se află în directorul rădăcină al discului logic pe care este instalat sistemul) și adăugând comutatorul / ONECPU la acesta și apoi reporniți în speranța că erorile vor dispărea.
Listarea 1
Un exemplu de fișier tipic boot.ini
timeout \u003d 30
multi (0) disc (0) rdisk (0) partiție (1) \\ WINNT \u003d "Windows 2000 Pro" / fastdetect / SOS
Listarea 2
Configurăm sistemul pentru a utiliza un singur procesor din toate cele disponibile
timeout \u003d 30
implicit \u003d multi (0) disc (0) rdisk (0) partiție (1) \\ WINNT
multi (0) disc (0) rdisk (0) partiție (1) \\ WINNT \u003d "Windows 2000 Pro" / fastdetect / SOS / ONECPU
Dar mai departe Windows Vista nu există fișier boot.ini și, deși există o opțiune (temporară) pentru a configura setările de boot folosind un utilitar special, Microsoft intenționează să elimine complet această lacună, astfel încât să rămână doar BIOS Setup. Cu toate acestea, în ceea ce privește Vista, apoi, la momentul trecerii la acesta, dezvoltatorii de drivere vor achiziționa probabil mașini multiprocesor (deoarece pur și simplu nu vor mai fi altele în vânzare) și își vor testa creațiile într-un mediu multiprocesor.
Un alt punct subtil. Vă amintiți că am spus mai sus că cea mai frecventă greșeală făcută de dezvoltatorii de drivere este accesarea memoriei preventive la nivelul IRQL la care managerul de paginare nu funcționează și, dacă pagina solicitată nu este în memorie, se blochează? Soluția evidentă aici ar fi creșterea nivelului de memorie RAM în măsura în care nu are loc nicio preempțiune de pagină. La prețurile actuale pentru memorie, aproape toată lumea își permite să cumpere câteva „matrițe” noi. Dar există o soluție mai accesibilă (și mai elegantă) la problemă. Dacă parametru DisablePagingExecutiveaflat în următoarea ramură a registrului HKLM \\ SYSTEM \\ CurrentControlSet \\ Control \\ Session Manager \\ MemoryManagement, este egal cu unu (zero în mod implicit), componentele nucleare nu vor fi deplasate. Prin urmare, lansăm pur și simplu „Editorul de registry”, schimbăm acest parametru râvnit și repornim (modificările vor intra în vigoare numai după o repornire), sperând că acest lucru va ajuta la rezolvarea problemei blocărilor.