El archivo “Comdlg32.ocx” no registrado para ejecutar la aplicación, Process Monitor, Regsvr32 y su solución

Tal cual mostraré en el problema de hoy, se ven muchos casos similares dentro de las empresas con aplicaciones que están hechas a la medida, y vitales para el negocio, sobre todo en los procesos normales que hacen las compañías con respecto a la Compatibilidad de Aplicaciones sobre una nueva versión del sistema operativo. Aunque el caso lo expondré sobre una aplicación que no marca trascendencia, decidí exponerlo para mostrar algunos detalles importantes y válidos para cuando alguna vez lo enfrenten.

El problema y su causa

El inconveniente lo traigo – como en muchas ocasiones – de un hilo abierto en los Foros de Windows 8 en Microsoft Community. Básicamente, un usuario estaba intentando ejecutar una aplicación llamada Pokémon Gold Sprite Editor que realiza un tipo de modificación sobre algunos ROMs del famoso juego de Pokemon, pero estaba recibiendo el siguiente mensaje de error:

image

Inglés:Component ‘COMDLG32.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid

Español:El componente ‘COMDLG32.OCX’ o alguna de sus dependencias no está registrada correctamente: archivo perdido o inválido

Como ven, el ejecutable estaba dependiendo de una OCX que normalmente no aparece en Windows 8, y por tanto no se podía seguir, solo aceptar para cerrarse. Este tipo de errores suele verse mucho con aplicaciones que están escritas en Visual Basic 6, y por lo general es durante el proceso de instalación, aunque es normal que algunos dejen incluso terminar la instalación, pero al momento de abrir algún módulo, presente algún tipo de error no controlado.

Tengamos presentes que los archivos con extensión .OCX son Controles ActiveX que la aplicación requiere tener en el Registro de Windows para funcionar adecuadamente.

Ahora, ¿Dónde se supone que esta aplicación estaba buscando el Control ActiveX? Para saber eso, ejecuté Process Monitor de Sysinternals y lo puse a monitorear mientras ejecutaba, y una vez terminado, busqué dentro de la Traza (CTRL + F) por el nombre de Comdlg32.ocx y esto fue lo que encontré:

PK6

Si analizamos un poco el resultado de Procmon, el ejecutable está tratando de abrir el Control ActiveX COMDLG32.OCX desde distintas partes, empezando por la ubicación original del ejecutable, así como en SysWOW64 que es donde normalmente deben residir estos controles y las respectivas DLLs utilizadas, pero también en otros directorios que Windows puede considerar como locación de referencia. Bastante autosuficiente el sistema operativo.

Para aclarar un poco la razón del por qué Process Monitor muestra la operación como CreateFile, es que si nos vamos a la API de Windows, por lo menos en Registro y Archivos, Antes de pasar a crear algo, la función internamente la busca para ver si ya existe.

Como mencioné, si esto fuera un instalador completo, tal cual debería suceder, o si tuviera embebido el Control ya que tanto lo necesita, podría registrarlo buscándolo en algún directorio fuente, así que para este caso, primero había que buscarlo manualmente desde algún servidor de confianza. Aquí por supuesto entro a decir que es algo bastante riesgoso, pues es muy probable que llegue a tener software malintencionado dependiendo de donde se baje. Con fines de prueba, y para poder encontrar la solución, yo recurrí a un blog de un MVP donde se entregaba la descarga del OCX y aún así, Sigcheck de Sysinternals reportaba como no firmado:

image

Para facilitar el trabajo a la aplicación, tenía el OCX en la misma carpeta de donde se lanzaba, pues ahí lo buscaba de primero. Si se ejecutaba entonces con privilegios estándar, seguía apareciendo el mismo error, pero al ejecutarlo con privilegios elevados (Clic derecho, Ejecutar como Administrador), mi sorpresa fue que la aplicación estaba viva:

image

¿Por qué? Claramente estaba haciendo algo más que buscar y abrir el archivo, así que busqué nuevamente en Process Monitor, y antes que nada iba a reportarla como SUCCESS al tratar de buscarla:

image

Lo interesante es que si iba un poco más adelante en todas las operaciones de CreateFile, viendo el Stack dentro de las Propiedades de la operación, me encontraría con la ejecución de la función DllRegisterServer:

image

No tengo los conocimientos necesarios para reproducir esto programáticamente con la API, o explicar en detalle, pero según la documentación oficial de Microsoft, con esto hace el registro Windows internamente, sea llamado por la respectiva aplicación, o utilizando la herramienta de Regsvr32.exe embebida.

Después de esto, ya podía correr el ejecutable incluso sin permisos administrativos, y abría correctamente. Esto sucedía porque ahora cada vez que se ejecutaba, la OCX había quedado registrada, y ya no la buscaría en su directorio, sino que la referenciaría directamente contra el Registro de Windows:

image

Para este caso, lo hacía específicamente en el valor (Default) ubicado en:

HKCRWow6432NodeCLSID{F9043C85-F6F2-101A-A3C9-08002B2F49FB}InprocServer32

*Nota: WOW64Node es porque es un equipo a 64 bits, y la aplicación es de 32 bits. La ruta normal sería: HKEY_CLASSES_ROOTCLSID

Si veía esto desde el Editor de Registro, me iba a encontrar con que el contenido del valor indicaba la ruta exacta de la OCX:

image

Esto quiere decir, que si esa OCX la eliminaba del directorio desde donde la aplicación la registró, el problema seguiría ocurriendo. Con la falta de la sub-clave InprocServer32, también se reproducía el problema, pero en general es necesaria toda la clave para que esté bien registrada.

¿La solución?

Pues bien, la solución consiste en registrar siempre el OCX de una forma correcta, y con esto me refiero a ubicación y procedimiento, dado el caso que la aplicación no lo haga bien y se presenten este tipo de mensajes.

Lo primero que debemos hacer es pegar el Control ActiveX (.OCX) en la carpeta System32 si es que estamos sobre un sistema operativo de 32 bits (x86), o en la carpeta SysWOW64 para una arquitectura de 64 bits (x64 o AMD64). Ambos directorios están ubicados en la carpeta %SystemDrive%Windows, siendo %SystemDrive% por lo general C:

Para este caso, al ser un sistema de 64 bits, la OCX la pegué en C:WindowsSysWOW64

image

El siguiente paso es abrir un Símbolo del Sistema con privilegios elevados, y desde Windows 8 se puede hacer fácilmente haciendo clic derecho en la parte inferior izquierda de la Barra de Tareas y seleccionar Símbolo del Sistema (Administrador):

PK1

El Símbolo del Sistema nos debe abrir en la ubicación C:WindowsSystem32, y el movernos dependerá de si el OCX se va a registrar en un equipo de 32 o 64 bits, pues si es el primero, la ubicación es la perfecta, pero si no es el caso, debemos digitar:

cd C:WindowsSysWOW64

image

Al asegurarnos estar en el directorio correcto y con la OCX copiada, haremos uso de la herramienta de Regsvr32 embebida en Windows para registrar el Control ActiveX digitando:

regsvr32 Comdlg32.ocx

image

Si el proceso se lleva a cabo correctamente, al presionar ENTER nos debe dar un mensaje con la operación completada sin problemas:

image

Después de esto, nuestra aplicación ejecutará normalmente, sin preocuparnos de nada más, mientras se mantenga la OCX en la ubicación correcta:

P3

PD. No olviden seguirme en Twitter: https://twitter.com/secalderonr

Saludos,

Checho

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *