Forum Discussion
The task you are trying to do can’t be completed because Remote Desktop Services is currently busy
- Oct 25, 2019
Daghoberto:Thank you for reaching out for those issues. I recommend to file a support request as those issues might have different root causes. Additional logs will help to pin down those issues.
What was the fix in your case? I have a different setup but I'm also receiving the same message periodically.
Chris Parker Yes, I was able to fix it by having a different svchost.exe process for each process.
The problem is bisrv (BrokerInfrastructure) is receiving a large number of events using threadpool threads and then it is sending a ALPC request (which again uses thread pool threads) to SystemEventBroker Service which is running in same SVCHost. This caused thread pool exhaustion. Since thread pool threads are exhausted, we can no longer process requests resulting in hang.
We do have a workaround for the issue, run SystemEventsBroker or BrokerInfrastructure service into its own host process.
Action Plan: Perform following on all WVD computers
- RDP into the computer with admin account -> Start Regedit
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SystemEventsBroker\ and change the value of the key “Type” to 16 (decimal) (or 0x10 hex)
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BrokerInfrastructure\ and change the value of the key “Type” to 16 (decimal) (or 0x10 hex)
- Reboot the machine
- Log into the VM again -> open command prompt as administrator and enter command tasklist /svc > c:\tasklist.txt
- Open tasklist.txt and verify SystemEventsBroker or BrokerInfrastructure are in own svchost
7. Monitor and let me know if the issue resurfaces
- Chris ParkerJan 13, 2020Iron Contributor
Daghoberto Much appreciated!
- R_AkersApr 10, 2020Brass Contributor
- Siege197Jul 22, 2020Copper Contributor
not sure if you have a fixe yet, but i had a similar issue today on a windows 2016 server. Some background as to what i think caused the issue. I was trying to RDP to a server, but both sessions were in use, so i left the screen open while checking with the guys if i could log either of them off, however, i got sidetracked and forgot about. Eventually, i recalled having a need to login, so i went back and instead of clicking "cancel" on the screen, i decided to "reconnect", so not cancelling my login attempt. all subsequent RDP requests resulted in the message " the task you are trying to do can be competed .. "
So to the simple fix for my issue.
ran quinsta /server:servername to see for any sesions ..
i saw "session 4" which had no session name or username but had a session ID,
Then,
used tasklist /s servername to view the tasks, but used a filter
tasklist /s "servername"/fi "session eq 4"
Then, i killed the LogonUI.exe , using the PID with Taskkill
taskkill /s servername /PID 4692
I tried kill winlogon, but that was not allowed.
hope this works for someone else who is unable to reboot the machine to fix it .
- AT1991Jan 15, 2020Copper Contributor
Chris Parker
Hi Chris,
How is this fix working out for you?
I've encountered similar issues for one user in our multi-session environment today and I can't reboot the machines just yet.
RDP'ing to the session hosts directly works but just cannot connect via the WVD client.