Fix Windows 11 langsom login (2026)

Q: Hvordan tjekker jeg hvad der gør min Windows 11-login langsom?

Brug Windows Performance Recorder ( wpr.exe -boottrace ) til at fange et komplet ETL-spor, og læs det i Windows Performance Analyzer. Kombinér med Event Viewer (Group Policy og User Profile Service Operational-logs) og gpresult /h . Det giver dig objektive millisekundtal for hver fase i login-sekvensen.

Opdateret: 17. september 2026

Langsom login i Windows 11 skyldes i 90 % af de sager, jeg får ind på helpdesken, én af fire ting: for mange synkrone Group Policy-udvidelser, en oppustet roaming-profil eller FSLogix-container, netværksdrev der ikke svarer inden for timeout, eller en tredjeparts-tjeneste (Sophos, CrowdStrike, Cisco AnyConnect) der starter synkront under Winlogon. Denne runbook viser præcist hvordan du måler hvor sekunderne forsvinder, læser de rigtige Event IDs, og fikser det uden at gætte. Målgruppen er 1st/2nd line helpdesk der arbejder mod Windows 11 24H2 klienter i et hybrid-joined Entra ID / Active Directory-miljø.

En sund Windows 11-login på firmahardware bør være under 30 sekunder ved cachet login og under 60 sekunder ved første netværkslogin efter genstart. Alt over det er en incident, ikke "sådan er det bare".
Læs Microsoft-Windows-GroupPolicy/Operational Event ID 8001 og 5312 for at se præcis hvor mange millisekunder hver CSE (Client-Side Extension) bruger. Det udpeger den skyldige GPO uden gætværk.
Windows Performance Recorder (wpr.exe) med OnOffTransition-profilen giver dig et komplet boot- og logon-spor du kan læse i Windows Performance Analyzer.
FSLogix-containere over 30 GB, defekte VHDX-filer eller manglende antivirus-eksklusioner er den hyppigste årsag til lange logins i VDI- og AVD-miljøer.
Slå synchronous foreground policy processing til hvis Folder Redirection, Drive Maps eller Software Installation opfører sig upålideligt, men vær opmærksom på at det gør logins længere, ikke kortere.
Startup-forsinkelse fra tredjeparts EDR og VPN-klienter kan reduceres med Delayed Start og betingede opstartsudløsere frem for at deaktivere sikkerhedsprodukter.

Hvad er en normal login-tid i Windows 11?

Så, før du fejlsøger noget som helst, skal du vide hvad du sammenligner med. På moderne hardware (NVMe SSD, mindst 16 GB RAM, kablet netværk eller stærk Wi-Fi 6) er de tal jeg selv bruger som intern SLA på min egen helpdesk:

Cachet login (bruger logget ind før, ingen ny GPO): 8–20 sekunder til skrivebordet er brugbart.
Første login efter en ren installation eller Autopilot ESP: 45–90 sekunder, hovedsageligt begrænset af netværk og Intune-policy-anvendelse.
Første login på en delt session-host (AVD/Citrix) med FSLogix: 25–45 sekunder ved sund container, op til 2 minutter når containeren er over 20 GB.
Login efter en Feature Update (fx 23H2 → 24H2): 60–120 sekunder. Det er engangs-cost af at anvende nye policies og profil-migration.

I mit sidste miljø målte jeg medianen for 4.000 kablede firma-laptops til 14 sekunder ved cachet login. Alt over 45 sekunder på cachede logins er en outlier og fortjener et ticket. Målet er ikke at slå rekord. Målet er at have tal at teste mod, så du kan afgøre om ændringen du netop foretog gjorde login hurtigere eller langsommere.

Hvor forsvinder tiden under login?

Et Windows 11-login er ikke ét trin. Det er en sekvens af faser, og hver fase kan blive den langsomste. Kender du fasenavnene, kan du læse ETL-spor og Event Logs som en historie i stedet for tilfældige tal.

PreShell-init: Winlogon starter, Credential Providers indlæses, LSA validerer tokenet mod Entra ID/AD.
User Profile Load: Profilen mountes (enten en lokal profil, en roaming-profil, eller en FSLogix VHDX). Det er her User Profile Service (ProfSvc) Event IDs 1, 2, 3, 4, 67 lever.
Group Policy Foreground: Computer- og bruger-GPO'er anvendes. Client-Side Extensions (CSE'er) som Folder Redirection, Drive Maps, Scripts, Software Installation kører her.
Logon Scripts og Startup Scripts: PowerShell/CMD/VBS-scripts konfigureret som synkrone kører i denne fase.
Explorer / Shell init: explorer.exe starter, Start-menuen og taskbar tegnes, OneDrive og andre auto-run-programmer boot'er.
Auto-run programmer: Alt i HKCU\Software\Microsoft\Windows\CurrentVersion\Run, Startup-mappen og Scheduled Tasks med "At logon"-udløser.

Hvis en bruger klager over "langsom login", er dit første job at afgøre hvilken af de seks faser der er skyldig. Windows Performance Recorder viser dette direkte. Uden det ender du med at deaktivere tilfældige ting og krydse fingre, og det gør både brugeren og din compliance-officer utilfredse.

Første triage: 5 minutter ved brugerens skrivebord

Før du åbner nogen avanceret trace, foretag denne triage. Den fanger ca. 60 % af sagerne uden yderligere værktøjer.

1. Verificér hardware- og netværksbaseline

Get-ComputerInfo | Select-Object CsName, WindowsVersion, OsBuildNumber, CsTotalPhysicalMemory
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, HealthStatus, Size
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name, LinkSpeed, MediaType

En HDD i 2026 er en dødsdom for login-hastighed. Hvis MediaType er HDD, er sagen løst: udskift disken eller send maskinen til reimaging. Kablet Ethernet på 1 Gbps eller Wi-Fi 6/6E er baseline; alt under det bør du logge som en medvirkende faktor.

2. Sammenlign en anden bruger på samme maskine

Log ind som en test-konto (fx en helpdesk-service-konto) på samme maskine. Er login stadig langsomt, ligger fejlen i maskinen eller GPO'en. Er login hurtigt, ligger fejlen i brugerens profil eller bruger-GPO'er. Denne enkle isolation sparer dig ofte en time.

3. Tjek profilstørrelse

# Størrelse på brugerens lokale profil
$user = 'jdoe'
Get-ChildItem "C:\Users\$user" -Recurse -ErrorAction SilentlyContinue |
    Measure-Object -Property Length -Sum |
    Select-Object @{N='SizeGB';E={[math]::Round($_.Sum/1GB,2)}}

Lokale profiler over 10 GB er en advarselslampe. Roaming-profiler over 5 GB er en katastrofe der venter på at ske. FSLogix-containere over 30 GB skal defragmenteres eller nulstilles.

4. Slå automatisk login-optimering til

Windows 11 har en indbygget "Fast Startup" der er slået fra på firmahardware af mange OEM-images. Kontrollér med:

powercfg /a
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power' -Name HiberbootEnabled

Bemærk: Fast Startup løser ikke selve login-fasen, det springer kun boot over. For firmaklienter er fordelen minimal, og det kan skabe konflikter med BitLocker og Windows Update. Slå det til på privathardware, lad det være slået fra på flåden.

Event Viewer: læs Group Policy og User Profile Service

Det næste værktøj er Event Viewer. Vi kigger på to logs der giver dig 80 % af sandheden om hvor tiden forsvinder.

Microsoft-Windows-GroupPolicy/Operational

Dette log er guld. Filtrér på Event ID 8001 (det er "Group Policy processing completed") og se feltet Elapsed time. Så filtrér på 5312 og 5313 for at se hver enkelt CSE med sin egen tid. Eksempel-forespørgsel via wevtutil:

wevtutil qe Microsoft-Windows-GroupPolicy/Operational `
  /q:"*[System[(EventID=8001)]]" /c:5 /rd:true /f:text

Hvis du ser at Event ID 5312 for CSE "Folder Redirection" bruger 42 sekunder, har du fundet skurken. Almindelige tunge CSE'er:

Folder Redirection ({25537BA6-77A8-11D2-9B6C-0000F8080861}): flytter Dokumenter/Skrivebord/Billeder til en netværksshare. Langsom netværksshare = langsom login.
Group Policy Drive Maps ({5794DAFD-BE60-433f-88A2-1A31939AC01F}): venter på hver netværkssti.
Group Policy Scripts ({42B5FAAE-6536-11D2-AE5A-0000F87571E3}): synkrone PowerShell/CMD-scripts.
Group Policy Software Installation ({C6DC5466-785A-11D2-84D0-00C04FB169F7}): deployerer MSI-pakker. Meget dyrt hvis kombineret med synchronous foreground processing.

Microsoft-Windows-User Profile Service/Operational

Filtrér på Event ID 1 (login begyndt) og Event ID 4 (login afsluttet). Forskellen mellem timestamps er præcist hvor lang tid profil-load tog. Er Event ID 1530 til stede? Så har du et låst registry hive der forhindrer profilen i at unloade, og det gør efterfølgende logins langsommere.

For dybere baggrund om at diagnosticere hvorfor GPO'er slet ikke anvendes (relateret men adskilt fra hastighed), se vores guide til Group Policy der ikke anvendes på Windows 11.

Windows Performance Recorder: mål præcist hvor sekunderne bruges

Når Event Logs ikke er nok, eller når du skal bevise over for en applikationsejer at deres agent bruger 14 sekunder under login, er Windows Performance Recorder (WPR) og Windows Performance Analyzer (WPA) svaret. WPR er en del af Windows ADK og fanger et ETW-spor af hele boot/logon-sekvensen.

# Installer ADK Performance Toolkit hvis ikke allerede installeret
# https://learn.microsoft.com/windows-hardware/get-started/adk-install

# Start OnOffTransition-trace for logon
wpr.exe -boottrace -addboot GeneralProfile -addboot CPU -addboot FileIO -addboot Registry -addboot Network

# Genstart maskinen
shutdown /r /t 0

# Efter genstart og login, stop trace'et
wpr.exe -boottrace -stopboot C:\temp\logon-trace.etl

Åbn logon-trace.etl i Windows Performance Analyzer. Den vigtige graf er "Regions of Interest" → "Fast Startup" / "WinLogonInit". Her ser du hver fase, hver proces, og præcist hvor mange millisekunder de brugte. Microsoft har detaljeret dokumentation for hvordan man læser disse regioner i Windows Performance Analyzer-dokumentationen.

Min personlige heuristik: hvis "UserInit" og "ShellReady"-regionerne tilsammen er over 8 sekunder, er auto-run-programmer skyldige. Hvis "WinlogonInit" alene er over 15 sekunder, er det GPO eller profil-load. Hvis "OSServices" er skyldig, er det en synkron tjeneste, typisk EDR eller VPN.

FSLogix og roaming-profiler

Ærligt talt: i VDI og Azure Virtual Desktop-miljøer er FSLogix næsten altid årsagen til lange logins. Containeren indeholder brugerens profil som en VHDX-fil på en SMB-share; når VHDX'en er stor, korrupt eller mangler antivirus-eksklusion, bliver login pinefuldt langsomt. Jeg ramte det her selv sidste år på et 800-brugers AVD-miljø hvor gennemsnitslogin var 2 minutter og 40 sekunder. Årsag: én glemt eksklusion.

Diagnosticering af FSLogix

Start med FSLogix-logfilerne på klienten:

Get-Content 'C:\ProgramData\FSLogix\Logs\Profile\*.log' -Tail 200

Kig efter linjer med ProcessResult, attach time og advarsler som "VHDX file not found" eller "container attached from different session host". En sund FSLogix-attach tager 500–2000 ms. Er den over 10.000 ms, har du et problem.

Antivirus-eksklusioner

Den absolut hyppigste årsag til langsomme FSLogix-logins er manglende antivirus-eksklusioner. Både Defender for Endpoint og tredjepartsprodukter skal ekskludere disse stier og processer, jf. Microsofts officielle FSLogix-forudsætninger:

# Filstier (afhænger af din storage-konfiguration)
\\storage\share\*.vhd
\\storage\share\*.vhdx
\\storage\share\*.meta
\\storage\share\*.metadata
\\storage\share\*.lock
%ProgramFiles%\FSLogix\Apps\frxdrv.sys
%ProgramFiles%\FSLogix\Apps\frxdrvvt.sys
%ProgramFiles%\FSLogix\Apps\frxccd.sys

# Processer
%ProgramFiles%\FSLogix\Apps\frxccd.exe
%ProgramFiles%\FSLogix\Apps\frxccds.exe
%ProgramFiles%\FSLogix\Apps\frxsvc.exe

Compact-VHDX ved storage-tilvækst

FSLogix VHDX-filer vokser konstant, men skrumper ikke automatisk. Kør frx.exe compact som en scheduled task om natten, eller aktivér den indbyggede DynamicVhdxCompact-funktion via registry. Jeg planlægger ugentlig kompaktering af alle FSLogix-shares fredag aften, og gennemsnitlig login-tid falder typisk 20–30 % umiddelbart efter.

Group Policy-optimering

Hvis Event ID 8001 fortæller dig at GPO er skurken, er der en håndfuld indstillinger der næsten altid hjælper. Ingen af dem er magi. De er tradeoffs.

Baggrunds- vs. forgrunds-processering

Windows anvender som standard GPO'er i baggrunden efter login. Men Folder Redirection, Software Installation og Drive Maps kræver synchronous foreground processing, som betyder at Winlogon venter på at GPO'en er færdig før skrivebordet vises. Kontrollér din nuværende indstilling:

gpresult /r /scope:computer | Select-String 'foreground'
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon' -Name WaitForNetwork*

Fjern døde eller redundante GPO'er

Jeg har set miljøer med 87 linkede GPO'er på en OU, hvoraf 60 % var enten tomme eller duplikerede. Hver GPO koster tid. Brug Get-GPO -All | Where-Object { $_.Description -like '*legacy*' } til at finde kandidater til oprydning. Konsolidér relaterede indstillinger i færre GPO'er.

Loopback-processing

Loopback-processing i merge-tilstand fordobler antallet af GPO'er der evalueres. Brug det kun hvor det er strengt nødvendigt (kioskmaskiner, delte session-hosts). Standard er replace, som er hurtigere.

Opstartstjenester og tredjepartsagenter

Efter GPO- og profil-fasen er du på skrivebordet, men brugeren opfatter stadig maskinen som "langsom" indtil auto-run-programmer er indlæst. Task Manager → Startup-fanen viser en "Startup impact"-vurdering, men den er upræcis. Brug autoruns.exe fra Sysinternals for et komplet billede.

# Auto-run entries i registry
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'

# Scheduled tasks der starter ved login
Get-ScheduledTask | Where-Object { $_.Triggers.AtLogOn } | Select TaskName, TaskPath

Typiske syndere jeg har set forsinke login med 5–20 sekunder pr. stk.:

OneDrive: Første synkroniseringstjek. Løsning: aktivér "Files On-Demand" og Known Folder Move, så synkronisering sker asynkront efter login.
Adobe Creative Cloud: Berygtet langsom starter. Løsning: sæt den til at starte via Delayed Start Scheduled Task 2 minutter efter login.
Microsoft Teams (classic vs. new): Gammel Electron-baseret Teams er langsom; new Teams boot'er hurtigere. Migrér.
Cisco AnyConnect / GlobalProtect: Netværkstunneler tager tid at forhandle. Løsning: sæt VPN-klienten til at starte kun uden for det interne netværk.
EDR-agenter (CrowdStrike, SentinelOne, Defender for Endpoint): Skal starte tidligt af sikkerhedsårsager, men konfigurér korrekte eksklusioner så de ikke scanner profil-VHDX under login.

For fejlfinding af selve VPN-klienten under login, se vores dedikerede VPN-fejlfindingsguide til Windows 11.

Netværksdrev og logon-scripts

Mappede netværksdrev og logon-scripts der venter på utilgængelige shares er et klassisk problem. Windows venter typisk 30 sekunder pr. utilgængeligt drev, så tre døde drev = 90 sekunder ekstra login. Diagnosticér med:

# List alle mappede drev og deres status
Get-SmbMapping

# Test hvert drev's target
$targets = @('\\fs01\dept', '\\fs02\projects', '\\legacy-fs\archive')
foreach ($t in $targets) {
    $sw = [Diagnostics.Stopwatch]::StartNew()
    try { Test-Path $t -ErrorAction Stop | Out-Null; $status = 'OK' }
    catch { $status = 'FAIL' }
    $sw.Stop()
    "{0,-30} {1,-6} {2} ms" -f $t, $status, $sw.ElapsedMilliseconds
}

Fjern døde drev fra GPO Drive Maps eller logon-scripts. Overvej at migrere fra CMD/VBS logon-scripts til Group Policy Preferences Drive Maps med Item-level Targeting. De er hurtigere og respekterer timeout bedre.

Networking Location Awareness (NLA)

NLA-tjenesten afgør om maskinen er på domænenetværket eller ikke. Er DC'erne langsomme til at svare på LDAP-forespørgsler, hænger login i op til 30 sekunder på NLA alene. Kontrollér med:

nltest /dsgetdc:contoso.local
Test-NetConnection -ComputerName dc01.contoso.local -Port 389 -InformationLevel Detailed

Hvornår skal du eskalere

Hvis du har kørt igennem hele denne runbook og login stadig er over 60 sekunder på cachet login, er det tid til at eskalere. Dokumentér følgende før du sender ticketet videre til 3rd line eller Microsoft Support:

Windows Performance Recorder ETL-fil af mindst tre logins (én god, én dårlig, én "gennemsnitlig").
Fuld gpresult /h-rapport for både bruger og computer.
Event Viewer-eksport af Group Policy/Operational, User Profile Service/Operational og System-log for den relevante dag.
FSLogix-logfiler hvis relevant, samt storage-latenstal fra fileshare-serveren.
En præcis beskrivelse af hvad "langsom" betyder for den ramte bruger med timestamps, ikke "det er bare langsomt".

Hvis du oplever samme mønster på tværs af mange brugere, kan grundårsagen være noget på infrastruktursiden: en overbelastet DC, en fileshare med for få IOPS, eller en netværksswitch der begrænser bandwidth. Vores generelle Windows 11-fejlfindingsguide giver en bredere ramme for at diagnosticere fælles infrastrukturproblemer.

For dybere baggrund om synkron GPO-processering og de præcise Winlogon-timeouts, henviser jeg til Microsofts officielle Group Policy processing-dokumentation.

Ofte stillede spørgsmål

Hvorfor tager min Windows 11-login så lang tid?

De hyppigste årsager er tunge Group Policy Client-Side Extensions (især Folder Redirection og Drive Maps), en stor eller korrupt roaming-profil/FSLogix-container, synkrone tredjeparts-agenter der starter under Winlogon (EDR, VPN), samt utilgængelige netværksdrev der får login til at vente på en 30-sekunders timeout pr. drev. Start med at læse Event ID 8001 i Microsoft-Windows-GroupPolicy/Operational for at se præcis hvor tiden går.

Hvordan tjekker jeg hvad der gør min Windows 11-login langsom?

Brug Windows Performance Recorder (wpr.exe -boottrace) til at fange et komplet ETL-spor, og læs det i Windows Performance Analyzer. Kombinér med Event Viewer (Group Policy og User Profile Service Operational-logs) og gpresult /h. Det giver dig objektive millisekundtal for hver fase i login-sekvensen.

Hvad er en normal Windows 11 login-tid?

På moderne firmahardware med NVMe SSD og kablet netværk: 8–20 sekunder for cachet login, 45–90 sekunder for første Autopilot/ESP-login, 25–45 sekunder for AVD/Citrix session-hosts med sund FSLogix-container. Alt over 45 sekunder på cachet login er en outlier og bør fejlsøges.

Hvordan deaktiverer jeg opstartsprogrammer i Windows 11?

Åbn Task Manager (Ctrl+Shift+Esc) → fanen "Startup apps", eller kør Sysinternals autoruns.exe for et komplet billede. Deaktivér kun programmer du er sikker på ikke er sikkerhedskritiske. For firmaklienter styres dette bedst via GPO eller Intune Configuration Profile frem for lokal deaktivering.

Kan FSLogix gøre login langsomt?

Ja, FSLogix er den hyppigste årsag til lange logins i VDI- og AVD-miljøer. Skyldige er typisk manglende antivirus-eksklusioner, VHDX-filer over 30 GB, langsom SMB-storage, eller korrupte containere. Læs C:\ProgramData\FSLogix\Logs\Profile\*.log for attach-tider, og planlæg ugentlig frx.exe compact-kørsel.

Skal jeg slå synchronous foreground policy processing til?

Kun hvis Folder Redirection, Drive Maps eller Software Installation opfører sig upålideligt. Synkron foreground-processering gør logins længere, ikke kortere, fordi Winlogon venter på at GPO'en er færdig før skrivebordet vises. Løsningen er sjældent at ændre denne indstilling. Det er at optimere selve GPO'erne og de netværksshares de peger på.