El post que buscas se encuentra eliminado, pero este también te puede interesar

Problemas con la inicialización de Explorer.exe

Anuncios

Uno de los problemas más frustrantes para un usuario es que su sistema no consiga iniciarse correctamente. En general estamos acostumbrados a trabajar con una máquina "más o menos operativa", pero cuando nos encontramos con un sistema que no llega al escritorio de Windows, empiezan a sonar las alarmas y la palabra "formateo" ronda nuestra cabeza. Este artículo intentará evitar que esto sea así.
El proceso de arranque de Windows es un proceso complejo que va desde la carga del sector de arranque de la partición del sistema hasta la aparición del escritorio de Windows y la barra de tareas. Este artículo se centrará en la parte final de este proceso: la carga del shell del sistema operativo (típicamente Explorer.exe) y cómo abordar un problema de inicialización del mismo.
El proceso de inicialización de Explorer.exe podría decirse que consta de tres fases bien diferenciadas: Una fase inicial en la que se prepara el shell, otra fase central en la que se crea el escritorio y la barra de tareas (esta es la fase principal), y otra fase de postinicialización que se inicia una vez que tenemos el escritorio, los iconos y la barra de tareas en pantalla. Obviamente un fallo en alguna de las dos primeras fases va a derivar en que el sistema solo muestre un escritorio vacío en el que no podremos hacer nada más. Este artículo se centra sólo en las dos primeras fases por ser en las que influyen en que un sistema no muestre ni barra de tareas ni escritorio.
Fase de preinicialización
Una cosa que no mucha gente sabe es que Explorer.exe admite parámetros. Si ejecutamos Explorer.exe /separate, le estamos diciendo al sistema que debe ejecutar obligatoriamente una nueva instancia de Explorer.exe. Por lo regular, Explorer.exe se ejecuta sin parámetros, como así indica la clave HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, valor Shell. Una de las primeras cosas que se realizan en esta fase es la creación (si no existiera ya) de la clave de Registro HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer. En ella se almacenan la mayoría de parámetros de configuración que tienen relación con la interfaz gráfica.
Posteriormente, tiene lugar la inicialización la tecnología de comunicación DDE (Dynamic Data Exchange), que pese a ser ya bastante antigua, se usa aún en algunas partes del shell, como la parte relacionada con las asociaciones de ficheros. Se establece en este momento el orden de apagado de Explorer.exe: Ante un apagado o un reinicio de la máquina, Explorer.exe terminará su ejecución en último o penúltimo lugar, dependiendo de si hay algún depurador en la máquina en ese mismo momento. Seguidamente se inicializa la cache de iconos, proceso explicado en uno de los artículos anteriores.
Quizá el momento más importante de esta fase es la ejecución automática de los programas presentes en la clave de Registro HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce. Estos programas se ejecutan, como su propio nombre indica, una sola vez: en el momento que un usuario con privilegios administrativos inicie sesión en la máquina. Hay un programa encargado de realizar este proceso: C:Windowssystem32Runonce.exe. Se llama al comando "Runonce.exe /Explorer", el cual, si el usuario es administrador del equipo, se encarga de ejecutar el contenido de la clave RunOnce (que por lo regular son fases finales de la instalación de algún programa). Quizá se pregunte qué es lo que ocurre en Windows Vista, en el que todo intento de elevación de privilegios es bloqueado según el artículo KB930367. La clave RunOnce es una excepción de la regla (tenga en cuenta que sólo un proceso que haya elevado sus privilegios ha sido capaz de escribir en la clave RunOnce, por lo que esto no es ninguna vulnerabilidad). También es posible desactivar la ejecución de la rama RunOnce mediante la siguiente política: DisableLocalMachineRunOnce.
Por último, se crean (si no existieran ya), tres de las carpetas del perfil de usuario relacionadas con el shell: C:UsersUsuarioDesktop, C:UsersUsuarioAppDataRoamingMicrosoftWindowsStart Menu y C:UsersUsuarioAppDataRoamingMicrosoftWindowsStart MenuPrograms.
Fase de inicialización del escritorio y la barra de tareas
Esta es la fase crucial. Cualquier fallo que ocurra en esta fase (y en la anterior, pero según mi experiencia es menos probable que esto ocurra) significará que Explorer.exe terminará abruptamente y no verá nada en pantalla, nada más que su escritorio sin ningún icono. Si se encuentra en una situación como ésta, primero abra Administrador de tareas pulsando Ctrl+Alt+Supr e intente ejecutar el proceso Explorer.exe. Si se ejecutara correctamente, más que seguramente se trate de un virus que ha modificado la clave HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon. En mi anterior blog tengo unas instrucciones al respecto. Si al ejecutar Explorer.exe observa que el proceso aparece un instante para luego desaparecer, primeramente intente un inicio limpio de Windows: inicie el sistema en Modo seguro y compruebe si persiste el problema. Si en Modo seguro todo funcionara correctamente, vaya añadiendo elementos al inicio mediante Msconfig hasta dar con el culpable. Hay un caso en el cual detecté que el servicio Shell Hardware Detection puede ser el culpable (en tal caso, lo que ocurre es que si espera unos 3 ó 4 minutos observa que el shell se inicia correctamente). El artículo KB913630 explica el problema, pero solo ofrece un workaround.
Si nada de lo anterior le diera resultado, es posible que se encuentre ante un problema con alguno de los componentes encargado de crear el escritorio y la barra de tareas. Explorer.exe se apoya en multitud de clases COM en su mayoría presentes en librerías de Internet Explorer (como Browseui.dll, por ejemplo). Es por ello que algún que otro artículo antiguo de la KB recomendaba reinstalar Internet Explorer como medida de corrección. El problema es que las últimas versiones de Internet Explorer están más y más separadas de lo que es el shell del sistema, por lo que una reinstalación de Internet Explorer probablemente no solucione el problema. ¿Cómo detectar dónde está, pues, el fallo?
Según mi experiencia, un altísimo número de problemas con la interfaz gráfica se deben a que el método CoCreateInstance de Ole32.dll falla por algún motivo. Este motivo suele ser que la clase correspondiente no está registrada en el Registro del sistema. Una manera de abordar este problema es adjuntar Process Monitor al proceso en cuestión (en nuestro caso Explorer.exe) y filtrar por resultado "NAME NOT FOUND". Nótese que no todas las entradas que se indiquen como "NAME NOT FOUND" son posibles causantes del problema; en muchas ocasiones un proceso busca una determinada clave en el Registro y, en caso de no encontrarla, establece valores por defecto para esa configuración. En este artículo se describe una manera en la que abordé el problema de un usuario usando Windbg:
Ejecute el programa Explorer.exe desde dentro de Windbg e introduzca este comando:
0:000> bp ole32!CoCreateInstance "dt ntdll!_GUID poi(@esp+4);gu;j (@eax & 0x0`ffffffff) = 0x0`80040154 '';'gc'"
No se asuste, este comando lo que hace es crear un punto de ruptura (breakpoint) cada vez que alcancemos la función CoCreateInstance. Seguidamente nos muestra el contenido de su primer parámetro (el CLSID implicado), y avanza hasta el retorno de la función (con gu). En este momento, la instrucción condicional j compara el contenido del registro EAX (donde se almacena el retorno de la función) con el valor 0x80040154, que según MSDN quiere decir REGDB_E_CLASSNOTREG. Si lo encuentra, detenemos la depuración; si no, seguimos adelante.
Ejecutamos el proceso y vemos lo siguiente:
0:000> g
ModLoad: 5cf60000 5cf86000 C:WINDOWSsystem32ShimEng.dll
ModLoad: 6fdb0000 6ff7a000 C:WINDOWSAppPatchAcGenral.DLL
ModLoad: 76b00000 76b2e000 C:WINDOWSsystem32WINMM.dll
ModLoad: 77bb0000 77bc5000 C:WINDOWSsystem32MSACM32.dll
ModLoad: 76630000 766e5000 C:WINDOWSsystem32USERENV.dll
ModLoad: 76340000 7635d000 C:WINDOWSsystem32IMM32.DLL
ModLoad: 773a0000 774a3000 C:WINDOWSWinSxSx86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83comctl32.dll
ModLoad: 74dc0000 74e2d000 C:WINDOWSsystem32RichEd20.dll
ModLoad: 58c30000 58cca000 C:WINDOWSsystem32comctl32.dll
ModLoad: 746b0000 746fc000 C:WINDOWSsystem32MSCTF.dll
ModLoad: 75160000 7518e000 C:WINDOWSsystem32msctfime.ime
ModLoad: 77b10000 77b32000 C:WINDOWSsystem32appHelp.dll
{750fdf0e-2a26-11d1-a3ea-080036587f03}
+0x000 Data1 : 0x750fdf0e
+0x004 Data2 : 0x2a26
+0x006 Data3 : 0x11d1
+0x008 Data4 : 8 "???"
ModLoad: 76f90000 7700f000 C:WINDOWSsystem32CLBCATQ.DLL
ModLoad: 77010000 770e0000 C:WINDOWSsystem32COMRes.dll
ModLoad: 779f0000 77a45000 C:WINDOWSSystem32cscui.dll
ModLoad: 765b0000 765cd000 C:WINDOWSSystem32CSCDLL.dll
ModLoad: 58e40000 58e65000 C:WINDOWSsystem32desk.cpl
{b12ae898-d056-4378-a844-6d393fe37956}
+0x000 Data1 : 0xb12ae898
+0x004 Data2 : 0xd056
+0x006 Data3 : 0x4378
+0x008 Data4 : 8 "???"
ModLoad: 5ba10000 5ba83000 C:WINDOWSsystem32themeui.dll
ModLoad: 76330000 76335000 C:WINDOWSsystem32MSIMG32.dll
{4c892621-6757-4fe0-ad8c-a6301be7fba2}
+0x000 Data1 : 0x4c892621
+0x004 Data2 : 0x6757
+0x006 Data3 : 0x4fe0
+0x008 Data4 : 8 "???"
ModLoad: 01110000 013e6000 C:WINDOWSsystem32xpsp2res.dll
{ecd4fc4d-521c-11d0-b792-00a0c90312e1}
+0x000 Data1 : 0xecd4fc4d
+0x004 Data2 : 0x521c
+0x006 Data3 : 0x11d0
+0x008 Data4 : 8 "???"
eax=80040154 ebx=00000000 ecx=00000000 edx=80040154 esi=000ee4a0 edi=001a009c
eip=01017362 esp=0146f66c ebp=0146f674 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
explorer!BandSite_CreateView+0x3b:
01017362 85c0 test eax,eax
Marcadas en negrita están las clases CLSID pasadas como primer parámetro a CoCreateInstance. El depurador se detuvo en este caso en la función BandSite_CreateView, que es parte de la creación de la barra de tareas. Como ve, el CLSID es {ecd4fc4d-521c-11d0-b792-00a0c90312e1}, así que inmediatamente sospeché que la clave HKEY_CLASSES_ROOTCLSID{ecd4fc4d-521c-11d0-b792-00a0c90312e1} faltaba o estaba dañada. Mis sospechas se confirmaron:
0:004> !dreg hkcrclsid{ecd4fc4d-521c-11d0-b792-00a0c90312e1}
Could not open subkey clsid{ecd4fc4d-521c-11d0-b792-00a0c90312e1}. Error (2).
No subkeys
Al importar dicha clave desde un sistema que funcionaba correctamente, el usuario logró solucionar su problema con Explorer sin necesidad de reinstalar Windows.
Quizá este escenario de depuración no sea aplicable a su caso, pero seguramente le habrá dado un punto de partida para enfrentarse a este tipo de problemas sin necesidad de reinstalar ni de instalar en limpio el sistema operativo.

Anuncios

2 comentarios - Problemas con la inicialización de Explorer.exe

@facubas
que buena info! sabes una bocha! pero separame los parrafos jajaj se complica bastante leer sino.. gracias por la data! no tengo pts, si no te daba je..