Seu sistema de armazenamento está falhando ou está muito lento para acompanhar. Se o pedido de inserção estiver parado por muito tempo, o Exchange acha que o armazenamento está morto e mata o Wininit para forçar a reinicialização a frio.
Consulte o link e vá até o final. É o mesmo para 2013 e 2016.
In some cases, the entire storage stack may be affected by the hang, making it impossible to write failure events to the crimson channel or any other area of the Windows Event Log. ESE also monitors the crimson channel by verifying that the event log can be written to. If writing to the event log fails for a long period of time, MSExchangeRepl intentionally causes a bugcheck of Windows by terminating wininit.exe. When the operating system I/O is hung, the system is obviously unable to write any ESE events to the event log.
Eu experimentei isso em primeira mão ao usar o Backup do Windows Server para fazer o backup do Exchange. Quando o backup é iniciado, ele fará a verificação de consistência em todos os bancos de dados em paralelo. Isso causou o Exchange para BSOD depois de alguns minutos quando o armazenamento caiu.
A primeira solução é desabilitar o heartbeat do ATS para o storage array link
O texto é muito longo para ser copiado, mas TL; DR: Sua conexão com o storage array pode ser descartada sob IO pesado quando o tempo de expiração de 8 segundos do ATS expirar, o que causará o tempo limite de IO na VM, fazendo com que o Exchange seja BSoD.
A solução secundária é adicionar controladores de armazenamento à VM e distribuir discos de banco de dados entre os controladores. No meu caso, o controlador pvscsi único iria sufocar mal sob 6 bases de dados, mas quando os discos (incluindo o disco do sistema operacional, etc) foram distribuídos por 4 controladores pvscsi, os problemas desapareceram. Não tenho uma referência para isso, apenas experiência pessoal no vSphere 5.5 U3.