Desktop vs sign-in screen: what a user session costs
On this page
Short answer
Section titled “Short answer”A logged-in desktop is more expensive than the sign-in screen, but far less than it seems: at steady idle it uses about 0.012 of a core versus 0.0074 on the sign-in screen, that is 1.6 times more. The real cost of a user session is the first hour after sign-in: the Defender scan and the wave of Store updates together consume about 79% of all CPU activity in the five-hour window. The shell itself is nearly free: explorer, sihost, dwm and the Start feed together spend about 2.3% of the budget.
Status: measured in a single 5-hour run on Windows 11 26H2 in a virtual machine. The comparison with the sign-in screen was made on the same build and snapshot. Transfer to physical hardware, other builds and nighttime windows was not tested.
Testable claim
Section titled “Testable claim”We tested four claims:
- A logged-in desktop is significantly more expensive than an idle sign-in screen.
- The main cost of a session is the constant work of the shell.
- A user session noticeably changes the network profile of idle.
- Scheduled Windows mechanisms (updates, service timers) behave in a session the same way as without it.
Scope of research
Section titled “Scope of research”- Windows 11 Pro, build 26300.9457 (26H2), virtual machine 4 vCPU / 8 GB;
- clean installation without third-party software; sleep and configuration updates were not disabled;
- two runs on one snapshot: the sign-in screen without a user session (6 hours) and a logged-in desktop (4 hours 46 minutes, stopped early);
- sign-in was performed manually; observation began after confirming that the shell had started;
- minute-by-minute snapshots: process CPU, sets of running services, memory and established connections.
The measurements did not include physical hardware, real work at the computer, GPU load and nighttime windows (daily maintenance tasks did not fall into the frame).
Methodology
Section titled “Methodology”For each process, accumulated CPU seconds were recorded once a minute; the difference between adjacent snapshots gives consumption for the interval. Services were tracked by sets of running instances and transitions; the network by established connections at the moment of the snapshot. The noise of our own monitoring (about 3.6% CPU) was excluded from interpretation. Both runs were compared by values normalized to an hour.
Results
Section titled “Results”Summary comparison
Section titled “Summary comparison”| Metric | Sign-in screen | Desktop | Difference |
|---|---|---|---|
| CPU averaged over the window, cores | 0.0098 | 0.0492 | ×5.0 |
| CPU of a steady hour, cores | 0.0074 | 0.0120 | ×1.61 |
| CPU of the first hour after sign-in/boot, cores | 0.0185 | 0.2942 | ×15.9 |
| System process launches per hour | 26.1 | 79.5 | ×3.05 |
| Minutes with activity above 1 CPU-s | 5% | 13.5% | ×2.4 by share |
| Established connections per hour (endpoint-minutes) | 88.3 | 228.1 | ×2.58 |
| Persistent connections | 1 | 3 | ×3 |
Key fact: the average figure of “×5” consists almost entirely of the first hour. The steady hours of the desktop are homogeneous (0.0118–0.0127 of a core) and do not drift.
The first hour: two waves
Section titled “The first hour: two waves”| Wave | Share | What was happening |
|---|---|---|
| Defender sign-in scan | ~55% of the hour’s CPU | The antivirus process ran at about 0.7 of a core for 8 minutes straight; the scan began immediately after sign-in |
| Store and USO update | ~27% of the hour’s CPU | Installation of 24 apps, download of about 880 MB via Delivery Optimization, including peering |
The Store wave matters separately: in this run the updates came through Microsoft Store and Delivery Optimization, not through classic Windows Update. The network spike at sign-in is 67 times larger than the steady level.
Steady idle: who is working
Section titled “Steady idle: who is working”| Source | CPU seconds per hour | Comment |
|---|---|---|
| The overall svchost scaffolding | 13–14 | Service timers |
| Kernel (System) | 8 | Part of the work of Defender and the infrastructure |
| Antivirus outside a scan | ~3 | Periodic checks |
| Shell (explorer, sihost, dwm, Start feed, search, widgets, OneDrive) | 4.1 | 2.3% of the budget; “desktop idle” is nearly free |
Three quarters of the difference in process launches come from the periodic mechanisms of the user session: the background UWP task host (a cycle of about 13 minutes), RuntimeBroker and SoftLanding every 15 minutes.
Network: three persistent connections and two new timers
Section titled “Network: three persistent connections and two new timers”On the sign-in screen there is one persistent connection. On the desktop there are three: two are held by the Start feed (MSN content: weather, news, live tiles) from the first minute and without interruptions, the third by the system notification service. The CPU cost of the feed over the whole window is less than 2 CPU seconds, but the connection itself lives forever.
New session timers: OneDrive syncs every 32–33 minutes with two connections, Edge updates are checked once every few hours. Defender signature checks run in clusters every 30–40 minutes. All traffic is directed to Microsoft infrastructure; no extraneous connections were observed.
Service timers
Section titled “Service timers”Group Policy update on the desktop cycles every 16–17 minutes versus about 80 minutes on the sign-in screen. The AppX Deployment Service (AppXSvc) and the Software Protection service (sppsvc) kept the same rhythm. Five session services live permanently, including user notifications and Clipboard.
Memory
Section titled “Memory”There are no system leaks: the antivirus released 81 MB after the scan, the shell grew only in the first 30 minutes and reached a plateau. The number of processes is 130–153 versus 84–98 on the sign-in screen.
What is confirmed
Section titled “What is confirmed”- Measured: a steady desktop is 1.61 times more expensive than the sign-in screen in CPU; the first hour after sign-in is the main cost of the session (79% of the window’s CPU).
- Measured: the Start feed holds two persistent connections for the entire session; OneDrive syncs every 32–33 minutes.
- Measured: the sign-in Store wave downloaded about 880 MB via Delivery Optimization; the network spike at sign-in is 67 times larger than the steady one.
- Measured: the shell (explorer, dwm, Start feed, search, widgets) at steady idle spends about 2.3% of CPU.
- Observed: the updates came through Store/DO, not through classic WU; nighttime maintenance tasks did not fall into the frame.
What is not confirmed
Section titled “What is not confirmed”- Behavior on physical hardware and on other Windows builds.
- Nighttime windows and daily maintenance tasks (the run was daytime and stopped early).
- The effect of disabling the Start feed or OneDrive on these figures: we only measured their contribution, disabling was not tested.
- The effect on FPS and overall gaming performance: not measured.
Limitations
Section titled “Limitations”One run per state, a virtual machine, a daytime window. Windows background work comes in bursts, so transferring absolute values to other hardware and a full day is not justified. Processes shorter than a minute and UDP traffic (DNS, NTP) are not fully visible. Some logs did not record events during the second run; service transitions were reconstructed from snapshots.
Practical conclusion
Section titled “Practical conclusion”“Windows background noise” falls apart into three different things, and they must be dealt with differently. Post-logon waves (the Defender scan and Store updates) account for most of the CPU — they cannot be turned off with fine-grained settings, but they end on their own. System metronomes (WMI polling, license checks, the OneDrive timer) are a steady but small background. The shell is nearly free.
Practical consequences: do not measure “optimization” by the first hour after sign-in unless you isolate the waves; to minimize network, disable the Start feed and OneDrive if they are not needed; expecting “silence” right after login is not justified.
State restoration
Section titled “State restoration”The system was not modified: both runs were pure observation without changes to settings, services or the registry. The virtual machine was returned to a clean snapshot after the measurements.
Sources and boundaries
Section titled “Sources and boundaries”The measurements were performed by BoosterX Research on the described virtual machine. The research belongs to the BoosterX developer, and the developer has a direct interest in the result; the methodology and limitations are described above, and the original observations can be reproduced using the open methodology.
- Microsoft: Delivery Optimization, checked 2026-09-22.
- Microsoft: Connected User Experiences and Telemetry, checked 2026-09-22.
Last check: 2026-09-22.