Plotselinge FPS-drops in games: vinden wat ze werkelijk veroorzaakt

Het was 140. Nu is het 70 en dat blijft zo tot je de game herstart — of tot je stopt, de machine laat afkoelen en terugkomt om te merken dat het weer in orde is.

Dat is een ander probleem dan gestotter, en de verwarring tussen die twee kost mensen weken. Gestotter is één te laat frame in een verder gezonde run — is dat wat je hebt, dan is Waarom games stotteren op Windows 11 de pagina die je zoekt. Een drop is een aanhoudende verandering in hoeveel werk de machine per seconde afkrijgt, en bijna alles hieronder kondigt zichzelf aan als je tijdens het gebeuren naar de juiste getallen kijkt.

Eerst de eerlijke zin. Niets op deze pagina maakt een game sneller. Ze laat drie sporen zien die Windows al bijhoudt — resets van het beeldschermstuurprogramma, firmware die de processorklok laag houdt, en de plafonds voor de processor in je actieve energiebeheerschema —, die de stotterscan van w0a voor je leest, en hoe je diezelfde drie in een paar minuten zelf leest.

De drie vragen die het hele veld splitsen

Beantwoord deze voordat je een instelling aanraakt — elke vraag schrapt ongeveer de helft van de lijst.

1. Herstelt hij vanzelf? Een drop die na een minuut stilstaan verdwijnt, wijst op hitte of een achtergrondtaak. Een drop die blijft tot je de game herstart, wijst op de eigen toestand van de game of een gebeurtenis in een stuurprogramma.
2. Gebeurt het in elke game of in één? Elke game wijst naar de machine. Eén game wijst naar de instellingen van die game, naar zijn update of naar zijn servers.
3. Loopt hij mee met de speelduur of met een plek op de map? Tijd betekent hitte en vermogen. Een plek betekent dat de scène zwaarder werd, of dat er iets wordt geladen.

Kijk daarna naar kloksnelheden en temperaturen terwijl het gebeurt, niet achteraf. Een drop die achteraf onzichtbaar is, is live overduidelijk: of een klok viel terug, of niet.

Hitte en het vermogensplafond

Een oorzaak om uit te sluiten bij "hij zakt na twintig minuten in".

Chips gaan niet stuk als ze heet worden, ze worden langzamer. Wordt een temperatuur- of vermogenslimiet bereikt, dan wordt de klok omlaaggetrokken en daar gehouden zolang die toestand duurt. De firmware neemt die beslissing zelf — de bescherming van het moederbord of van de processor, niet van Windows — dus niets in Taakbeheer verklaart het. Aan de grafische kant noemt de driver de reden als je het hem onder belasting vraagt: hittebescherming, een vermogenslimiet die onder de fabrieksinstelling is gezet, een programma dat de driver vraagt terug te klokken, of een PCIe-voedingsstekker die niet goed vastzit.

Hoe je het ziet: het loopt mee met de speelduur en met de kamertemperatuur, en de klok is tijdens de drop zichtbaar lager dan bij de start.

Wat je doet: de montage van de koeler, stof, de luchtstroom in de kast. Kijk daarna of een vermogenslimiet met opzet is verlaagd — in de firmware, in een programma van de fabrikant, of in een opgeslagen profiel van de videokaart.

De machine wisselde van energietoestand

Laptops doen dit het duidelijkst: haal de lader eruit en het platform stapt over op een andere set limieten. Op desktops gebeurt het ook — een gewijzigd energiebeheerschema, core parking of een plafond op de processorstatus dat een ouder tuningscript heeft achtergelaten, een schema dat na een Windows-update is teruggevallen.

Hoe je het ziet: de drop begint bij een gebeurtenis — de stekker eruit, het deksel, ontwaken uit de slaapstand, een herstart — niet bij een temperatuur.

Wat je doet: zet de eigen standaardwaarden van het schema terug in plaats van nieuwe waarden te verzinnen. De pagina Fix heeft kaarten voor het energiebeheerschema en voor de processor-energie-instellingen, en elke kaart schrijft de Windows-standaard onvoorwaardelijk terug, welk programma hem ook heeft veranderd.

Een driverreset

Het scherm wordt een seconde of twee zwart, komt terug, en alles is trager — of de game is gesloten. Windows heeft vastgelegd dat het beeldschermstuurprogramma vastliep en is gereset.

Hoe je het ziet: dit laat een duidelijk spoor na, en de stotterscan meldt hoeveel resets er de afgelopen dag zijn geweest. Het spoor wijst meestal naar een overklok of naar de koeling, niet naar software.

Wat je doet: heb je een offset op het geheugen of op de kernen staan, halveer die dan en speel één partij als test; zet hem daarna op nul en test opnieuw. Herstel na een GPU-crash behandelt de rest, inclusief het terugzetten van de Windows-standaard als een ouder programma de time-out heeft verhoogd in plaats van de oorzaak op te lossen.

Drie sporen die Windows al bijhoudt

1. Een reset van het beeldschermstuurprogramma (gebeurtenis 4101)

Wanneer het beeldschermstuurprogramma niet meer reageert en opnieuw wordt ingesteld, schrijft Windows gebeurtenis 4101 naar het gebeurtenislogboek System. De stotterscan telt die van de afgelopen 24 uur en meldt ze als zijn enige kritieke bevinding; boven tien zegt hij "10+" in plaats van te doen alsof hij het precieze aantal kent. Kan het logboek zelf niet worden gelezen, dan zegt de scan dat de controle niet kon draaien in plaats van de machine schoon te verklaren.

Om zelf te kijken, in PowerShell:

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Display'] and (EventID=4101) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 10

Zijn er geen, dan antwoordt PowerShell met een fout die zegt dat geen gebeurtenissen aan de selectiecriteria voldoen: dat is het antwoord "geen in de afgelopen dag". Zegt het dat het het logboek niet kan lezen, start PowerShell dan als administrator en probeer het opnieuw.

De weg terug is die uit de sectie hierboven: verlaag of verwijder een overklok, kijk naar de koeling, en Herstel na een GPU-crash als een ouder programma de time-out van het stuurprogramma heeft verhoogd. w0a verhoogt die time-out zelf niet: een langere watchdog maakt elke bevriezing alleen langer, en het herstel uitschakelen haalt het helemaal weg.

2. De firmware hield de klok laag (gebeurtenis 37)

Gebeurtenis 37 van Microsoft-Windows-Kernel-Processor-Power is de firmware die vastlegt dat hij de processorklok omlaag heeft gehaald en hele seconden achter elkaar daar heeft gehouden; de tekst van de gebeurtenis zelf zegt hoe lang. Dat telt, omdat een temperatuurmeting alleen het moment laat zien waarop je kijkt: een machine die een uur geleden terugklokte en sindsdien is afgekoeld, ziet er volkomen gezond uit, en deze gebeurtenis is het enige spoor van dat uur dat erop achterblijft.

De scan telt ze over de afgelopen 24 uur, alleen op netstroom — op de accu is dezelfde gebeurtenis het platform dat zijn werk doet — en waarschuwt vanaf drie. Eén of twee zijn gewoon in de eerste seconden na het opstarten, terwijl het moederbord zijn vermogenslimieten instelt.

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-Kernel-Processor-Power'] and (EventID=37) and TimeCreated[timediff(@SystemTime) <= 86400000]]]" -MaxEvents 20

Laat de naam van de provider in het filter staan. Andere onderdelen gebruiken het nummer 37 voor gebeurtenissen die er niets mee te maken hebben, en een telling zonder de provider betekent niets.

Vind je er een hele reeks van, dan is de oorzaak hitte of een vermogenslimiet, zoals in de sectie over hitte hierboven; CPU- en GPU-temperaturen tijdens het gamen legt uit wat je moet aflezen, en op een laptop behandelt Gaming-laptop trager dan hij zou moeten zijn de lader en de energiemodi.

3. Het actieve schema begrenst de processor

De naam van een schema is niet wat er draait. Een schema voor hoge prestaties met de maximale processorstatus op 80% is een begrensde machine met het juiste etiket. De scan leest vier instellingen uit het processorgedeelte van het schema dat actief is, op netstroom:

De scan leest deze instellingen via de energie-interface van Windows en niet via powercfg, omdat er op een standaardinstallatie twee verborgen zijn en powercfg voor die twee helemaal niets toont. Kan hij geen van de vier lezen, dan zegt de scan dat hij niet kon meten, niet dat het schema schoon is.

Om zelf te kijken, in de opdrachtprompt of in PowerShell:

powercfg /getactivescheme
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PROCTHROTTLEMAX
powercfg /query SCHEME_CURRENT SUB_PROCESSOR IDLEDISABLE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR PERFBOOSTMODE
powercfg /query SCHEME_CURRENT SUB_PROCESSOR CPMINCORES

Zo lees je de antwoorden:

• De waarde staat op de laatste twee regels van het antwoord, hexadecimaal: de eerste is de waarde op netstroom (AC), de tweede de waarde op de accu (DC). 0x00000064 is 100, 0x00000050 is 80, 0x00000001 is 1, 0x00000000 is 0.
• De namen van de instellingen rond de getallen worden in de taal van je Windows getoond; de aliassen die je typt (SUB_PROCESSOR, PROCTHROTTLEMAX) zijn in elke taal hetzelfde.
• Bestaat het hele antwoord uit één regel met de GUID van het schema en niets eronder, dan vraagt de opdracht naar een instelling die Windows op deze installatie verbergt. Dat zegt niets over de waarde ervan; de stotterscan is de manier om hem te lezen.

De weg terug, instelling voor instelling:

• PROCTHROTTLEMAX of CPMINCORES, geschreven in de eigen schema's van Windows: de kaart Processor-energie-instellingen zet de minimale en maximale processorstatus en core parking terug op de standaardwaarde die elk schema zelf opgeeft, en past daarna het actieve schema opnieuw toe, omdat Windows de waarden van een schema leest wanneer het wordt geactiveerd.
• Een plafond dat in een schema zit dat een programma heeft aangemaakt: de kaart Energieplan en accu schakelt eerst over naar Gebalanceerd, zodat dat schema niet langer het schema is dat draait, en verwijdert de eigen schema's van w0a.
• PERFBOOSTMODE of IDLEDISABLE: vandaag zet geen enkele reparatiekaart deze twee bij naam terug. De weg terug is het schema zelf, met powercfg, naar de waarde die het schema als standaard opgeeft.

Het gebeurde vlak na een update

Hier gaan twee heel verschillende dingen schuil.

Een update van de game of de driver maakt de shadercache ongeldig, en de game compileert opnieuw terwijl je speelt. De framerate is een tijdlang echt lager en daarna niet meer. Hij zakt weg; dat is het kenmerk. Stotteren door shadercompilatie legt uit waarom, en waarom je in dat venster niet moet benchmarken.

Een regressie in een driverbranch zakt niet weg. Fabrikanten geven die op schrift toe — in release notes staan regels als "lagere prestaties in deze titel op branches nieuwer dan X". Ga niet uit reflex terug naar een oudere versie: maak je updates af, meet op je eigen machine, en overweeg pas een andere versie als je de regressie zelf kunt documenteren.

Er is iets anders gaan draaien

Een geplande scan, een updateproces dat uitpakt, een archief dat wordt uitgepakt, een video-export. Het staat in de wachtrij voor dezelfde kernen als de game en verdwijnt, anders dan een hapering, niet tussen twee frames — vaak reproduceerbaar op een bepaald tijdstip van de dag. Het totale CPU-gebruik is het verkeerde getal om naar te kijken: één verzadigde kern op een achtkernsmachine leest als een bescheiden totaal. Wacht het af, of verzet het werk.

De framerate is helemaal niet gedaald

Een limiet. Is het getal waar je op uitkomt precies je verversingsfrequentie, je limiet in de game of een limiet van de driver, dan zit er nergens een flessenhals — je zit tegen het plafond dat je zelf hebt gevraagd.

Dynamische resolutie. Een game die zijn eigen renderresolutie schaalt om een doelframerate vast te houden, laat een stabiele teller zien terwijl in plaats daarvan de beeldkwaliteit beweegt.

Het is één game, en de teller ziet er goed uit

Dan zit de drop misschien helemaal niet op jouw machine. Een online partij loopt voor iedereen op de server tegelijk terug, en netwerkellende is geen framerateprobleem: pakketten die te laat aankomen laten de wereld om je heen stotteren terwijl je machine op volle snelheid blijft tekenen. Zijn de frametijden gezond dwars door het voorval heen, stop dan met naar de pc te kijken.

Is de framerate in plaats daarvan gewoon lager dan hij zou moeten zijn terwijl de videokaart niets doet, dan is dat een eigen diagnose met een eigen lijst: GPU niet op 100% werkt die op volgorde af.

Een run die een antwoord oplevert

1. Maak een opname van een normale sessie voordat er iets mis is, en bewaar die. De benchmark lezen legt uit hoe, en waarom het gemiddelde daar het minst bruikbare getal is.
2. Gebeurt de drop, noteer dan kloksnelheden en temperaturen tijdens de drop, niet erna.
3. Verander één ding, en herhaal daarna dezelfde scène en dezelfde sessieduur.
4. Beoordeel het tegen je eigen variatie van run tot run. Verschillen drie ongewijzigde runs meer dan het verschil waar je blij mee bent, dan heb je ruis gevonden.

Wat je bij een drop niet moet doen

Verhoog de hersteltime-out van de GPU-driver niet om een driverreset te verbergen: het maakt van een kort herstel een langere bevriezing en haalt het bewijs weg. Schakel geen kernen of simultaneous multithreading uit op gezag van een gids zonder bronnen — je zou bekende meerkernscapaciteit inruilen voor een winst waar niemand een methode voor heeft gepubliceerd. En pas geen kernelwaarden voor geheugenbeheer toe als prestatie-oplossing; dit product weigert ze te schrijven, en geen enkele meting ondersteunt ze.

Hetzelfde geldt voor de energie-instellingen: geen van de vier hierboven is een "prestatie"-schakelaar die je de andere kant op moet zetten. Met turbo uit blijft de processor op zijn nominale klok, en de eigen scan van w0a markeert uitgeschakelde rusttoestanden ook als begrenzing, waar hij ze ook vindt.

Gerelateerd

• Waarom games stotteren op Windows 11
• GPU niet op 100%
• Stotteren door shadercompilatie
• Herstel na een GPU-crash
• Wat de stotterscan zoekt
• CPU- en GPU-temperaturen tijdens het gamen