A laptop I set up for a relative started spinning its fan the moment the screen unlocked. Task Manager showed a process called Microsoft Cross Device Service sitting at 30 to 40 percent CPU, which on a four-core machine is the kind of load that makes the fan audible from across the room. The user had not installed anything new, had not changed any settings, and had not plugged in a phone. The service was just sitting there, chewing cycles, for no obvious reason.
I went through the usual round of fixes before I figured out what was actually going on. Most of the steps I tried did nothing. One of them worked. This is the writeup of what I did, in the order I did it, with the bits that did not matter and the one that did.
Here is the breakdown:
- What the Cross Device Service actually does, in plain terms
- The five things I tried, ranked by what was actually worth my time
- The one fix that dropped the CPU usage back to idle
- What I would tell past me about debugging background-service CPU spikes
What the service is and what it is for
The Microsoft Cross Device Service is a background process that helps your phone talk to your PC. If you have ever used Phone Link to read a text on your laptop, or to drag a photo off your phone and drop it into a chat window, the Cross Device Service is what made that work. The service handles the connection between the two devices, keeps the link alive, and ferries data back and forth as you interact.
When it works, it is invisible. The service runs in the background, syncs quietly, and uses almost no CPU. When it does not work, it shows up in Task Manager at the top of the CPU column and does not let go. The two failure modes I have seen are roughly: the connection has dropped but the service has not noticed, so it keeps retrying at full speed, or the service is trying to do several jobs at once and is starving itself on the polling loop. Either way, the visible symptom is the same: a process that should be using near-zero CPU is using tens of percent.
The important thing to know before you start fixing it is that this is one of several Windows services that behave this way. The Audio Device Graph Isolation service has the same failure mode. The Windows Modules Installer Worker has it too. The general shape is the same: a background service that normally sits at idle starts pegging the CPU for reasons that are not obvious from the process name alone.
The five fixes I tried, in order
I went through five fixes before the CPU usage dropped. Most of them were dead ends. I am listing all five because the dead ends are useful to know in advance, not just the one that worked.
Restart was the first thing I tried. This is the standard “have you tried turning it off and on again” fix and it is worth doing because it costs nothing. It did not fix the CPU spike here. The service came back at the same high usage within a minute of the desktop loading.
Disabling Phone Link on startup was the second attempt. This is in Task Manager under the Startup Apps tab, and the steps are: open Task Manager with Ctrl + Shift + Esc, click Startup Apps in the sidebar, find Phone Link, right-click, and choose Disable. I also disabled Mobile Devices in the same place because it also uses the Cross Device Service and can keep the connection alive even when Phone Link itself is closed. This did not fix the spike either, but it is a useful change regardless. Phone Link does not need to be running from boot, and there is no reason for it to be.
Turning off Share Across Devices was the third fix I tried. This is in Settings under Apps, then Advanced app settings, then the Share Across Devices toggle at the top. The toggle controls whether Windows tries to share app state (recent files, clipboard, notifications) between your PC and your phone. Turning it off cuts one of the things the Cross Device Service is responsible for, which in theory should cut its CPU usage. In practice, on the machine I was debugging, this did nothing visible. The service kept using the same amount of CPU with the toggle off.
Stopping Phone Link from running in the background was the fourth attempt. The path is Settings, Apps, Installed apps, find Phone Link, click the three dots, choose Advanced options, and under Background apps permissions set the dropdown to Never. This stops Phone Link from doing anything when it is not the active window. It is a useful change for laptops where you do not want background syncing eating battery. It also did not fix the CPU spike.
Reinstalling the Cross Device Service itself was the fifth and final fix I tried. This is the one that worked. The steps are in PowerShell, run as Administrator, which you can launch with Win + R, then type powershell, then Ctrl + Shift + Enter.
The command to remove the service is:
Get-AppxPackage *CrossDevice* -AllUsers | Remove-AppxPackage -AllUsers
After the command finishes, restart the machine, open an Administrator Command Prompt, and reinstall the service with:
winget install 9NTXGKQ8P7N0
That second command is the Windows Package Manager install for the Cross Device Service. After the install completes, the service came back at near-zero CPU and the fan stopped spinning within ten seconds.
Why the reinstall worked when the toggles did not
My best guess, having watched the service spin for a few hours, is that the install state on this machine had gotten into a state where the polling loop and the connection state machine disagreed. The service kept trying to connect to a paired device that was no longer there, the connection state never settled, and the polling loop never backed off. The toggles I tried did not change the polling loop. They changed what the service was supposed to do, but the loop kept running anyway.
A reinstall is a heavier fix than a toggle because it rebuilds the package, which means the polling loop comes back at default settings. That is the part that mattered here. Once the loop was at default settings, the service correctly noticed that no phone was paired and went back to idle.
I cannot prove this is what was happening on this specific machine. The fix is the fix. If your CPU spike has the same shape (Cross Device Service at the top of Task Manager, no recent changes, no paired phone), the reinstall is worth doing before you spend more time on toggles.
Trade-offs
Reinstalling the Cross Device Service is not free in setup. You have to remember the winget install command, which is not something most people have memorized, and you have to run PowerShell as Administrator, which on a locked-down machine may require IT involvement. If the spike is mild and intermittent, the toggle approach is cheaper even though it did not work in my case.
The reinstall also resets the service to default settings. If you have customized anything in the Phone Link app, those customizations stay, because they live in the app, not in the service. The connection state between the phone and the PC does have to be re-paired, which is a one-time cost of about thirty seconds.
If the spike is severe (CPU usage in the 30 to 40 percent range, fan running constantly), reinstalling is the right move. If the spike is mild (5 to 10 percent, only when the laptop is on battery), start with the toggles and see if any of them change the picture before you reach for PowerShell.
What I would tell past me
- Do not assume the toggle fixes will work. They look promising in the menu and they did not move the CPU usage on this machine.
- Watch the service for two to three minutes after each toggle before declaring it a failure. The polling loop sometimes takes a minute to back off, and a fast “this did not work” call wastes time.
- Keep the winget install command somewhere you can find it. Reinstalling the service is the fix that actually works, and you will not remember the package ID when you need it.
If I only had time to do one of those, it would be the winget install command. The first four fixes cost me about twenty minutes, and the fifth one took thirty seconds once I had the right command.