professor green
Bronze Level Poster
Driveradministration er et aspekt af Windows support, der synes at forårsage en retfærdig få problemer. Det kan skyldes, at driverens funktion og drift ikke forstås godt, eller fordi driverstøtte synes at være en slags "mørk kunst".
Driver problemer er den mest almindelige årsag til BSOD'er, men en driver-forårsaget BSOD kan være vanskelig at diagnosticere. Det er ofte ikke muligt for eksempel at pege med nogen tillid til føreren, der faktisk forårsagede BSOD. Derudover skal du i det store flertal af driver-forårsagede BSOD'er være temmelig dygtige til at bruge Windows-fejlfindingsværktøjerne og have en god forståelse for internerne af I / O-operationer i Windows og dets relaterede kontrolblokstrukturer til nøjagtigt identificere den fejlbehæftede driver - og det forudsætter selvfølgelig, at du har en kernel dump-fil til at analysere i første omgang.
Det er ikke at sige, at alle chaufførproblemer resulterer i en BSOD, driverstyring ville være meget enklere, hvis de gjorde det! Driverproblemer kan også forårsage systemnedbrud, hænger, sorte skærme og selvfølgelig et utal af niggly problemer med den eller de enheder, de håndterer.
På grund af ovenstående er det nok værd at bruge lidt tid på at tale om, hvad chauffører er, om hvad de gør, og om hvorfor chaufførfejl ofte resulterer i en BSOD. Vi bør også bruge lidt tid på at tale om, hvad du kan gøre for at reducere risikoen for en driver-forårsaget BSOD (eller faktisk en driver-forårsaget fiasko) og hvilke enkle og logiske trin du kan tage for at identificere den svigtende driver, når du får problemer .
Drivere er en integreret del af Windows I / O-delsystemet, så måske er det første, vi skal gøre, at definere, hvad vi mener ved I / O. I / O står for input / output og alt, hvad der foregår i din pc uden for CPU og RAM er I / O. Når vi taler om 'input', mener vi input til CPU / RAM, og når vi taler om 'output' betyder det output fra CPU / RAM. Uden I / O-kapacitet ville din pc være en ubrugelig boks. Tastaturet og musen er I / O-enheder, skærmen er en I / O-enhed, selv dine diskdrev er I / O-enheder.
Hver I / O-enhed har brug for en driver til at styre den, nogle gange er disse "enhedsdrivere" en del af Windows I / O-delsystemet (f.eks. De grundlæggende mus og tastaturdrivere), nogle gange er de drivere skrevet og leveret af Microsoft (cd'en / DVD-drivere til eksempel), og ganske ofte leveres de af den leverandør, der oprettede enheden (bundkortdrivere for eksempel)
Hvordan jeg / O arbejder
Drivere håndterer det meste af behandlingen, der er involveret i alle I / O-operationer, så det er værd at se på et simpelt overblik over, hvordan en I / O-operation håndteres af Windows for at se, hvor bilisterne passer ind. Som et eksempel tager vi en simpel læseoperation fra en fil på en disk, initieret af en almindelig brugerapplikation (denne forklaring er blevet stærkt forenklet) ...
Vores brugerprogrammets visning af den fil, den bruger, er som en sekventiel liste over poster, der findes 'et eller andet sted', og applikationen vil nu have rekordnummer 237 (for eksempel). Det tildeler således en buffer i virtuel lagring for at holde posten og udsteder en læseanmodning til post 237 (i den angivne fil), og dette sendes til I / O-manager i Windows-kernen.
I / O-manager gør nogle grundlæggende fejlkontrol for at sikre, at I / O-anmodningen er gyldig og komplet, og den sender derefter I / O-anmodningen til den relevante driver til den enhed, som den specificerede fil er bosat (en diskdrev i dette tilfælde). På dette tidspunkt er den oprindelige ansøgnings tråd placeret i ventetilstand og venter på en bestemt begivenhed - afslutningen af denne I / O-operation.
Enhedsdriveren til disken (kører i kernel-tilstand) gør en smule mere kontrol af anmodningen ved hjælp af dens intime kendskab til enheden (som at sikre, at den tildelte buffer er stor nok til at holde posten for eksempel) og derefter oversætter applikationens rekord 237 til en faktisk datablok i et bestemt spor og sektor på en bestemt disk. Hvis den krævede disk er ledig (dvs. ikke midt i en anden I / O-operation), kommunikerer chaufføren med disken ved hjælp af de relevante diskhardwareporte, -registre og -kommandoer for at instruere den til at læse den krævede datablokke fra det angivne spor og sektor. På dette tidspunkt afbryder enhedsdriveren og en ny tråd afsendes på denne CPU.
En harddisk vil nu flytte læse / skrivehovederne til det ønskede spor og vente på, at den ønskede sektor skal rotere under dem (det er søgelysernes søgnings- og latenstidstider, derfor er de så langsomme). En SSD ville bare elektronisk skifte til den relevante blok, en proces, der er meget hurtig ...
Da den ønskede datablok passerer under læs / skrivehovedet (eller vælges elektronisk på en SSD) kopierer diskcontrolleren dataene fra diskoverfladen (eller fra SSD-cellerne) og ind i programmets buffer (ved hjælp af Direct Memory Access - DMA ). Når det er gjort, hæver diskstyringen en afbrydelse. Afbrydelser er hardware signaler, der får CPU'en til at stoppe udførelsen af den aktuelle tråd (dens status er gemt) og skifte CPU'en til at begynde at udføre afbrydelsesrutinen i enhedsdriveren til den enhed, der hævede afbrydelsen. I vores eksempel bliver det diskdriveren (samme driver som tidligere).
Afbrydelsesrutinen i diskdriveren kontrollerer med diskcontrolleren at dataene er placeret og kopieret og derefter "indsender" ventetiden, med andre ord det signalerer, at den begivenhed, som applikationstråden venter på, er afsluttet. Programmets tråd er nu markeret som klar og vil gå på en CPU-klar kø, der skal sendes. Enhedsdriveren går nu ud, og I / O er færdig.
Når applikationens tråd derefter sendes på en CPU, er indholdet af post 237 nu magisk til stede i bufferen, og applikationen kan begynde at behandle den.
Der er et par nøgle ting at bemærke fra ovenstående ...
1. Drivere kører i kernel-tilstand. (Nogle enkle drivere, som printer og scannerdrivere, kan køre i brugertilstand).
2. Føreren (og enheden) gør alt det tunge løft i en I / O-drift.
Det første af disse observationer, der kører i kernel-tilstand, er en enorm aftale, fordi du i kernel-tilstand kan udføre privilegerede CPU-instruktioner, få adgang til data og kode i ethvert adresserum og potentielt ændre kernen selv. En misbrug eller en ondsindet driver kan forårsage uhyggelig skade på dit system eller skjule det svært at finde malware (keyloggers og lignende). Derudover er Windows-evne til at gendanne fra at opretholde kernekode begrænset, kernekoden skal opføre sig og overholde alle regler, så ofte er den eneste mulighed, Windows har med at opretholde kernekode, at BSOD systemet.
Det andet af disse observationer, drivere (og enhederne) gør alt det tunge løft betyder, at det er helt. afgørende, at førerkoden installeret er designet specielt til den nøjagtige enhed, den administrerer. Brug af den forkerte driver, der ikke forstår fuldt ud, hvordan man styrer enheden, vil ende i tårer (eller mere sandsynligt en BSOD). Derudover er mange drivere ikke skrevet af Microsoft, de er skrevet af hardwareleverandørerne selv (normalt i C og C ++), så kvaliteten af kodningen ikke altid kan garanteres. Vi så i punkt 1. ovenfor, det er også vigtigt, at føreren kun indeholder den kode, der er nødvendig for at styre enheden og ingen anden »mistænkt« kode, det er svært at sikre. Og husk, at drivere er kernekode
Det er også værd at bemærke fra ovenstående, at denne I / O var synkron, fordi den oprindelige ansøgning blev sat i vent, mens I / O blev gjort. De fleste I / O-operationer i Windows er synkrone, men Windows understøtter asynkron I / O. Her er applikationen ikke sat i ventetilstand og kan fortsætte med at udføre, og starter yderligere I / O-operationer uden at vente på den første til at fuldføre. Det betyder, at den oprindelige ansøgning skal kontrollere, om dens I / Os har gennemført og håndteret enhver synkronisering, der er nødvendig mellem dem. Applikationer, der bruger asynkron I / O, er meget sværere at skrive selvfølgelig, og de er meget sværere at debugere også!
Mange drivere kan også bruges til at styre enheden; ændre buffertstørrelser, slå funktioner til og fra mv. I disse tilfælde kaldes ledelsens (i stedet for I / O) -funktionen af en driver direkte enten fra en brugerapplikation eller ved en bestemt administrationsprogram (og undertiden af Windows-applikationer ).
Nogle gange ændrer føreren selv sin adfærd ved I / O-tid, baseret på enten på den applikation, der hedder det eller specielle parametre, der overføres af den kaldende applikation. Dette gøres ved at påberåbe sig "filtre", der er en del af førerkoden selv, enten før eller efter hoveddriverens kode kaldes. Grafiske drivere bruger generelt filtre til at forbedre ydeevnen (eller brugeroplevelsen) i bestemte spil.
Hvordan drivere installeres
Når du downloader en driver, udfører du i almindelighed en form for setup.exe-fil, der installerer driveren til dig, men driverinstallationen i sig selv består af fire hovedtyper af filer, og i dette eksempel lad os kalde enhedens dongle ...
dongle.sys - dette er den egentlige driverkode, og for nogle drivere er der mange .sys-filer inkluderet. Dette skyldes, at mange drivere er lagdelt og kontrol går fra et lag til det andet under en I / O-operation. Åbn Enhedshåndtering, højreklik på en enhed (disk, cd-rom, skærm osv.), Vælg Egenskaber, klik på fanen Driver og derefter på knappen Driverdetaljer. Typisk er det, du vil se, en af flere .sys-filer; Det er disse chauffører selv. Hvis du navigerer til C: \ Windows \ System32 \ Drivers, vil du se alle driveren .sys-filer, der er gemt her, her er de hentet fra ved opstartstidspunktet. Nedenfor er driveren til min DVD / CDROM-enhed .
Driver problemer er den mest almindelige årsag til BSOD'er, men en driver-forårsaget BSOD kan være vanskelig at diagnosticere. Det er ofte ikke muligt for eksempel at pege med nogen tillid til føreren, der faktisk forårsagede BSOD. Derudover skal du i det store flertal af driver-forårsagede BSOD'er være temmelig dygtige til at bruge Windows-fejlfindingsværktøjerne og have en god forståelse for internerne af I / O-operationer i Windows og dets relaterede kontrolblokstrukturer til nøjagtigt identificere den fejlbehæftede driver - og det forudsætter selvfølgelig, at du har en kernel dump-fil til at analysere i første omgang.
Det er ikke at sige, at alle chaufførproblemer resulterer i en BSOD, driverstyring ville være meget enklere, hvis de gjorde det! Driverproblemer kan også forårsage systemnedbrud, hænger, sorte skærme og selvfølgelig et utal af niggly problemer med den eller de enheder, de håndterer.
På grund af ovenstående er det nok værd at bruge lidt tid på at tale om, hvad chauffører er, om hvad de gør, og om hvorfor chaufførfejl ofte resulterer i en BSOD. Vi bør også bruge lidt tid på at tale om, hvad du kan gøre for at reducere risikoen for en driver-forårsaget BSOD (eller faktisk en driver-forårsaget fiasko) og hvilke enkle og logiske trin du kan tage for at identificere den svigtende driver, når du får problemer .
Drivere er en integreret del af Windows I / O-delsystemet, så måske er det første, vi skal gøre, at definere, hvad vi mener ved I / O. I / O står for input / output og alt, hvad der foregår i din pc uden for CPU og RAM er I / O. Når vi taler om 'input', mener vi input til CPU / RAM, og når vi taler om 'output' betyder det output fra CPU / RAM. Uden I / O-kapacitet ville din pc være en ubrugelig boks. Tastaturet og musen er I / O-enheder, skærmen er en I / O-enhed, selv dine diskdrev er I / O-enheder.
Hver I / O-enhed har brug for en driver til at styre den, nogle gange er disse "enhedsdrivere" en del af Windows I / O-delsystemet (f.eks. De grundlæggende mus og tastaturdrivere), nogle gange er de drivere skrevet og leveret af Microsoft (cd'en / DVD-drivere til eksempel), og ganske ofte leveres de af den leverandør, der oprettede enheden (bundkortdrivere for eksempel)
Hvordan jeg / O arbejder
Drivere håndterer det meste af behandlingen, der er involveret i alle I / O-operationer, så det er værd at se på et simpelt overblik over, hvordan en I / O-operation håndteres af Windows for at se, hvor bilisterne passer ind. Som et eksempel tager vi en simpel læseoperation fra en fil på en disk, initieret af en almindelig brugerapplikation (denne forklaring er blevet stærkt forenklet) ...
Vores brugerprogrammets visning af den fil, den bruger, er som en sekventiel liste over poster, der findes 'et eller andet sted', og applikationen vil nu have rekordnummer 237 (for eksempel). Det tildeler således en buffer i virtuel lagring for at holde posten og udsteder en læseanmodning til post 237 (i den angivne fil), og dette sendes til I / O-manager i Windows-kernen.
I / O-manager gør nogle grundlæggende fejlkontrol for at sikre, at I / O-anmodningen er gyldig og komplet, og den sender derefter I / O-anmodningen til den relevante driver til den enhed, som den specificerede fil er bosat (en diskdrev i dette tilfælde). På dette tidspunkt er den oprindelige ansøgnings tråd placeret i ventetilstand og venter på en bestemt begivenhed - afslutningen af denne I / O-operation.
Enhedsdriveren til disken (kører i kernel-tilstand) gør en smule mere kontrol af anmodningen ved hjælp af dens intime kendskab til enheden (som at sikre, at den tildelte buffer er stor nok til at holde posten for eksempel) og derefter oversætter applikationens rekord 237 til en faktisk datablok i et bestemt spor og sektor på en bestemt disk. Hvis den krævede disk er ledig (dvs. ikke midt i en anden I / O-operation), kommunikerer chaufføren med disken ved hjælp af de relevante diskhardwareporte, -registre og -kommandoer for at instruere den til at læse den krævede datablokke fra det angivne spor og sektor. På dette tidspunkt afbryder enhedsdriveren og en ny tråd afsendes på denne CPU.
En harddisk vil nu flytte læse / skrivehovederne til det ønskede spor og vente på, at den ønskede sektor skal rotere under dem (det er søgelysernes søgnings- og latenstidstider, derfor er de så langsomme). En SSD ville bare elektronisk skifte til den relevante blok, en proces, der er meget hurtig ...
Da den ønskede datablok passerer under læs / skrivehovedet (eller vælges elektronisk på en SSD) kopierer diskcontrolleren dataene fra diskoverfladen (eller fra SSD-cellerne) og ind i programmets buffer (ved hjælp af Direct Memory Access - DMA ). Når det er gjort, hæver diskstyringen en afbrydelse. Afbrydelser er hardware signaler, der får CPU'en til at stoppe udførelsen af den aktuelle tråd (dens status er gemt) og skifte CPU'en til at begynde at udføre afbrydelsesrutinen i enhedsdriveren til den enhed, der hævede afbrydelsen. I vores eksempel bliver det diskdriveren (samme driver som tidligere).
Afbrydelsesrutinen i diskdriveren kontrollerer med diskcontrolleren at dataene er placeret og kopieret og derefter "indsender" ventetiden, med andre ord det signalerer, at den begivenhed, som applikationstråden venter på, er afsluttet. Programmets tråd er nu markeret som klar og vil gå på en CPU-klar kø, der skal sendes. Enhedsdriveren går nu ud, og I / O er færdig.
Når applikationens tråd derefter sendes på en CPU, er indholdet af post 237 nu magisk til stede i bufferen, og applikationen kan begynde at behandle den.
Der er et par nøgle ting at bemærke fra ovenstående ...
1. Drivere kører i kernel-tilstand. (Nogle enkle drivere, som printer og scannerdrivere, kan køre i brugertilstand).
2. Føreren (og enheden) gør alt det tunge løft i en I / O-drift.
Det første af disse observationer, der kører i kernel-tilstand, er en enorm aftale, fordi du i kernel-tilstand kan udføre privilegerede CPU-instruktioner, få adgang til data og kode i ethvert adresserum og potentielt ændre kernen selv. En misbrug eller en ondsindet driver kan forårsage uhyggelig skade på dit system eller skjule det svært at finde malware (keyloggers og lignende). Derudover er Windows-evne til at gendanne fra at opretholde kernekode begrænset, kernekoden skal opføre sig og overholde alle regler, så ofte er den eneste mulighed, Windows har med at opretholde kernekode, at BSOD systemet.
Det andet af disse observationer, drivere (og enhederne) gør alt det tunge løft betyder, at det er helt. afgørende, at førerkoden installeret er designet specielt til den nøjagtige enhed, den administrerer. Brug af den forkerte driver, der ikke forstår fuldt ud, hvordan man styrer enheden, vil ende i tårer (eller mere sandsynligt en BSOD). Derudover er mange drivere ikke skrevet af Microsoft, de er skrevet af hardwareleverandørerne selv (normalt i C og C ++), så kvaliteten af kodningen ikke altid kan garanteres. Vi så i punkt 1. ovenfor, det er også vigtigt, at føreren kun indeholder den kode, der er nødvendig for at styre enheden og ingen anden »mistænkt« kode, det er svært at sikre. Og husk, at drivere er kernekode
Det er også værd at bemærke fra ovenstående, at denne I / O var synkron, fordi den oprindelige ansøgning blev sat i vent, mens I / O blev gjort. De fleste I / O-operationer i Windows er synkrone, men Windows understøtter asynkron I / O. Her er applikationen ikke sat i ventetilstand og kan fortsætte med at udføre, og starter yderligere I / O-operationer uden at vente på den første til at fuldføre. Det betyder, at den oprindelige ansøgning skal kontrollere, om dens I / Os har gennemført og håndteret enhver synkronisering, der er nødvendig mellem dem. Applikationer, der bruger asynkron I / O, er meget sværere at skrive selvfølgelig, og de er meget sværere at debugere også!
Mange drivere kan også bruges til at styre enheden; ændre buffertstørrelser, slå funktioner til og fra mv. I disse tilfælde kaldes ledelsens (i stedet for I / O) -funktionen af en driver direkte enten fra en brugerapplikation eller ved en bestemt administrationsprogram (og undertiden af Windows-applikationer ).
Nogle gange ændrer føreren selv sin adfærd ved I / O-tid, baseret på enten på den applikation, der hedder det eller specielle parametre, der overføres af den kaldende applikation. Dette gøres ved at påberåbe sig "filtre", der er en del af førerkoden selv, enten før eller efter hoveddriverens kode kaldes. Grafiske drivere bruger generelt filtre til at forbedre ydeevnen (eller brugeroplevelsen) i bestemte spil.
Hvordan drivere installeres
Når du downloader en driver, udfører du i almindelighed en form for setup.exe-fil, der installerer driveren til dig, men driverinstallationen i sig selv består af fire hovedtyper af filer, og i dette eksempel lad os kalde enhedens dongle ...
dongle.sys - dette er den egentlige driverkode, og for nogle drivere er der mange .sys-filer inkluderet. Dette skyldes, at mange drivere er lagdelt og kontrol går fra et lag til det andet under en I / O-operation. Åbn Enhedshåndtering, højreklik på en enhed (disk, cd-rom, skærm osv.), Vælg Egenskaber, klik på fanen Driver og derefter på knappen Driverdetaljer. Typisk er det, du vil se, en af flere .sys-filer; Det er disse chauffører selv. Hvis du navigerer til C: \ Windows \ System32 \ Drivers, vil du se alle driveren .sys-filer, der er gemt her, her er de hentet fra ved opstartstidspunktet. Nedenfor er driveren til min DVD / CDROM-enhed .