martes, 23 de febrero de 2010

Más errores del parser XML de Microsoft (MSXML)

En mi anterior entrada explicaba un problema bastante común en distintas versiones de Windows (estación y servidor) debido a un fallo en el registro de una DLL relacionada con el motor de parseo XML de Microsoft.

Vimos los problemas más comunes y un sencillo procedimiento para arreglar el problema, consistente en el registro manual de uno o varios archivos DLL.

Pues además, como ya adelantaba, existe una variante de este mismo problema causado por la actualización del MSXML versión 6 de Microsoft en Windows XP con el SP3 o versiones superiores del sistema operativo de Microsoft.

Dicha actualización se produce, por ejemplo, durante la instalación del cliente de Microsoft Dynamics NAV (o lo que antiguamente llamábamos Navision), y más concretamente durante la parte  en que se instala el motor de SQL Server 2005 en la misma estación de trabajo.


La razón del fallo es que Microsoft ha protegido ciertos archivos del sistema contra sobreescritura mediante un sistema llamado WFP (Windows File Protection) como medida desesperada para luchar contra el malware y los problemas inherentes a la arquitectura de Windows. El archivo MSXML6R.DLL está incluido dentro de este programa de protección. Y el sistema funciona tan bien, o tan mal, según se mire, que inhibe la sobrescritura de dicho archivo incluso para las propias herramientas de Microsoft.

Por tanto, como ya os imagináis, al llegar al momento de actualizar la MSXML6, el sistema intenta primero desinstalar la actual MSXML6 para reinstalar la nueva versión. La DLL queda "desregistrada", pero la actualización de la misma nunca llega a producirse por el error de escritura. La aplicación se suele dejar terminar de instalar ignorando ese archivo, pero el sistema ya queda "tocado" de muerte con síntomas similares a los descritos en mi anterior artículo.

La vergonzosa respuesta de Microsoft sobre este problema es inconcebible. "Sí, esto es lo que pasa, y si lo quieres bien, y si no, ajo y agua".

La promiscuidad es sana

A pesar del problema, la mayoría de las veces se puede reparar si se vuelve a registrar manualmente de forma similar al artículo anterior, pero con el archivo MSXML6R.DLL, ya que aunque el registro de dicha biblioteca esté defectuoso, el archivo está físicamente en su lugar.

Aún así, una forma de evitar este problema es desactivar el Windows File Protection que provoca tantos quebraderos de cabeza incluso a sus propios autores. Para ello tenemos dos opciones:


  • Desinstalar temporalmente el SP3; tiene el inconveniente de que es un proceso muy lento y luego hay que volverlo a instalar. Además, no se aconseja si ya se han instalado nuevas actualizaciones o aplicaciones posteriores a la instalación de dicho SP3.
  • Desinhibir el WFP a partir del siguiente inicio. Implica más reinicios del sistema, pero es más limpio. Para ello hay que cambiar el siguiente valor en el registro (y si no existe, crearlo):
Ruta de la clave: HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon
Nombre del valor: SFCDisable
Tipo de dato: DWORD
Dato del valor: 0 = Activado (opción por defecto), 1=desactivado (pregunta en el siguiente arranque), 2=desactivado tras reiniciar, 4=activado con avisos desactivados

Lo mejor para nuestro caso particular es ponerlo a 2 y reiniciar el equipo. A partir de ese momento podemos probar la reinstalación. Si ésta vuelve a fallar, entonces lo mejor es ejecutar manualmente la actualización del MSXML versión 6. De esta forma, el instalador del SQL Server 2005 o del Dynamics NAV se saltará este paso al encontrar que la versión instalada es posterior, lo que evitará el problema.

Se puede actualizar manualmente la MSXML6 descargando la actualización de la siguiente ruta:


Espero que haya sido de utilidad este truqui, pues por algo tan simple a veces se pueden perder horas o días de trabajo si no se tiene la solución.

Si hay algo que me viene a la mente al pensar en este fallo, es la muerte del loro.

Buenas noches.