Höga CPU-användningstoppar per system eller svchost.exe – Steg-för-steg teknisk guide

Att se höga CPU-toppar från System eller svchost.exe kan förvandla vilken dag som helst till en mardröm, Eftersom din dator är långsam, fläktarna dånar och allt verkar gå obemärkt förbi. Den goda nyheten är att det med ett organiserat tillvägagångssätt är möjligt att identifiera vilken tjänst, leverantör eller applikation som är ansvarig och implementera en effektiv lösning.

I den här praktiska guiden guidar jag dig steg för steg, Från att identifiera den faktiska CPU-förbrukande processen (System, svchost.exe eller WmiPrvse.exe) till att isolera problematiska WMI-frågor, dela upp tjänster, mäta användning med Perfmon, granska drivrutiner och åtgärda typiska orsaker som systemavbrott, skadlig kod eller föråldrade konfigurationer. Tanken är att gå från "varför körs det på 100 %?" till "Jag vet exakt vad som orsakar det och hur man kan mildra det."

Identifiera den exakta processen och dess PID

Det första steget är att ta reda på vilken binärkod och PID som förbrukar CPU, och om den verkliga boven i dramat är WmiPrvse.exe (WMI-leverantörens värd), svchost.exe (som är värd för Winmgmt/WMI) eller själva systemet (system- och kärnavbrott).

Från Uppgiftshanteraren Gå till fliken Detaljer och sortera efter Namn eller CPU, Leta reda på den körande WmiPrvse.exe eller svchost.exe och anteckna dess PID. I Tjänster (i Aktivitetshanteraren), leta reda på Winmgmt, anteckna dess PID och använd Gå till detaljer för att gå till svchost.exe som är värd för den. Detta kommer att göra det tydligt vilken specifik instans som körs som hetast.

Observera användningsmönstret: Regelbundna toppar, ihållande förbrukning, slumpmässig förbrukning, endast under arbetstid eller vid in-/utloggning? Dessa uppgifter är värdefulla för korrelation med uppgifter, skript, övervakningsverktyg eller appar från tredje part som utlöser WMI.

Mätning och korrelation med Performance Monitor (Perfmon)

Perfmon låter dig korsreferera PID med en grafisk vy av % CPU, och avgöra exakt vilken instans av WmiPrvse.exe eller svchost.exe som förbrukar resurser.

1. Öppna en kommandotolken upphöjd och avrättad perfmonVälj Prestandamonitor och tryck på +-knappen för att lägga till räknare.
2. Lägg till räknaren "Process \ Process-ID" och väljer alla WmiPrvse#-instanser (eller svchost# om tillämpligt). Värdena för Last/Average/Minimum/Maximum återspeglar PID: ta bort alla som inte matchar det PID du riktar in dig på med Del.
3. Lägg nu till "Process \ % Processortid" på den exakta instansen (t.ex. WmiPrvse#1) som matchar det varma PID:t, och observera förbrukningskurvan i realtid.

Har svchost.exe många tjänster? Kontrollera vilka som påverkar din WMI med: tasklist /svc /fi "Services eq Winmgmt"Om du vill isolera WMI i en egen process för att bättre diagnostisera eller begränsa påverkan, använd:

sc config Winmgmt type= own
net stop winmgmt && net start winmgmt

När du har löst problemet kan du återställa det till den delade processen. med sc config Winmgmt type= share och starta om WMI-tjänsten.

Inspektera processen inifrån: WMI-resurser och leverantörer

Fokusera inte bara på processorn: kontrollera minne, handtag, trådar och användare av PID:t på fliken Detaljer i Aktivitetshanteraren. Om det finns läckor i handtag eller för många trådar förstärker detta hypotesen om en ineffektiv WMI-leverantör eller klient.

Identifierar WMI-providers (DLL:er) som laddats in i den specifika WmiPrvse.exe, Till exempel, med Process Explorer (kör den som administratör): öppna egenskaperna för WmiPrvse.exe med det PID du undersöker och på fliken Providers ser du detaljer som Providernamn, namnrymd och DLL-sökväg. Ett typiskt fall är MS_NT_EVENTLOG_PROVIDER i root\CIMV2 med DLL-filen %systemroot%\system32\wbem\ntevt.dllFör fler tekniker, kolla in Analys av schemalagda frågor och leverantörer i WMI.

Om problemet är intermittent och WmiPrvse.exe återvinns kan du snabbt hitta instansen som innehåller en viss DLL med: tasklist /m <Proveedor.dll>. Exempel: tasklist /m ntevt.dll.

Granska inkommande frågor till WMI (Event Viewer)

Microsoft-Windows-WMI-aktivitetsloggen är din radar, eftersom den återspeglar varje inkommande WMI-operation och anger vilken fråga som kom från vilket klient-PID, med vilken användare och mot vilken klass/namnrymd.

Aktivera och granska två källor: Drifts- och analys-/felsökningsloggar. I Loggboken går du till Program- och tjänstloggar > Microsoft > Windows > WMI-aktivitet. I Visa-menyn väljer du "Visa analys- och felsökningsloggar" och aktiverar loggning under Spåra och felsöka. Håll dem aktiva medan du registrerar CPU-spiken och exportera sedan till .csv eller .xml.

Viktiga händelser och hur man tolkar dem: Id. 11 (T.ex. operationsstart) IWbemServices::ExecQuery o CreateInstanceEnum) och ID 12 (ProviderInfo, mappar operationen till HostId/PID och provider-DLL-filen). I beskrivningen ser du fält som CorrelationId, GroupOperationId, OperationId, Operation, ClientMachine, User, ClientProcessId, NamespaceName och själva frågan, till exempel: select * from Win32_Product o CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent.

Med några filter på klassen (t.ex. "Win32_NTLogEvent") och HostId/PID, Du kommer att kunna lista sekvenser av typen: Början av CreateInstanceEnum kontra Win32_NTLogEvent från klient-PID 5484, mappad till MS_NT_EVENTLOG_PROVIDER på värd-ID 556 (din aktiva WmiPrvse.exe) vars DLL är ntevt.dllDenna korsreferens ger dig slutligen klientprocessen som originerar inläsningen.

WMIMon: Liveövervakning av WMI-anrop

Om du vill ha en snabb, direktsänd översikt över vem som ringer WMI och hur ofta, Det publika verktyget WMIMon.exe (projektet «luctalpe/WMIMon» på GitHub) är mycket användbart för att lista klient-PID, namnrymd, klass och användare per operation.

1. Ladda ner WMIMon och kör det med förhöjt behörighet. helst efter att ha identifierat WmiPrvse.exe med hög processorhastighet, för att fånga det kritiska ögonblicket.
2. Låt den samla in WMI-aktivitet några minuter och analysera vilka PID:er som efterfrågas i en loop och vilka klasser (det typiska mönstret för dåligt utformade övervakningsprober eller skript).

Om du inte kan begränsa dig till en specifik app, grupperad efter användarkonto eller källdator; ofta är det ett servicekonto som är kopplat till ett inventeringsverktyg, SCCM (PolicyAgent/Övervakningsvärd) eller manus av Power som konsulterar för mycket eller med löjligt korta intervall.

Korrigerande åtgärder på WMI och relaterade tjänster

När du väl har den misstänkte, vidta först icke-förstörande åtgärder: Inaktivera tjänsten tillfälligt för det programmet, stoppa övervakningsagenten eller åtgärda problemet skript (fråga efter specifika egenskaper, använd filter, öka intervall, undvik problematiska klasser som Win32_Product (vilket är långsamt). Se om processorn sjunker.

Om svchost.exe grupperar för många tjänster och gör det svårt för dig att isolera dem, lämnar Winmgmt i sin egen process med sc config Winmgmt type= own, starta om WMI och upprepa mätningarna. Detta begränsar sprängradien och gör diagnosen enklare. För en djupare titt på optimering, kolla in förbättra WMI-prestanda.

För avancerad Microsoft-support, Du kan fånga allt med TSS-paketet (Troubleshooting Script Set) som körs i förhöjd PowerShell: .\TSS.ps1 -UEX_WMIBase -WIN_Kernel -ETWflags 1 -WPR CPU -Perfmon UEX_WMIPrvSE -PerfIntervalSec 1 -noBasicLogNär det är klart genereras en ZIP-fil som innehåller ETW, Perfmon, WPR med mera, redo för uppladdning.

System och systemavbrott: När kärnan höjer räkningen

Om "System"-processen (systemavbrott) ligger runt 5–10 % ihållande eller med toppar, Det finns förmodligen en förare eller hårdvara orsakar problem (DPC:er och latenser). Här ändras fokus: det är dags att diagnostisera drivrutins- och enhetslatens.

Kom igång med DPC Latency Checker och LatencyMon: Den första varnar dig för latensspikar i kärnan; den andra talar om vilka drivrutiner (t.ex. ljud, nätverk, lagring, USB) genererar förlängda DPC:er. Om du ser röda staplar eller markerade drivrutiner är du redan informerad.

Stäng av misstänkta i delar av Enhetshanteraren, tillfälligt inaktivera nätverkskort, internt ljud, inspelningskort, PCI/PCIe/USB-hubbar etc. Observera effekten på processorn i "Systemavbrott". Återaktivera det som inte påverkas och fortsätt iterera tills du hittar komponenten.

Koppla bort externa kringutrustningar (inklusive USB-hubbar) en i taget samtidigt som du håller ett öga på Aktivitetshanteraren. Om det är krångligt, inaktivera USB-hubbar från Enhetshanteraren (var försiktig om din mus/tangentbord är beroende av dem: ha en alternativ fjärrkontroll).

Uteslut inte skadad hårdvara eller instabil strömförsörjning: En felaktig strömförsörjning eller laddare till en bärbar dator kan orsaka IRQ/DPC-toppar. Den enda lösningen är ibland att tillfälligt byta ut den och testa.

Försök att inaktivera ljudeffekter i äldre Windows (t.ex. 7), vilket ibland utlöser latenser: Ljudpanelen > Uppspelningsenheter > Högtalaregenskaper > fliken Effekter > Inaktivera effekter.

Håll din BIOS/UEFI uppdaterad och kontrollera dess version innan du uppdaterar: öppnas CMD och spring systeminfo | findstr /I /c:bios y wmic bios get manufacturer, smbiosbiosversionFölj sedan tillverkarens procedur med största noggrannhet för att undvika att kortet brickas.

Allmänna åtgärder för att tämja CPU-toppar

• Stäng appar du inte använder och undvik extrem multitasking, Särskilt om du har dussintals flikar eller processer som körs i bakgrunden; frigör resurser och se om din CPU sjunker under 90-100%.
• Uteslut skadlig kod med en fullständig, aktuell skanning, Eftersom adware, miners och maskar ofta slukar processorn, skanna både systemet och externa hårddiskar.
• Uppdatera buggbenägna drivrutiner och programvara, särskilt nätverk, ljud och grafik. En föråldrad Wi-Fi-drivrutin kan vara tillräckligt för att överbelasta processorn efter en Windows-uppdatering.
• Justerar effekten för att undvika termisk strypning eller onödiga begränsningar, med hjälp av en balanserad plan och, om du behöver mildra punktlig värme, begränsa "Maximal processorstatus" till 90 % från de avancerade energialternativen.
• Minskar brus från aviseringar och bakgrundsprocesser i Windows, inaktivera icke-bidragande aviseringar och leveransoptimering (Windows Update > Avancerade alternativ > Leveransoptimering > Tillåt descargas från andra enheter: Inaktiverad).
• Om du inte använder Cortana kan du inaktivera dess hjälptjänst i registret, kommer in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TokenBroker och etablerande Start en 4 (vänligen säkerhetskopiera registret först).
• Starta om WMI Provider Host (Winmgmt) när den hänger sig. Från Tjänster: Sök efter "Windows Management Instrumentation" och tryck på Starta om och bekräfta om CPU-användningen minskar.
• Glöm inte bort det fysiska underhållet: Damm på fläktar och kylflänsar höjer temperaturen, och processorn skyddar sig själv genom att sänka frekvensen; rengör med tryckluft och kontrollera luftflödet.

svchost.exe (tjänstvärd: lokalt system) förbrukar CPU

svchost.exe är en servicebehållare och inte ett enskilt program, Så topparna beror vanligtvis på en av de värdbaserade tjänsterna (Windows Update, WMI, nätverk, etc.).

För att identifiera den specifika tjänsten: I Aktivitetshanteraren > Processer, expandera "Tjänstvärd: Lokalt system" och titta på användningen per tjänst; eller använd tasklist /svc och matcha PID:er med tjänster. Om WMI är boven i dramat, gå tillbaka till avsnittet WMI-diagnostik.

Typiska steg som hjälper: Starta om datorn, kör ett antivirusprogram, uppdatera drivrutiner, kör Windows Update, inaktivera tillfälligt icke-nödvändiga tjänster (med försiktighet) och granska ditt energischema. Att hålla systemet och apparna uppdaterade minskar inkompatibiliteter som orsakar strömavbrott.

På en förebyggande nivå, Använd övervakningsverktyg för att upptäcka avvikande toppar, konfigurera automatiska uppdateringar, förhindra tvivelaktiga nedladdningar och utföra rensning och defragmentering när det är tillämpligt.

Företags- och VDI-miljöer (Citrix): Att beakta

Om din miljö är Citrix (XenApp/XenDesktop/StoreFront/PVS), Observera att det finns flera kända problem som kan påverka stabilitet, strömförbrukning och sessionsupplevelse. Även om de inte är den typiska orsaken till System/svchost.exe-toppar, är de värda att vara medveten om.

Exempel på berörda områden som anges i versionsinformationen: Citrix Studio (licensiering, publicering med offerter, domänupplösning, långsamhet med frånkopplade kontrollanter, App-V med duplicerat ApplicationID, uppdateringsloopar, problem med att lägga till leveranskontroller/SQL-spegling); Provisioneringstjänster (guider med SCVMM/ESX, vDisk-replikering, SOAP-timeout på grund av oåtkomliga domäner, svartlistning av domäner i %ProgramData%\Citrix\Provisioning Services\blacklist.json); StoreFront (mappfärg, kraschar vid anpassning av CSS, federerad autentisering, självbetjäning, återanslutningar till flera webbplatser); VDA/Receiver (Framehawk, Urklipp, skärmlås, ljud, flera bildskärmar, virtuella kanaler, SDK:er); integrerad App-V (synkronisering, specialtecken i namn, publicering från mappade enheter).

Snabba tips om Citrix: Underhåller versioner som stöds, granskar snabbkorrigeringar (ID:n som LCxxxx), validerar App-V och SCCM i labbet, övervakar VDA:er och leveranskontroller efter ändringar och dokumenterar tidsmässig korrelation mellan CPU-toppar och Citrix-uppgifter (kataloguppdateringar, MCS/PVS, Director, etc.).

När är 100 % CPU "normal" och när är det inte?

Att rendera video, kompilera eller installera stora uppdateringar kan tillfälligt öka din processorhastighet till 90–100 %. Och det är förväntat om det sedan sjunker under 10 % i vila eller till 10–30 % vid lätt användning. Om 100 %-nivån kvarstår utan motiverade åtgärder är ingripande nödvändigt.

Om du har kommit så här långt har du redan en komplett färdplan: Identifiera PID och den faktiska processen, mät och korrelera med Perfmon- och WMI-loggar, lokalisera leverantören och klienten, vidta korrigerande åtgärder (optimera frågor, dela upp tjänster, finjustera drivrutiner och strömförsörjning), åtgärda vanliga orsaker (skadlig programvara, dust, kringutrustning) och, i företagsmiljöer, var medveten om särdragen hos Citrix och App-V. Med metod och tålamod upphör dessa toppar att vara ett mysterium och är nu under kontroll.