DasHost.exe High CPU: Fix Device Association Host Safely

DasHost.exe high CPU usually means Windows is repeatedly trying to associate with a printer, scanner, Bluetooth accessory, USB device, or network device whose driver is not responding correctly. 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.

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.
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.

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 Every Device Triggers It

If the System32 process remains busy after the responsible device is removed, Windows component corruption may be involved. 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.

Right-click the process in Task Manager, choose Open file location, then open the file’s Properties. A suspicious location, missing or invalid Microsoft signature, unexpected startup entry, or unexplained remote connection deserves a full investigation. You can collect the active paths and signature status in an elevated PowerShell window:

Get-Process dasHost -ErrorAction SilentlyContinue | Select-Object Id, Path, CPU
Get-AuthenticodeSignature C:\Windows\System32\dasHost.exe | Select-Object Status, SignerCertificate

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