A sessão RDP do Windows Server continua matando o AudioSrv (audiodg.exe), levando a atrasos na inicialização do áudio

Question

Executando o Windows Server 2012 R2, notei um recurso irritante nas conexões RDP:

O Windows continua encerrando o serviço de áudio audiodg.exese ele ficar inativo por mais de 5 minutos.

O problema com isso é que qualquer nova saída de áudio sofrerá agora com um atraso de inicialização de 5 a 10 segundos, tendo que esperar para audiodg.exeser spool novamente antes que a saída de áudio possa ser iniciada.

Já vi problemas de atraso de áudio sendo discutidos inúmeras vezes com conexões RDP em todas as versões do Windows Server, mas ainda não vi ninguém mencionar que essa poderia ser a causa de todos esses problemas.

O tempo de spoolup do audodg.exe atrasará todo o áudio no servidor. Não importa de onde vem o áudio. Os aplicativos interativos com feedback de áudio ficarão fora de sincronia e os vídeos do YouTube no Chrome congelarão até que o audiodg seja executado novamente.

No meu servidor, o audiodg consome 100% da CPU na inicialização. Não sei o que está fazendo, mas faz algo com 100% da CPU por cerca de 5 a 10 segundos antes que o áudio normal seja retomado.

Assim que estiver instalado e funcionando, todo o áudio será instantâneo. Sem atrasos ou atrasos. Tudo funciona bem, desde que continue funcionando.

A única maneira que encontrei de corrigir esse "recurso" irritante foi criar uma tarefa repetitiva que reproduz alguns segundos de som (silêncio) a cada 4 minutos para evitar que o Windows mate o audiodg.

Parece uma solução boba.

Algumas perguntas vêm à mente (em ordem de importância, eu acho):

1. Como eu poderia evitar que o audiodg fosse morto sem recorrer a soluções hacky? Existe uma configuração de registro para isso em algum lugar? Configurei o serviço como "manual", mas isso não faz diferença. Automático/Manual..mesmo problema independentemente.

2. Por que a inicialização do audiodg é tão lenta? Acho que isso também pode ser algum tipo de bug ou recurso não intencional.

Atualizar

Parece que encontrei a resposta para a pergunta 2 aqui:
O processo audiodg.exe verifica catroot e monopoliza IO