Un error 500 en Power BI Report Server puede parecer un problema de memoria o un archivo PBIX dañado. En este caso real, el origen estaba relacionado con el inicio del motor interno de Analysis Services, los permisos de la cuenta de servicio y el acceso a claves criptográficas después de una actualización de Windows Server.
El incidente: informes que dejaron de cargar después de una actualización
En un entorno productivo basado en Windows Server 2022, los usuarios comenzaron a recibir el mensaje:
Something went wrong – Unable to load the data model
El portal devolvía además un código de estado 500. Los informes que utilizaban modelos semánticos locales en modo Import dejaron de abrirse y la carga de nuevos archivos .pbix fallaba con mensajes que sugerían, de manera incorrecta, que los archivos estaban dañados.
El comportamiento apareció después de instalar la actualización acumulativa KB5094128. Esta relación temporal convirtió al parche en uno de los primeros elementos que debían revisarse, aunque no era suficiente para concluir que la actualización fuera, por sí sola, la causa definitiva.
El objetivo del diagnóstico fue identificar qué componente estaba fallando y evitar cambios innecesarios sobre los informes, la memoria o las bases de Report Server.
¿Qué mostraban los logs de Power BI Report Server?
El archivo RSHostingService.log reveló un patrón repetitivo:
WARN|Child Process [AS] Died. Check the log for further information
INFO|Throttled restart of process by 472,015.46ms: AS
El proceso hijo identificado como [AS] corresponde al motor interno de Analysis Services utilizado por Power BI Report Server para cargar y ejecutar los modelos semánticos de los informes.
El proceso msmdsrv.exe se iniciaba, permanecía activo durante aproximadamente ocho segundos y finalizaba abruptamente. Power BI Report Server intentaba reiniciarlo, pero después de varias caídas consecutivas aplicaba un mecanismo de protección o throttling. Este comportamiento aumentaba progresivamente el tiempo de espera entre reinicios.
El resultado visible para los usuarios era un error 500. El problema real estaba varios niveles por debajo: el motor analítico no conseguía mantenerse operativo.
La primera hipótesis: falta de memoria
El archivo SQLDUMPER_ERRORLOG.log mostraba que se generaban volcados .mdmp al intentar abrir un informe. Ante este comportamiento, una de las primeras hipótesis fue la falta de memoria disponible para Analysis Services.
Se revisó la configuración del archivo msmdsrv.ini y se evaluaron parámetros como:
<HardMemoryLimit>95</HardMemoryLimit>
<TotalMemoryLimit>85</TotalMemoryLimit>
<VertiPaqPagingPolicy>2</VertiPaqPagingPolicy>
Modificar estos valores no resolvió el incidente. El motor continuaba fallando prácticamente desde el inicio, antes de cargar un volumen significativo de información.
Este punto fue decisivo: cuando un proceso cae de forma inmediata y sistemática, la memoria puede no ser la causa principal. Conviene revisar también permisos, identidad del servicio, claves criptográficas, archivos temporales y cambios recientes en el sistema operativo.
La pista clave: el motor no podía determinar su clave de instancia
En los registros apareció una línea especialmente relevante:
ERROR, msmdsrv.exe, Right instance-specific key can not be determined
El mensaje indicaba que el proceso no conseguía identificar o utilizar correctamente la clave asociada a su instancia. Power BI Report Server utiliza claves de cifrado para proteger credenciales, conexiones y otra información sensible almacenada en su base de datos.
La investigación se concentró entonces en tres factores relacionados:
- la actualización reciente de Windows Server;
- los privilegios efectivos de la cuenta de servicio;
- el acceso a los contenedores y claves criptográficas utilizados por Report Server.
En el entorno analizado, la cuenta de dominio utilizada por el servicio ya no tenía todos los derechos necesarios para ejecutar correctamente el motor analítico. Además, la configuración criptográfica asociada a la identidad del servicio parecía haber quedado en un estado inconsistente.
No debe interpretarse este resultado como una afirmación de que KB5094128 provoque siempre este fallo. Se trata de un caso técnico concreto en el que el incidente apareció después de la actualización y se resolvió al reparar permisos, identidad y componentes temporales.
Cómo se recuperó Power BI Report Server
La intervención se dividió en tres etapas. Antes de modificar la cuenta de servicio, se verificó la existencia de un respaldo actualizado de las claves de cifrado y se documentó la configuración vigente. Este paso es crítico para evitar la pérdida de credenciales almacenadas, suscripciones y conexiones cifradas.
1. Revisar los derechos de la cuenta de servicio
Desde secpol.msc se revisaron las políticas locales en:
Directivas locales > Asignación de derechos de usuario
En este entorno fue necesario validar la presencia de la cuenta en los siguientes derechos:
- Iniciar sesión como servicio.
- Ajustar las cuotas de memoria para un proceso.
- Aumentar el conjunto de trabajo de un proceso.
Después de aplicar los cambios, se ejecutó:
gpupdate /force
La asignación de privilegios debe realizarse con criterio de mínimo acceso. No conviene agregar derechos de forma automática sin comprobar previamente la identidad utilizada por Power BI Report Server, las políticas de dominio y los requisitos del motor analítico.
Si una política de grupo de dominio administra esos derechos, una modificación local puede ser reemplazada durante la siguiente actualización. En ese caso, el ajuste debe coordinarse con el equipo responsable de Active Directory y seguridad.
2. Reprocesar la identidad del servicio desde Configuration Manager
El segundo paso buscó reparar la relación entre la cuenta de servicio, Power BI Report Server y las claves cifradas.
Desde Power BI Report Server Configuration Manager, en la pestaña Service Account, se realizó una conmutación controlada:
- Se verificó el respaldo de la clave de cifrado.
- Se documentaron la cuenta actual y la configuración de Report Server.
- Se cambió temporalmente el servicio a una cuenta integrada, como Network Service.
- Se aplicó el cambio y se verificó el resultado en el panel de operaciones.
- Se volvió a configurar la cuenta de dominio original con su contraseña.
- Se aplicó nuevamente la configuración.
El cambio realizado desde Configuration Manager es preferible a modificar la cuenta directamente desde la consola de servicios de Windows. La herramienta administra tareas adicionales relacionadas con la identidad, las claves protegidas, las reservas de URL y la conexión con la base de Report Server.
Este procedimiento permitió regenerar y volver a asociar correctamente determinados componentes de seguridad vinculados con la identidad del servicio.
3. Limpiar los workspaces temporales dañados
Con Power BI Report Server detenido, se revisó la ruta:
C:\Program Files\Microsoft Power BI Report Server\PBIRS\ASEngine\workspaces\
Antes de eliminar contenido, se confirmó que el servicio estuviera completamente detenido y se conservó una copia temporal de respaldo para facilitar una eventual reversión.
Luego se removieron los archivos y carpetas temporales generados durante el ciclo de fallos. Estos elementos no correspondían a los archivos PBIX publicados ni a las bases de datos de catálogo, sino a estructuras de trabajo utilizadas por el motor analítico.
Al reiniciar el servicio, Power BI Report Server generó nuevos workspaces sin reutilizar los componentes temporales que habían quedado atrapados durante el crash loop.
Resultado de la recuperación
Después de aplicar los cambios, el proceso msmdsrv.exe permaneció estable en el Administrador de tareas. El motor volvió a escuchar las solicitudes internas, los modelos semánticos pudieron cargarse y los informes recuperaron su funcionamiento normal.
Las validaciones incluyeron:
- apertura de informes existentes;
- carga de nuevos archivos PBIX;
- consulta de modelos en modo Import;
- revisión de los logs de Hosting Service y Analysis Services;
- monitoreo del proceso msmdsrv.exe;
- comprobación de suscripciones y conexiones almacenadas;
- verificación de la estabilidad después de varios reinicios.
El servicio quedó operativo en pocos minutos después de completar la reparación y limpiar los componentes temporales.
En resumen
Ante un error 500 y un crash loop de Power BI Report Server, conviene revisar:
- RSHostingService.log;
- logs de Analysis Services y msmdsrv.exe;
- archivos generados por SQLDumper;
- fecha y hora exactas del último Windows Update;
- privilegios efectivos de la cuenta de servicio;
- estado y respaldo de las claves de cifrado;
- cambios recientes en políticas locales o de dominio;
- contenido temporal de ASEngine\workspaces;
- versión instalada de Power BI Report Server.
La secuencia recomendada es diagnosticar antes de modificar. Aumentar la memoria, reinstalar el servidor o volver a publicar todos los informes puede no resolver el problema si la causa está en la identidad del servicio o en las claves criptográficas.
Buenas prácticas para evitar el mismo incidente
Las actualizaciones de seguridad son necesarias, pero deben incorporarse a un procedimiento controlado. En servidores de Power BI Report Server resulta recomendable:
- probar los parches en un ambiente no productivo;
- respaldar las claves de cifrado;
- documentar la cuenta y los permisos del servicio;
- guardar una copia de la configuración;
- controlar los logs antes y después de la actualización;
- verificar que la versión de Power BI Report Server tenga soporte vigente;
- monitorear msmdsrv.exe después del reinicio;
- contar con un procedimiento de reversión;
- validar informes Import, DirectQuery, suscripciones y actualizaciones programadas.
También es conveniente registrar una línea de tiempo precisa. La coincidencia temporal entre un parche y un incidente constituye una pista importante, pero no reemplaza el análisis de logs ni la validación técnica de la causa.
Cómo puede ayudar BigTelligent
En BigTelligent trabajamos en la administración, diagnóstico, mantenimiento y modernización de plataformas basadas en Power BI Report Server, SQL Server, Analysis Services, Azure y Microsoft Fabric.
Un entorno de Business Intelligence confiable no depende únicamente del diseño de los dashboards. También requiere administrar correctamente servicios, permisos, memoria, claves de cifrado, modelos semánticos, procesos de actualización y componentes del sistema operativo.
Nuestro enfoque combina diagnóstico técnico, arquitectura y continuidad operativa para ayudar a las organizaciones a reducir riesgos y recuperar con rapidez sus plataformas críticas de información.
Preguntas frecuentes
¿Por qué Power BI Report Server muestra un error 500 al abrir un informe?
El error puede aparecer cuando el motor interno de Analysis Services no logra iniciar o cargar el modelo. Las causas posibles incluyen problemas de memoria, permisos, claves de cifrado, workspaces dañados, incompatibilidades o fallos del proceso msmdsrv.exe.
¿Qué significa “Child Process [AS] Died”?
Significa que el proceso de Analysis Services utilizado por Power BI Report Server finalizó de forma inesperada. El servidor intenta reiniciarlo, pero puede aplicar throttling si las caídas se repiten.
¿Por qué Power BI Report Server demora el reinicio del motor?
El mecanismo de throttling limita los reinicios consecutivos de un proceso que falla repetidamente. Su objetivo es evitar un consumo continuo de recursos, aunque durante ese período los informes pueden devolver errores.
¿Un error de SQLDumper siempre significa falta de memoria?
No. SQLDumper genera archivos de diagnóstico cuando detecta determinados fallos. El dump puede estar relacionado con memoria, permisos, excepciones nativas, acceso a claves u otras causas. Debe analizarse junto con los demás logs.
¿Es seguro cambiar temporalmente la cuenta del servicio?
Puede ser una medida válida, pero debe hacerse desde Power BI Report Server Configuration Manager, con respaldo previo de las claves de cifrado y una ventana de mantenimiento. No conviene modificarla directamente desde services.msc.
¿Se puede eliminar el contenido de la carpeta workspaces?
Solo con el servicio detenido, después de confirmar la ruta y preferentemente conservando una copia temporal. La acción debe formar parte de un procedimiento documentado y no debe confundirse con la eliminación de informes o bases de catálogo.
¿KB5094128 es una causa confirmada de este fallo?
En este caso, el incidente apareció después de instalar la actualización y el análisis encontró problemas de permisos y claves. Sin embargo, debe tratarse como una correlación observada en ese entorno, no como un problema universal hasta que exista confirmación oficial o pueda reproducirse de forma controlada.
