DasHost.exe High CPU: Fix Device Association Host Safely

DasHost.exe high CPU can occur when Windows repeatedly tries to associate with a printer, scanner, Bluetooth accessory, USB device, or network device that is not responding as expected. The legitimate process is C:\Windows\System32\dasHost.exe and is called Device Association Framework Provider Host. Do not delete it or disable it permanently. First identify the device that makes the load appear; treat the file as suspicious only when its path, signature, startup behavior, or network activity does not fit the Windows component.

What Is DasHost.exe?

DasHost.exe hosts device-association providers for wired and wireless hardware. Windows can start it when a device is discovered, paired, installed, reconnected, or queried. A brief increase while a device connects is not the same as a process that remains near the top of Task Manager while the PC is idle.

You may also see more than one Device Association Framework Provider Host. Multiple instances are not automatically malicious: Windows can isolate work for different devices or providers. Compare the file location and publisher instead of assuming the process count proves an infection.

• Short spike while pairing: wait for pairing to finish and check whether the load settles.
• CPU returns with one printer, USB, or Bluetooth device: disconnect that device and inspect it in Device Manager; a device or driver loop is a useful hypothesis to test.
• Memory keeps growing with no active pairing: record the busy instance, end it once if necessary, then compare device and background-app triggers before choosing a driver repair.
• A running copy is in Temp, AppData, Documents, or Downloads: verify that exact file and investigate it with a security scan; do not judge a different System32 copy instead.
• The System32 process contacts an unexplained Internet destination: identify the process, device, and remote endpoint before making a firewall rule.

Find the Device Causing the CPU or Memory Spike

Do this before repairing all of Windows. The strongest clue is usually the last device that was paired, woke up, lost connection, received a driver update, or started failing.

1. Open Task Manager and sort the Processes or Details tab by CPU. Confirm that the busy item is Device Association Framework Provider Host or dasHost.exe. In Details, record its PID and current CPU or memory reading so you keep tracking the same instance.
2. Disconnect one nonessential device at a time. Start with a recently added printer, scanner, Bluetooth headset, mouse, game controller, webcam, USB receiver, smart display, or network-discovered device.
3. Wait 20 to 30 seconds after each disconnect. If CPU drops, reconnect the device once to confirm the relationship.
4. Open Device Manager and check that device for a warning icon or error in Properties > General > Device status.
5. If the problem is a storage device that shows 0 bytes or disappears, use the separate USB No Media decision guide. Do not keep reinstalling unrelated device providers.

For a printer-related spike, also check whether spoolsv.exe is consuming resources. A stuck print job belongs in the Print Spooler high-CPU workflow; a dasHost-only spike that follows printer discovery points more strongly to the device or its association driver. If the busy Task Manager row is Windows Driver Foundation instead of dasHost.exe, use the WUDFHost.exe high CPU guide to map that host to its loaded driver and device.

If disconnecting devices does not identify a cause

No warning icon in Device Manager does not settle which app or device triggers the activity. Leave Task Manager open and close one nonessential device-related app at a time, such as a printer utility, phone-link app, or Bluetooth accessory manager. Compare the same idle interval before and after; if the load falls, reopen that app once to check whether the symptom returns. Save work first and leave security software and essential input or accessibility tools running.

A repeatable change points to an interaction worth reporting to that app or device vendor; it does not prove the app is malicious or the driver is broken. If nothing changes, stop cycling through unrelated drivers. Record the Windows build, busy PID, executable path, device and driver versions, and what you disconnected or closed. Include whether CPU remains high or memory continues growing after a restart. Give that record to support; use the component-repair steps below when Windows corruption is suspected, rather than treating an unsuccessful device test as proof of corruption.

Is It Safe to End DasHost.exe?

Ending the task once is a reasonable diagnostic step after saving your work. Windows may restart the process when the device-association service needs it again. Connected-device discovery, pairing, or setup can pause until that happens.

If the load returns immediately, repeatedly ending the process only hides the trigger. Do not rename, delete, or replace C:\Windows\System32\dasHost.exe, and do not download a copy from a file-library site. Fix the device or driver that calls it.

Repair the Device or Driver

Use the narrowest repair that matches the device you identified:

1. Reconnect cleanly. Turn a Bluetooth device off and on, unplug its receiver, or power-cycle the printer or scanner. Remove a failed duplicate device entry only when you know which physical device it represents.
2. Install Windows updates. Check Windows Update, including relevant optional driver updates. Restart afterward.
3. Update from the manufacturer. For a printer, scanner, chipset, Bluetooth adapter, or specialty USB device, use the PC or device maker’s official support page. Avoid generic driver-updater apps.
4. Roll back a recent driver. If the loop began immediately after a driver change and Roll Back Driver is available, use it and restart.
5. Reinstall the identified device. In Device Manager, choose Uninstall device, restart Windows, and let Windows redetect it. Microsoft documents update, rollback, and reinstall paths in its current driver guidance.

Do not remove every item in Device Manager. That makes attribution harder and can disconnect keyboards, network adapters, storage controllers, or accessibility hardware.

Repair Windows Components If Corruption Is Suspected

If the signed System32 process stays busy after device and app checks, and Windows errors or other symptoms suggest component corruption, use the repair tools below. Install pending updates, restart, then open Terminal or Command Prompt as administrator and run Microsoft’s repair order:

DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow

Let both commands finish. Restart and repeat the one-device-at-a-time test. DISM and SFC repair Windows components; they do not update the device manufacturer’s firmware or prove that a third-party driver is compatible.

Should You Allow DasHost.exe Through the Firewall?

Device discovery and association can involve local network traffic, so a firewall prompt is not proof of malware. Check three details before choosing:

• the process path is exactly C:\Windows\System32\dasHost.exe;
• the activity starts when a known printer, display, media device, or other local device is discovered;
• the destination is a local network address or expected device, not an unexplained public Internet host.

A blanket block can break discovery or pairing, while a blanket allow can hide a wrong-path copy. If the prompt names a file in Temp or AppData, or activity continues with all devices disconnected, use the security branch below.

UDP broadcasts on ports 22222 or 10004

If a firewall attributes repeated UDP traffic on 22222 or 10004 to dasHost.exe, check the destination and what triggers it before allowing or blocking the process. Microsoft Community users reported this pattern in October 2024, with later replies describing Windows 11 24H2, printer discovery, and print-dialog triggers [4]. A separate June 2025 report described excessive internal broadcast traffic on 3289, 22222, and 10004 [5]. These are historical user reports, not confirmation that every current Windows build has the same bug or that a universal fix exists.

1. Record the affected PC and process. Note the Windows version and OS build, when the traffic began, recent driver or Windows updates, and the busy process ID (PID) in Task Manager’s Details tab. Check its path and signature using the security checks below.
2. Keep the traffic evidence. Save the source PC, destination address, UDP destination port, timestamps, and rate shown by the firewall or network monitor. Match the event to the process at the same time; a filename or port number alone does not identify the sender. A gateway log may identify only the PC, not its PID. If attribution is missing, ask IT to correlate a short capture with process information. Windows includes Packet Monitor for packet capture, filtering, and counting [6].
3. Separate discovery from a sustained loop. A brief local burst during device discovery differs from repeated traffic that continues after discovery ends or coincides with slow printing, CPU growth, or network disruption. Confirm whether the destination is the local subnet’s broadcast address, another local device, or an unexplained public address. Do not infer that distinction from the port alone, and do not label every denied packet a broadcast storm.
4. Isolate one trigger. Note whether opening Add printer or a print dialog starts the traffic. Close it and observe whether the rate falls. Disconnect one nonessential suspected device and compare the same observation interval. Reconnect once only if doing so will not disrupt a shared network. If the network is already impaired, stop reproducing the issue and involve its administrator.
5. Repair and verify. When one device or driver consistently triggers the loop, follow the device-repair section above: supported Windows/device updates, or a targeted driver rollback or reinstall when appropriate [1]. After restarting, check both the packet rate and normal printing or pairing. If the problem remains, give support the build, device/driver version, trigger, and before/after traffic record rather than repeatedly killing dasHost.exe.

The community thread contains conflicting results for print-dialog registry changes, and reports that disabling the Device Association Service disrupted printing. Do not apply those workarounds as a universal fix. A signed System32 process producing excessive local discovery traffic needs device/network troubleshooting; a wrong-path copy or unexplained public destination still needs the security investigation below.

Is DasHost.exe a Virus?

The Microsoft-signed file in System32 is a Windows component. The name alone is not proof: Microsoft has documented Backdoor:MSIL/Medirot.A creating %TEMP%\dashost.exe and adding a startup value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run. That is a different file using a familiar name.

In Task Manager’s Details tab, right-click the busy dasHost.exe row, choose Open file location, and inspect that file’s Properties. Match the PID, path, and signature for the same instance. Checking the genuine System32 file does not validate a second copy running from another folder.

For a text record, open Windows PowerShell as administrator and list the running instances:

Get-Process -Name dasHost -ErrorAction SilentlyContinue |
    Select-Object Id, Path, CPU

CPU is accumulated processor time in seconds, not current CPU percentage. Use Task Manager’s CPU column to compare the load before and after a device or app change. A long-running idle process can have a larger accumulated total than a newly started busy one. Microsoft documents this distinction in Get-Process [7].

Replace 1234 below with the PID you just observed. This reads the signature of that process’s executable; it does not run or change the file:

$targetProcessId = 1234
$process = Get-Process -Id $targetProcessId -ErrorAction Stop
if ($process.ProcessName -ne 'dasHost') {
    throw 'This PID is no longer a dasHost process. Check Task Manager again.'
}
if (-not $process.Path) {
    throw 'No executable path returned. Check the same PID with Open file location.'
}
$process | Select-Object Id, ProcessName, Path
Get-AuthenticodeSignature -LiteralPath $process.Path |
    Format-List Path, Status, StatusMessage, SignerCertificate

Confirm that the returned path is the one you intended to inspect. Valid means signature validation succeeded; also check that the signer is Microsoft for the Windows component. A valid signature does not explain a CPU spike or guarantee that the running process is uncompromised. NotSigned, an invalid signature, or an unexpected publisher calls for investigation, not automatic deletion. The signature command checks the specified file, including supported Windows catalog signatures [8].

If the process has exited, find the current busy PID and start again. A blank path or access error is not a malware verdict; use an elevated PowerShell session matching Windows’ architecture or inspect the same instance through Task Manager. A file found in a folder search is not necessarily running: investigate the executable behind the observed process, not every same-named Windows servicing copy.

If a wrong-path copy already ran, quarantine the detection and check for persistence rather than deleting only the visible file. Review the suspicious startup entries guide. Repeated alerts after reboot can mean a scheduled task, startup value, loader, or bundled module is recreating the file. Gridinsoft Anti-Malware can scan for those related artifacts through the official download path. It cannot prove that no compromise occurred, so change important passwords from a clean device if browser sessions or credentials may have been exposed.

If you are comparing another familiar process running from Temp or AppData, the fake svchost.exe path check explains the same name-versus-location principle without treating every Windows host process as malware.

FAQ

References

1. Microsoft. Update drivers through Device Manager in Windows. Microsoft Support, current living documentation. Accessed August 18, 2026.
2. Microsoft. Using System File Checker in Windows. Microsoft Support, current living documentation. Accessed August 18, 2026.
3. Microsoft Security Intelligence. Backdoor:MSIL/Medirot.A threat description. Published December 21, 2015; updated September 15, 2017. Accessed August 18, 2026.
4. Microsoft Community contributors. “dasHost.exe is causing udp broadcast flood on 22222 or 10004 ports…” Microsoft Q&A, question October 16, 2024, with later replies; accessed September 12, 2026. Device-association traffic reports
5. Microsoft Community contributors. “Flooding broadcast traffic from Windows11 to destination ports 3289, 22222, and 10004.” Microsoft Q&A, June 18, 2025; accessed September 12, 2026. Internal broadcast report
6. Microsoft. “Packet Monitor (Pktmon).” Microsoft Learn, updated May 5, 2025; accessed September 12, 2026. Windows packet diagnostics
7. Microsoft. Get-Process. Windows PowerShell 5.1 documentation. Accessed November 5, 2026.
8. Microsoft. Get-AuthenticodeSignature. Windows PowerShell 5.1 documentation. Accessed November 5, 2026.