El problema más grande de comprar un equipo con Windows preinstalado, es decir, que sea OEM, es que normalmente tiene toda la basura que te puedas imaginar instalada. Casi siempre tiene antivirus de terceros, aplicaciones del fabricante que no sirven para nada y otra tanta cantidad de cosas que afectan el rendimiento del sistema operativo desde el primer momento.
Sumado a lo anterior, está la cantidad de basura adicional que ofrecen algunas instalaciones de productos como impresoras, agregando una cantidad de complementos inútiles en Windows.
La parte positiva de todo eso, por lo menos para los que nos emocionamos con problemas extraños, es que se puede llegar a aprender mucho con cualquier inconveniente causado por la combinación de tanta instalación. A continuación paso a describir un caso muy interesante, que puede ser además de ayuda para los que experimenten algo similar.
El problema
Básicamente, se había comprado la licencia personal de Office 365 a un equipo OEM, que obviamente tenía antivirus, software de impresora y otra cantidad interminable de aplicaciones de terceros; poco tiempo después de instalado Office, siempre que intentaban abrir un archivo de Word o Excel, Windows respondía con estos mensajes:
<<Microsoft Word dejó de funcionar>>
<<Microsoft Excel dejó de funcionar>>
No importa si se abría con privilegios estándar o administrador, un documento ya hecho o en blanco, siempre había crash antes de empezar a editar. Ahora, existían dos cosas curiosas:
1. Si se ejecutaba Word, la pantalla de bienvenida funcionaba sin ningún problema:
Al hacer clic en Documento en blanco, se reproducía el problema. Lo mismo pasaba en Excel, solo funcionaba hasta la pantalla de bienvenida.
2. El crash solo se reproducía en Word y Excel; PowerPoint por otra parte, funcionaba perfectamente, sin importar de qué forma se abriera.
Antes de yo entrar a revisar el problema, habían intentado reinstalar y reparar el Office, pero sin resultado positivo.
La causa
Lo más trágico de un crash en Windows, sea de aplicación o de sistema operativo, es que la información que brinda no sirve absolutamente para nada en la mayoría de ocasiones. En el caso de este mensaje, el “dejó de funcionar” es el mismo para cualquier aplicación que se detenga y no se pueda recuperar.
Primero que todo, se me ocurrió que seguramente había alguna extensión proveniente de otra aplicación integrada en Office, y me acordé que hace muy poco Autoruns de Sysinternals agregó una nueva pestaña enfocada precisamente para revelar qué complementos tiene instalado la suite.
Descargué Autoruns, lo ejecuté como administrador en el equipo y, en efecto, había algunos complementos cargando con Office:
Deshabilité los tres complementos, reinicié Word con mucha expectativa, pero para mi mala fortuna, el problema continuaba. Nada más para hacer por el lado de Autoruns, pues rara vez se le escapa algo a las herramientas de Sysinternals.
Aunque no sé nada sobre depuración de volcados de memoria, es decir, archivos .DMP, un análisis elemental puede ser de mucha ayuda como en el caso de pantallazos azules. Lo que hice entonces fue descargar ProcDump de Sysinternals, copiarlo en la carpeta de System32 para ejecutarlo desde cualquier procedí a hacer lo siguiente:
1. Creé la carpeta C:Dump para almacenar cualquier volcado de memoria.
2. Desde un símbolo del sistema con privilegios elevados, ejecuté:
procdump -e -w -ma winword.exe -accepteula C:Dump
La función de ProcDump es monitorear un proceso y escribir un volcado de memoria cuando el proceso exceda los parámetros indicados, o cuando hay alguna excepción que genere un crash. Esto es mucho más útil que hacerlo desde el Administrador de tareas, puesto que lo hace en el instante adecuado y de forma automática.
El parámetro de –e, sirve para escribir un volcado de memoria cuando el proceso tenga una excepción no controlada, –w espera a que el proceso se ejecute y –ma escribe un volcado de memoria completo. Después de esto, especifiqué el proceso que deseaba monitorear y dónde quería guardar el volcado de memoria.
Una vez hecho esto, ejecuté Windbg en mi propio equipo y abrí el volcado de memoria creado desde la opción File > Open Crash Dump:
Ya en la consola de Windbg, hice la operación más básica, ejecutar: !analyze –v
Tal cual como lo haría con un análisis de pantalla azul, después del amplio reporte que entrega Windbg, me concentré en lo que contenía el STACK_TEXT, que es básicamente lo que había en memoria al momento del crash.
Lo ideal es descartar las entradas que se refieran a módulos de Windows y analizar las demás. En este caso, me encontré con dos muy interesantes:
Ambas entradas tenían un mismo módulo llamado SprintIntegration. Para obtener más información, ejecuté desde la consola: lm vm SprintIntegration y obtuve esto:
Era una DLL llamada SprintIntegration.dll, perteneciente a una empresa con el nombre de ABBYY y con nombre de producto: ABBYY FineReader. Ya había una interesante pista, ¿cómo sabía de qué forma estaba interactuando esto con Office? Seguramente desde el Windbg hubiese podido obtener muchos más detalles, pero a falta de conocimiento, decidí ejecutar Process Monitor y seguir el rastro desde la ejecución de Word, hasta el crash.
Con todo el log de Process Monitor a la mano, realicé un primer filtro para que sólo me mostrara actividad que tuviese el proceso de Winword.exe perteneciente a Microsoft Word:
Hecho esto, abrí el cuadro de búsqueda (CTRL + F) y busqué por entradas que tuviesen referencia al nombre de producto ABBYY FineReader; el primer resultado arrojó una luz sobre lo que pasaba:
Tal como ven en la captura (clic para verla en tamaño real), Word estaba consultando a un valor llamado FriendlyName, en la sub-clave:
HKLMSOFTWAREWow6432NodeMicrosoftOfficeWordAddinsSprint.WordIntegration.9
Lo primero que llamó mi atención, es que estaba sobre la sub-clave de Addins y Autoruns no me había mostrado nada relacionado a Sprint.WordIntegration, cosa que me extrañaba bastante, porque al parecer esto era en realidad una extensión más de Office.
Cuando vi en las propiedades de la entrada en Process Monitor, pude ver finalmente la relación con el módulo de ABBYY:
Así se veía todo el contenido de la sub-clave Sprint.WordIntegration.9 en el Registro:
En la misma sub-clave de Office además, noté que cada producto tenía su apartado de Addins, y cuando expandí los de Excel y PowerPoint, encontré algo particular:
Tanto la sub-clave de Addins para Word, como la de Excel tenían la clave de Sprint, pero PowerPoint no; esto era un claro indicador del porqué ahí no había crash y en los otros dos productos sí.
La prueba final era proceder a eliminar la sub-clave para que el producto no la pudiera encontrar al abrirse:
Después de esto, abrí solo Word que es donde le había quitado ese complemento y no hubo ningún tipo de crash.
La solución
Encontrado y probado la causa, mi siguiente paso era ver de qué forma podía implementar una solución. Eliminar ambos complementos solucionaría el problema tanto en Word como en Excel, pero decidí buscar otro camino directamente desde la aplicación.
En Programas y Características, identifiqué la versión que tenía instalado Windows de ABBYY:
Tal como ven, era la 9.01.513.58212; abrí la aplicación en cuestión, fui al menú de Ayuda y como pensaba, existía la opción para buscar actualizaciones:
Para mi grata sorpresa, se abrió una página web indicándome que en efecto, había una actualización para la versión 9.0, pero lo más interesante era uno de los detalles sobre esta:
Esta aplicación corregía la integración con Office 2010 y 2013, así que probablemente el desarrollador ya tenía identificado el problema que estaba causando.
Descargué la actualización y procedí a instalarla. La versión cambió ligeramente:
Volví finalmente a abrir Word y como supuse, ya no había crash, así que podía utilizar libremente Word y Excel:
Obviamente, eliminar la sub-clave Sprint.WordIntegration.9 en los Addins de Word y Excel hubiese solucionado el problema sin necesidad de actualizar el cliente, pero actualizar era más sano y soportado.
¡Espero sea de utilidad!
No olviden seguirme en Twitter: www.twitter.com/secalderonr
Saludos.
Checho
