dasHost.exe is causing udp broadcast flood on 22222 or 10004 ports...

Was scanning my site network (Wireshark) yesterday and located a subject PC that was generating multiple packets on port 22222/10004. It had the KB5055523 2025-04 patch installed, so MS either haven't fixed or it is something else connected with printer discovery. I applied the registry key

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Print\UnifiedPrintDialog] "PreferLegacyPrintDialog"=dword:00000001

Re-started PC and all went quiet. I do not have any idea what triggers this. I see small bursts of UDP 22222 from various machines but that is all. Something appears to get stuck in a loop when the flood is happening - I can see 75 or more UDP packets to 22222 and 10004 from a PC in 1 second.

KB5055523 2025-04 問題依然存在

Exact same boat here. We're dependent on the BD firewall, and it doesn't have the ability to filter broadcast traffic (according to them, this is due to a bug with the Windows Filtering Platform, not a decision on their part). The registry trick has greatly reduced how often people start the broadcast, but it still happens without fail when printing from certain applications (photos.exe, snipping tool, etc.). Our only recourse at the moment is watching for the traffic in wireshark 24/7 and manually killing dashost.exe as soon as someone starts being problematic (or scripting the same steps). It's truly heinous and all we can do is angrily await a new build that hopefully fixes the issue.

We're in the same, 120 computers and as they've been updated, it's become unsustainable, I have logged 4 broadcasts per second per computer, network stability is clearly in danger, It's incredible that Microsoft hasn't fixed this!

We've disabled the device association service and the broadcasts disappear, but programs that use native Windows printing fail or take forever (Notepad, Paint, Photos...)

We use BitDefender Firewall instead of the Windows one, and not permit drop broadcast...

Any other suggestion?

Same here. Rolled out a GPO with firewall rule blocking those outbound ports seems to have fixed the issue. Blocking those ports hasn't caused any issues with production so far.

抱歉我的母語是中文，

經過前面的訊息至今，我觀察的分享...

會發生的電腦是 Windows 11 24H2 且使用新版列印畫面介面

我發現預先載入不更新的軟體，基本上會觸發的電腦就會觸發。

當確認會觸發的電腦，基本上 小畫家 筆記本 相片的列印視窗打開都可以觸發。

且不用列印，只需開啟新版列印視窗即可。

開一次會少量，但是不會結束(即使你關掉所有的軟體)，

隨著工作時間增加，觸發次數越多，

發UDP的頻率會隨著次數增加，直到DAS服務重啟或重開機才會歸零。

所以通常引發影響網路內問題的時候，通常發UDP的電腦數量夠多，或是運行時間內觸發夠多次就可以產生。

我遇過嚴重影響其他公司案例，他是11天不關機的工作累積到高超頻發送頻率。

至於前面有人提到的Edge/Chrome 我的驗證環境不會(總是更新到最新版本)，

但軟體特性是時常更新，不像上述的應用小畫家 筆記本 相片(幾乎萬年不更新的預載軟體)，

也許Chrome/Edge在某次更新就修正了，至少目前我確認可以觸發的電腦，

Chrome/Edge開啟列印不會發生，我認為目前的版本列印介面是瀏覽器自家的所以不會了，

Firefox列印介面也是自家的，但它留下一個可以呼叫Windows新版介面出來，一叫出來也會發生。

但判斷關鍵很簡單，小畫家筆記本會發生的，其他軟體只要能呼叫內建新版列印畫面，就會發生。軟體自家的列印介面並不一定會。 可能還有更多沒被發現也會觸發此問題的軟體，但可以用這方式判斷。

可以透過Wireshark判斷，我個人是寫專用程式去偵測網內有無此現象的電腦，

讓我預先知道風險並處理掉，不像大多數的人是經過報修才知道又發生了。

(但這問題也增加了工作項目)

已知熱感出單機EPSON TM系列網卡介面會被影響，不過我已經有辦法透過偵測封包程式預知問題，讓我的工作沒這麼充滿不確定性。