miércoles, diciembre 05, 2007

¿Dos procesos residentes Csrss.exe en Windows Vista?

Un usuario de Windows Vista tenía la siguiente inquietud: Al abrir Administrador de tareas, pestaña Procesos, observaba que había dos procesos Csrss.exe residentes en su sistema, ambos ejecutados desde la cuenta SYSTEM. Automáticamente el usuario relacionó esto con que alguna de las dos copias podría tratarse de un virus, ya que suelen aprovechar nombres de ficheros del sistema operativo para pasar desapercibidos.

En Windows Vista esta situación es normal, y se debe a una nueva característica de seguridad denominada "Session 0 isolation". En Windows 2000/XP/Server 2003, el usuario puede iniciar sesión en la llamada "sesión 0", una sesión que comparte con el resto de servicios críticos del sistema operativo. Esto supone que un atacante podría aprovechar alguna vulnerabilidad en alguno de esos servicios del sistema y hacerse con el control total de la máquina. Para evitar este potencial problema, el arranque de Windows Vista ha sido totalmente rediseñado. El primer proceso de usuario que se inicia en Windows es Smss.exe. En Windows Vista se crean dos copias de este proceso, y una de ellas se encarga de configurar la sesión 0 (Smss es el acrónimo de "Session Manager System Service"). El proceso Smss.exe crea a su vez una instancia de Csrss.exe en la sesión 0 y luego finaliza. Por este motivo, al observar la jerarquía de procesos en Process Explorer, verá que Csrss.exe está situado lo más a la izquierda (Process Explorer muestra procesos lo más a la izquierda cuando su "padre" ha finalizado).

Así pues, quedan configurados dos procesos Csrss.exe, uno para la sesión 0 y otro para la sesión del usuario, lo que aclaró la duda del usuario.

Nota: Puede observar esta diferencia en el propio Administrador de tareas si hace clic sobre Ver, Seleccionar columnas y agrega la casilla correspondiente al identificador de sesión. Necesitará haber iniciado Administrador de tareas con privilegios administrativos, o haber hecho clic sobre el botón Mostrar procesos de todos los usuarios y haber confirmado la operación.

viernes, noviembre 16, 2007

Sobre Windows Aero [Parte I]

Continuando con la serie de artículos dedicados a los nuevos componentes de Windows Vista, presento una visión detallada de Windows Aero, quizá su componente más conocido. Este artículo pretende enfatizar que Windows Aero implica muchísimo más que los meros efectos de transparencia, instantáneas y Flip3D que se observan a simple vista, a la vez que ofrecerá pautas para entender cómo funciona Windows Aero y cómo se pueden abordar problemas con este componente de Windows Vista.

Esquema simplificado de la arquitectura de Windows Aero y Windows Presentation Foundation (WPF)



La base de todo: Windows Presentation Foundation

Windows Presentation Foundation (WPF), conocido anteriormente como Avalon, es la raíz en la que se sustenta Windows Aero. Una de sus librerías principales, Milcore.dll (Media Integration Layer Core DLL), es la encargada de implementar una serie de efectos, computaciones geométricas, texturas, etc. haciendo para ello uso de DirectX (Direct3D). Otra DLL relacionada es WindowsCodecs.dll, que contiene numerosos algoritmos gráficos y de tratamiento/codificación/descodificación de vídeo que se usan en muchas de esas animaciones y efectos. El administrador de ventanas de escritorio de Windows Vista, DWM, o Desktop Window Manager, del que se hablará posteriormente, también hace uso de WPF. Como puede ver en la figura, WPF dispone de un "árbol visual" formado por los componentes gráficos de las aplicaciones que están ejecutándose en ese momento. Cuando una de ellas requiera que se vuelva a dibujar alguna de sus partes, WPF recorrerá ese árbol y actualizará sólo aquello que se necesita actualizar, con el objetivo de no penalizar el rendimiento del sistema. Este proceso es lo que se denomina "composición", término que se empleará a menudo en este artículo. Una de las consecuencias de esta aproximación es que las aplicaciones no dibujan directamente sobre la pantalla, sino que lo hacen sobre unos búferes proporcionados por el hardware de vídeo. Windows Vista lo que hace es tomar una a una esas representaciones y, a partir de ellas, componer el escritorio del usuario. Esto supone que la experiencia sea mucho más agradable y suave, y se evitan entre otros los molestos fallos gráficos que suelen ocurrir en Windows XP cuando, por ejemplo, se mueve una ventana que está situada encima de otra que está bloqueada.

WDDM (Windows Display Driver Model)

Para hacer uso de DWM, se requiere que un nuevo modelo de controladores gráficos esté presente en el sistema. Entre los beneficios más notables de WDDM destacan los siguientes:


  • Mejora notablemente la estabilidad del sistema, gran parte de los controladores que antes residían en módo kernel ahora lo hacen en modo usuario. Un fallo gráfico posiblemente sólo implique un reinicio del administrador de ventanas, no un reinicio de todo el sistema operativo.

  • Se permite virtualizar la memoria de vídeo, es decir, los gráficos pueden moverse de memoria gráfica a memoria principal según las necesidades de cada momento. Esto es importantísimo porque hay que tener en cuenta que Windows Aero probablemente esté "conviviendo" con aplicaciones 3D, como juegos, que hagan un uso intensivo del hardware gráfico.

  • Se permiten las interrupciones de GPU. La GPU puede interrumpir un procesamiento gráfico para atender a otra otro proceso.

Windows Manager (Administrador de ventanas)

El administrador de ventanas de Windows NT reside en el controlador de núcleo Win32k.sys. Éste consta de una serie de métodos que comunican las llamadas en modo usuario relacionadas con ventanas y otros aspectos gráficos, en su mayoría residentes en User32.dll, con el hardware gráfico del equipo. En Windows Vista el administrador de ventanas recibe información sobre aspectos de composición y redirección, procedentes del DWM. Se tratará esto con más profundidad más adelante.

En resumen, esta es la base en la que se sustenta Windows Aero. El próximo artículo tratará sobre DWM (Desktop Windows Manager), sus servicios asociados, cómo se comunica internamente con WDDM, Milcore, etc., cuáles son los requisitos mínimos para su activación, problemas comunes, etc.

sábado, noviembre 03, 2007

Tras reinstalar el sistema operativo, Windows Update no instala ninguna actualización

Un problema bastante común últimamente con Windows Update consiste en que, tras una reinstalación del sistema operativo (Windows XP SP2), las actualizaciones no se logran instalar.

Si experimenta ese mismo problema, su solución está en este artículo de la KB: http://support.microsoft.com/default.aspx/kb/943144/es.

viernes, octubre 26, 2007

Cómo crear accesos directos a temas de ayuda de Windows Vista

Estoy notando que es mucha gente la interesada en saber cómo crear accesos directos a los temas de ayuda y soporte técnico de Windows Vista, para tenerlos más a mano. Me refiero específicamente al contenido offline, pues el contenido online es fácilmente accesible desde http://windowshelp.microsoft.com/Windows/es-ES/default.mspx. En Windows Vista no sirve con copiar la ruta del tema y crear un acceso directo; quizá lo que haya venido haciendo hasta ahora es indicar paso por paso los enlaces que se deben pinchar para dar con el tema en cuestión, lo que resulta ciertamente engorroso.

Para acceder de manera directa a un tema de ayuda en Windows Vista, se debe hacer uso de la API pública IHxHelpPane::DisplayTask, a la que se le pasa como parámetro la URI del documento mshelp:// que queremos abrir. Incluso sería posible crear una pequeña aplicación que registrara un nuevo protocolo en el sistema y automatizara todo este proceso. Ciertamente tendría bastante aceptación, creo yo. Quizá me anime a codificarla.

jueves, octubre 11, 2007

Sobre el mensaje de error "Ha ocurrido una excepción al intentar ejecutar..."

Si observa la lista de tareas programadas incluidas por defecto en Windows Vista, verá una encargada de crear puntos de restauración con regularidad. Si accede a la pestaña Acciones verá que la tarea que se ejecuta es la siguiente: %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation.

¿Qué significa el parámetro /d?

Cuando se incluye una DLL como parámetro del comando Rundll32.exe (muchos ficheros del Panel de control se ejecutan así), automáticamente se captura toda excepción que el código del fichero pueda producir, como por ejemplo una infracción de acceso (AV). Si esto ocurre, se muestra una ventana con el siguiente texto:

RUNDLL

Ha ocurrido una excepción al intentar ejecutar Comando

El "RunDLL" del título de la ventana puede hacer pensar que el sistema está infectado, pues el fichero Rundll.exe no se incluye en Windows XP y además Rundll.exe es un nombre muy común de los ejecutables de muchos virus. Sin embargo, el mensaje es legítimo, procede del sistema operativo.

El parámetro /d de Rundll32.exe lo que hace es evitar la captura de excepciones que comento anteriormente, lo que en ciertos casos puede resultarnos útil. Por ejemplo, en el caso de una excepción de infracción de acceso lo más probable es que entre en acción el depurador "post-mortem" por defecto de Windows (Dr. Watson), o cualquier otro que esté configurado.

En un futuro artículo mostraré en qué consisten las excepciones, de qué tipo pueden ser, cómo las maneja Windows y cómo se puede usar un depurador (Windbg, AdPlus, UserDump, etc.) para detectar error comunes en el código de ciertas aplicaciones de terceros mal diseñadas.

viernes, octubre 05, 2007

¿Sabía que...? [VII]

En esta nueva entrega de la saga "Sabía que...", pongo dos consultas breves que he recibido:

Pregunta

¿Cómo determina Administrador de tareas cuando una aplicación no responde?

Respuesta

En MSDN hay una API para saber esto mismo, IsHungApp. En la propia documentación se explica lo que tiene que ocurrir para que se determine que una aplicación no está respondiendo:
  • No espera entrada por parte del usuario.
  • No está iniciándose.
  • No ha llamado a PeekMessage o GetMessage en 5 segundos.

Pregunta

En Windows XP trabajo normalmente con un usuario limitado (¡bien hecho! :-P) y si hago doble clic sobre algún instalador, me aparece automáticamente un cuadro que me pide privilegios administrativos. ¿Cómo lo sabe Windows?

Respuesta

La respuesta a esta pregunta reside en nuestra "querida" clave de registro HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths, de la que ya hablé en un artículo anterior. En una instalación limpia de Windows verá que ya hay algunas subclaves ahí, entre otras Setup.exe, Installer.exe, Winnt32.exe, etc. Si hace un clic sobre cualquiera de ellas, verá un valor RunAsNonAdminInstall, con contenido 1. Ese es todo el secreto.

martes, septiembre 25, 2007

Cómo solucionar problemas con el servicio de acceso remoto de Windows XP

En los últimos días he recibido una serie de problemas relacionados con el servicio "Enrutamiento y acceso remoto" (RemoteAccess) de Windows XP. En particular se trata de problemas al intentar iniciar este servicio, que es imprescindible para poder establecer conexiones remotas entre dos PCs. En este artículo doy algunas pautas para solucionar este tipo de problemas.

En primer lugar abra una ventana de línea de comandos y teclee lo siguiente: sc queryex RemoteAccess. En la salida del comando verá cuál es el código específico con el que se ha detenido el servicio. Si dicho código fuese el 340 (0x154), pude determinar que esto suele ocurrir cuando cierta información del registro relacionada con Jet y OleDB falta o está dañada. Este artículo mío propone una solución para este caso.

Es posible que el código de salida no sea el 340; otro que he encontrado al tratar con usuarios afectados es el 16389 (0x4005). Este código suele indicar que hay un problema con la base de datos IAS (Internet Authentication Service) del equipo. Para abordar este problema suele resultar útil habilitar tracing en el servicio RAS. Siga estos pasos:

  1. Abra Inicio, Ejecutar, escriba cmd y pulse Aceptar.
  2. Teclee este comando y pulse INTRO: netsh ras set tracing * en

A partir de ahora, toda la actividad relacionada con el acceso remoto quedará registrada en ficheros con extensión LOG dentro del directorio %SystemRoot%\tracing. Este es un ejemplo del contenido del fichero IASRECST.log:

[3264] 09-24 09:02:51:796: INFO Enter IASOpenJetDatabase. path = F:\WINDOWS\system32\IAS\ias.mdb readonly = 0

[3264] 09-24 09:02:53:750: IDBInitialize::Initialize failed; return value = 0x80004005

[3264] 09-24 09:02:53:859: Description: 'F:\WINDOWS\system32\IAS\ias.mdb' no es una ruta de acceso válida. Asegúrese de que la ruta está escrita correctamente y que está conectado al servidor donde se encuentra el archivo.

[3264] 09-24 09:02:53:859: Record 0: hrError = 0x80004005; dwMinor = 0xE01FFC01

En este ejemplo, el error Jolt que se devuelve es JET_errInvalidPath. Lo primero que se debería comprobar en este caso es si el directorio "F:\WINDOWS\system32\IAS" existe y en caso negativo, crearlo manualmente y expandir los ficheros Dnary.mdb, Ias.mdb desde el disco compacto de XP SP2. Podría tratarse de otro problema distinto relacionado con el acceso a la base de datos, u otro problema de otro tipo, pero en general los reportes suelen ser bastante claros.

Espero que este artículo les ayude a solucionar problemas con el servicio de acceso remoto de Windows XP.

domingo, septiembre 09, 2007

Sobre el servicio de licencias de Windows Vista

Hace unas semanas me encontré con un equipo con Windows Vista instalado que tenía el siguiente problema: Al intentar abrir Panel de control, simplemente se abría una ventana de Explorador de Windows que, segundos después, se cerraba automáticamente. Después de analizar el problema por un tiempo, decidí depurar con Windbg para clarificar el asunto.

Al depurar Control.exe (el ejecutable encargado de cargar ficheros de Panel de control) no obtuve nada reseñable. De hecho, Control.exe es un proceso efímero que dura poco tiempo en ejecución. Es el proceso Explorer.exe el que se hace cargo de la inicialización del Panel de control en última instancia (esto puede comprobarlo ejecutando "control.exe" con Process Explorer abierto). Así que decidí depurar Explorer.exe a partir de funciones conocidas de Shell32.dll que están relacionadas con la carga de Panel de control. También podría "volcar" los símbolos de Shell32.dll y poner "breakpoints" en aquellas funciones que, por el nombre, le parezca que están relacionadas con la carga de Panel de control. De pronto me encontré con una llamada a la DLL Slc.dll, una nueva DLL en Windows Vista que implementa funciones relacionadas con el servicio de licencias de software de Windows Vista. El servicio de licencias de software (Slsvc.exe) es un nuevo servicio de Windows Vista encargado de consultar la licencia del equipo (estado de la activación, si el sistema es genuino o no, qué funcionalidades permite la versión de Vista instalada, etc.).

Decidí poner "breakpoints" en funciones con el patrón "slc!*" y reiniciar la depuración. Llegué en primer lugar a una función de Slc.dll encargada de obtener información sobre la versión de Windows instalada.



Seguidamente, al retornar de la función se obtuvo el código de error 0x80070426, que significa que el servicio no está iniciado. Por ser la función Slc.dll, inmediatamente relacioné esto con el servicio Slsvc antes mencionado. Efectivamente comprobé que dicho servicio no estaba iniciado, así que lo inicié, reinicié el sistema y el problema quedó solucionado.



La función que realiza la llamada al servicio de licencias como ve es CPLD_GetRegModules. Esta función delega toda su actividad en otra función proxy: CPLD_GetRegModulesWorker, encargada de leer la caché de ficheros .cpl del sistema, almacenada en el Registro en la clave HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Controls Folder.

Curiosidad: En la clave anterior hay dos valores: Presentation Cache, que contiene la caché propiamente dicha así como un "flag" que indica que esa caché es posterior a octubre de 2001, fecha en la cual se introdujo un arreglo en el código del Panel de control que invalida toda caché anterior. También está el valor Presentation LCID, que contiene el ID del idioma de la caché.


El motivo de emplear una función "representante" (proxy) es que no se quiere que ciertas funciones se ejecuten sin realizar antes una comprobación de la licencia del equipo.

En resumen, el servicio "Licencias de software" es muy importante para Windows Vista, muchas funciones del sistema operativo realizan antes de ejecutarse una llamada a este servicio. La licencia incluye, entre otras cosas, el máximo número de conexiones permitido, si se permite ejecutar Windows Aero o no, si se incluye un codec MPEG2, Control parental, Media Center, etc.). La conexión con el servicio de licencias evita que, por ejemplo, sustituyendo binarios de versiones distintas de Vista se obtenga una característica que no permita la licencia instalada. Como curiosidad final, durante la inicialización del núcleo de NT y del administrador de memoria (Ntoskrnl.exe), se consulta también la licencia del equipo para saber si se puede inicializar uno o dos procesadores, y el máximo tamaño de RAM direccionable, pero esto quizá lo muestre experimentalmente en un próximo artículo.

sábado, agosto 11, 2007

En lo que a seguridad se refiere, usar el navegador X en lugar del navegador Y influye más bien poco

En diversos foros de Internet hay abiertos muchos debates sobre si Internet Explorer es menos seguro que cierto navegador X, y se suele acabar recomendando usar ese navegador X en lugar de Internet Explorer. A decir verdad, ante un ataque malicioso, el usar el navegador X o el navegador Y no influye apenas en nada, y sólo genera una sensación de falsa seguridad. Quizá lo más influyente en esa situación de ataque es de qué privilegios disponga el navegador en ese momento. Si dispone de privilegios administrativos, está perdido.

Cuando un usuario ejecuta cierta aplicación -o el propio sistema operativo- con privilegios administrativos, automáticamente está diciendo que confía plenamente en esa aplicación que va a abrir y que le dejará hacer lo que le plazca con el sistema. Cuando se instala y se ejecuta un juego, es de esperar que ese juego se limite a "mover triángulos" y, si acaso, conectarse a Internet para descargar actualizaciones o poder jugar en red. Pero ciertamente ese juego es un potencial vector de ataque, por haber sido ejecutado con privilegios administrativos (cuando no se requieren). Simplemente cualquier usuario malicioso podría tomar el control del sistema al aprovecharse de una vulnerabilidad de ese programa.

El ejecutar un navegador aparentemente muy seguro en un entorno con privilegios administrativos, no sirve casi para nada. Al navegar por algún sitio infectado, si el sistema operativo no está actualizado o el sitio web intenta aprovechar alguna vulnerabilidad no corregida del navegador (cosa que todos tienen), se instalarán, sin que el usuario note nada, ficheros en \system32, tareas programadas, procesos residentes, entre otras cosas. Un navegador es una aplicación muy delicada, pues está en contacto con un mundo -Internet- en el que las amenazas de malware y virus están a la orden del día. De nada sirve haber diseñado el navegador más robusto del mundo cuando sus usuarios lo ejecutan con privilegios administrativos. Y navegar por Internet es una actividad que no requiere privilegios administrativos.

En conclusión, si usa Windows Vista debería tener activado Control de cuentas de usuario (UAC) y Modo protegido de IE7. Hay mucha gente que lo desactiva, por resultar demasiado pesado, pero deben ser conscientes de que si lo hacen estarán navegando con privilegios administrativos, y cualquier desarrollador de un sitio malicioso está ansioso por encontrarse con visitantes que le faciliten la instalación automática de adware. Si usa otro navegador distinto de IE, debería ejecutarlo siempre con privilegios limitados. La seguridad de un sistema no consiste nunca en usar únicamente tal o cual producto, sino en seguir unas pautas para reducir la posibilidad de ataque (usar antivirus, cortafuegos y actualizar el software a menudo, por ejemplo), y mitigar las consecuencias en el caso de que ocurra algo malo (ejecutar la aplicación sin privilegios administrativos, por ejemplo).

domingo, agosto 05, 2007

Sobre el nuevo Monitor de fiabilidad de Windows Vista

Continuando con los artículos referidos a cómo funcionan los nuevos componentes de Windows Vista, he elaborado un pequeño conjunto de preguntas y respuestas sobre el nuevo Monitor de confiabilidad (Reliability Monitor) de Windows Vista, componente que entre otras cosas se encarga de otorgar una puntuación numérica al equipo según el grado de estabilidad del sistema durante un periodo de tiempo.

¿Qué se tiene en cuenta a la hora de calcular la puntuación?

El índice de un día depende del número de "interrupciones" que ha sufrido el usuario en una sesión de trabajo en Windows. Por "interrupción" se refiere a cualquier suceso que esté en alguna de estas categorías: fallos de aplicaciones o "cuelgues" (eventos 1000 y 1002, respectivamente), fallos de hardware y fallos del sistema operativo (errores graves, pantallas azules o "bugchecks"). El número de "interrupciones", una vez filtrado mediante un algoritmo pendiente de patente, se hace corresponder con una puntuación de 1 a 10, ya sea directamente o mediante interpolación lineal.

¿Cuántos días se tienen en cuenta para el cálculo de la estabilidad?

Depende de la versión de Windows. Si es de la rama cliente, 28; si es de la rama servidora, 120.

¿Es cierto que la estabilidad depende de los días anteriores?

Sí, además la suma que se realiza es una suma ponderada, en la que la puntuación de los días más recientes tiene más peso que la puntuación de los días más alejados en el tiempo. Con esto se consigue observar un efecto de recuperación paulatina en la situación de un equipo que haya sufrido problemas de estabilidad durante un periodo determinado, pero que en estos momentos todo funcione correctamente pues se logró dar con el causante.

¿Se cuentan todos y cada uno de los eventos de fallo?

Se cuentan siempre y cuando no puedan ser emparejados, esto es, si son muy cercanos en el tiempo, o bien si tienen relación directa (por ejemplo, un evento que haga referencia a una pantalla azul y otro que explique que el equipo se reinició por un error grave). En estos casos sólo se tiene en cuenta uno de ellos.

¿Quién se encarga de recopilar toda esa información?

Un módulo denominado Racagent.exe y que se ejecuta programadamente en cada inicio del sistema operativo. Se ejecuta con bajas prioridades de CPU, E/S y memoria para tener un impacto mínimo en el arranque del sistema operativo. Su DLL asociada, RacEng.dll, se encarga de calcular un índice de estabilidad para la sesión en curso (si no ha sido calculado ya) y almacenarlo en el correspondiente repositorio.

¿Dónde se almacena toda la información sobre instalación de aplicaciones, desinstalación, errores de software, etc.?

Se almacenan en el directorio C:\ProgramData\Microsoft\RAC\PublishedData\, en los siguientes ficheros:
  • PublishedRacMonIndex.dat: Almacena el índice (puntuación).
  • PublishedRacMonSWITable.dat: Almacena las instalaciones de programas.
  • PublishedRacMonAFLTable.dat: Almacena fallos de aplicaciones.
  • PublishedRacMonHFLTable.dat: Almacena fallos de hardware.
  • PublishedRacMonOSFTable.dat: Almacena fallos del sistema operativo.
  • PublishedRacMonCLKTable.dat: Almacena fallos del sistema operativo.

El Monitor de fiabilidad es un componente muy útil para los administradores de sistemas que quieran observar, de un vistazo, el estado de la estabilidad del equipo, en qué momento surgieron los problemas y cuáles podrían ser sus causantes.

miércoles, julio 18, 2007

¿Sabía que...? [VI]

Process Explorer (http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx) puede ser una ayuda inestimable a la hora de eliminar malware de un equipo. Es común que un sistema infectado por malware presente varios procesos maliciosos, encargados, por ejemplo, de mostrar publicidad no deseada, registrar acciones realizadas en el equipo o enviar información privada a un servidor remoto. El problema que surge al intentar matar uno a uno dichos procesos es que el esfuerzo resulta en vano, pues muchos de ellos actúan como centinelas, es decir, cada proceso malicioso comprueba si algún otro proceso malicioso ha muerto y, en tal caso, lo revive. Con Process Explorer puede establecer un proceso como suspendido. Si selecciona con el botón derecho del ratón cada uno de los procesos maliciosos y hace clic sobre Suspend, a continuación podrá matar tranquilamente uno a uno los centinelas sin que "revivan". Una vez muertos todos los procesos maliciosos, las tareas de desinfección se hacen mucho más sencillas.

Al margen de todo esto, es recomendable que las tareas de desinfección se realicen siempre en Modo seguro. El complemento ideal de Process Explorer es Autoruns, una aplicación del estilo de HijackThis, pero mucho más completa y potente. En resumen, si va a abordar un problema de desinfección de malware, no es recomendable que emplee los clásicos Administrador de tareas y Msconfig, incluidos en el sistema operativo.

jueves, julio 05, 2007

Artículo sobre redes en Windows Vista

Una persona me preguntó en un comentario a un artículo de esta bitácora si podría ofrecer información acerca del tema de redes en Windows Vista. Acabo de publicar un artículo al respecto, que contiene las causas y soluciones a los problemas más comunes que he ido recibiendo por parte de los usuarios. Si observo con el tiempo que surgen nuevas dudas o problemas, lo actualizaré convenientemente. Puede consultarlo si hace clic aquí.

viernes, junio 22, 2007

Tenga cuidado al deshabilitar servicios del sistema operativo

Muchos sitios en Internet proponen una lista de servicios para desactivar, con el fin de que Windows XP/Vista funcionen más ligeramente. En general, suelen basar su decisión en el nombre del servicio o su descripción, que ya ofrece una buena idea de su cometido. Sin embargo, además de las posibles dependencias entre servicios, debe tener en cuenta que algunas funcionalidades del sistema operativo "se esconden" en servicios que aparentemente no deberían tener ninguna relación, según su nombre y descripción. Por ejemplo, un sistema que tenga desactivado el servicio Programador de tareas perderá ciertas funciones de prefetch, que se alojan en una DLL que implementa dicho servicio. Y prefetch es una característica muy buena de Windows.

Tenga cuidado al desactivar servicios del sistema operativo: unos son vitales y harán que su sistema no funcione o malfuncione si son deshabilitados, y otros, aparentemente "prescindibles", pueden estar relacionados con otras características "menos prescindibles" de Windows.

lunes, junio 04, 2007

Cómo funciona el motor de compatibilidad de aplicaciones de Windows XP/Vista

En un hipotético mundo perfecto, todas las aplicaciones funcionarían correctamente, no seguirían métodos indocumentados y los fabricantes se encargarían de adaptarlas adecuadamente a una nueva versión del sistema operativo en el que se ejecutan. Lamentablemente, en el mundo real, esto no es en absoluto así y los problemas de compatibilidad son muchos y variados. En algunos casos, Microsoft simplemente decide aplicar un shim general, o bien específico para esa aplicación, con el objetivo de que funcione correctamente. Pero, ¿qué es un shim?

Se trata de un "arreglo" incluido en el sistema operativo que permite que ciertas aplicaciones antiguas o mal diseñadas puedan funcionar correctamente. Windows NT fue diseñado con la compatibilidad en mente, y las sucesivas versiones así lo demuestran. Por ejemplo, Windows XP y Vista incorporan una base de datos de shims en el directorio \WINDOWS\AppPatch. En este directorio hay bases de datos de shims (.sdb) y DLLs que contienen las funciones que "arreglan" ciertas cosas que suele hacer mal el software existente. El fichero AcGenral.dll contiene shims inespecíficos, generales; AcSpecfc.dll contiene shims aplicables sólo a cierto software mal diseñado y AcLua.dll contiene shims relacionados con lo que hoy día es UAC (User Account Control). Vista no tiene esta DLL porque ha sido sustituida por el mecanismo de virtualización. Las bases de datos (.sdb) contienen shims aplicables en general (Sysmain.sdb), sólo a instaladores MSI (Msimain.sdb), o incluso a controladores de hardware (Drvmain.sdb). Una vez hemos analizado el cometido de esa carpeta, veremos a continuación cómo funciona el motor de shims (Shim engine):

Todo comienza en CreateProcess

La función encargada de crear procesos en Windows XP/Vista reside en Kernel32.dll y se llama CreateProcess. Ésta lleva a cabo muchas operaciones antes de "dar a luz" al proceso. Entre estas operaciones está el comprobar si la aplicación es una aplicación que Microsoft sabe que no funciona o que necesita de algún "arreglillo" para hacerlo correctamente. La DLL Apphelp.dll del directorio \system32 se encarga de consultar las bases de datos antes mencionadas y así decidir si se debe aplicar un shim o no.

En el caso de que la aplicación necesite de un shim, durante la ejecución del proceso se cargarán un par de módulos, entre ellos el motor shim (Shimeng.dll) encargado entre otras cosas de enlazar con la función residente en alguna de las DLLs antes mencionadas del directorio \AppPatch y que contiene el código del "arreglo".

Podemos "forzar" un shim persistente. Modo de compatibilidad

En Windows XP y Windows Vista, al desplegar las propiedades de un acceso directo se presenta una pestaña denominada Compatibilidad. Si el ejecutable no está protegido por Windows (WFP) y no procede de una unidad de red, se nos permitirá configurarlo de modo que funcione, por ejemplo, "forzando" una cierta resolución de pantalla, o como si estuviera ejecutándose en un sistema operativo anterior. Esta información se almacena en la clave de Registro HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers y es leída por Apphelp.dll antes de crear el proceso del ejecutable.

¿Pero qué hace que la aplicación se crea que está funcionando en un sistema Windows anterior?

Realmente lo que ocurre es que las llamadas a las funciones GetVersion, GetVersionEx (ANSI y Unicode) son interceptadas por una función hook (gancho) del shim, que "miente" y devuelve información referente a un sistema anterior. Veremos lo que ocurre exactamente empleando un depurador:



Una API un poco rara...

En la imagen puede ver como intento abrir una instancia del programa WinRAR, que expresamente he configurado con el modo compatibilidad con Windows 95. Una función de WinRAR al parecer quiere saber en qué sistema operativo está funcionando. Aquí entra en acción una cierta función de AcLayers.dll (del directorio \WINDOWS\AppPatch), "APIHook_GetVersionExA". El nombre lo dice todo, :-P, pero veamos qué hace exactamente:

Se realiza una llamada a las funciones "reales" GetVersionExA y GetVersionExW. Poniendo un breakpoint en el retorno de la función, examinamos la estructura OSVERSIONINFOEX que devuelve como parámetro. Para ello, anotamos el contenido del registro ESI y examinamos esa porción de memoria (con el comando dd). Esta imagen ejemplifica esto:


Accediendo al tipo estructurado OSVERSIONINFOEX


Probablemente se sienta abrumado por esos números hexadecimales, es algo normal, hay que echar antes un vistazo a cómo es el tipo estructurado OSVERSIONINFOEX. El comando dt del depurador puede hacer esto mismo (dt OSVERSIONINFOEX), aunque también puede consultar MSDN. Con la información en la mano, podemos ver que, la segunda columna hace referencia al tamaño de la información de versión (dwOSVersionInfoSize), la tercera, ese 5 hexadecimal, indica cuál es la versión principal (dwMajorVersion), el 1 siguiente, la versión secundaria (dwMinorVersion), y el 0xa28 el número de build. Introduciendo el comando ?a28 obtenemos la representación decimal de este valor: 2600. ¡Ajá! 5.1.2600, o lo que es lo mismo, Windows XP, el sistema operativo donde está funcionando "realmente" la aplicación. :-)

Veamos ahora qué ocurre cuando se retorna el control a la función del shim y, en último momento, a la función de WinRAR que está interesada en obtener información del sistema operativo donde está funcionando. Repetimos el mismo procedimiento:



Bueno, WinRAR, estás funcionando en... Windows 95

¡Ops! parece ser que la información que se devuelve ha cambiado "por arte de magia". Ahora, como ve, hace referencia a un tal Windows 4.0.950, que precisamente es Windows 95. Lo que ha ocurrido es que el shim que apliqué explícitamente a WinRAR le ha "mentido" vilmente. Si esta aplicación hiciera una comprobación de versión y ni siquiera se ejecutara en el caso de que no conociera la versión del sistema operativo, con el shim que he aplicado probablemente no habría problema alguno.

Así es como funciona a grandes rasgos el motor de compatibilidad de aplicaciones de Windows XP/Vista. Gracias a él nuestra experiencia con Windows es mucho más agradable y menos frustrante: actúa en segundo plano, no nos enteramos apenas de lo que ocurre "por lo bajo" y nos permite hacer funcionar cierto software no muy bien diseñado.

sábado, mayo 12, 2007

El caso de la extensión "rebelde" del menú contextual

Es posible que en alguna ocasión haya experimentado este problema: Al abrir una fotografía en Visor de imágenes y fax y pulsar sobre el icono con la leyenda "Cierra este programa y abre la imagen para editarla (Ctrl+E)", el visor desaparece, pero no se abre Paint o su programa preferido de edición de imágenes.

Probablemente piense que el problema pueda estar en la ruta del Registro que referencie el programa de edición, pero lamentablemente el problema es algo más complicado de detectar: Se trata de alguna extensión del menú contextual con un error de programación muy común. Hace un tiempo identifiqué una versión de WhoLockMe que producía el problema, así que me dispuse a mostrar la causa interna de tan extraño comportamiento.

En primer lugar, describo brevemente lo que ocurre cuando el usuario hace clic sobre el botón del Visor de imágenes y fax para editar la fotografía: En primer lugar se decide qué verbo invocar para abrir el fichero. Éste puede ser "open" o "edit", dependiendo de la configuración de cada sistema. En el Registro dicho verbo está asociado, por defecto, a la ruta "%SystemRoot%\system32\mspaint.exe %1", lo que hace que se abra Paint con la correspondiente imagen cargada. La ruta en cuestión junto al verbo apropiado se incluyen en una llamada a la función ShellExecuteEx, de la que hablé un poquito en un artículo anterior. Esta función realiza, entre otras cosas, una llamada al menú contextual para "preguntarle" a cada manejador: "¿Oye, manejas el verbo Z?", a lo que cada manejador le da una respuesta según su implementación del método InvokeCommand, que obviamente también es llamado cuando el usuario selecciona la opción de la extensión de shell en el menú contextual.


Aquí se le pregunta a la extensión de shell encargada de anclar elementos al inicio: ¿Puedes manejar este verbo y abrir la fotografía?


Poniendo un breakpoint en el retorno de la función y observando el registro EAX (en x86 es común que las funciones devuelvan sus resultados en ese registro), observamos el código 0x80070057, que se traduce por E_INVALIDARG, o lo que es lo mismo, "esto no iba para mí".


"No, lo siento, sólo entiendo de 'pin' y 'unpin', nada más"

A continuación el shell sigue invocando elementos del menú contextual hasta que llega la extensión problemática, la perteneciente a WhoLockMe:

"¿Tú podrías manejar el verbo que te paso y abrir la fotografía?"

A pesar de que no se disponen de símbolos para el módulo "WhoLockMe.dll", es fácil deducir que se trata de la implementación del método InvokeCommand.

Veamos qué nos encontramos al retornar de la función:

¡Adjudicado! La extensión WhoLockMe se ha hecho cargo del verbo.

Como ve, se devuelve S_OK, lo que le hace indicar al shell de Windows que esa extensión va a encargarse apropiadamente del verbo en cuestión, algo que obviamente es un error. Tras ello, el shell deja de consultar elementos del menú contextual, se cierra el visor de imágenes, pero Paint no se abre puesto que el módulo "WhoLockMe" se ha hecho cargo, incorrectamente, de un verbo que no implementa.

También es común que, si añade las opciones "Copiar a" y "Mover a" al menú contextual, tal y como describen muchas páginas en Internet, observe que aparece su cuadro de diálogo asociado en los momentos más imprevistos: Al hacer clic sobre "Reproducir todo" -tras seleccionar un conjunto de canciones-, al abrir un adjunto en Outlook, etc. El motivo es prácticamente el mismo: Esas extensiones están "respondiendo" a más peticiones del shell de las que deberían, ya que sólo están diseñadas para "responder" cuando el usuario haga clic sobre ellas, esto es, deberían estar posicionadas en una barra de herramientas, no en el menú contextual.

La moraleja de todo esto, si hay algún programador de extensiones del menú contextual leyendo esta bitácora :-P, es que si tu extensión no maneja ciertos verbos canónicos ("open", "edit", "print", etc.), el método InvokeCommand que implemente la extensión debe devolver E_FAIL, E_INVALIDARG, para hacerle saber al shell: "Yo no manejo este verbo, sigue preguntando por ahí". En el sitio web de MSDN dispone de información precisa sobre cómo crear manejadores del menú contextual, por ejemplo aquí.

Espero que este artículo les ayude a detectar problemas producidos por extensiones de shell, aprender un poco a depurarlas con WinDbg, por ejemplo, y saber qué es lo que no hay que hacer si en algún momento se dispone a programar alguna.

lunes, abril 30, 2007

Detalles sobre la instalación de Windows Vista

Un usuario se preguntaba por qué la fecha de creación de la carpeta "Windows" de su sistema Windows Vista era siempre 2 de noviembre de 2006, si instaló el sistema operativo mucho después. Eso se debe al nuevo sistema de instalación de Windows Vista. Es radicalmente distinto al de versiones anteriores de Windows.

Windows Vista es un sistema muy diferente de Windows XP, ya desde su instalación. La arquitectura interna de la instalación de Windows XP se resume básicamente en la copia de binarios (EXEs, DLLs, etc.), la creación de claves de Registro, servicios, etc. y la configuración del hardware, configuración de red, regional, etc. Esta aproximación tiene varios inconvenientes, entre otros:

  • La creación de SKUs tales como Home Edition, Professional Edition, Tablet PC, Media Center Edition supone un elevado coste de ingeniería para Microsoft.
  • Los OEM que ensamblan PCs pueden juntarse con miles de imágenes personalizadas diferentes de XP.
  • La instalación del sistema operativo requiere más tiempo.
  • Se tarda más en generar actualizaciones para el sistema. Esto es importante en el caso de actualizaciones de seguridad, por ejemplo.

Windows Vista introduce un nuevo concepto de instalación basado en imágenes. Asimismo, el sistema operativo ahora está formado por componentes, en lugar de por archivos binarios, claves de Registro, etc. Se tratará posteriormente el concepto de componente en Windows Vista.

El siguiente gráfico muestra el proceso de instalación de Windows Vista:

Esquema simplificado de la instalación de Windows Vista

Sí, ha leído bien, el proceso de instalación de Windows Vista comienza en Microsoft. En un laboratorio (Windows Build Lab) se genera una imagen WIM del sistema operativo. Esta imagen se ha visto sometida a un proceso de generalización, que consiste en eliminar toda referencia al hardware de la máquina donde haya sido instalada. Se genera, pues, una imagen neutra del sistema operativo. Esa imagen WIM se graba en el DVD de Windows Vista.

Cuando el usuario introduce el DVD de Windows Vista y comienza la instalación, en un primer momento se le pide que elija una imagen del DVD (si hubiera varias para elegir) así como un idioma. Después se particiona el disco y comienza la instalación propiamente dicha.

Windows Vista está formado por componentes

Vista está internamente organizado en componentes, cada uno de los cuales contiene ejecutables, DLLs y manifiestos XML con las claves de Registro relacionadas, COM, etc. Puede ver una lista de estos manifiestos en su directorio %SystemRoot%\winsxs\Manifests. Estos componentes mantienen dependencias entre sí, por lo que la instalación/desinstalación de uno puede implicar necesariamente la instalación/desinstalación de otro.

Fase de volcado de la imagen inicial

La primera fase de la instalación de Vista consiste en volcar la imagen WIM de instalación al disco duro del usuario. A partir de ella, se expande una parte inicial denominada Windows Foundation. Windows Foundation es el conjunto de componentes que Microsoft ha determinado como básicos para poder hacer funcionar el sistema operativo, independientemente de la versión del mismo. Esta fase no suele tomar demasiado tiempo, especialmente en sistemas modernos con discos duros rápidos.

Fase de especialización

Posteriormente, con el sistema base ya instalado y operativo, se procede a especializar la instalación según el hardware del sistema del usuario, por lo que esta fase comprende el reconocimiento de dispositivos, instalación de controladores, etc. Otra parte de la especialización consiste en generar la versión de Vista (Home Basic, Ultimate, Enterprise, etc.) a partir de la clave de producto (PID) proporcionada, así como instalar el paquete de idioma seleccionado (Windows Vista es un sistema neutro en lo que a idioma se refiere). Esta fase se realiza cuando se resalta el texto Instalando características.

¿Cómo se construye una versión concreta de Vista, digamos Home Premium?

Recuerde que partimos de un sistema operativo básico ya instalado. Para generar una versión concreta de Windows Vista, un fichero XML decide qué SDPs (SKU Dependent Package) incluir. Cada SDP incluye componentes tales como Media Center, Tablet PC, etc. Estos paquetes los instala la utilidad Package Manager (Pkgmgr.exe). Puede obtener más información sobre la misma si pincha aquí.

Por ejemplo, el conjunto formado por Windows Foundation (componentes básicos del sistema operativo), ciertos SDPs y un paquete de idioma DE-DE formaría un sistema Windows Vista Home Premium en alemán. Observe que todo está muy granularizado.

Finalmente, tras el reinicio del sistema operativo y su primer arranque, se configuran los aspectos finales (nombre de usuario, fondo de pantalla, etc.) si no han sido preconfigurados mediante un fichero XML, y se le muestra el escritorio al usuario.

Como ve, el cambio de arquitectura de Windows Vista es bastante profundo. Ya desde la salida de Windows XP se empezó a trabajar en todo esto, y los beneficios son bastante importantes: Se reduce el número de imágenes del sistema operativo, se facilita la creación de nuevas versiones de Windows Vista (SKUs) según las demandas del mercado, la instalación se realiza en menos tiempo y las actualizaciones por parte de Microsoft requieren de un menor tiempo de pruebas: Al separar la parte neutra de la parte dependiente del idioma, una actualización de seguridad, que en un altísimo porcentaje afecta sólo a un componente neutro del sistema operativo, se genera con más rapidez y no es necesario probarla exhaustivamente en todas las versiones localizadas de Windows Vista.

En un posterior artículo espero profundizar sobre los componentes de Windows Vista. A la hora de solucionar un problema con Windows Vista es muy probable que acabe revisando reportes generados por el servicio de componentes (CBS), así que pienso que le resultará de mucha utilidad saber cómo funciona.

viernes, abril 13, 2007

Sobre el nuevo motor de copias de archivos y carpetas de Windows Vista

Recientemente he recibido esta consulta de un usuario:

¿Es posible hacer que Windows Vista no calcule el tiempo restante estimado cada vez que hace una copia de archivos? Esto hace que las copias sean más lentas.

Para poder responder esta cuestión, es necesario observar cómo funciona internamente el sistema de copias de archivos y carpetas de Windows Vista:

Cuando el usuario copia, mueve o elimina archivos desde Explorador de Windows, se sigue un largo proceso que tiene su origen en la función SHFileOperation. Esta función enlaza con el nuevo motor de operaciones de archivos y carpetas de Windows Vista. Es importante hacer notar que este motor es totalmente nuevo. Esto es debido a que ahora es necesario tener en cuenta elevaciones de privilegios mediante UAC, así como añadir la implementación de una nueva interfaz para controlar mejor las colisiones de archivos y carpetas (si dos elementos tienen el mismo nombre, ofrecer las opciones de conservar ambos, sobrescribirlos, etc.).

El motor de copias de Windows Vista consta principalmente de la siguientes entidades:

  • El motor de copias propiamente dicho, que se encarga de "preparar" y "realizar" nodos y árboles de elementos (ficheros o carpetas) aplicando, para ciertas operaciones, la recursión.

  • La barra de progreso que informa al usuario de la fase en la que se encuentra la operación.

  • Un reloj (timer) que se encarga entre otras cosas de sincronizar el estado de la operación para así calcular el tiempo restante, la velocidad, etc.

El primer proceso que tiene lugar es lo que se denomina "preflight". En esta fase se enumeran los elementos que intervendrán en la operación y se muestra la barra de progreso con el texto "Descubriendo x elementos (y MB)". Esta operación suele durar poco tiempo, por lo que incluso es posible que en ocasiones ni la vea aparecer. Además, se hace uso de Superfetch para establecer una prioridad de memoria de 2 si la copia está dentro de un umbral determinado. Windows Vista introduce prioridades para las páginas de memoria, para más información consulte este artículo.

Los nodos se preparan y enumeran de manera recursiva para ciertas operaciones (por ejemplo, una copia) y, una vez preparados, se produce un cambio en la barra de progreso: El texto central se cambia por "Calculando tiempo restante". Lo que la mayoría de gente piensa es que aún no ha comenzado la operación en sí, y eso no es cierto. Mientras se está mostrando ese mensaje, ya se están "haciendo" los primeros nodos. Hacer un nodo básicamente consiste en mover, copiar o borrar el elemento físicamente, utilizando para ello una serie de funciones intermedias internas y no documentadas (podrá verlas si conecta un depurador que tenga los símbolos apropiados). Lo que ocurre realmente es que la barra de progreso muestra la frase "calculando tiempo restante" hasta que disponga de información "buena". El reloj es el encargado de darle esa información (nótese que, mientras tanto, la operación sigue su curso). A partir del cuarto segundo (con menos de 4 segundos la estimación de tiempo restante suele ser incorrecta), se le pregunta al reloj ¿cuál es el tiempo restante? Cuando éste puede dar una buena respuesta con la información disponible, actualizará el cuadro para decir, por ejemplo: "quedan 2 minutos". Este cuadro se irá actualizando progresivamente hasta que se finalice la operación.

Por último, otra de las cosas que debe tener en cuenta es que tanto la información sobre el tiempo restante como la velocidad de la operación no son demasiado fiables. La arquitectura del sistema de copias de Windows Vista y la forma en la que se obtiene el tiempo restante suelen dar lugar a inestables mediciones del tiempo restante, por lo que es normal que observe que la operación tarda realmente más de lo que se informa en el cuadro de diálogo. Asimismo, la velocidad de transferencia no es más que la velocidad global de la copia hasta el momento, es decir, no se incluye ningún matiz de velocidad local, así que puede ser algo inexacta también.

Como conclusión, yo considero posible que en ciertos escenarios y configuraciones de hardware las copias de archivos puedan realizarse lentamente, dada la manera de trabajar del nuevo motor, y de que se trata de algo totalmente nuevo en Windows Vista, con errores que se irán subsanando en versiones posteriores. De hecho, Microsoft ya ha hecho pública una corrección cuando las copias desde la red local se realizan muy lentamente, puede acceder a este artículo de la KB para obtener más información. Pero en ningún momento debería echar la culpa a la frase "calculando tiempo restante", porque Vista paralelamente ya está moviendo ficheros y carpetas mientras sigue apareciendo ese mensaje. Tampoco debería creer ciegamente en la información sobre el tiempo restante ni sobre la velocidad de transferencia, puesto que son dos aspectos que Microsoft espera calcular de un modo más exacto en versiones posteriores de Windows.

jueves, abril 05, 2007

UAC, tan querido, tan odiado...

Llevamos unos meses con Windows Vista en el mercado y, por consiguiente, el público ya puede comenzar a formarse una opinión sobre el nuevo sistema operativo. Una de las características que más críticas ha recibido es, sin duda, Control de cuentas de usuario (UAC, en inglés). La impresión general es que esta nueva herramienta no es más que una molestia para el usuario, especialmente para aquellos usuarios avanzados que afirman saber qué están "tocando" en su sistema.

Mi opinión es que UAC es la ayuda para que se produzca el necesario cambio de mentalidad en la mayoría de usuarios de Windows: el trabajo diario con el PC no requiere privilegios administrativos, salvo momentos puntuales. Esto es importante. Era necesario que Microsoft cambiara la manera de trabajar en Windows (todos los usuarios administradores por defecto) para que así los usuarios y desarrolladores se adaptaran a entornos con privilegios más limitados. Y, aunque no lo parezca, UAC es la manera más suave y sencilla posible para que se produzca ese cambio de mentalidad. Tiene sus fallos, es cierto que algunas copias de archivos pueden hacerse mortalmente pesadas (Microsoft es consciente de ello y quizá introduzca mejoras en SP1), pero a pesar de todo es la manera más simple de presentar las diferencias entre usuario administrador y limitado a un usuario general. Por otra parte, el número de ventanas de confirmación suele decrecer drásticamente una vez han pasado 2 ó 3 días desde la instalación de Windows, momento en el que se realizan muchísimas tareas administrativas para configurar aspectos de Windows, instalar software, etc.

Otro motivo importante por el cual UAC es necesario es que, cuantos más usuarios trabajen por defecto como usuarios limitados, mejores y más seguras aplicaciones recibiremos por parte de los fabricantes de software. Ellos también deben adaptarse a entornos limitados, deben dejar de almacenar la configuración de sus programas en partes delicadas del sistema operativo (la carpeta \Windows, \Archivos de programa, la rama de Registro HKLM\Software, etc.). Estas son prácticas que ha seguido casi desde siempre todo programa que funciona bajo Unix/Linux, pero que muy pocos programas para Windows seguían hasta ahora.

UAC, a largo plazo, se verá como una herramienta de transición, la ansiada transición en la que los usuarios del sistema operativo Windows ya no poseen privilegios administrativos por defecto. Así que personalmente yo recomendaría que todo usuario mantenga activado UAC en su sistema, no ya por seguridad (aunque sepa lo que está haciendo), sino para que el ecosistema de Windows sea mejor y más seguro. Todos ganamos con esto.

Tengo preparado publicar próximamente en la bitácora algunos artículos que detallen el funcionamiento interno de ciertos componentes nuevos en Windows Vista. Uno de esos artículos, por ejemplo, tratará sobre UAC, que es mucho más que una simple ventana de confirmación con un botón para continuar.

miércoles, marzo 21, 2007

¿Sabía que...? [V]

Por defecto observará que el menú Todos los programas de Windows Vista se presenta alfabéticamente, sin posibilidad de ser ordenado al gusto del usuario. Sin embargo, existe una opción en la interfaz gráfica para modificar este comportamiento: Haga clic con el botón derecho del ratón sobre el botón Inicio, seleccione Propiedades, botón Personalizar, desmarque la casilla Ordenar el menú Todos los programas por nombre y haga clic sobre Aceptar dos veces para cerrar todos los cuadros de diálogo abiertos.

jueves, marzo 01, 2007

Cómo funciona Restaurar sistema [Parte II]

En la primera parte del artículo ya comenté cómo funciona el controlador de Restaurar sistema, qué información almacena y cómo la almacena. En esta segunda parte, me centraré en la parte más gráfica de Restaurar sistema así como en el proceso de restauración en sí. La mayoría de problemas con esta herramienta se concentran en este ámbito.

Cuando el usuario abre el panel Propiedades de sistema, en primer lugar se carga la DLL Srclient.dll. El código de la misma decidirá si crear la correspondiente pestaña "Restaurar sistema" y qué opciones activar y cuáles no. Si el usuario goza de los privilegios necesarios para restaurar el sistema, Windows examinará si se ha establecido una política que desactiva Restaurar sistema.


Problema 1: No aparece la pestaña Restaurar sistema en Propiedades de sistema.

¿El usuario tiene privilegios necesarios para restaurar el sistema? Si los tuviera, observe si está presente la siguiente directiva en el Registro: Clave HKLM\Software\Policies\Microsoft\Windows NT\System Restore, valor "DisableSR", contenido "1". Elimínela si fuera así.



Finalmente, Windows enumera las unidades de disco, examina si están aplicadas otras directivas y observa si la herramienta está activada o desactivada para generar un contenido de la pestaña apropiado (una o varias unidades de disco, opciones desactivadas, etc.).

La herramienta Restaurar sistema

Al abrir la herramienta Restaurar sistema, se ejecuta el fichero Rstrui.exe del directorio %SystemRoot%\system32\restore\. En primera instancia se observa si el servicio "Servicio de restauración del sistema" está iniciado. Si no fuera así, se le intenta establecer un tipo de inicio automático e iniciarlo.


Problema 2: Al abrir Restaurar sistema aparece el siguiente mensaje de error: Restaurar sistema no puede proteger su equipo. Reinicie el equipo y vuelva a ejecutar Restaurar sistema.

Abra una ventana de comandos (Cmd.exe) y teclee lo siguiente:

sc queryex Srservice

Observe el estado del servicio y su código de salida. Al tratarse de un error Win32, puede saber qué significa cada código hexadecimal buscándolo en el fichero Winerror.h del Platform SDK de Windows XP.

Si la información de Registro o archivos encargados de implementar el servicio estuviesen dañados, podría reinstalar Restaurar sistema (Síntoma 1, Método 2 de este artículo: http://www.fermu.com/content/view/249/2/lang,es/).


A continuación, tras pasar de la pantalla inicial, se muestra un calendario para que el usuario elija un punto de restauración. Al confirmar la operación de restauración, comienza un proceso algo complejo que merece un apartado para él solo.

Restaurando el sistema

Una vez que el usuario hace clic sobre Siguiente para iniciar la restauración, se realizan una serie de pasos que generan un "entorno de restauración". Concretamente es la función InitiateRestore contenida en el fichero Srrstr.dll la encargada de realizarlos.

  1. Se crea un valor *Restore en la clave de Registro HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce. Este valor apunta al ejecutable Rstrui.exe y sirve para que se muestre la ventana informativa de Restaurar sistema tras el reinicio del sistema.
  2. Se crea un valor DWORD de nombre RestoreStatus con contenido 2. Este valor sirve para que otras aplicaciones sepan que se está produciendo una restauración.
  3. Automáticamente se crea un nuevo punto de restauración que será utilizado en caso de que la restauración falle o el usuario quiera deshacer los cambios realizados. El punto creado es de tipo nested, lo que quiere decir que ninguna otra aplicación puede crear otro punto en ese periodo de tiempo.
  4. Se crea un valor RestoreInProgress con contenido 1 en la clave HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore. Este valor lo leerá Winlogon y así sabrá que debe proceder con una restauración del sistema.
  5. Una vez que Winlogon determina que debe realizar una restauración, se reanuda la misma.

La funcion no documentada ResumeRestore de la DLL Srrstr.dll es la que realiza la restauración en sí y es llamada por Winlogon. Ésta consta de tres partes:

  • Preparar la restauración.
  • Restaurar archivos y directorios.
  • Grabar la instantánea del Registro y manipularla ligeramente.

Cada una de estas fases se corresponde con un porcentaje de la barra de progreso que aparecerá en pantalla: "Preparar la restauración" se realiza en el punto 0%, "restaurar archivos y directorios" en el 20% y "grabar la instantánea de Registro" en el 90%.

Preparar la restauración

En esta fase se crea un mapa de restauración a partir del archivo de cambios (Changelog). Entiéndase un mapa de restauración como una entidad abstracta que sirve para "dirigir" el proceso de restauración. Cada operación de creado de archivos, borrado, renombrado, etc. tiene su correspondiente entrada en el mapa. Esta operación dura relativamente poco tiempo.

Restaurar archivos y directorios

Esta fase se ve precedida por una "precarga" de la instantánea del Registro almacenada en el punto de restauración. Se hace esta "precarga" para asegurarse de que después no haya problemas de espacio en disco. Si hay menos de 60 MB libres, se realiza una operación FIFO para tratar de liberar espacio. Esto se realiza un par de veces, si fuera necesario. Si durante la restauración el sistema no contara con el espacio en disco necesario, la restauración no se puede completar, se registra el error, se deshacen los cambios realizados y el valor RestoreDiskSpaceError de la clave HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore almacenará un 112 decimal, error Win32 que significa ERROR_DISK_FULL.

Seguidamente se restaura el sistema realizando operaciones inversas a partir del mapa de restauración: Es decir, si se realizó una operación que añade un directorio, al restaurar deberá eliminarse dicho directorio, y así similarmente con las demás operaciones. En este momento es casi inevitable que surjan pequeños problemas, algunos se ignoran y otros, como si hubiera archivos en uso, se tratarán adecuadamente después. Las principales operaciones que generan un "Failed" (único resultado que detiene una restauración) son las siguientes:

  • Al renombrar un directorio, si el directorio origen no existe o la función MoveFile devuelve un error por cualquier motivo.
  • Al crear un directorio, si la función CreateDirectory devuelve algún error.
  • Al eliminar un directorio, si la función RemoveDirectory devuelve algún error.
  • Al modificar un archivo, si una función no documentada de Restaurar sistema devuelve un error.

Si durante la restauración aparecen dos archivos o directorios con el mismo nombre, se produce lo que se denomina una colisión. Restaurar sistema resuelve la colisión renombrando el archivo o carpeta afectado añadiéndole un "(n)" al final, donde "n" es un número comprendido entre 2 y 1000. Si por cualquier motivo no pudiera encontrar un nombre alternativo, la restauración falla pues el sistema quedaría en estado inconsistente si se obviara la operación que ha resultado en la colisión.

Si se produce cualquier error durante la restauración, debe restaurarse el sistema empleando para ello el punto de restauración que se creó al principio de la misma. Para deshacer una restauración se utiliza el mismo procedimiento que el que realiza la restauración, sólo que esta vez deben realizarse las operaciones en orden inverso.

Grabar la instantánea del Registro y manipularla ligeramente

En primer lugar se trata la rama Software: Se añade el valor *Restore a la clave RunOnce (como ya comenté), se añade un valor DWORD SfcScan con contenido 2 en la clave HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon para que se analice la integridad de los archivos del sistema. Seguidamente se restauran las claves de dicha rama, con algunas obvias excepciones:

  • La información sobre Asistencia remota no se restaura.
  • La información del Asesor de contenido de Internet Explorer.
  • La base de datos LSA.

A continuación se trata la rama SYSTEM. Las excepciones más notables son:

  • La información sobre la activación de Windows (WPA).
  • La información sobre la zona horaria.
  • La asignación interna de letras de unidades.

Por último se trata la rama SAM (Security Account Manager).


Los archivos, carpetas y claves de Registro que no se restaurarán se definen en las claves de Registro HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup y HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore.



También se restaura toda la información COM, los contadores de rendimiento, base de datos WMI y IIS (si procede).

Parte final. Mostrar la pantalla de información

El último punto del proceso consiste en mostrar la pantalla con la información sobre la restauración (si tuvo éxito o si no y por qué). Esta información la muestra el fichero Rstrui.exe cuando es llamado con unos parámetros internos y no documentados.

Cuando se produce una restauración "normal", esto es, no silenciosa, se anota en el Registro que debe ejecutarse el comando %SystemRoot%\system32\restore\rstrui.exe -c tan pronto como un administrador inicie sesión en el equipo. El parámetro -c, de "check", analiza el fichero %SystemRoot%\system32\restore\Rstrlog.dat para determinar si la restauración falló, o si se realizó correctamente. En caso de fallo, se llamará a rstrui.exe -result:f. Este parámetro hace que Restaurar sistema informe de si se trató de un error por falta de espacio en disco o de un error inespecífico. Lo determina leyendo el contenido de la clave HKLM\Software\Microsoft\Windows NT\CurrentVersion\SystemRestore.

Así es como funciona internamente Restaurar sistema. Si hubiera algún punto importante que me hubiera olvidado de comentar o si tuviera alguna duda, puede utilizar la sección de comentarios de la entrada y trataré de contestar todas las preguntas (si sé la respuesta, claro). Si fuese un problema técnico con Restaurar sistema, es mejor que formule su pregunta en alguna de las comunidades que existen en Internet sobre Windows.

martes, febrero 27, 2007

Cómo funciona Restaurar sistema [Parte I]

En este artículo (será de los últimos o quizá el último que dedique a Windows XP) comentaré cómo funciona internamente una herramienta bastante útil: Restaurar sistema. Además de ofrecer detalles sobre su diseño, incluiré las causas de los mensajes de error y comportamientos anómalos más frecuentes que me he ido encontrando al analizar problemas de usuarios. Si asimila este artículo de dos partes, comprenderá mucho mejor cómo funciona todo y podrá abordar la resolución de problemas con altas garantías de éxito.

En la primera parte del artículo explicaré cómo funciona el controlador en modo núcleo de Restaurar Sistema: Sr.sys. Este controlador, presente en \WINDOWS\system32\drivers, se encarga básicamente de monitorizar los accesos de entrada y salida que se produzcan en el volumen. Lo hace interceptando llamadas de tipo IoCallDriver. El comportamiento del controlador Sr.sys viene determinado por el contenido de la clave de Registro HKEY_CLASSES_ROOT\SYSTEM\CurrentControlSet\Services\Sr\Parameters.

Inicialización del controlador

Al tratarse de un controlador de arranque, se inicializa en una etapa temprana de la carga de Windows. Nada más terminar de inicializarse, se "adhiere" a todos los volúmenes montados por el sistema operativo. Esta es la causa por la que, si dispone de un arranque dual con Windows Vista, observe que pierde todos los puntos de restauración si arranca Windows XP. Seguidamente, crea un directorio llamado "System Volume Information\_restore{GUID}" (si no existiera) en la raíz del disco. Lo crea de tipo oculto, de sistema y por defecto sólo le otorga permisos al usuario SYSTEM. En él se generan unos cuantos archivos, entre los que destacan:

  • _driver.cfg: Contiene el número del punto de restauración actual, número de secuencia del LOG y otra información relacionada.
  • _filelist.cfg: Este fichero es una copia del fichero Filelist.xml presente en el directorio %SystemRoot%\system32\restore\.

¿Qué monitoriza exactamente el controlador?

Básicamente monitoriza todo fichero "interesante". Por interesante se entiende lo siguiente:

  • Que el archivo o carpeta no esté presente en la lista de exclusiones de _filelist.cfg.
  • Que igualmente no esté incluido en una caché interna de Restaurar sistema.
La caché interna a la que se refiere el segundo punto es una tabla hash que "recuerda" las operaciones que se han realizado sobre los archivos y evita monitorizar aquéllas que se repitan. Con esto se minimiza el número de operaciones de copia de archivos.

Una vez que Sr.sys ha determinado que el fichero debe ser respaldado antes de proceder con la operación que se quiere realizar (por ejemplo, eliminarlo), crea una copia del mismo en el directorio System Volume Information\_restore{GUID}\RPX. La copia tiene la forma "AXXXXXXX.ext", donde "X" son números y "ext" es la extensión original del fichero. El subdirectorio Snapshot contiene copias del estado del Registro en el momento de la creación del punto de restauración. Los archivos guardados mantienen sus DACLs, atributos, streams, etc. y a la vez son comprimidos para evitar su fragmentación. Si por algún motivo los ACLs de algún fichero no cupieran en el correspondiente registro (que es de pocos KBs), se creará un fichero de la forma SXXXXXXX.acl y se incluirá una entrada en el LOG apuntando a dicho fichero.

El fichero Change.log

Este fichero es una parte extremadamente importante a la hora de restaurar el equipo de manera satisfactoria. Cuando se realiza una operación de entrada/salida "interesante", además de guardarse una copia del fichero en cuestión (como ya he comentado), se escribe en un fichero Change.log todos los detalles de la operación que se ha realizado. Nótese que, en el caso de que se hayan modificado directorios, no se realiza copia física de respaldo de los mismos, sólo se registra en Change.log la operación que se haya completado.

Para que este fichero sea manejable por el sistema operativo, el sistema lo divide en varios "trozos". Windows finaliza un trozo cuando ocurre alguno de estos eventos:

  • Se ha apagado el equipo.
  • Por algún motivo se ha deshabilitado el volumen en cuestión.
  • Se ha desactivado Restaurar sistema en ese volumen.
  • El archivo ocupa más de 1 MB de tamaño.
Los trozos se diferencian por sufijos numéricos. Así existirían Change.log.1, Change.log.2, etc., siendo el más reciente el de sufijo más alto.

Esta es la funcionalidad básica del controlador de Restaurar sistema en modo núcleo, Sr.sys. En el siguiente artículo me detendré en la parte en modo usuario así como en lo que ocurre "por lo bajo" cuando el usuario pide restaurar su sistema a un punto anterior. Obviamente aclararé por qué ocurren las temidas "restauraciones incompletas", que impiden revertir de manera satisfactoria el estado del sistema.

martes, febrero 20, 2007

Una curiosidad sobre la caja Ejecutar

En uno de los foros en los que participo, un usuario tenía la siguiente inquietud: ¿Por qué si en una ventana de comandos se escribe "msconfig" no se reconoce el comando y, en cambio, desde Inicio, Ejecutar, sí se ejecuta correctamente dicha herramienta?

El secreto está en que la caja Ejecutar del menú Inicio invoca a una función muy específica (y útil): ShellExecuteEx. Es ella la que realiza todo el trabajo "sucio" de encontrar lo que se ha escrito en la caja Ejecutar. Simplificando detalles que no son relevantes en el tema de este artículo, en primer lugar ShellExecuteEx va a mirar en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. Las aplicaciones pueden incluir las rutas de sus ejecutables en esta clave sin necesidad de manipular la variable de entorno Path. En el caso de que no haya encontrado el ejecutable en la clave anterior, la función ShellExecuteEx se dispondrá a examinar la variable de entorno Path del sistema operativo. Esto lo hace llamando a la función PathFindOnPath, públicamente documentada. Esta función hace uso a su vez de FindFirstFileEx, FindNextFile y FindClose para encontrar el archivo en cada ruta que encuentre en la variable antes mencionada. Estas funciones residen en Kernel32.dll, por lo que realizan la búsqueda utilizando para ello ciertas funciones del núcleo de Windows que no están públicamente documentadas. Desde símbolo de sistema sólo se examina el contenido de la variable de entorno Path para buscar un comando no interno. Como la ruta de Msconfig.exe no está por defecto en el contenido de la variable Path, aparece un mensaje de error indicando que el comando no ha sido reconocido.

Como siempre, muchos virus se aprovechan de esto y redireccionan el contenido de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths para que apunte a su código malicioso. Así, el usuario, que inocentemente trata de ejecutar Regedit o Msconfig para reparar su sistema, acaba ejecutando un troyano o el ejecutable de un gusano, por ejemplo.

Por cierto, las funciones FindFirstFileEx, FindNextFile y FindClose antes mencionadas las utiliza Windows en muchísimos contextos. Como curiosidad, en el artículo donde comentaba cómo Agregar o quitar programas obtenía la información sobre el tamaño de los programas instalados, el módulo Appwiz.cpl llama a estas funciones si no hay información en la caché o ésta se ha corrompido.

lunes, febrero 05, 2007

Sobre el desfragmentador de Windows Vista

Reproduzco una consulta que recibí de un usuario:

Daniel, el desfragmentador de Windows Vista pienso que es bastante malo, ¿qué han hecho los chicos de MS? No hay barra de progreso y, lo que es más importante, si analizo una partición desfragmentada desde Vista aún sigo viendo mucha fragmentación. ¿Cómo lo han empeorado tanto?

Aunque le parezca lo contrario, el desfragmentador incluido en Windows Vista es mucho mejor que el de su predecesor. En este artículo discutiré cómo funciona internamente, centrándome en las quejas más frecuentes que he ido recibiendo.

¿Por qué no hay barra de progreso al desfragmentar?

Una barra de progreso en un proceso de desfragmentación es una incorrección. Todo proceso de desfragmentación del espacio en disco es un proceso en el cual se siguen múltiples fases: una para desfragmentar archivos, otra para consolidar el espacio libre en disco, etc. Cada una de estas fases puede durar un tiempo variable, por lo que la barra de progreso del desfragmentador de Windows XP carece de sentido práctico.

Los resultados del desfragmentador difieren de los del de XP

En efecto, el desfragmentador de Windows Vista utiliza un algoritmo distinto del de Windows XP. Es mucho más eficiente. El algoritmo empleado en Windows XP podría simplificarse del modo siguiente: Todo archivo del disco que esté en, al menos, dos posiciones no contiguas del disco se marca como "fragmentado". El desfragmentador obtendrá ese dato y unirá todas las partes para, posteriormente, compactar el espacio libre en disco. Esto supone dos puntos negativos:
  • Se requiere de un cierto espacio libre en disco para poder realizar la desfragmentación. En el caso de Windows XP este espacio mínimo es de un 15%. En Windows Vista no hay espacio libre mínimo necesario.
  • Si los fragmentos son "demasiado grandes" el tiempo empleado en mover los bloques es superior a la ganancia en rendimiento obtenida.
Quiero precisar sobre el último punto: En un volumen NTFS, el salto de un fragmento a otro consume un bajísimo porcentaje de tiempo en comparación con el tiempo que se tarda en leer un bloque no fragmentado. Partiendo de bloques de 64 MB o más, no merece la pena mantenerlos contiguos, el "esfuerzo" necesario para ello no compensa la ganancia de rendimiento. Debido a esta optimización, el desfragmentador de Vista reduce el consumo de CPU de manera considerable.

El desfragmentador hace uso de la característica "Low-priority I/Os" de Windows Vista

Una de las nuevas posibilidades del núcleo de Windows Vista que más me gusta son las "low-priority I/Os". Así, un desarrollador, que antes podía ejecutar procesos con baja prioridad, ahora puede realizar entradas/salidas igualmente con baja prioridad. En Windows Vista el servicio de indizado, Windows Defender, las aplicaciones que se inician con Windows, y el desfragmentador (entre otros) hacen uso de entradas/salidas de baja prioridad.

El objetivo de Microsoft es que el usuario pueda desfragmentar el disco mientras utiliza cómodamente el PC. Todo el proceso de desfragmentación se hace empleando entradas/salidas de baja prioridad en el momento que se detecte actividad en el sistema. La única excepción es la fase en la que se desfragmenta la MFT del disco. Puede hacer la prueba, inicie el proceso de desfragmentación, deje el sistema sin usarlo y observe el consumo de recursos. Efectivamente es alto, pero ahora realice tareas en el sistema, verá como el consumo disminuye (aumentará lógicamente el tiempo de desfragmentado).

Hay una tarea programada que desfragmenta el disco

Windows Vista incorpora una tarea programada para desfragmentar el disco. Puede acceder a ella desde Administración de equipos, Herramientas del sistema, Programador de tareas, Biblioteca del Programador de tareas, Microsoft, Windows, Defrag. Esta tarea sólo se realiza cuando el sistema está inactivo, por lo que si despliega la pestaña Historial quizá observe que la tarea se ha iniciado, detenido e iniciado de nuevo un sinfín de veces. Es normal, se detectó actividad en el equipo y la tarea se detuvo, para continuarse tan pronto como el sistema vuelva a estar inactivo.

Así pues, ya ve que el desfragmentador incluido en Windows Vista es mucho más eficiente y menos intrusivo que el de Windows XP, a pesar de que la interfaz gráfica sea demasiado "simple" y esto pueda confundir a los usuarios.

Una última optimización del desfragmentador de Windows Vista que no quiero dejar sin comentar tiene que ver con el almacén de copias sombra ("shadow copies"): El nuevo algoritmo de desfragmentación está diseñado del tal forma que se reduce el número de operaciones copy-on-write en el disco. Si esto no fuera así, el almacén de copias sombra y puntos de restauración de Windows Vista vería acelerado su llenado, perdiéndose por tanto el contenido más antiguo del mismo.

martes, enero 23, 2007

Ese "extraño" mensaje: La memoria no se puede "read"

Uno de los problemas que más recibo y que pienso que más despista a la gente es un error del tipo "La instrucción en "0xnúmero_hexadecimal" hace referencia a la memoria en "0xnúmero_hexadecimal". La memoria no se puede "written"/"read". Observe la siguiente imagen que ilustra el error:

Mensaje de error de aplicación

Mucha gente asocia este mensaje de error con un problema con la memoria RAM, pensando que pudiera estar dañada o que quede poca disponible. Probablemente el problema no se deba a un módulo defectuoso de RAM.

Ese mensaje de error es la manera "fea" que tiene Windows XP de decir que ha ocurrido una excepción en modo usuario porque alguna aplicación o componente ha intentado acceder a una posición de memoria que no debería (por ejemplo, mediante un puntero erróneo). Esto se denomina infracción de acceso y se identifica mediante el código de error c0000005.

Veamos un poco qué ocurre por dentro de Windows cuando sucede un error de este tipo

Windows debe tener un mecanismo interno que le permita actuar de algún modo cuando ocurra una excepción no controlada en modo usuario. Para simplificar las cosas, supongamos que se trata de un bloque try convencional que puede lanzar la excepción mediante la función UnhandledExceptionFilter. En este momento, Windows examina el Registro para saber qué hacer una vez ha ocurrido un error de aplicación. La clave HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug contiene un valor Auto que le indica al sistema si debe iniciar automáticamente el depurador por defecto del sistema, definido éste en el valor Debugger. El depurador por defecto de Windows XP es Dr Watson.


Nota: Si instala alguna aplicación relacionada con el desarrollo, es probable que ésta instale su propio depurador. Quizá también lo establezca automáticamente como depurador por defecto del sistema.


En este momento se carga la dll Faultrep.dll que examina el Registro para saber cómo desea el usuario que se le informe de los errores de aplicación. La clave de Registro HKLM\SOFTWARE\Microsoft\PCHealth\ErrorReporting contiene la información accesible desde la interfaz gráfica de Windows en el panel Informe de errores, situado en la pestaña Opciones avanzadas de Propiedades de sistema. Observe la siguiente imagen:

Panel Informe de errores de Windows XP

Si se desea que se muestre una intuitiva interfaz gráfica (valor ShowUI distinto de cero), Windows cargará el proceso \WINDOWS\system32\Dwwin.exe en memoria, que es el que muestra la típica pantalla de error de aplicación de Windows XP, mostrada en la siguiente imagen:

Típica ventana de error de aplicación de Windows XP

Si el valor ShowUI es igual a cero, siempre obtendrá la pantalla mostrada al principio del artículo, que no ofrece la posibilidad de ver el módulo afectado por el error ni de enviar la información a Microsoft. Dependiendo de la aplicación que haya generado el error, es posible que se le muestre esta pantalla pese a que utilice la configuración por defecto. No debe preocuparse, se trata del mismo problema: una excepción no controlada en modo usuario.

¿Cómo solucionar el problema?

En primer lugar debe asegurarse de que el sistema esté libre de virus y ficheros espía. Un sistema infectado puede producir excepciones de este tipo. En segundo lugar, revise la esquina superior izquierda del título de la ventana de error, es posible que se haga referencia a un fichero de terceros conocido, en cuyo caso habría que contactar con el fabricante para informarse de si es un problema conocido o de si existe alguna solución al respecto.

Si el proceso referenciado fuese demasiado inespecífico (como por ejemplo Explorer.exe), no queda más remedio que hacer pruebas iniciando el sistema en Modo seguro o realizar sucesivos inicios limpios hasta dar con el posible culpable.

También es posible examinar la información registrada por el depurador de programa.

Nota: Si el proceso referenciado fuese Iexplore.exe, es posible que algún añadido (plug-in) sea el que ha generado la excepción. Si usa Internet Explorer 7, ejecute el navegador sin complementos y observe si se reproduce el problema. Para ejecutar el navegador sin complementos abra Inicio, Ejecutar, escriba "%ProgramFiles%\Internet Explorer\iexplore.exe" -extoff y pulse Aceptar.


En este caso deberá pulsar sobre Cancelar en la ventana de error para depurarlo. Abra Inicio, Ejecutar, escriba "%AllUsers%\Datos de programa\Microsoft\Dr Watson" (con comillas) y pulse Aceptar. Observará dos ficheros: Drwtsn32.log contiene un reporte con todos los errores de aplicación que han sido administrados por Dr Watson. Los últimos errores recibidos se sitúan al final de la lista. User.dmp suele ser un pequeño volcado de la memoria en el momento del error. Este fichero se sobreescribe cada vez que ocurre un error de aplicación. Puede cargar este fichero en cualquier depurador como Windbg (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) para examinarlo.

Espero que este artículo haya aclarado algunas dudas acerca de esa "extraña" ventana que nos indica que la memoria no se puede "read" (o "written") y que nos podemos encontrar cuando nos topamos con software mal diseñado en nuestro sistema.

miércoles, enero 17, 2007

El caso de la instalación fallida de antivirus

En cierto foro me encontré con un problema bastante interesante. Cualquier software antivirus que el usuario afectado intentaba instalar en su sistema, Windows Installer devolvía el número de error 1304, que quiere decir, literalmente, "Error al escribir el archivo, verifique que tenga acceso a ese directorio". En un principio este mensaje puede hacer pensar que se trata de un problema de permisos, pero, como descubrirá más adelante, el causante era bien distinto.

En primer lugar examiné el fichero de reporte de instalación que genera AVG al ser instalado, el fichero Avg7inst.log. En él busqué la línea que detalla el problema concreto de instalación, representada en la siguiente imagen:

¿No puede encontrar el archivo o el directorio? Extraño mensaje de error, sin duda.

Como ve, el mensaje de error es bastante despistante. El programa de instalación no pudo crear lo que presumiblemente es uno de los ficheros ejecutables esenciales para el funcionamiento del antivirus porque no encontró el fichero o el directorio. ¿? Pero el directorio se ha creado correctamente, como así referencia el reporte. ¿Qué ocurre entonces? El problema no parecía estar relacionado con los permisos.

¿Cómo averiguar cuál era el causante?

Ante este mensaje de error durante la instalación, no me quedó otra opción que examinar detalladamente la instalación del antivirus hasta llegar al punto en el que se trata de instalar el fichero Avgamsvr.exe. Para ello, pedí al usuario un fichero PML generado por Process Monitor. Process Monitor (http://www.microsoft.com/technet/sysinternals/processesandthreads/processmonitor.mspx), es una excelente herramienta que monitoriza los accesos al registro y a archivos del disco que realizan los procesos del sistema. Combina lo mejor de Regmon, Filemon y Process Explorer en una sola herramienta.

Al abrir el fichero PML y filtrar adecuadamente, me encontré con un código de error algo más esclarecedor:

El error que devolvió el controlador de Process Monitor sin duda era más explicativo.

El código Sharing Violation (infracción al compartir) es un código de error muy común en Windows. Ocurre cuando algún proceso intenta modificar de alguna manera algún fichero que está siendo utilizado por otro proceso. Pero, ¿cuál podría ser el proceso que estaba manejándolo?

Es bastante extraño que un fichero que acaba de ser creado esté siendo accesado por el sistema operativo. Quise echar un vistazo a la pila de llamadas del hilo del proceso Avgsetup.exe que estaba funcionando en el momento de recibir el mensaje de error. Me encontré con esto:

Este era el causante de la instalación fallida.

Si lee la información de la pila, verá que el hilo de la instalación en el punto concreto de la creación del fichero estaba funcionando en modo kernel (todas las funciones tienen una K rosa a la izquierda). En concreto, la función ZwSetSystemInformation del fichero Ntoskrnl.exe llama a un extraño fichero M_hook.sys, residente en el directorio %AppData%\hidires. La función ZwSetSystemInformation no está públicamente documentada, pero su prefijo (Zw) me indica que es una función relacionada con los servicios del sistema que acceden en modo kernel (y por tanto no hay validación de parámetros, al contrario de las que tienen prefijo Nt).

Ya se encontró al culpable

El fichero M_hook.sys tiene toda la pinta de tratarse de un rootkit instalado por algún troyano. Su objetivo debe de ser esconderse de los mecanismos internos del sistema operativo y bloquear la creación en el disco de ficheros relacionados con software antivirus conocido. Ante un sistema comprometido de esta manera, la única solución que garantice que no resta código malicioso en el disco es reinstalar el sistema operativo de cero.

Espero que les haya parecido interesante el artículo. Para evitar este tipo de problemas, recomiendo mantener el sistema al día, trabajar con un usuario con los menores privilegios posibles, activar un antivirus actualizado así como un cortafuegos y tener mucho cuidado con el software que se descarga de Internet, especialmente si proviene de sitios no oficiales o de redes P2P.