El caso que pasaré a describir, ha sido uno de los más duros que he logrado resolver, y me gustaría compartirlo aquí, porque es uno de los que empieza a tener mucha frecuencia en los foros de soporte de Microsoft. Como suelo hacerlo, mostraré el problema, la posible causa según toda la investigación hecha y su solución.
El problema
Todo nació en un hilo de los foros de Windows 7 en Microsoft Community; aunque era el mismo problema, la solución resultó ser bastante diferente.
Básicamente, cada que el usuario iniciaba sesión en su Windows 7, el siguiente mensaje de error aparecía:
«Error al cargar la secuencia de comandos “D:bin.doc“ El dispositivo no está listo.»
Inglés: «Loading script “D:bin.doc” failed (The device is not ready.)»
Después de hacer clic en el botón Aceptar, el mensaje desaparecía y no habían más comportamientos extraños en el sistema operativo, por lo menos hasta el siguiente reinicio o cierre de sesión.
El problema solo afectaba a ese usuario en particular, y se volvía bastante molesto tener que aceptar el mismo mensaje cada que iniciaba sesión.
La causa
La recomendación que doy siempre en este tipo de casos, es identificar todo lo que esté iniciando con el usuario, debido a que es muy común que aplicaciones dejen basura en el sistema y Windows intente arrancar algo mientras el usuario ingresa.
Para poder ver esto y a causa de que el Administrador de Tareas de Windows sirve poco o nada, le pido al usuario que utilice Autoruns de SysInternals para poder gestionar correctamente lo que verdaderamente está arrancando. Como no es muy normal que un usuario que pide ayuda sepa utilizar este tipo de herramientas, hago que cargue el log, lo guarde y después de lo envíe.
Volviendo al caso y una vez obtenido el log de Autoruns, pensé que iba a encontrar alguna entrada en amarillo en la pestaña de Logon o de Scheduled Tasks que tuviera algún nombre extraño y buscara el archivo bin.doc, pero no fue así.
Era muy extraño que Autoruns no hubiese podido identificar la entrada, pero como no encontré nada, procedí a pedirle el log de Process Monitor, utilizando la característica de Boot logging; de esta forma, podría monitorear lo que sucedía en Windows mientras el usuario iniciaba sesión, así que necesariamente tendría que ver algún rastro de ese mensaje.
*Nota: Boot Logging, como lo he mostrado en otras entradas, permite decirle a Process Monitor que ubique su controlador antes que cualquier otro cuando está prendiendo el equipo, así que puede recolectar todo lo que sucede en el proceso de encendido de Windows y ver cosas que sólo ocurren mientras se ingresa desde la pantalla de inicio de sesión. Para activar esta característica, hay que ir al menú Options > Enable Boot Logging.
Cuando tuve el log de Process Monitor, busqué inmediatamente por el “bin.doc” y en toda la traza que recolectó, encontré solo tres entradas al respecto:
Básicamente, el proceso de Explorer.exe de Windows, estaba creando, o más bien instanciando el proceso de wcript.exe y después, en la segunda entrada, iniciaba Windows iniciaba ese proceso directamente.
Al entrar en las propiedades del primer evento que muestra la captura haciendo doble clic en la entrada desde Process Monitor, me encontraba con que el Explorer.exe además de iniciar el proceso wscript.exe, le mandaba unos parámetros específicos donde incluía ejecutar el archivo: bin.doc.
Los parámetros, como lo ven en la captura, eran:
“C:WindowsSystem32wscript.exe” /e:VBScript.Encode D:bin.doc
La primera parte llamaba el proceso de wscript.exe y luego intentaba ejecutar el script. Debido a que ese archivo no existía en el equipo del usuario afectado, la ejecución fallaba y Windows mostraba el mensaje de error de Windows Script Host.
Si ejecutaba esa línea en cualquier equipo, recibía un mensaje muy similar al del error:
Con eso pude comprobar que era la creación y ejecución de ese proceso con la línea extraña la que generaba el mensaje de error; sin embargo, esto no me decía la razón por la cual el proceso de Explorer.exe resultaba llamando a wscript.exe y menos aún, por qué le enviaba ese parámetro.
Después de darle vuelta un par de días, decidí mirar en detalle todos los eventos que ocurrían antes de que se instanciara el proceso de wscript.exe, y luego de varias líneas, encontré algo de lo que no me había percatado anteriormente:
Como ven en la captura –si hacen clic en ella para el tamaño real-, Windows estaba leyendo un curioso archivo llamado Start.lnk, ubicado en la ruta:
C:UsersUreAppDataRoamingMicrosoftWindowsStart MenuProgramsStartup
Lo interesante aquí, es que todo lo que se encuentre en la carpeta Startup, se ejecutará automáticamente en cada inicio de sesión y el nombre del archivo no parecía muy normal.
Decidí entonces pedirle al usuario que me navegara hasta esa ruta y me enviara el archivo sin eliminarlo y al ingresar a sus propiedades –debido a que era un acceso directo-, me encontré con una grata sorpresa:
El acceso directo, ubicado en esa carpeta, estaba lanzando la ejecución del proceso wscript.exe, con sus respectivos parámetros.
Ahora, ¿Por qué Process Monitor identificaba a Explorer.exe como el proceso que llamaba a wscript.exe para hacer la ejecución? Pues bien, Explorer.exe es el primer proceso que carga al iniciar sesión y es el proceso padre que ejecuta todo lo que esté en los respectivos directorios; debido a que Start.lnk era un archivo dentro de una carpeta predestinada para lanzarse en cada inicio, era Explorer.exe el responsable de esta ejecución.
Ya sabía dónde estaba ubicado el archivo responsable, por qué iniciaba con el usuario y por qué se ligaba a un proceso del sistema operativo. Mi último paso, era solucionarlo.
La solución
Para solventar el problema, bastó lo siguiente:
Primero que todo, le pedí al usuario navegar hasta la ruta:
C:UsuariosUreAppDataRoamingMicrosoftWindowsMenú inicioProgramasInicio
*Nota: Si tienen el mismo problema, la ruta será igual, pero variará el nombre de usuario.
Segundo, que hiciera clic derecho sobre el archivo de Start.lnk y Eliminar.
*Nota: Es probable que no siempre tenga el mismo nombre, pero casi siempre será un acceso directo.
Tercero, le pedí reiniciar el sistema y después de esto, el mensaje de error se había ido.
Notas finales
La razón por la que Autoruns no muestra este tipo de entradas, es porque las considera como de Windows al llamar ejecutables conocidos y este tipo de entradas están ocultas de forma predeterminada en Autoruns. Basta ir al menú Options > Filter Options y quitar la selección sobre: Hide Microsoft entries y Hide Windows entries.
Por otro lado, me di cuenta después que el archivo se habría podido identificar desde Process Explorer, accediendo a las propiedades del Windows Script Host mientras estuviera en ejecución:
Espero haber sido de utilidad.
PD: No olviden seguirme Twitter: www.twitter.com/secalderonr
Saludos.
Checho