If Cross Device Service keeps using memory or CPU after a phone transfer has finished, test phone access in File Explorer before removing Windows components. Open Settings > Bluetooth & devices > Mobile devices > Manage devices and turn off Show mobile device in File Explorer for the connected phone. Then compare the same process at idle and after a normal restart. A drop in CPU, stable RAM, and a process that merely remains listed are three different results. The steps below help you choose the next action without dismantling features you still use.
First, check which process is actually busy
Microsoft Cross Device Service supports Windows phone-to-PC experiences. In Task Manager, it may appear inside the Mobile devices group. Expand that group and check the individual row; in the Details view, look for CrossDeviceService.exe. A group’s memory total can include more than one process.
Similar names lead to different repairs. If the busy executable is PhoneExperienceHost.exe, follow the Phone Link CPU and synchronization checks. If a sign-in error names CrossDeviceResume.exe, use the Resume settings and error guide. Do not remove a package based only on the word “CrossDevice.”
Why phone files are worth testing
A Microsoft Q&A contributor reported tracing repeated phone-file enumeration by CrossDeviceService.exe with Process Monitor. In that person’s setup, disabling phone access in File Explorer stopped the activity and reduced CPU use. Other participants described memory growth and a process that returned after being ended. These are community observations, not a Microsoft bulletin establishing one cause for every PC.[2]
The useful question is whether your resource use follows that feature. A short burst while transferring files is different from memory that keeps climbing after work stops. A large but stable memory number alone cannot establish a leak. Likewise, high CPU by itself does not establish a miner or another infection.
Run a reversible before-and-after test
Save your work first. Let an active file transfer finish or cancel it normally before changing the connection. If the PC is nearly out of memory or becoming unusable, stop the transfer and restart normally; do not keep reproducing the problem just to collect more measurements.
- Write down the starting conditions. Record the exact process name, Windows version/build from
winver, phone model, and whether phone browsing, a transfer, screen sharing, or a call is active. Keep other workloads as similar as practical. - Observe an idle interval. Note that process’s CPU and memory now and again after roughly five minutes without starting another transfer. This interval is a practical comparison, not a diagnostic threshold. Record whether CPU stays busy and whether memory rises, settles, or falls.
- Change one feature. In Settings > Bluetooth & devices > Mobile devices > Manage devices, select the paired phone and turn off Show mobile device in File Explorer. This is Microsoft’s documented control for disabling that phone’s Explorer access.[1]
- Repeat the idle observation. Leave other settings alone. Compare CPU activity and memory growth separately. If CPU settles but RAM stays allocated, record that distinction instead of assuming the switch failed.
- Check a fresh session. Restart Windows normally with the feature still off, then repeat the same idle observation. Check the features you want to retain, such as Phone Link messages or calls. The target is usable performance and stable resource use; the service does not have to disappear from Task Manager.
Turning off Explorer access changes where you can browse the phone; it does not require uninstalling Phone Link or deleting files. To restore that access, return to the same setting and turn it on. If the PC is stable and you need confirmation, an optional short retest with the feature on can show whether the symptom returns. Stop if resource use grows quickly. This is a troubleshooting comparison you can perform, not a benchmark we have run on your hardware.
Choose the next step from the result
- CPU settles and memory stops growing with Explorer access off. Keep that feature off if you can work without it. Test the phone features you still need. Revisit Explorer access after relevant updates.
- CPU falls, but memory remains high. Compare a fresh session after restart. A retained allocation and continuing growth are different symptoms; report which one you see.
- The switch is already off, absent, or no phone is paired. Skip this branch. Record the setup and update the affected components; do not pair a phone or change unrelated settings just to reproduce these steps.
- Load continues in a fresh session with the feature off. The test did not isolate Explorer access as the cause. Keep the observations and follow the update/support route below.
- Only a different executable stays busy. Follow that process’s troubleshooting route. Do not judge CrossDeviceService by total PC memory or the whole Mobile devices group.
If the load continues, update before making broader changes
Install available Windows updates, check Microsoft Store for updates to the relevant Microsoft phone/cross-device apps, and update Link to Windows on the phone. Complete any required restart, then repeat the same condition that produced the problem. Record the versions so a later improvement can be compared with a specific change.
If Windows exposes an Advanced options > Repair control for the affected app, try Repair before considering Reset. Microsoft’s app-repair instructions explicitly note that these controls are not available for every app.[3] Read the Reset warning: it can clear local app data and require setup again. Repairing Phone Link is relevant when Phone Link itself fails; it is not proof that an independent CrossDeviceService problem has been repaired.
If the component has no supported repair control, or the problem survives updates, send a reproducible report through Feedback Hub or Microsoft support. Include the Windows build, available app versions, exact process, paired-device state, trigger, before/after CPU and RAM, and whether restarting with Explorer access off changed the result. Keep private filenames, account details, and phone content out of public screenshots. For a work or school PC, give this information to IT rather than bypassing managed settings.
A useful report says, for example, “memory continues increasing while idle after Explorer phone access is disabled and Windows has restarted,” rather than only “Phone Link uses too much RAM.” That tells the next person which proposed fix has already been tested.
Why End task or disabling startup may not last
Ending a process stops its current instance; it does not change every feature that can request it. A process returning after sign-in or when you use a phone feature is therefore a different observation from its resource use becoming excessive again. Avoid repeatedly killing it during transfers.
If you no longer want phone-to-PC integration, use the Phone Link startup and unlinking controls and accept the corresponding loss of connected features. For diagnosis, change one control at a time. Disabling startup, turning off a feature, unlinking a phone, and uninstalling an app have different effects.
Do not take ownership of C:\Program Files\WindowsApps\, delete an EXE from a protected package, or run broad all-users package-removal scripts simply to lower a memory number. Blanket service or scheduled-task disabling also makes it harder to identify which change mattered. If you need the feature and the reversible workaround is unacceptable, use support with your test results instead of stripping out its dependencies.
When a security scan makes sense
For an unexpected copy, right-click the process in Task Manager, choose Open file location, and inspect the file’s Properties and digital-signature information. A familiar name is not authentication. A separately downloaded executable, an unexpected publisher, or a process that appeared with an untrusted installer deserves a security check. Do not alter protected-folder permissions just to inspect a file; use the executable safety checklist if the origin is unclear.
If an untrusted copy ran or independent security warnings accompany it, related bundled files or startup entries may also need cleanup. Download and install Gridinsoft Anti-Malware from the official site, update the database, run a Full Scan, review the findings, remove confirmed threats, and restart. Check whether the unwanted activity returns. A malware scan does not fix a legitimate synchronization bug or prove that no account data was exposed.
If the process path is wrong, the name imitates a Windows component, or high CPU started after an unknown installer, scan for hidden miners, services, startup entries, and bundled components.
Scan suspicious filesFAQ
Should I delete phone files to free the service’s RAM?
No. Process memory and storage occupied by phone files are different resources. Deleting files through the connected-phone view can affect the phone itself. Use the feature switch for this test, and handle storage cleanup separately with a backup.
Does the File Explorer test apply to an iPhone?
The Microsoft feature described here is for an Android phone linked to a Windows 11 PC. If your device has no Show mobile device in File Explorer option, skip that branch and diagnose the exact busy process. Do not apply unrelated Android cross-device settings to the PC.
References
- Microsoft. “Setting up and using your phone in File Explorer.” Microsoft Support, accessed October 27, 2026.
- Keegang, Ruslan Livanskiy, and Microsoft Q&A contributors. “Cross Device service High CPU, RAM usage.” Microsoft Q&A, opened February 26, 2026; file-enumeration observation posted April 27, 2026; accessed October 27, 2026.
- Microsoft. “Repair apps and programs in Windows.” Microsoft Support, accessed October 27, 2026.
