Daniel Martín's blog

Como quizá sepa, el comando Runas.exe de Windows XP y Windows Server 2003 sirve para ejecutar procesos en el contexto de otra cuenta de usuario. Los usuarios domésticos normalmente lo usan para ejecutar un proceso como administrador desde una cuenta limitada. Echando un vistazo al listado de parámetros de Runas.exe nos encontramos con uno que suele llamar la atención de bastante gente. Sirve para almacenar temporalmente en el administrador de credenciales (Credential Manager) el usuario y contraseña que va a ejecutar el programa. El atractivo de este parámetro es que no tendremos que introducir el nombre de usuario y contraseña para ese programa durante la sesión en curso. Sin embargo, no hay unanimidad con respecto al nombre del parámetro (incluso la propia documentación del sistema operativo creo que presenta alguna inconsistencia al respecto): Unos lo llaman /savecred, otros /savedcred, otros /savedcreds... Incluso en algunos sitios se indica que tienen semántica diferente.

Nada más lejos de la realidad. Runas.exe solo entiende el parámetro /sa (que contiene el mínimo número de letras que diferencian /savecred de los parámetros /smartcard y /showtrustlevels); lo que venga después le es indiferente. Del mismo modo, en cuanto se encuentra con /p supone el parámetro /profile; si se encuentra con /e supone /env, y así sucesivamente.

Nota: Por limitaciones del administrador de credenciales de XP Home Edition, el parámetro /savecred no es tenido en cuenta en esta versión de Windows. Este artículo no es aplicable tampoco a Windows Vista, pues el comando Runas.exe en Windows Vista es bastante diferente del de XP y será tema de un próximo artículo.

Desde que salió a la luz Windows Vista, y ahora con las versiones preliminares de Windows 7, me he dado cuenta de que el número de problemas cuya solución implica el registro de una DLL (mediante el comando regsvr32 nombreDLL) ha descendido notablemente en estos dos últimos sistemas operativos. Una de las causas de esto, para mí, es la inclusión de Windows Resource Protection (WRP), mecanismo que garantiza la integridad de los componentes vitales del sistema operativo y que supone una tremenda mejora con respecto a Windows File Protection (WFP), sistema de protección de archivos de sistema presente en Windows 2000 y XP.

Windows File Protection (WFP)

Windows 2000 y XP incorporaron una característica denominada WFP (Windows File Protection), encargada de proteger los archivos más importantes del sistema operativo para evitar que sean modificados o eliminados.

Su funcionamiento se basa en uno o varios hilos de tipo centinela residentes en el proceso Winlogon e implementados en la DLL Sfc_os.dll. Es decir, estos hilos están al tanto de cualquier tipo de modificación que se realice sobre directorios del sistema (típicamente \System32 y \System32\drivers). Si hubiera cambiado alguna DLL de estos directorios, se registra dicho suceso en una cola destinada a tal efecto. En ese momento se señaliza un evento que despierta a otro hilo encargado de realizar la verificación del correspondiente archivo y su recuperación desde la cache (carpeta oculta \WINDOWS\System32\dllcache). Si no estuviera en cache, se mostrará una interfaz al usuario informándole de tal situación e invitándole a introducir el CD de Windows 2000/XP para intentar recuperar la versión original del archivo.

Windows Resource Protection (WRP)

La llegada de Windows Vista supuso que la estructura interna del sistema operativo cambiara radicalmente. Ahora el sistema operativo está formado por componentes, claves de Registro, manifiestos XML y ficheros binarios, entre otras cosas, por lo que la aproximación empleada en versiones anteriores de Windows ya no podía seguir siendo válida. Este aspecto puede ser interpretado como una ventaja, pues si se desarrolla un sistema de protección para cada uno de los componentes del sistema operativo, ya no solo estaremos protegiendo ejecutables y DLL, como en Windows 2000/XP, sino que estaremos protegiendo también claves de Registro y otro tipo de recursos que son igualmente vitales para el correcto funcionamiento del equipo. Este sistema de protección recibió el nombre de Windows Resource Protection (WRP).

Cada uno de los componentes que conforman el sistema operativo Windows Vista/Windows 7 contiene un fichero denominado manifiesto. Un manifiesto es un fichero de tipo XML que contiene información específica sobre el componente, es decir, archivos que lo componen, archivos de los que depende, claves de Registro, privilegios con los que se ejecutará por defecto, idioma, etc. Uno de estos posibles parámetros (etiquetas XML) es la protección del recurso en cuestión, etiqueta <systemProtection></systemProtection>. Existen distintos valores posibles para el parámetro behavior (comportamiento) de esa etiqueta:

• readOnlyIgnoreWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación será descartado; es decir, se le informará de que la escritura se realizó con éxito pero el fichero no se verá modificado.
• readOnlyFailWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación tendrá como consecuencia que reciba un error.
• OSOnlyIgnoreWrites: Similar a readOnlyIgnoreWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
• OSOnlyFailWrites: Similar a readOnlyFailWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
• applicationVirtualized: Cualquier cambio que se haga sobre el recurso supondrá que el sistema operativo cree una copia privada a la aplicación que lo ha modificado. El recurso global no se ve modificado.
• userVirtualized: Similar a applicationVirtualized pero la copia privada es por usuario, no por aplicación.

En el mismo fichero de manifiesto se indica también qué descriptor de seguridad usar para dicho componente. Por ejemplo, la carpeta Winsxs de Windows Vista tiene este descriptor de seguridad:

Donde S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 es el SID de TrustedInstaller, un servicio encargado de instalar actualizaciones y componentes en Windows Vista y Windows 7.

Vamos a explicar un poco el descriptor de seguridad: Las dos primeras líneas indican que el propietario (O, de owner) como el grupo (G, de group) es TrustedInstaller. La línea D:PAI quiere decir que el DACL es protegido (es decir, que no hereda listas de control de acceso o ACL) y además se hereda automáticamente. A continuación se indica que TrustedInstaller tiene acceso total al recurso (FA, de full access); el grupo de administradores, sistema y usuario (BA, SY y BU, respectivamente) tienen acceso genérico de lectura/escritura. Así pues, ni siquiera un administrador podrá modificar el contenido del directorio Winsxs. Tan solo TrustedInstaller, con motivo de la instalación/desinstalación de actualizaciones, Service Packs o componentes opcionales de Windows podrá modificar ese directorio.

Si quiere saber más sobre ACL y DACL le recomiendo el libro Windows Internals, escrito por Mark Russinovich y David Solomon, ya sea en su cuarta o su quinta edición.

Veámoslo con un ejemplo

Abriendo el fichero de manifiesto del componente Bloc de notas de Windows Vista podemos observar entre otras cosas lo siguiente:

<dependentAssembly>
      <assemblyIdentity name="Microsoft-Windows-Kernel32" version="6.0.6001.18000" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" />
    </dependentAssembly>

Aquí se hace referencia a que Bloc de notas depende del componente Microsoft-Windows-Kernel32 (que contiene entre otras cosas la DLL Kernel32.dll) para funcionar correctamente.

<systemProtection xmlns="urn:schemas-microsoft-com:asm.v3" behavior="readOnlyFailWrites" perUserVirtualization="Disabled" />

Aquí se hace referencia a que cualquier intento de escritura sobre el componente Bloc de notas dará como resultado un error y no se llevará a cabo la modificación. La virtualización está desactivada, por tratarse de un componente de Windows.

<shortCut arguments="" destinationPath="$(runtime.documentsSettings)\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories" destinationName="Notepad.lnk" targetPath="$(runtime.system32)\notepad.exe" iconPath="$(runtime.system32)\notepad.exe,0" windowStyle="normal" workingDirectory="%HOMEDRIVE%%HOMEPATH%" description="@%SystemRoot%\system32\Shell32.dll,-22563" displayResource="$(runtime.system32)\shell32.dll,22051" />

Aquí se hace referencia a la configuración del acceso directo al bloc de notas que hay en el menú Inicio.

<registryKey keyName="HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command" owner="false">
      <registryValue name="" valueType="REG_EXPAND_SZ" value="%SystemRoot%\system32\NOTEPAD.EXE %1" operationHint="replace" owner="true" />

Aquí se hace referencia a una de las claves de Registro gobernadas por Bloc de notas, la correspondiente a las asociaciones de ficheros.

Como puede observar, la integridad del sistema operativo fue uno de los objetivos principales para Microsoft mientras diseñaba Windows Vista. La protección de todos y cada uno de los recursos vitales del sistema operativo mediante Windows Resource Protection (WRP) hacen que Windows Vista y Windows 7 sean sistemas mucho más estables y robustos que sus predecesores.

Si se hiciera un listado con las consultas más frecuentes en los foros de Windows, seguro que esta ocuparía una posición bastante destacada: ¿Por qué no puedo cambiar el atributo de solo lectura a una carpeta de mi sistema?

Pese a que Microsoft dispone de un artículo al respecto (KB326549), considero que mucha gente aún tiene dudas sobre este tema y por eso me he decidido a escribir este artículo.

Si un usuario hace clic con el botón derecho sobre una carpeta de su sistema y selecciona Propiedades, le aparecerá un cuadro de diálogo similar al siguiente (en un sistema XP):

Como puede observar en la imagen, la casilla Sólo lectura tiene un aspecto particular: No está marcada, pues no aparece la típica marca de verificación en el cuadrado blanco, ni tampoco está desmarcada, pues el color del cuadrado no es blanco sino verdoso. ¿Qué significa esto? Esa casilla es una casilla de tipo triestado; es decir, hay tres posibles estados para esa casilla: Marcada, desmarcada e indeterminada, que es el caso que nos ocupa. Si hace clic varias veces sobre la casilla Sólo lectura podrá ver que va cambiando el estado de la misma. Sin embargo, pese a dejar la casilla en estado marcado y pulsar Aceptar, al volver a abrir las propiedades de la carpeta la casilla vuelve al estado indeterminado.

¿Cuál es la causa de esto?

La causa de este comportamiento es que el atributo de sólo lectura no se puede cambiar, para carpetas, desde la interfaz de Windows. Microsoft tomó esta decisión porque el atributo de sólo lectura aplicado a carpetas tiene una semántica que nada tiene que ver con la del atributo de sólo lectura aplicado a ficheros. El atributo de sólo lectura aplicado a carpetas únicamente quiere decir que la carpeta es una carpeta personalizada (con un icono distintivo, con un fondo, etc.).

Debe quedar claro que el atributo de sólo lectura aplicado a una carpeta no quiere decir que la carpeta no se pueda eliminar o cosas por el estilo.

¿Para qué está la casilla Sólo lectura en las propiedades de una carpeta?

Está presente porque puede aplicarse a los ficheros que contenga esa carpeta. Si desmarca la casilla Sólo lectura en las propiedades de una carpeta y pulsa Aceptar, lo que ocurre es que se quita el atributo de sólo lectura a todos los ficheros que contenga esa carpeta, si es que contiene alguno. De igual forma, si establece el estado de la casilla como marcado (con una marca de verificación en el cuadrado blanco) y pulsa Aceptar, todos los ficheros de esa carpeta pasarán a tomar el atributo de sólo lectura.

Entonces, ¿cómo cambiar el atributo de sólo lectura a una carpeta?

Como ha podido ver, Explorador de Windows no permite que el usuario cambie el atributo de sólo lectura a una carpeta. Esto se debe a que Microsoft no quiere que los usuarios "jueguen" con este atributo, lo que podría suponer que se perdieran las personalizaciones de algunas carpetas del equipo, incluidas algunas carpetas de sistema importantes para Windows. Así pues, si un usuario quiere "jugar" con el atributo de sólo lectura aplicado a una carpeta, debe hacerlo desde la línea de comandos usando el comando Attrib.exe de un modo similar al siguiente:

attrib +r <Ruta_carpeta>

Esto aplicaría el atributo de sólo lectura a la carpeta indicada por <Ruta_carpeta>

Similarmente, el comando

attrib -r <Ruta_carpeta>

desactivaría este atributo.

Espero que este artículo sirva para aclarar de manera definitiva en qué consiste exactamente el atributo de sólo lectura cuando se aplica a una carpeta, por qué Explorador de Windows siempre muestra la casilla correspondiente como indeterminada, y qué ocurre cuando el usuario deja esa casilla en estado marcado o en estado desmarcado y pulsa sobre Aceptar.

En la primera parte de esta serie de artículos aprendió a instalar Windbg y a configurar un aspecto básico, los símbolos de depuración. En este artículo veremos cómo configurar otros aspectos menores de Windbg, pero que le pueden resultar necesarios, y depuraremos la primera aplicación en modo usuario.

Configurar la ruta de código fuente

Si está depurando una aplicación que no haya desarrollado, es probable que no disponga del código fuente de la misma; sin embargo, si estuviera depurando una aplicación de la que dispone el código fuente, es muy buena idea configurar Windbg para que sea capaz de usar toda esa información y mostrar la ejecución paso a paso en formato de instrucciones de código fuente, no instrucciones máquina. Para configurar este aspecto, despliegue el menú File, Source File Path (o pulse Ctrl+P). También puede usar el comando .srcpath <Ruta_código_fuente>

Para que el depurador muestre instrucciones de código fuente y no instrucciones máquina es necesario además que los símbolos de depuración contengan información acerca del fichero fuente y número de línea que se corresponde con un determinado símbolo. Estos símbolos, denominados normalmente símbolos privados, no suelen estar a disposición de los usuarios ajenos a la empresa creadora del software en cuestión.

Configurar la ruta de los módulos

En la mayoría de ocasiones, Windbg es capaz por sí solo de encontrar las imágenes de los ejecutables implicados en una sesión de depuración. En determinados casos, como por ejemplo cuando se está depurando un volcado de memoria pequeño o minidump (la depuración de volcados de memoria se tratará en un posterior artículo), es necesario indicarle al depurador dónde debe buscar los módulos (.exe, .dll, .sys, etc.). Para ello, abra File, Image File Path (o pulse Ctrl+I). Como siempre, si desea lograr esto mediante un comando de Windbg, ejecute .exepath <Ruta_ejecutables>

Ejecutar una aplicación dentro del depurador

Ya está en condiciones de depurar su primera aplicación en Windbg y para ello vamos a ejecutar la calculadora de Windows dentro de Windbg.

Abra File, Open Executable (o pulse Ctrl+E) y busque el ejecutable Calc.exe dentro del directorio \Windows\system32\. En este caso deje desmarcada la casilla Debug child processes also, que sirve para depurar no solo el proceso principal que cree ese ejecutable sino sus procesos hijos también. Haga clic sobre Abrir.

La pantalla de Windbg se rellenará con un texto similar al siguiente:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Analicemos detalladamente toda esta información:

La línea CommandLine nos está indicando el archivo que vamos a ejecutar dentro de Windbg, en este caso la calculadora de Windows. A continuación se muestra la ruta establecida para los símbolos y la ruta de búsqueda de módulos ejecutables, que en este caso está vacía porque no la hemos establecido desde la opción File, Image File Path. Seguidamente el depurador ha registrado información sobre la carga de una serie de módulos de los que depende la calculadora de Windows. Para ver las dependencias de un módulo yo recomiendo usar la herramienta Dependency Walker (http://www.dependencywalker.com/).

La siguiente línea, (23c.24c): Break instruction exception - code 80000003 (first chance), da pie a comentar bastantes cosas:

La sintaxis (23c.24c) la va a encontrar no pocas veces en Windbg. Hace referencia a un hilo dentro de un proceso. 23c es el identificador de proceso (PID), en formato hexadecimal. En este caso es el PID del proceso Calc.exe. 24c hace referencia al identificador de hilo (TID), en formato hexadecimal también. La excepción recibida en este caso es "Break instruction" (STATUS_BREAKPOINT), identificada por el código hexadecimal 0x80000003. Vamos a ver qué ocurre "por lo bajo" para explicar por qué ha ocurrido esto:

Cuando hemos seleccionado el ejecutable Calc.exe y hemos hecho clic sobre Abrir, Windbg ha llamado a la API CreateProcess con el sexto parámetro establecido a DEBUG_PROCESS. Esto permite crear un proceso e indicarle a Windows que deseamos depurarlo. Pero depurar un proceso requiere de algo más. Requiere que el programa depurador reciba una serie de eventos procedentes de la ejecución de la aplicación y los muestre al usuario o los trate de manera conveniente. Lo que ocurre durante una sesión de depuración se puede entender como un bucle en el cual el depurador espera eventos de depuración mediante la API WaitForDebugEvent, los trata de manera conveniente, y continua la ejecución del programa mediante la API ContinueDebugEvent. Este bucle se repite indefinidamente hasta que o bien la aplicación que está siendo depurada desaparece de la memoria, o bien finaliza correctamente su ejecución, o bien desacoplamos el depurador mediante el comando Debug, Detach Debugee.

La frase (first chance) hace referencia al comportamiento de las excepciones. Cuando una aplicación genera una excepción y está siendo depurada, el depurador recibe una excepción de primera oportunidad (first chance) y le da la opción de tratarla. En este caso, el depurador trata la excepción STATUS_BREAKPOINT deteniendo la ejecución de la aplicación permitiendo que el usuario introduzca comandos o examine el estado de la imagen de memoria del proceso y el estado del procesador. Si el depurador no capturase la excepción, se comprueba si el código de la aplicación la capturara. Este procedimiento implica verificar en la pila de ejecución si hay algún código manejador de excepciones, desde el marco de activación más reciente hasta al más antiguo. Este procedimiento recibe técnicamente el nombre de stack unwinding. No se preocupe, en posteriores artículos se va a tratar la estructura de datos conocida como pila, pues es de capital importancia a la hora de entender buena parte de la información que nos proporcione Windbg. En caso de que el código no capturase la excepción, se lanza al depurador una excepción de segunda oportunidad (second chance) y se vuelve a comprobar si el código captura la excepción.

Lo que aparece a continuación en la pantalla de Windbg es el estado de los registros del procesador. Para entender esta parte de la salida es necesario disponer de ciertos conocimientos específicos de la máquina que está siendo depurada. En este caso se trata de la arquitectura x86, por lo que la referencia obligada es este documento: http://download.intel.com/design/PentiumII/manuals/24319102.PDF. Cuando veamos algunos casos de estudio verá cómo aplicar la información sobre los registros de la máquina a un caso real.

Para finalizar nos aparece la última instrucción ejecutada en el procesador antes de que se pasara el control al depurador. En este caso se trata de una instrucción dentro de la función DbgBreakPoint dentro del módulo Ntdll.dll. La instrucción en cuestión es la instrucción int 3, identificada mediante el código hexadecimal CC. Esta instrucción lanza una interrupción software. El parámetro 3 indica que ejecutaremos la posición 3 del vector de interrupciones y básicamente se enviará la excepción STATUS_BREAKPOINT al depurador, para que haga con ella lo que considere oportuno. La dirección de memoria que contiene esa instrucción es la 7c91120e (en este ejemplo particular).

Para concluir, puede configurar Windbg para que no informe de ciertos eventos (tales como la finalización de un proceso, la carga de una DLL, etc.). Para ello puede ir al menú Debug, Event Filters.

Si desea hacer uso de la línea de comandos de Windbg, el comando en cuestión es sx y sus derivados sxe, sxd, sxi, sxn. En la documentación de Windbg (Help, About) puede obtener información adicional sobre el uso de estos comandos.

En este artículo hemos aprendido a configurar Windbg para comenzar una sesión de depuración y hemos ejecutado nuestra primera aplicación dentro del depurador. También hemos aprendido qué quiere decir la información que aparece en pantalla y en qué consiste "por lo bajo" la depuración de aplicaciones y el manejo de excepciones. En la siguiente parte veremos algunos comandos para examinar el estado de la máquina y del proceso que está siendo depurado. Se detallarán también algunos aspectos de la arquitectura interna de Windows que son importantes para saber realmente lo que está pasando.

Un problema que le ocurre a no poca gente que usa Windows XP consiste en que al intentar abrir un fichero con extensión MSC (Services.msc, Diskmgmt.msc, etc.) el sistema muestra el siguiente mensaje de error:

MMC no puede abrir el archivo C:\WINDOWS\system32\services.msc.

El propio mensaje nos explica las posibles causas del problema, pero ciertamente la información que ofrece es algo vaga e inespecífica. El principal problema con el que se encuentra el usuario al recibir este mensaje de error es que, al tratarse de un mensaje de error genérico, es posible que la causa del problema que está experimentando no quede recogida en el texto del mensaje de error.

¿Cómo actuar en casos como este?

Hay muchas formas de actuar ante un mensaje de error de este estilo. Una manera consiste en observar si hay algún tipo de LOG que registre información detallada sobre el error (lo primero que debemos buscar es el código de error exacto). Es bastante probable que, de existir la posibilidad de registrar en un fichero LOG la información correspondiente a un mensaje de error, esta opción deba activarse explícitamente a través del registro del sistema operativo, o mediante algún otro método avanzado similar. En ocasiones, como último recurso para obtener información detallada sobre un mensaje de error tendremos que instalar una versión de depuración del sistema operativo o aplicación (versión checked). Las versiones checked son versiones que incorporan información detallada de depuración (trazas, aserciones, etc.) que son de mucha utilidad a los programadores de aplicaciones. De hecho, para adquirir la versión checked de un sistema operativo de Microsoft debe ser suscriptor de MSDN. Las versiones de depuración de los Service Packs sí están disponibles públicamente desde el Centro de descargas de Microsoft. Por ejemplo, este es el enlace para descargar la versión de depuración del SP3 de Windows XP.

En este artículo se va a describir un método menos complicado que puede sacarnos del atolladero en bastantes casos. De hecho, nos va a sacar del atolladero en el problema concreto que se describe más arriba.

En primer lugar, instale la última versión de Debugging Tools for Windows y configure el depurador Windbg apropiadamente. Para saber cómo hacer esto, siga los pasos de este tutorial.

A continuación, vamos a ejecutar la aplicación desde dentro del depurador. Para ello, haga clic sobre File, Open Executable. En la caja de texto Nombre, escriba lo siguiente: %SystemRoot%\system32\mmc.exe En la caja de texto Arguments, escriba lo siguiente: Services.msc (o el nombre del fichero MSC que no es capaz de abrir). Pulse Abrir.

Asegúrese de que Windbg le informe de que la información sobre los símbolos es correcta y pulse F5 (Go).

Cuando se muestre el mensaje de error en pantalla, active la ventana de Windbg y pulse Ctrl+Pausa o haga clic sobre Debug, Break.

Ahora tendrá que examinar la pila de ejecución de todos y cada uno de los hilos activos de la aplicación para ver si encuentra el código de error como parámetro de alguna de las funciones que allí aparezcan. Para cambiar de hilo, puede hacerlo gráficamente desde el menú View, Processes and Threads. Seleccione con un simple clic el hilo que quiera examinar (quedará marcado en negrita) e introduzca en la caja de texto de Windbg el comando kb para mostrar la pila de ejecución. En mi caso, esta es la pila de ejecución del hilo responsable de abrir el fichero MSC:

0:000> kb
ChildEBP RetAddr  Args to Child             
0007f030 7c91df4a 7c809590 00000002 0007f05c ntdll!KiFastSystemCallRet
0007f034 7c809590 00000002 0007f05c 00000001 ntdll!ZwWaitForMultipleObjects+0xc
0007f0d0 7e3995f9 00000002 0007f0f8 00000000 kernel32!WaitForMultipleObjectsEx+0x12c
0007f12c 6c6d4b52 00000001 0007f160 ffffffff USER32!RealMsgWaitForMultipleObjectsEx+0x13e
0007f14c 6c6d4cbd 000024ff ffffffff 00000000 DUSER!CoreSC::Wait+0x3a
0007f170 6c6d4eb9 000024ff 00000000 0007f19c DUSER!CoreSC::WaitMessage+0x40
0007f180 7e3d8e33 000024ff 00000000 00000064 DUSER!MphWaitMessageEx+0x22
0007f19c 7c91e473 0007f1ac 00000008 000024ff USER32!__ClientWaitMessageExMPH+0x1e
0007f1b0 7e399418 7e3a770a 00000000 00000000 ntdll!KiUserCallbackDispatcher+0x13
0007f1e8 7e3a49c4 000301b4 00000000 00000001 USER32!NtUserWaitMessage+0xc
0007f210 7e3ba956 7e390000 000c44f8 00000000 USER32!InternalDialogBox+0xd0
0007f4d0 7e3ba2bc 0007f62c 00000001 00000000 USER32!SoftModalMessageBox+0x938
0007f620 7e3e63fd 0007f62c 00000028 00000000 USER32!MessageBoxWorker+0x2ba
0007f678 7e3d0853 00000000 00e76008 00bafeb0 USER32!MessageBoxTimeoutW+0x7a
0007f698 7e3e6579 00000000 00e76008 00bafeb0 USER32!MessageBoxExW+0x1b
0007f6b4 4754f5fe 00000000 00e76008 00bafeb0 USER32!MessageBoxW+0x45
0007f6f0 0107a216 00e76008 00002010 00e86458 mmcbase!MMCErrorBox+0x7f
0007f740 01058ce9 00000003 80040154 00000000 mmc!DisplayFileOpenError+0x191
0007f794 0104093c 0007f748 00000004 00e6e018 mmc!CAMCDoc::OnOpenDocument+0x90
0007f7e0 5f81424a 0007fc14 00000001 00038988 mmc!CAMCMultiDocTemplate::OpenDocumentFile+0x21f

Marcada en negrita está la parte importante de la traza, el error en cuestión (0x80040154). ¿Qué quiere decir ese código de error? El propio Windbg nos lo puede decir:

0:001> !error 80040154
Error code: (HRESULT) 0x80040154 (2147746132) - Clase no registrada

Un error de clase no registrada. Para sabér qué clase es la afectada, puede usar Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), monitorizar el sistema mientras intenta volver a abrir el archivo MSC y analizar con calma los resultados NOT FOUND que hagan referencia al Registro del sistema, o bien puede seguir las pautas de este artículo referido a Explorer.exe.

Para no hacerle perder el tiempo, le diré que en este caso la clase afectada está en la librería Msxml3.dll y se puede volver a registrar con el comando regsvr32 msxml3.dll.

Otro código de error que se puede encontrar es el código 0x2 (archivo no encontrado). En este caso lo ideal es hacer uso de Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), monitorizar el sistema mientras intenta volver a abrir el archivo MSC y analizar con calma los resultados NOT FOUND que hagan referencia, en esta ocasión, al sistema de archivos. Un caso que he analizado tenía como culpable al virus Vundo, aunque en general podría tratarse de cualquier otro tipo de malware.

Una duda que quizá tenga es, ¿cómo distinguir en la salida del comando kb lo que es un código de error de lo que no? En general yo suelo descartar en primer lugar lo que seguro sé que no es un código de error. Por ejemplo, en la traza de pila del ejemplo puede ver que 7e3a770a es un valor que está cerca de las direcciones de retorno de cada una de las funciones, por lo que probablemente no sea un código de error. Los valores 00bafeb0 y similares, es decir, un número hexadecimal no muy alto, suelen ser punteros a estructuras de datos, por lo que tampoco suelen ser códigos de error. Los valores muy bajos (00000002), o que comiencen por 8 (80040154), sí suelen ser códigos de error. Por supuesto, en este caso el nombre de la función mmc!DisplayFileOpenError+0x191, nos da la pista fundamental.

Espero que este artículo les ayude a investigar a fondo los mensajes de error en Windows en los que no aparece de manera explícita el código de error. En futuros artículos verá cómo atacar un problema similar pero esta vez causado por una excepción de aplicación, o bien por una versión incompatible de una DLL en el sistema, usando para ello la aplicación Dependency Walker.

He añadido a mi página web un artículo que explica lo que ocurre cuando se ejecuta el comando Explorer.exe tanto sin parámetros como con parámetros, en sistemas XP y Vista. Se incluye toda la casuística, lista completa de parámetros soportados, cómo forzar la creación de un nuevo proceso, etc. El artículo lo puede leer en la dirección http://winvista.mvps.org/Tema.aspx?ID=233

Cualquier duda o sugerencia la puede hacer llegar a través de la sección de comentarios de esta entrada o mediante el enlace Contact de la parte izquierda del blog.

A petición de un buen número de personas que me han escrito a través del blog, he decidido comenzar un tutorial sobre depuración de aplicaciones y el sistema operativo Windows usando Windbg. A través de este tutorial espero cubrir conceptos introductorios (tales como aprender a configurar Windbg, saber qué comandos son los más destacados y para qué sirven, etc.), hasta llegar a conceptos más avanzados que impliquen la aplicación de la teoría al análisis y solución de problemas reales. Se van a tratar tanto la depuración de volcados de memoria (algo que se conoce como postmortem debugging), como la depuración de sistemas en vivo (live debugging). Al final del tutorial espero que tenga la información apropiada para abordar un problema en su máquina ejecutando algo más que el clásico comando de Windbg "analyze -v".

¿Qué es un depurador y qué tipos de depuradores hay?

El concepto de depuración en el ámbito de la computación podría describirse como un procedimiento metódico consistente en el análisis y corrección de los defectos de un sistema software o hardware. Esta sencilla descripción representa una tarea ardua y dificultosa en sí misma dada la alta complejidad de cualquier sistema computacional de hoy en día. Para poder llevarla a cabo, los ingenieros se sirven de unos programas denominados depuradores (en inglés, debuggers) que permiten, entre otras cosas, analizar un volcado de memoria, adjuntarse a un proceso (más adelante veremos en qué consiste esto exactamente), ejecutar un programa y examinar el estado de la máquina (registros, memoria, procesos en ejecución, etc.), ejecutar paso a paso una aplicación, parar la ejecución según una cierta condición, etc.

Los depuradores pueden clasificarse en dos grupos bien diferenciados:

• Depuradores en modo usuario: Este tipo de depuradores son capaces de mostrar el estado de un proceso en un determinado momento (hilos en ejecución, registros de la máquina, contenido de la memoria, etc.), es decir, el depurador tiene exactamente la misma visión de la máquina que tendría cada uno de los procesos que se estén ejecutando.
• Depuradores en modo núcleo: Este tipo de depuradores disponen de una visión completa de la máquina sobre la que se están ejecutando. Suelen utilizarse para detectar errores en controladores de sistema, pero en ciertos casos es necesario recurrir a un depurador en modo núcleo para depurar una aplicación que funcione en modo usuario.

¿Qué es Windbg?

Windbg es un completo depurador de Microsoft, tanto en modo usuario como en modo núcleo, con una intuitiva interfaz gráfica y descargable de forma gratuita desde la página http://www.microsoft.com/whdc/devtools/debugging/default.mspx. El paquete Debugging Tools for Windows incorpora un buen número de depuradores y utilidades relacionadas, y aunque este tutorial solo se vaya a centrar en el depurador gráfico Windbg mi recomendación personal es que se instale el paquete completo de Debugging Tools for Windows.

Una vez finalizada la instalación, podemos ejecutar Windbg desde Inicio, Todos los programas, Debugging Tools for Windows (x86)/(x64), Windbg. La pantalla principal tendrá un aspecto similar al de la siguiente imagen:

Lo primero que se debe hacer es configurar el depurador. El aspecto de configuración más importante de Windbg es quizá la información referente a los símbolos del código del programa que vayamos a depurar. Antes de proseguir, vamos a describir lo que es un símbolo:

Durante la fase de construcción de un fichero ejecutable a partir de su código fuente, se genera información referente a las funciones, variables, estructuras de datos, etc. usadas en dicho código. Dependiendo de los intereses del programador, esta información puede acabar embebida en el propio ejecutable o bien proporcionarse de manera separada en la forma de ficheros con extensión .pbd (si se ha usado algún compilador de Microsoft). Embeber dicha información en el ejecutable tiene como consecuencia que su tamaño se vea incrementado de manera considerable, además por información que solo es de utilidad para programadores o profesionales de soporte. Por lo tanto, la gran mayoría de compañías de software proporcionan los símbolos para la depuración de manera separada. Sin embargo, es muy probable que existan multitud de versiones de una determinada DLL o ejecutable, en cuyo caso, ¿cómo sabe el depurador qué símbolos escoger? La primera alternativa supondría indicar individualmente la ruta que apunte a los símbolos de cada una de estas versiones, algo inviable. Para dar solución a este y otros problemas, se ideó el concepto de servidor de símbolos, una máquina cuyo cometido es proporcionar los símbolos de depuración conforme el depurador los vaya necesitando. Y lo que es más importante, el servidor de símbolos mantiene una lista de símbolos indizada por nombre, tamaño, versión o cualquier otro parámetro, por lo que es capaz de ofrecer la versión apropiada de un símbolo de manera cómoda y rápida.

¿Cómo configurar la información referente a los símbolos de depuración en Windbg?

Hay que precisar que si se configura Windbg para que consiga los símbolos de depuración desde un servidor de símbolos, es necesario que el sistema tenga conexión a Internet durante todo el periodo que dure la depuración. Si esto no fuera posible, existe la alternativa de descargarse un paquete de símbolos acorde con la versión del sistema operativo que está siendo depurado desde una web de Microsoft, http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d. Sin embargo, esta opción tiene el inconveniente de que los símbolos suelen estar actualizados solo hasta el Service Pack más reciente que haya salido. Si Windows Update hubiera actualizado algún ejecutable o DLL con motivo de una actualización de seguridad, por ejemplo, es posible que el depurador no disponga de la información simbólica pertinente. En particular, si faltan los símbolos de Ntoskrnl.exe (depuración en modo núcleo) o bien Ntdll.dll, Shell32.dll o alguna otra DLL muy usada del sistema operativo (depuración en modo usuario), el análisis que hagamos no servirá para nada. Es, por tanto, muy importante que configuremos correctamente la información simbólica en Windbg.

Para configurar Windbg para que acceda al servidor de símbolos de Microsoft se pueden seguir estos pasos:

1. Abrir el menú File, Symbol File Path (o pulsar Ctrl+S).
2. Introducir en la caja de texto Symbol path lo siguiente:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

3. Pulsar OK.

Téngase en cuenta que se ha configurado como carpeta de descarga de los símbolos la carpeta C:\websymbols, pero se podría indicar cualquier otra. A continuación podemos salvaguardar la configuración que hemos realizado para que no se pierda en sucesivas depuraciones haciendo clic sobre el menú File, Save Workspace (o Save Workspace As).

Si estamos en una sesión de depuración (algo que se describirá en un posterior artículo), podemos usar comandos para configurar los símbolos adecuadamente:

.sympath

Este comando muestra la ruta que esté configurada para el servidor de símbolos.

.sympath <Ruta>

Este comando establece la ruta <Ruta> como ruta del servidor de símbolos.

.sympath+ <Ruta>

Este comando es similar al anterior pero respeta cualquier otra ruta de servidor de símbolos que pueda haber configurada con anterioridad.

.symfix <Carpeta>

Este comando nos evita tener que aprender de memoria la dirección del servidor de símbolos de Microsoft. Tan solo tenemos que indicarle la carpeta en la que queremos que se descarguen los símbolos.

.symfix+ <Carpeta>

Este comando es similar al anterior pero respeta cualquier otra ruta de servidor de símbolos que pueda haber configurada con anterioridad.

Ya hemos configurado uno de los aspectos más importantes de Windbg, la información simbólica de depuración. En el siguiente artículo veremos otros aspectos menores de configuración del depurador y aprenderemos a depurar una aplicación o proceso en modo usuario.

Cuando lea estas líneas es probable que ya pueda descargar la versión final de Internet Explorer 8 desde su web oficial: http://www.microsoft.com/windows/internet-explorer/download-ie.aspx.

Una de las dudas que creo que mucha gente tendrá es sobre cómo integrar Internet Explorer en el DVD de Windows Vista/Windows Server 2008. Al integrarlo, cuando instale Windows Vista/Windows Server 2008 automáticamente ya tendrá instalada la versión 8 del navegador de Microsoft, con la comodidad que esto supone. Los pasos a seguir están disponibles en el blog oficial de IE (http://blogs.msdn.com/ie/archive/2008/06/20/slipstreaming-ie8.aspx), lo que sigue es una mera traducción de dicho contenido, con ligeras modificaciones para adaptarlo al idioma español.

Preparación

1. Instalar el kit de instalación automática de Windows (WAIK)

El kit de instalación automática de Windows (WAIK) es una herramienta disponible para Vista y Windows Server 2008 que administra y personaliza las imágenes del sistema operativo. Esta es la herramienta que va a usar para integrar IE8. Descargue una versión de WAIK que concuerde con la configuración de su máquina local (no la imagen en la que va a integrar IE8).

Nota: No es posible usar una versión de 64 bits de WAIK para integrar IE sobre una imagen de Vista de 32 bits. Para más información, lea el fichero Readme.txt del WAIK.

2. Crear el directorio de Windows Vista

Cree en el sitio que quiera una carpeta de nombre Slipstream y, dentro de ella, un directorio VistaSP1x86es. Copie el contenido del DVD de Windows Vista en el directorio VistaSP1x86es.

3. Crear tres carpetas temporales: Mount, Pkg, Sandbox

Cree en la raíz del directorio Slipstream tres carpetas: Mount, Pkg y Sandbox.

4. Descargar Internet Explorer 8

Cree en el directorio Slipstream la carpeta IE8x86es y descargue en ese directorio Internet Explorer 8.

5. Extraer y expandir el archivo MSU

Abra una ventana de línea de comandos (Cmd.exe) y teclee este comando: <ruta del instalador de IE8> /x: <carpeta donde quiera alojar el fichero MSU>. Por ejemplo: C:\Slipstreaming\IE8x86es\IE8-WindowsVista-x86-esn.exe /x: C:\Slipstreaming\IE8x86es

Para extraer el fichero MSU, desde la ventana de línea de comandos teclee lo siguiente: expand.exe <ruta del fichero MSU de IE8> -F:* <carpeta Pkg>. Por ejemplo: expand.exe C:\Slipstreaming\IE8x86es\IE8.MSU -F:* C:\Slipstreaming\Pkg

Integración

1. Montar la imagen de instalación de Vista en el directorio temporal

En la ventana de línea de comandos, ejecute lo siguiente: imagex.exe /mountrw install.wim <número_de_imagen> <carpeta Mount>

Para este ejemplo estoy integrando IE8 en un Windows Vista Ultimate que tiene como número_de_imagen = 4. El comando que ejecuté fue "C:\Archivos de programa\Windows AIK\Tools\x86\imagex.exe" /mountrw C:\Slipstreaming\VistaSP1x86es\sources\install.wim 4 C:\Slipstreaming\Mount

Si no sabe cuál es el número de imagen de su sistema operativo, puede usar un número grande al azar en lugar del 4 del comando anterior, tal que así: imagex.exe /dir C:\VistaRTM\sources\install.wim 20. Esto hace que se muestre la información de ayuda. Busque la versión de Vista/Server 2008 que esté usando y el valor IMAGE INDEX será el valor del parámetro número_de_imagen que está buscando. 

2. Integrar IE8 en la imagen de Vista

Si está usando la versión Gold de Windows Vista (es decir, sin ningún Service Pack instalado), es necesario que cambie el atributo de solo lectura de un fichero antes de ejecutar el comando de integración: attrib -R "<Carpeta Mount>\Windows\Offline Web Pages"

Por ejemplo: attrib -R "C:\Slipstreaming\Mount\Windows\Offline Web Pages"

Ahora ya está listo para integrar IE8. Ejecute lo siguiente en la ventana de línea de comandos: pkgmgr.exe /n:<Carpeta Pkg>\WindowsVista-KB#-NEUTRAL.xml /o:"<Carpeta Mount>;<Carpeta Mount>\windows" /s:<Sandbox> /l:<Sitio donde quiera que se genere el fichero de LOG>. Asegúrese de que el ejecutable Pkgmgr.exe que utilice sea el incluido en el WAIK.

Por ejemplo: "C:\Archivos de programa\Windows AIK\Tools\x86\Servicing\pkgmgr.exe" /n:"C:\Slipstreaming\Pkg\Windows6.0-KB944036-x86.xml" /o:""C:\Slipstreaming\Mount";"C:\Slipstreaming\Mount\windows"" /s:"C:\Slipstreaming\Sandbox" /l:"C:\Slipstreaming\Slp.log"

Una vez que el comando de integración finalice correctamente, el fichero Slp.log contendrá la línea "exit code 0x00".

Recuerde establecer de nuevo el atributo de solo lectura una vez que haya finalizado la integración (solo si usa Windows Vista Gold, es decir, sin ningún Service Pack instalado): attrib +R "<Carpeta Mount>\Windows\Offline Web Pages"

Por ejemplo: attrib +R "C:\Slipstreaming\Mount\Windows\Offline Web Pages"

3. Guardar los cambios

Use Imagex.exe para guardar los cambios: imagex /commit /unmount <Carpeta Mount>

Para este ejemplo: "C:\Archivos de programa\Windows AIK\Tools\x86\imagex.exe" /commit /unmount c:\Slipstreaming\Mount

Y con esto ya habrá integrado IE8 en su imagen de Windows Vista. Ya solo tiene que crear un DVD con dicho contenido. Como IE8 es parte de la imagen de Vista, puede personalizarlo creando un fichero Answer.xml y ejecutando el programa de instalación de Vista con la opción desatendida, tal como: <Carpeta Vista>\setup.exe /unattend:<Carpeta del fichero Answer.xml>

Enlaces relacionados:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=728ab2c8-8000-4888-8f62-340223d01fe0

En este artículo se va a describir el arranque de los sistemas operativos Windows Vista y Windows 7. Antes de comenzar, es necesario que veamos unas pinceladas del arranque de sistemas operativos anteriores, para poner el nuevo sistema de arranque en contexto.

El proceso de arranque en Windows XP y anteriores

El proceso de arranque comienza cuando la BIOS de la máquina lee el primer sector del disco duro. Este sector (el sector de arranque), típicamente contiene una porción de código denominada MBR (Master Boot Record), pero podría contener cualquier otro código ejecutable. En sistemas Windows XP y anteriores sistemas NT, dicho código apunta al fichero Ntldr mediante una cadena de tipo Unicode situada en una posición fija de dicho primer sector del disco duro. El archivo Ntldr es el encargado de leer el fichero Boot.ini, que contiene información importante sobre los sistemas que están instalados y cómo se debe arrancar cada uno de ellos. Si procede, Ntldr muestra al usuario una lista de sistemas operativos para que elija alguno mediante las flechas de dirección.

La nueva arquitectura de arranque

El problema principal de este esquema primitivo de arranque es que se trata de un esquema enormemente dependiente del hardware. Este problema se hizo patente cuando Intel desarrolló, a mediados de los años 90, una nueva especificación para sus máquinas Itanium, con el objetivo de evitar las limitaciones impuestas por el ya vetusto sistema PC BIOS. Esta especificación se denominó EFI (Extended Firmware Interface) y básicamente consiste en una interfaz entre el sistema operativo y el firmware de la máquina. EFI soporta tanto el esquema clásico de particiones basado en MBR como el nuevo esquema GPT (Guid Partition Table). La principal ventaja de este nuevo esquema es que no se ve afectado por las limitaciones de MBR, tales como el límite de 4 particiones primarias por disco y los 2TB como máximo por partición.

Con la salida al mercado de Windows Vista, Microsoft introdujo un nuevo almacén de configuración de arranque denominado almacén BCD (Boot Configuration Data). Podríamos decir que este almacén realiza las mismas funciones que el fichero Boot.ini realiza en sistemas Windows XP o anteriores. La diferencia fundamental reside en que el almacén BCD es independiente del hardware y es capaz de arrancar tanto sistemas PC BIOS tradicionales como sistemas basados en EFI. En el futuro podría darse soporte a nuevos esquemas de arranque.

La arquitectura del BCD está formada por tres componentes bien diferenciados: almacén BCD, objeto BCD y elemento BCD.

Almacén BCD

El almacén BCD es un contenedor de objetos BCD, entidad que a su vez contiene elementos BCD. Físicamente es un fichero binario con una estructura similar a los ficheros binarios que representan ramas del Registro del sistema. Su nombre es BCD y está situado en el directorio \Boot (en un sistema PC BIOS) o \EFI\Microsoft\Boot (en un sistema EFI) de la partición activa del disco. 

Objetos BCD

Por defecto, el almacén BCD contiene los siguientes objetos BCD:

• Administrador de arranque de Windows: Este objeto contiene entradas correspondientes a cada uno de los sistemas operativos instalados en la máquina. También existen parámetros adicionales, tales como el tiempo de espera hasta que se seleccione la entrada por defecto de dicho menú o la ordenación de la lista de sistemas operativos. Podríamos decir que este objeto BCD reemplaza la funcionalidad de la porción [boot loader] del fichero Boot.ini.
• Cargador de arranque de Windows: Existe un objeto BCD de este tipo por cada sistema Windows Vista/Windows 7 que esté instalado en el equipo. Se podría decir que este objeto reemplaza la funcionalidad de la sección [operating systems] del fichero Boot.ini.
• Ntldr: Este objeto BCD es opcional y contiene la información necesaria para arrancar sistemas Windows XP o anteriores. Nótese que el fichero Ntldr no sirve para nada en Windows Vista/Windows 7, excepto para arrancar sistemas anteriores.

Además de estos objetos BCD, las aplicaciones pueden crear sus propios objetos utilizando la interfaz de programación del almacén BCD. Por ejemplo, la utilidad de comprobación de memoria RAM incluida en el entorno de recuperación de Windows Vista/Windows 7 programa un análisis de RAM mediante el ejecutable Mdsched.exe, que crea un nuevo objeto BCD que apunta al ejecutable \Boot\Memtest.exe (en sistemas PC BIOS) o \EFI\Microsoft\Boot\Memtest.efi (en sistemas EFI). Otras aplicaciones de terceros podrían crear sus propios objetos en el BCD.

Elementos BCD

Los elementos BCD guardan los parámetros de configuración de cada uno de los objetos BCD. Estos parámetros, como ya se ha comentado, pueden ser la existencia de un depurador de kernel, el sistema operativo que iniciará por defecto, si se han activado las PAE (Physical Address Extensions), etc.

Este diagrama proporciona una visión global de la arquitectura del BCD:

Cada uno de los objetos BCD anteriores enlaza con un ejecutable diferente. Como ya se comentó, el objeto BCD correspondiente al análisis de memoria RAM enlaza con el ejecutable Memtest.exe o Memtest.efi. La entrada correspondiente al arranque de un sistema Windows Vista/Windows 7 enlaza con el ejecutable Winload.exe o Winload.efi, encargado de inicializar el núcleo del sistema operativo mediante Ntoskrnl.exe y cargar algunos controladores de arranque. Si el sistema hibernó por última vez, un objeto BCD apuntará al ejecutable Winresume.exe o Winresume.efi, que es el encargado de reanudar el sistema operativo para dejarlo tal cual estaba antes de ser hibernado.

¿Qué hace la herramienta Reparación de inicio si se encuentra con algún problema?

Si alguna de las estructuras comentadas anteriormente se ha dañado, el sistema no podrá arrancar. La herramienta Reparación del inicio habrá obtenido toda la información mediante su conjunto inicial de pruebas. Si la tabla de particiones, sector de arranque o almacén BCD estuviera dañado, el ejecutable BCDMD (Boot Critical Disk Meta-data Repair) se encarga de regenerar toda esta información. Esta herramienta básicamente realiza un análisis en busca de sistemas operativos, a la vez que compara esta información con la residente en el almacén BCD. Si la información del BCD no fuera coherente, esta herramienta es capaz de modificarla para que lo sea. Si los ficheros Winload.exe o Bootmgr no estuvieran o estuvieran dañados, Reparación de inicio puede recuperarlos en ciertas circunstancias, como ya vimos, mediante el comando Bfsvc.exe /nosetupcheck.

Otro de los problemas que puede afectar al arranque del sistema, como ya vimos, es una corrupción de los ficheros de sistema o bien un problema de permisos sobre ciertos ficheros importantes. Para el primer caso, Reparación del inicio ejecuta el comando Sfc.exe, cuyo funcionamiento se describió en un anterior artículo. Para el segundo caso, la herramienta reconstruye los permisos correctos, teniendo en cuenta que los ficheros del sistema operativo tienen una serie de permisos por defecto, para evitar su accidental eliminación o sobreescritura.

Si el Registro resultara estar corrupto, se puede recuperar a partir de la copia de seguridad del directorio %windir%\system32\config\RegBack. Si dicha copia tampoco estuviera en buen estado, se recurre a la copia con extensión .old que hay en el mismo directorio. Sin embargo, ante una corrupción del Registro la restauración del sistema se intenta aplicar siempre en primer lugar. El motivo es claro, las ramas de Registro del punto de restauración probablemente serán más recientes que las que hay en la carpeta RegBack. Solo se recurre a esta carpeta si no hubiera puntos de restauración disponible o estos no hubieran solucionado el problema.

Haciendo referencia a los puntos de restauración, la herramienta elige el más reciente que sea anterior a la causa que ha producido el fallo. Por ejemplo, si el usuario instaló un controlador y el sistema dejó de iniciar, Reparación del inicio intentará usar el punto de restauración más reciente anterior a la instalación del controlador. Para el caso de un Registro corrupto, la herramienta prueba con el punto de restauración más reciente que haya disponible.

Espero que toda esta información sobre el arranque de Windows Vista/Windows 7 y la herramienta Reparación del inicio les sirva para comprender un poco mejor cómo arranca el sistema operativo, qué estructuras están asociadas al arranque, qué problemas pueden surgir y cómo los aborda la herramienta de Reparación del inicio.

(Esta entrada ha sido programada. Daniel está en estos momentos en Redmond, Washington).

Aunque Internet Explorer no sea algo que conozca en profundidad, últimamente mucha gente me ha estado enviando mensajes indicando que su navegador se bloquea a menudo. He estado analizando por encima el volcado de memoria de un sistema afectado y al parecer el complemento Adobe Flash es el presunto culpable. De hecho, desactivando dicho complemento en IE, desde Herramientas, Administrar complementos, se ha solucionado el 100% de los casos que he tratado. Otra sugerencia que ha resultado útil consiste en desinstalar la versión 10 de Adobe Flash y a continuación instalar la versión 9. Así que si ha llegado a esta página buscando información sobre un cuelgue de Internet Explorer, espero que esta información le resulte útil.

Buscando en la web de Adobe, he visto que se trata de un posible bug que ya está siendo analizado, pero aún no hay solución: http://bugs.adobe.com/jira/browse/FP-1145.

Si conoce alguna web con contenido Flash que haga que el navegador se cuelgue con frecuencia, o si ha logrado obtener unos pasos que reproduzcan el problema de manera consistente, le agradecería que contactara conmigo ya sea a través de la sección de comentarios de esta entrada o a través de la página Contact de la parte izquierda de este blog. Gracias de antemano.

Actualización 25/02/2009: Gracias a todos por la información. El problema ya está solucionado en la nueva versión de Adobe Flash Player que se puede descargar desde http://get.adobe.com/flashplayer.

Ayer a las 12 del mediodía (hora de Redmond), Microsoft anunció cuáles serán las ediciones de su nuevo sistema operativo, Windows 7. En resumen, las dos ediciones más apropiadas para el segmento de consumo serán Windows 7 Home Premium y Windows 7 Professional. Esta última estará orientada a profesionales y pequeñas empresas que utilicen Windows Vista Business y quieran migrar a Windows 7.

El resto de ediciones serán Windows 7 Home Basic, que solo estará disponible en mercados emergentes (Asia, África y Latinoamérica); Windows 7 Starter, disponible en todo el mundo pero limitada su distribución a los OEM; Windows 7 Enterprise, para empresas, y Windows 7 Ultimate, que, como en el caso de Windows Vista, contendrá todas las funcionalidades del sistema operativo. Aún no se sabe nada de los precios de cada una de ellas.

Puede obtener más información en esta entrevista realizada a Mike Ybarra, general manager de Microsoft: http://www.microsoft.com/presspass/features/2009/feb09/02-03Win7SKU-QA.mspx

En la parte primera de esta serie de artículos sobre la herramienta Reparación de inicio de Windows Vista se trató con detalle el conjunto de pruebas iniciales que realiza esta aplicación, así como las conclusiones que extrae en función de los signos experimentados en el sistema. Estas pruebas iniciales se centran principalmente en la primera fase del arranque del sistema operativo, pues lo más normal es que si hay un problema que impida que un equipo se inicie, tenga que ver con el disco en sí, con el MBR, con la tabla de particiones, con el sector de arranque, etc.

A continuación se comentará sobre el resto de comprobaciones que siguen a las pruebas iniciales si estas no han dado con una posible causa.

Pruebas adicionales

Como ya vimos, si el sistema no ha sido capaz de iniciarse y tanto el administrador de arranque como el cargador de arranque de Windows Vista no han reportado ningún error, es de suponer que el problema probablemente esté encuadrado en alguna fase posterior del arranque del sistema operativo. Si se detecta que ha sucedido una pantalla azul (bugcheck), la herramienta trata de realizar un análisis rudimentario del volcado de memoria resultante. Si no es capaz de extraer ninguna conclusión, supone sencillamente que es un controlador mal diseñado el culpable del problema.

En el caso de que no haya sucedido ninguna pantalla azul durante el último intento de arranque, el siguiente conjunto de pruebas tiene como objetivo detectar un posible fallo que anterior a la inicialización del sistema de ficheros. Un fallo de este tipo por lo general tiene que ver con permisos incorrectos sobre ficheros importantes del sistema operativo, o bien con un sistema de archivos corrupto. En el primer caso, lo que se hace es comparar los permisos de los ficheros de los directorios %windir%\system32 y %windir%\system32\drivers con los permisos originales tras una instalación limpia de Windows Vista. Los permisos originales sobre ficheros de sistema en Windows Vista son un tanto peculiares; esto tiene que ver con la característica WRP (Windows Resource Protection), que se tratará en un posterior artículo. La corrupción en el disco se analiza con la conocida herramienta Chkdsk.

Si las pruebas anteriores no sacan nada en claro, Reparación de inicio investiga si el usuario ha instalado alguna actualización o algún controlador tras el último inicio correcto del sistema. Para ello repasa los eventos del Visor de sucesos, físicamente disponible en la ruta %windir%\System32\winevt\Logs. Si se ha instalado un controlador y/o actualización, la herramienta supone automáticamente que es la causa del problema, sin realizar más pruebas.

Y con esto finalizan las pruebas que realiza la herramienta Reparación de inicio en Windows Vista y Windows Server 2008. Si tras todas las comprobaciones no se hubiera dado aún con el culpable, el sistema registra este hecho e intentará una restauración del sistema como último recurso.

En el siguiente artículo de la serie se tratarán los arreglos que realiza la herramienta Reparación de inicio, según el problema que haya detectado. Será un artículo en el que también se explique detalladamente el arranque de Windows Vista, que ha cambiado bastante con respecto a sistemas NT anteriores (XP, 2000, NT).

El caso de hoy es el de un sistema Windows Vista en el que no era posible instalar el componente IIS (Internet Information Server), que sirve para publicar páginas web tanto local como remotamente y es un requisito previo a la instalación de algún que otro programa, como por ejemplo Virtual Server. Para instalar componentes opcionales en Vista, como sabrá, hay que ir a Panel de control, Programas, Instalar o desinstalar componentes de Windows.

El mensaje de error que aparecía era el siguiente:

Una de las primeras cosas que hay que examinar cuando hay problemas para instalar un componente de Windows, un paquete de idiomas, una actualización, un Service Pack, etc. es el fichero C:\Windows\Logs\CBS\CBS.log. Es posible que el registro sea bastante extenso y por ello se haya creado un fichero CBS.persist.log con las entradas más antiguas. En tal caso, es posible que tengamos que examinar este fichero también.

Buscando en el fichero de abajo hacia arriba, encontré el error que probablemente estaba abortando la instalación:

2008-12-23 11:57:34, Error                 CSI    00000012@2008/12/23:10:57:34.500 (F) d:\rtm\base\wcp\sil\silp.h(2661): Error STATUS_INVALID_PARAMETER originated in function Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes expression: Valid flags check failed: Attributes
[gle=0x80004005]

Estas líneas quieren decir que ha fallado la comprobación de parámetros de una función del servicio de componentes de Vista. Concretamente la función es SetAttributes, que probablemente tenga como objetivo aplicar ciertos atributos sobre un fichero. La parte "[gle=0x80004005]" (gle es la función GetLastError) quiere decir que el último error surgido durante la ejecución de dicha función es un error HRESULT que básicamente quiere decir que el error es inespecífico. Obviamente necesitaba información mucho más útil, así que examiné el reporte a partir de ese punto y me encontré con esta línea, mucho más interesante:

2008-12-23 11:57:34, Error                 CSI    00000011 (F) STATUS_INVALID_PARAMETER #3228437# from Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes(Attributes = 2048 (0x00000800))[gle=0xd000000d]

El error 0xd000000d quiere decir STATUS_INVALID_PARAMETER pero, ¿qué atributos se le estaba pasando a la función? El valor Attributes = 2048 (0x800 en hexadecimal) nos da la clave. Una búsqueda en el fichero Winddk.h del DDK de Windows devolvió el siguiente resultado:

#define FILE_ATTRIBUTE_COMPRESSED         0x00000800

Como ve, el atributo que se estaba pasando es el atributo comprimido. La compresión de ficheros es una característica del sistema de ficheros NTFS y no tiene nada que ver con los archivos .zip o .rar. Ya estaba cerca de desvelar el misterio, pero para poder aplicar una solución necesitaba saber qué fichero o ficheros estaban involucrados en el error. Observando minuciosamente el fichero CBS.log me encontré con esa información:

2008-12-23 11:57:49, Info                  CSI    00000013 Error STATUS_INVALID_PARAMETER while executing operation SetFileInformation on [l:138{69}]"\??\C:\Windows\System32\inetsrv\config\schema\FX_schema.xml, N/A, N/A"

Hay que tener en cuenta que el fichero FX_schema.xml no había sido servido aún al directorio C:\Windows\System32\inetsrv\config\schema\ (directorio de instalación de IIS), pues la instalación no pudo completarse, por lo que le indiqué al usuario que acudiera al almacén de componentes (C:\Windows\winsxs) y buscara allí el componente que contuviera ese fichero FX_schema.xml. El usuario me informó de dos resultados:

amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6000.16386_none_6ad14c4c7044b7ae (estaba sin comprimir)
amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6001.18000_none_6d080e486d2fc882 (comprimido, es decir, en color azul).

El primer resultado es el componente instalado por la versión RTM de Windows Vista; el segundo es el instalado por el Service Pack 1.

Así pues, el usuario descomprimió la segunda carpeta desde el panel de propiedades, botón Opciones avanzadas, y ya pudo instalar IIS.

¿Por qué estaba comprimida esa carpeta? Ciertamente lo desconozco, pero mi opinión es que algún software o el propio usuario lo hizo con el objetivo de ahorrar espacio en disco debido al elevado espacio en disco consumido por el directorio C:\Windows\winsxs en Windows Vista. Como puede leer en este blog del equipo de Windows, el espacio realmente ocupado es mucho menor y, como ya pudo comprobar, comprimirlo puede tener como consecuencia no poder instalar un componente de Windows.

¡Caso cerrado!

Hoy he recibido de Microsoft el galardón MVP por cuarto año consecutivo. Para mí es un honor formar parte de ese selecto grupo de profesionales de todo el mundo y haber aprendido tanto de ellos como de los grupos de producto de Microsoft Windows. Espero seguir participando regularmente en las comunidades técnicas y aportar contenido interesante tanto en mi blog como en mi página web.

Como el día de hoy es una fecha señalada, aprovecho para felicitar el nuevo año 2009 a los lectores de mi blog.

No es extraño encontrarse de vez en cuando con un sistema operativo que ni siquiera es capaz de arrancar. En esos casos el usuario, al no tener apenas nada para poder operar y tratar de solucionar el problema, suele recurrir a un servicio técnico o bien reinstala el sistema operativo. Para evitar situaciones como ésta, Microsoft incorporó en Windows Vista una nueva herramienta especializada en el diagnóstico y la solución de la mayoría de problemas que afectan al correcto arranque del sistema: Reparación de inicio (Startup Repair). ¿Pero qué hace exactamente esta herramienta? ¿En qué casos nos podría servir y en cuáles no? Explicar en detalle el funcionamiento de la herramienta es el motivo de este artículo.

Introducción

Reparación de inicio consiste gráficamente en un asistente implementado en el ejecutable StartupRep.exe del directorio \Windows\System32. Para poder iniciar la herramienta es necesario que el equipo arranque en el entorno de recuperación de Windows (Windows Recovery Environment). Este entorno es la evolución de la Consola de recuperación presente en Windows anteriores. Para iniciar el sistema dentro del entorno de recuperación, hay que arrancar el sistema desde el DVD de Vista y seleccionar Opciones de recuperación del sistema. En la lista de herramientas disponibles, la primera es Reparación de inicio.

La aproximación que sigue la herramienta Reparación de inicio es la que seguiría un médico que está atendiendo a un paciente. Cuenta con una batería de comprobaciones para tratar de averiguar la causa del problema que está provocando que el sistema no arranque. Una vez determinada la o las posibles causas, la herramienta incorpora una serie de reparaciones que podrían solucionar el problema. Si la primera no lo soluciona, se pasa a la siguiente, y así sucesivamente. El orden de aplicación de las soluciones es algo que también decide la herramienta en función de los métodos aplicados con anterioridad y del tipo de problema que el usuario está experimentando.

Las comprobaciones que realiza la herramienta podrían dividirse en dos grandes grupos: Unas pruebas iniciales, centradas en las fases iniciales del arranque de la máquina, y una serie de pruebas más avanzadas, que solamente se realizan si las pruebas iniciales no han dado con la causa del problema. Las reparaciones que se realizan una vez finalizado el diagnóstico son tema de un próximo artículo.

Pruebas iniciales

Inicialmente, Reparación del inicio intenta detectar cuál es el disco de sistema (recuerde que éste es el disco que contiene los ficheros de arranque) y analiza, basándose en la tecnología SMART del disco, si hay algún tipo error. Un fallo en este punto es un fallo de hardware y el usuario probablemente tendrá que reemplazar físicamente el disco o su cable.

Seguidamente Reparación de inicio procede a analizar el disco en profundidad; dos son las estructuras que deben estar en perfecto estado para que el sistema arranque correctamente: la tabla de particiones y el sector de arranque de la partición de sistema. Si por algún motivo no se pudiera encontrar la partición de sistema, esto suele ser síntoma de que la tabla de particiones está dañada. Si se encontrara dicha partición pero no fuera legible, es posible que su sector de arranque esté corrupto. Asimismo es importante que la partición de sistema contenga dos ficheros críticos para el arranque: Bootmgr y Boot.ini.

El siguiente punto a comprobar es que haya un sistema operativo en el disco. Para ello se examina el almacén BCD del disco. Este almacén contiene la información necesaria para saber qué sistemas arrancar y cómo arrancarlos. Parte de la información de este almacén se almacenaba en el fichero Boot.ini en versiones anteriores de Windows. Una vez encontrado el sistema operativo, se comprueba la consistencia de los directorios más importantes del mismo, tales como System32, System32\drivers, System32\config, etc. Por supuesto, el sistema operativo debe ser Windows Vista o Windows Server 2008. Reparación de inicio no es compatible con versiones anteriores de Windows.

El fichero Bootmgr de la partición de sistema es el administrador de arranque de Windows Vista y es un archivo crítico para que el sistema arranque correctamente. Si dicho fichero estuviera corrupto, Windows puede recuperarlo copiando de nuevo los archivos de arranque desde una carpeta de origen. El ejecutable Bfsvc.exe es el encargado de hacer esto. Concretamente, Reparación de inicio llama a Bfsvc.exe mediante la siguiente sintaxis: Bfsvc.exe /nosetupcheck. El parámetro /nosetupcheck sirve para que Bfsvc.exe se ejecute incluso si el sistema está en proceso de instalación. Lo que hace Bfsvc.exe es básicamente copiar los archivos de arranque desde el directorio de orígen, que típicamente es C:\Windows\Boot.

Si aún no se hubiera encontrado la posible causa del problema, se examina el fichero Bootstat.dat, un fichero que, entre otras cosas, registra los inicios y apagados incorrectos del equipo. Es el encargado, por ejemplo, de hacerle saber al código de arranque de Windows que el sistema se apagó incorrectamente para así mostrar por defecto la pantalla de opciones de inicio avanzadas.

Reparación de inicio también verifica la consistencia de las ramas del registro, por si hubiera algún tipo de corrupción. Las ramas del registro residen en el directorio \Windows\System32\config y son las siguientes: SYSTEM, SOFTWARE, COMPONENTS y SAM. Como veremos en un posterior artículo, hay varias formas de recuperar un registro corrupto en Windows Vista, y la herramienta sabrá decidir qué método aplicar en cada caso. La rama COMPONENTS es nueva en Windows Vista y registra información relacionada sobre los componentes instalados en Windows Vista. Como esta información tiene que ir en sincronismo con el almacén de componentes (%windir%\winsxs), hay que tener cuidado a la hora de determinar si se debe reparar esa rama del registro o no.

Por último, si aún no se hubiera encontrado una causa del fallo tras todas las pruebas anteriores, es posible que el sistema sea incapaz de arrancar porque cíclicamente aparece una pantalla azul. Si fuera el caso, Reparación de inicio es capaz de extraer la información del volcado, residente en el archivo de paginación, y realizar un análisis básico para determinar al culpable. Por análisis básico se entiende que no se trata de un humano que está analizando el volcado de memoria, sino que únicamente se incorpora una correspondencia bastante simple entre algunos códigos de error grave (bugchecks) y su causa probable. Por ejemplo, el bugcheck MACHINE_CHECK_EXCEPTION (0x9C) suele ser indicativo de un módulo de RAM dañado, por lo que es probable que ante este código de error Reparación de inicio decida analizar la memoria RAM en el siguiente reinicio mediante el ejecutable Memtest.exe. Otro código de error con causa bastante conocida es el KERNEL_STACK_INPAGE_ERROR (0x77), cuyo causante principal es un error físico en el disco (salvo cuando el primer parámetro es 0, 1 ó 2, puede ver la descripción de este bugcheck en MSDN). Como podrá adivinar, ante este código de error es muy probable que el tratamiento consista en analizar el disco con el comando Chkdsk.

Si del código de error no se pudiera sacar nada en claro, la herramienta supone que el culpable del pantallazo azul es un controlador mal diseñado.

Una vez realizadas todas las pruebas iniciales, se anotan las posibles causas que se han detectado y se intenta reparar el problema siguiendo los métodos que se presentarán en un posterior artículo, junto con un conjunto adicional de pruebas, donde es menos probable que se detecte algún fallo pero que se ejecutan si el conjunto inicial de pruebas no hubiera detectado ninguna anomalía en el equipo.

Este diagrama de flujo resume el proceso de análisis básico de problemas de arranque:

El artículo de hoy trata de una consulta bastante interesante sobre Windows XP que he recibido. En resumen, el usuario preguntaba si es posible organizar el contenido de una carpeta usando apartados, de manera similar a como está organizado por defecto Mi PC. En este artículo describo algunas alternativas para lograr esto.

La opción para organizar el contenido de una carpeta en apartados está presente en el menú Ver, Organizar iconos, Organizar en grupos. El criterio que se emplee para agrupar se establece también desde dicho submenú y puede incluir el nombre, el tipo, el tamaño total, etc. Cabe destacar que existe una serie de parámetros adicionales en el menú Ver, Seleccionar detalles. Simplemente marque las casillas correspondientes a los parámetros que desee añadir y ya estarán disponibles para ser seleccionados desde el submenú Organizar iconos.

Quizá el atributo más flexible sea el atributo Comentarios, que permite añadir un texto emergente a una carpeta. ¿Cómo se añade dicho texto? Debe crear (o modificar) un fichero oculto y de sistema con el nombre Desktop.ini que tenga, como mínimo, este contenido:

[.ShellClassInfo]
InfoTip=Mi comentario

Para que Explorador de Windows tenga en cuenta esta personalización, la carpeta debe tener aplicado el atributo de solo lectura (o de sistema). El comando Attrib.exe logra esto a través de las sintaxis, respectivamente:

attrib +r NombreCarpeta

attrib +s NombreCarpeta

¿Qué ocurre si ninguna de las opciones del cuadro Seleccionar detalles nos convence? Es posible que queramos añadir información relativa a la propia carpeta, como su tamaño, por ejemplo. Para ello podemos crear una extensión de shell, concretamente del tipo column handler (manejador de columna). Windows no incluye ninguna columna que muestre el tamaño de una carpeta, ya que dicho cómputo es una tarea costosa, sobre todo si la carpeta reside en un servidor remoto. Sin embargo, sí existen en la red manejadores de columnas de terceros, por lo que en principio sería posible agrupar carpetas según su tamaño. Una de estas herramientas es Folder Size for Windows.

Si se animara a desarrollar manejadores de columnas, le recomiendo echar un vistazo a la documentación presente en el sitio web de MSDN: Creating Column Handlers.

Una de las novedades más notables de Windows 7 es la nueva configuración de particiones que aplica por defecto. Cuando Windows 7 se instala en un disco recién formateado, automáticamente crea una partición de 200 MB, la marca como activa y no le asigna una letra de unidad. Esta captura de pantalla refleja esto:

Lo primero de todo aclarar un poco la nomenclatura, que resulta algo confusa: La primera partición de la imagen se denomina partición de sistema y contiene los archivos que sirven para que Windows 7 arranque correctamente. La otra partición se denomina partición de arranque y contiene el resto de archivos del sistema operativo.

¿Qué beneficios conlleva separar la partición de arranque de la partición de sistema?

Tener una partición separada para los ficheros de arranque es beneficioso puesto que facilita la instalación de múltiples sistemas operativos, sobre todo si unos son de la rama Windows NT (Windows NT, 2000, XP, Vista) y otros de la rama Windows 9x (Windows 95, 98, ME) ya que estos últimos no soportan el sistema de archivos NTFS. Otro motivo por el cual es beneficioso tener particiones separadas es que algunos virus y malware (aunque cada vez menos) suponen que el sistema operativo reside en la unidad C. Al tener los archivos del sistema operativo en otra partición, el código del virus fallará.

Sin embargo, el motivo principal por el cual Microsoft ha adoptado esta medida es que ciertas herramientas relacionadas con el almacenamiento requieren una configuración de particiones en la que la unidad de arranque esté separada de la unidad de sistema. Una de estas herramientas es Bitlocker, ya presente en las ediciones Ultimate y Enterprise de Windows Vista. Bitlocker requiere una partición de sistema separada de la partición de arranque para poder cifrar correctamente el contenido de un volumen.

¿Puedo configurar en algún sitio que esa reserva de 200 MB sea menor?

No es posible, pero Microsoft espera reducir el tamaño de la partición de sistema en posteriores versiones de Windows 7 (tenga en cuenta que aún no está ni en fase beta).

¿Se puede evitar la creación de dos particiones de alguna manera?

Si durante la instalación Windows 7 detecta que la partición donde se va a instalar es la partición activa, los ficheros de arranque y el resto de archivos del sistema operativo se almacenarán en una única partición. Sin embargo, por todo lo comentado más arriba, es altamente recomendable indicar que se instale en una partición no activa para que los archivos de arranque se instalen en otra partición separada (la partición activa).

Es importante comentar que la creación de dos particiones es una posibilidad que ya estaba presente en Windows Vista, con tres diferencias con respecto a Windows 7: No era la configuración por defecto, la partición de sistema sí recibía una letra de unidad y el tamaño de dicha partición era bastante elevado (1,5 GB). Por último comentar que si tiene Windows Vista y los archivos de arranque y de sistema residen en una misma partición, puede separarlos en dos particiones usando la herramienta Bitlocker Drive Preparation.

Si usa Windows XP es posible que en alguna ocasión se haya encontrado con el siguiente mensaje de aviso:

Win 16 Subsystem no tiene suficientes recursos para que continúe ejecutándose. Haga clic en Aceptar, cierre sus aplicaciones y reinicie su equipo.

¿Qué quiere decir exactamente este mensaje? Básicamente, es la consecuencia de una desacertada decisión de diseño que Microsoft tomó hace décadas y que provocó una serie de fallos descubiertos poco tiempo antes de la salida al mercado de Windows XP. Este artículo indagará un poco en este tema tan curioso.

Un poco de historia

Windows incorpora desde sus comienzos una interfaz que permite a los programadores diseñar elementos gráficos para sus aplicaciones. Esta interfaz recibe el nombre de GDI (Graphics Device Interface). Ya desde Windows 3.1, Microsoft supuso que GDI solamente podría generar handles de tamaño menor de 16 K. En aquellos tiempos, los handles se implementaban en el montón (heap) de GDI y estaban limitados a 14 de los 16 bits posibles. Es decir, los dos últimos bits estaban reservados (el último bit siempre era cero porque las direcciones de memoria tenían que ser pares). Con la llegada de los 32 bits, llegó GDI32 y con él los handles pasaron a ocupar una palabra de longitud: La mitad inferior contenía el valor en sí y la mitad superior una serie de bits para dar unicidad al handle.

Como supongo que ya sabrá, los sistemas operativos Windows de 32 bits incorporan un subsistema de 16 bits encargado de hacer funcionar aplicaciones antiguas de 16 bits. Este subsistema recibe el nombre de WoW (Windows on Windows). Obviamente, dicho subsistema tiene que tener alguna manera de convertir un handle GDI de 32 bits a uno de 16 bits y viceversa. Hasta la llegada de Windows XP lo que se había venido haciendo es simplemente descartar la mitad superior, quedarse con la mitad inferior y desplazarla dos posiciones hacia la izquierda. Como los handles eran menores de 16 K, el desplazamiento no suponía pérdida de información y todo funcionaba a pedir de boca... hasta que llegó Windows XP.

Con Windows XP empezaron los problemas

Con la llegada de Windows XP, surgió la necesidad de tener handles GDI de tamaño superior a 16 K. Por este motivo, el equipo de GDI decidió utilizar completamente los 16 bits de la parte inferior del handle (recuerde que hasta entonces solo se usaban 14 bits). El problema, como puede empezar a vislumbrar, sucedía cuando un handle de tamaño mayor de 16 K tenía que ser convertido por la máquina virtual de 16 bits. Al hacer el desplazamiento de los bits, ya sí se perdía información, y los efectos negativos no tardaron en aparecer.

Este problema se descubrió en una fase muy tardía de la beta de XP, por lo que Microsoft no tuvo otra opción que implementar rápidamente una solución temporal: Concretamente decidió que, antes de convertir, se comprobara el tamaño del handle; si éste fuese superior a 16 K, se mostraría el mensaje de aviso del principio de este artículo y se finalizaría la ejecución de la máquina virtual de 16 bits. La solución adoptada en Windows Vista y Windows Server 2008, ya con tiempo suficiente para comprobarla exhaustivamente, consiste en una tabla de correspondencias entre handles de 32 bits y handles de 16 bits.

Es curioso ver que una solución válida durante un determinado contexto temporal (desplazamiento de bits para convertir handles de 32 bits a 16 bits, y viceversa) puede ser totalmente errónea en el momento que se introduzca algún tipo de "ampliación" con la que no se contaba en ese momento. La implementación desde un principio de la tabla de correspondencias habría ahorrado un buen número de usuarios disgustados por la solución temporal.

Ya como curiosidad final, y esto ya es más una opinión personal, si se da cuenta, la cadena de texto en español contiene la nomenclatura inglesa ("Win 16 Subsystem"), cuando el resto de cadenas de Wow32.dll que hacen referencia a este concepto usan su acertada traducción al español, "Subsistema Windows de 16 bits". Ésta podría ser otra prueba más de que la implementación de esta solución temporal llegó muy, pero que muy tarde en el ciclo de desarrollo de Windows XP.

Este martes 27 de octubre, Microsoft dio a conocer en la conferencia PDC una versión "pre-beta" de lo que será su próximo sistema operativo, Windows 7. A estas alturas del ciclo de desarrollo aún es pronto para ver lo que nos va a ofrecer el nuevo sistema, si bien es claro que no representará un cambio tan importante como lo fue el paso de XP a Vista. En esta ocasión, Microsoft se ha basado en los numerosos cambios arquitectónicos que ocurrieron con Windows Vista y se ha centrado en asegurarse de que funcionen lo mejor posible.

Por supuesto, hay algunas novedades que merece la pena resaltar:

• Un centro de problemas y soluciones mucho más refinado con respecto a Windows Vista.
• Soporte Bluetooth mejorado.
• Una nueva barra de tareas mucho más intuitiva.
• La interfaz de usuario es más sencilla de utilizar y las opciones de configuración están más a la vista.
• Reconocimiento táctil y de escritura.
• Control de cuentas de usuario (UAC) proporciona más información para ayudarle a decidir al usuario.
• Soporte nativo de imágenes de CD/DVD.
• Creación por defecto de una partición separada para los ficheros de arranque.

Alguna de estas nuevas funcionalidades, y otras más, serán descritas en próximos artículos. Por supuesto, si tiene alguna inquietud sobre Windows 7 puede mandar un mensaje como comentario a esta entrada o utilizar la página "Contact" del blog.

Una de los quejas que más se ven en los foros de Windows Vista es la siguiente: 

El sistema arranca/apaga/hiberna muy lentamente. Cuando inicio sesión tengo que esperar un montón de tiempo hasta que finalmente se apaga la luz del disco duro y puedo trabajar.

Como cada persona tiene su propia idea de lo que es "lento" y, ciertamente, es difícil describir de manera precisa en qué fase concreta del arranque se consume una mayor cantidad de tiempo, lo que suelo indicar es que se utilice la infraestructura ETW (Event Tracing for Windows) de Windows Vista para generar una traza detallada del arranque/apagado/hibernación para así determinar la causa del problema. Concretamente, la herramienta Xbootmgr (http://www.microsoft.com/whdc/system/sysperf/perftools.mspx), parte del kit de herramientas Windows Performance, se apoya en la infraestructura ETW para generar una traza detallada del apagado, inicio, suspensión e hibernación del equipo.

Una vez instalado el software, vamos a usar la herramienta Xbootmgr para generar una traza del arranque, por ejemplo. Antes de comenzar la prueba, es recomendable que:

• No use el sistema durante la prueba, para que la medición sea lo más precisa posible.
• Desconecte toda conexión de red, unidad de red, etc. que tenga en el equipo.
• Configure el sistema para iniciar sesión automáticamente. Para ello, puede usar la powertoy Autologon de Windows Vista.

La sintaxis sería:

xbootmgr -trace boot -numRuns 2 -resultPath %systemdrive%\traces -prepSystem -traceflags base

El valor boot del parámetro -trace indica que queremos trazar el arranque del equipo. Podríamos poner shutdown y estaríamos trazando el apagado del equipo.

El valor 2 del parámetro -numRuns indica que queremos realizar 2 trazas consecutivas.

El parámetro -prepSystem implica que se realizará un par de arranques "preparatorios" antes de la prueba en sí.

Una vez ejecutado el comando anterior, el sistema informará de que se va a reiniciar automáticamente. Cuando finalice la traza, verá que en el directorio que haya indicado tras el parámetro -resultPath se ha creado un fichero con extensión .etl. Para extraer un resumen de la información de ese fichero en formato XML, puede usar la utilidad Xperf del siguiente modo:

xperf -i traza.etl -o resumen.xml -a boot

(Donde "traza.etl" es la traza que se ha obtenido como resultado del comando Xbootmgr).

Al abrir el fichero Resumen.xml encontrará un resumen de cada una de las fases de arranque así como los correspondientes tiempos de ejecución, entre otros datos. Es bastante más intuitivo mostrar la información de una manera gráfica. Para ello, simplemente ejecute el siguiente comando:

xperf traza.etl

Se abrirá la herramienta Windows Performance Analyzer y mostrará la información de la traza de manera gráfica. La siguiente captura de pantalla muestra una parte de la información mostrada en un sistema:

En la parte superior se puede ver un diagrama temporal de los procesos del sistema operativo, es decir, en qué momento "nacen" y en qué momento finalizan. En la parte inferior aparece el concepto "hard faults", que hace referencia a todos aquellos fallos de página que han requerido una operación de E/S hacia el disco. Como esto es una operación costosa (varios órdenes de magnitud más lenta que el acceso a memoria principal), toda herramienta que analice el rendimiento de un sistema suele proporcionar este dato. Es normal que en las etapas iniciales del arranque se produzca un gran número de fallos de página. Windows Performance Analyzer permite mostrar gráficas adicionales tales como el consumo de CPU por proceso, E/S por proceso, etc.

En general, ¿qué produce un inicio lento?

Suponiendo dos máquinas iguales o parecidas en lo que a hardware se refiere (hardware que cumpla los requisitos recomendados de Windows Vista), el que una de ellas arranque mucho más lentamente que la otra puede deberse a:

• Controladores de arranque sin una firma digital embebida. Esto supone que Windows Vista debe ir al catálogo (%windir%\catroot) a buscar la correspondiente firma digital, demorándose la carga del controlador.
• Controladores que responden lentamente a los eventos generados por el administrador Plug and Play de Windows. Concretamente, el cuello de botella suele encontrarse a la hora de manejar la IRP IRP_MN_START_DEVICE. Tiene información sobre la misma en el sitio web de MSDN. Como se comenta en la propia documentación, los controladores deberían devolver el resultado STATUS_PENDING y posponer el tratamiento de la IRP para así no perjudicar excesivamente el tiempo de arranque del sistema.
• Un controlador de vídeo que tarda mucho tiempo en inicializarse.
• Conexiones de red persistentes (una unidad de red, por ejemplo) que tardan en responder mucho tiempo.
• Scripts de inicio impuestos mediante directivas (esto es más común en un dominio).
• Servicios que tardan demasiado en iniciarse.

Si interpretando la información de la traza determinase que es en la fase final del arranque en la que se consume más tiempo, quizá desee desactivar servicios u otros elementos que arrancan junto con Windows. Para ello lo ideal es que haga uso de la herramienta Autoruns.

En resumen, el arranque y apagado del sistema operativo son dos procesos complejos (especialmente el primero) formados por una serie de fases bien diferenciadas. Interpretando la información proporcionada por las herramientas Xbootmgr y Xperf podrá comprender mejor qué es lo que ocurre cuando arranca o apaga su sistema y será capaz de detectar los cuellos de botella que tantos segundos de nuestro preciado tiempo nos roban cada vez que ponemos en funcionamiento nuestra máquina.

Por supuesto, si necesitara ayuda para interpretar los resultados de alguna traza, puede plantear su pregunta en los comentarios de esta entrada.