• Artículo

[Archivo de boletines ^][< Volumen 1, Número 1][Volumen 1, Número 3 >]

Boletín de información interna de sistemas Volumen 1, Número 2

http://www.sysinternals.com

15 de mayo de 1999: en este número:

  1. NOVEDADES DE SYSTEMS INTERNALS

    • SDelete
    • Actualización de Win2K del protector de pantalla BlueScreen
    • "Linux y la empresa"
    • "Dentro de las utilidades de NT"
    • Mi columna de mayo de Windows NT Magazine
    • Cosas no tan nuevas

  2. NOTICIAS INTERNAS

    • Los malos modales del Dr. GUI
    • WinDev '99 East
    • Lanzamiento inminente de Numega Driver Works
    • Versión beta 3 DDK publicada
    • Spinlocks en cola de Win2K

  3. PRÓXIMAMENTE

    • Protector de archivos del sistema (SFP) Win2K

PATROCINADOR: WINTERNALS SOFTWARE

El Boletín de The Systems Internals está patrocinado por Winternals Software, en la Web en http://www.winternals.com. Winternals Software es el principal desarrollador y proveedor de herramientas avanzadas de sistemas para Windows NT/2K. Los productos de Winternals Software incluyen FAT32 para Windows NT 4.0, ERD Commander (funcionalidad de disco de arranque para Windows NT) y NTRecover.

Hola a todos:

Bienvenido a la segunda edición del boletín de Systems Internals. En la actualidad, el boletín cuenta con 2 700 suscriptores, y las suscripciones siguen en aumento.

Desde el último boletín, Microsoft ha publicado oficialmente Windows 2000 Beta 3. El número de compilación del kernel Beta 3 es 2031, mientras que el del kernel de la versión inicial de NT 4.0 fue 1381 y el de NT 3.51 tuvo un número de compilación de 1025. . Lo que encuentro extraño (y algo molesto), es que Microsoft incrementa el número de compilación cada vez que realizan una compilación completa del sistema operativo (todos los días laborables), sin embargo, el número de compilación notificado del kernel refleja el de su versión pública inicial. Por ejemplo, aunque el número de compilación real del kernel de NT 4.0 Service Pack 5 es mucho mayor que 1381, el kernel sigue indicando 1381 como número de compilación.

La versión Beta 3 de Windows 2000 pretende ser una llamada de atención para la comunidad de desarrolladores. Microsoft ha anunciado que lanzará Windows 2000 en octubre, y que la Beta 3 representa la versión completa de lo que se lanzará, por lo que los desarrolladores pueden empezar a escribir nuevos productos sin temor a que las cosas cambien.

Windows 2000 incluye una gran cantidad de nuevas API, servicios en capas y mejoras de kernel. Un cambio que será especialmente visible para los desarrolladores de controladores de dispositivos es que la Pantalla azul de la muerte (BSOD) ha cambiado. En versiones anteriores de NT, la BSOD mostraba información sobre el tiempo de enlace y la dirección de carga de todos los controladores de un sistema, así como un volcado de la pila tal y como existía en el momento del fallo. En Windows 2000 solo se muestran el código de parada y la(s) línea(s) de dirección asociada(s) (las líneas de dirección traducen uno o más de los parámetros del código de parada a ubicaciones dentro de los controladores de dispositivo), junto con un mensaje detallado. El mensaje de soporte le sugiere que compruebe la configuración de la BIOS y del disco duro, y que desactive el software de desfragmentación y los antivirus para intentar evitar que se vuelva a producir el fallo. Los Servicios de soporte técnico Premier (PSS) de Microsoft determinaron, basándose en su experiencia y en los comentarios de los clientes, que la BSOD al estilo de NT 4 no es útil para determinar la causa de un fallo.

Personalmente, la lista de controladores cargados y, en particular, el volcado de pila, me resultaron útiles a la hora de obtener informes de errores de controladores de los usuarios: es mucho más fácil y rápido obtener esta información que hacer que los usuarios envíen un volcado de errores de varios megabytes. A menudo he aislado la causa del fallo basándome en el volcado de pila, y he verificado las versiones de los controladores que los usuarios han cargado basándome en la información de la versión que aparece en la lista de controladores. Tengo curiosidad por saber qué piensa: ¿le gustaría que la BSOD de estilo NT 4 se trasladara a Windows 2000, o es suficiente con el nuevo formato de BSOD? Envíeme un correo electrónico si tiene alguna opinión. Informaré sobre los resultados de esta encuesta informal en el próximo boletín informativo. Y ya que hablo de BSOD, no deje de echar un vistazo a la actualización para Windows 2000 del siempre popular protector de pantalla de Systems Internals BlueScreen, que se trata en este número.

Gracias

-Mark

NOVEDADES DE SYSTEMS INTERNALS

SDELETE

Como parte del cumplimiento de los requisitos de clasificación de seguridad C2 por parte de Windows NT 4.0, implementa la "protección de reutilización de objetos". Esto significa que NT pone a cero los recursos de archivos y memoria que las aplicaciones asignan cuando acceden a ellos por primera vez. Esto impide que una aplicación, por ejemplo, cree un archivo de gran tamaño y examine su contenido para ver qué se almacenó previamente en el disco. Sin embargo, la protección de la reutilización de objetos no llega a proteger los recursos a los que pueden acceder las aplicaciones que omiten las API estándar relacionadas con los recursos, o que omiten por completo el sistema operativo. Por ejemplo, puede usar un editor de discos, como DiskProbe del Kit de recursos, para examinar el contenido de las partes no asignadas de un disco. Esto le permite ver los datos que anteriormente pertenecían a los archivos eliminados.

Muchos entornos requieren una capacidad de "borrado seguro". Esta característica permite a los usuarios eliminar de forma permanente los datos confidenciales para que no sean visibles por herramientas que eluden las funciones de protección del sistema operativo. La llegada del sistema de cifrado de archivos (EFS) ha puesto de manifiesto la necesidad de una función de borrado seguro en Windows 2000. Cuando cifra un archivo no cifrado previamente, EFS no borra el contenido de las asignaciones de disco que contenían los datos no cifrados del archivo cuando libera las asignaciones de disco. Por lo tanto, aunque la versión activa de un archivo que usted encripte sea segura, la versión antigua del archivo sigue existiendo en las porciones no asignadas de un disco hasta que casualmente se sobrescribe con los nuevos datos de archivo que NTFS asigna a esas porciones.

Para llenar este hueco, he escrito SDelete (Eliminación segura). Es una herramienta de línea de comandos que le permite no solo eliminar de forma segura archivos estándar, sino también eliminar de forma segura cualquier dato eliminado previamente que exista en las partes no asignadas de un disco. Además, funciona con archivos comprimidos, cifrados y dispersos de Windows NT/2000, algo que requiere el uso de la API de desfragmentación. SDelete se adhiere a la normativa de limpieza y saneamiento del Departamento de Defensa DOD 5220.22-M, por lo que puede estar seguro de que una vez que borra los datos, desaparecen para siempre.

Proporciono SDelete con el código fuente completo y una descripción de cómo funciona, para que pueda ver cómo hace uso de la API de desfragmentación, y para que pueda verificar mis afirmaciones de que evitará que sus datos confidenciales borrados sean recuperables.

Puede encontrar documentación sobre la API de desfragmentación de Windows NT/2000 en http://www.sysinternals.com/defrag.htm. Descargue SDelete con el código fuente completo en http://www.sysinternals.com/sdelete.htm.

ACTUALIZACIÓN DE WIN2K DEL PROTECTOR DE BLUESCREEN

Los cambios que Microsoft ha introducido en el diseño de la pantalla de inicio de NT y de la Pantalla azul de la muerte (BSOD) en Windows 2000 hicieron que el protector de pantalla Systems Internals BlueScreen necesitara una actualización importante. Para seguir proporcionándole el máximo realismo de BSOD, he lanzado la versión 2.0 del protector de pantalla. No solo refleja los cambios en el formato de la BSOD, sino que también imita con precisión la pantalla de inicio de Windows 2000, completa con la franja de progreso giratoria y las actualizaciones de la barra de progreso. Es tan real que el protector de pantalla engañará incluso a los usuarios y desarrolladores expertos de Windows 2000. Por supuesto, en NT 4.0 el protector de pantalla de BlueScreen todavía presenta las pantallas de BSOD y de inicio de NT 4.0.

¿Cómo he podido recrear la pantalla de inicio de Windows 2000 de forma tan perfecta y al mismo tiempo no infringir las leyes de derechos de autor? No incluí los gráficos de mapa de bits de inicio de Windows 2000 con el protector de pantalla. En su lugar, uso DirectX para cambiar el modo gráfico al mismo que usa Windows 2000 durante la secuencia de inicio, y después hago referencia a los recursos de mapa de bits del archivo del kernel de Windows 200, ntoskrnl.exe. Estos recursos (puede verlos abriendo los recursos de ntoskrnl.exe en Visual Studio) son los que muestra el kernel, lo que supone un cambio respecto a la forma de hacer las cosas de Windows 9x, en la que los gráficos de inicio eran en realidad archivos independientes. No parece que los fabricantes de equipos originales vayan a tener la oportunidad de personalizar la experiencia de inicio en Windows 2000...

Puede descargar el protector de pantalla de BlueScreen en http://www.sysinternals.com/bluescreen.htm. Si tiene alguna historia humorística relacionada con engañar a alguien con el protector de pantalla, por favor, pásela.

Puede encontrar más información sobre el cómo y el porqué de las BSOD en mi columna de diciembre de 1997 de Windows NT Magazine NT Internals, " Dentro de la pantalla azul". Un vínculo en la página de Publicaciones de Systems Internals, de http://www.sysinternals.com/publ.htm, le llevará a la versión en línea de esa columna. La página también contiene vínculos a otras presentaciones en línea de artículos y columnas que he creado.

"LINUX Y LA EMPRESA"

La enorme respuesta de la comunidad Linux a mi artículo en el número de abril de Windows NT Magazine sobre las deficiencias de escalabilidad del kernel de Linux ha llevado a la revista a publicar la versión en línea del artículo antes de lo previsto. Puede encontrar un vínculo al artículo "Linux y la empresa", en la sección "Artículos" de http://www.sysinternals.com/publ.htm. El artículo describe varias limitaciones de la versión actual del kernel de Linux (2.2x), incluida la falta de un mecanismo eficiente de espera de eventos, una serialización significativa de las llamadas al sistema, la ausencia de E/S asíncrona y una implementación deficiente de la API de socket sendfile (en NT se llama TransmitFile). La combinación de estas limitaciones impide que Linux compita en igualdad de condiciones con NT y otros UNIX, en términos de rendimiento, en aplicaciones de clase empresarial como servidores web, servidores de bases de datos y servidores de correo electrónico.

"DENTRO DE LAS UTILIDADES DE NT"

Si ha usado Filemon, Regmon o HandleEx y quería saber más sobre lo que le dicen y cómo se implementan, le interesará mi columna de febrero de Windows NT Magazine, "Dentro de las utilidades de NT". Esta columna describe el funcionamiento interno de estas herramientas y, en el caso de Regmon y Filemon, le informa un poco sobre los códigos de error y los tipos de solicitud que registran al capturar la actividad del Registro o del sistema de archivos. Un vínculo a la versión en línea de este artículo, que acaba de hacerse disponible, se encuentra en http://www.sysinternals.com/publ.htm.

MI COLUMNA DE MAYO DE WINDOWS NT MAGAZINE

¿Se ha preguntado alguna vez cómo organiza Windows NT/2000 el contenido del Registro en memoria o en disco? El número actual (mayo) de Windows NT Magazine incluye mi columna, "Dentro del Registro", que le cuenta esto y mucho más. Por ejemplo, obtendrá información sobre cómo el subsistema en modo kernel del Administrador de configuración (el subsistema responsable de administrar el Registro) busca claves, almacena datos de valores, optimiza la búsqueda y protege la integridad de los archivos del Registro en disco. Windows NT Magazine, http://www.winntmag.com, está disponible en Borders y Barnes & Noble.

COSAS NO TAN NUEVAS

No mucho después del lanzamiento de Windows 2000 Beta 2, tomé la compilación comprobada (depuración) del archivo de imagen del kernel (ntoskrnl.exe), hice una búsqueda de cadenas en el kernel y obtuve una lista de los nombres de los archivos de origen usados para compilar el kernel. La compilación comprobada del kernel de NT/2000 contiene numerosas instrucciones Assert (comprobaciones de coherencia) que incluyen el nombre del archivo en el que se encuentra Assert. Suponiendo que prácticamente todos los archivos de algún significado en el origen del kernel tendrán al menos una Assert en ellos, la lista es bastante completa. Volcando la lista en un script de Java obtuve una bonita vista en árbol, similar a la de Explorer, de la estructura de directorios del árbol de orígenes de Windows 2000. Compruébelo en http://www.sysinternals.com/nt5src.htm..

NOTICIAS INTERNAS

LOS MALOS MODALES DEL DR. GUI

En el número de marzo/abril de Noticias de Microsoft Developer Network el Dr. GUI responde a la pregunta de un lector que se pregunta cómo puede un controlador afinitizar (forzar a usar una CPU específica) sus subprocesos. El Dr. GUI responde que no hay forma de determinar el número de procesadores de un sistema a partir de un controlador, y que un subproceso del controlador no puede saber en qué procesador se está ejecutando. Desgraciadamente, el Dr. GUI se equivocó en este diagnóstico (quizá el Dr. GUI debería ceñirse a los GUI).

El kernel de NT (ntoskrnl.exe) exporta una variable llamada KeNumberProcessors que se define en NTDDK.H como:

extern PCCHAR KeNumberProcessors;

Se puede hacer referencia a ella directamente en un controlador como este:

CHAR    i;

for( i = 0; i < *KeNumberProcessors; i++ ) {

    // do processor specific stuff
}

Para determinar en qué procesador se está ejecutando un subproceso del controlador, use KeGetCurrentProcessorNumber(), otra exportación del kernel que no solo está definida en NTDDK.H, sino que está documentada en el DDK.

El Dr. GUI recetó la medicación equivocada para la enfermedad, así que se lo hice saber educadamente a través de un cortés correo electrónico. Sorprendentemente, el Dr. GUI ni siquiera confirmó la recepción del correo electrónico. Veremos si el buen Dr. confiesa el error en el próximo número...

WINDEV '99 EAST

La edición de 1999 en la Costa Este de la principal conferencia para desarrolladores de Windows se acerca rápidamente. WinDev '99 East tendrá lugar del 14 al 18 de junio en el Boston Cambridge Marriot. Intervendrán varios grandes nombres del desarrollo de Windows, como Jeff Richter, Jeff Prosise y Don Box. Estaré allí con Jamie Hanrahan y Brian Catlin en la pista de controladores de dispositivos. Mis presentaciones incluyen un tutorial de un día sobre los aspectos internos de NT, así como uno sobre la escritura de controladores del sistema de archivos de Windows NT/2K y otro sobre cuestiones avanzadas de desarrollo de controladores de dispositivos. ¡Venga a saludarnos!

LANZAMIENTO INMINENTE DE NUMEGA DRIVER WORKS

Compuware NuMega Labs está a punto de lanzar un nuevo y potente kit de desarrollo de controladores de dispositivos de Windows 9x/NT/2K, DriverStudio. DriverStudio combina todas las herramientas existentes de NuMega para controladores de dispositivos, incluidos DriverAgent, DriverWorks, SoftICE y VtoolsD, y agrega el nuevo BoundsChecker para controladores y FieldAgent (solo para Windows NT/2K).

La versión de BoundsChecker para controladores de dispositivos proporciona una supervisión exhaustiva de todas las API del kernel que usa su controlador, y puede usarla para supervisar las interacciones de su controlador con cualquier otro controlador de dispositivos del sistema. FieldAgent le permite implementar la versión del controlador de BoundsChecker en sistemas cliente para que puedan recopilar trazas que usted podrá analizar. Próximamente, como actualización gratuita para los clientes de DriverStudio, estarán disponibles TrueTime para controladores y TrueCoverage para controladores, herramientas que le permitirán ajustar fácilmente el rendimiento y probar la cobertura de los controladores de sus dispositivos.

Este paquete es el kit de desarrollo de controladores definitivo, y lo recomiendo de todo corazón (estoy en el programa Beta). Obtenga más información en http://www.numega.com.

VERSIÓN BETA 3 DDK PUBLICADA

Junto con el lanzamiento de Windows 2000 Beta 3, Microsoft ha puesto a disposición para su descarga gratuita el DDK (kit de controladores de dispositivos) de Windows 2000 Beta 3. Puede obtener el DDK en http://www.microsoft.com/ddk/ddk2kb3.htm. Espero que el SDK le siga pronto, ya que hay una serie de API de Win32 en la Beta 3 que no están documentadas a partir de la edición de abril de MSDN.

SPINLOCKS EN COLA DE WIN2K

Windows 2000 usa un nuevo tipo de spinlock llamado " spinlock en cola" para sus bloqueos globales. Los bloqueos globales de Windows 2000 son los mismos que los de Windows NT 4.0, e incluyen:

  • KiDispatcherLock: bloqueo de la base de datos del programador
  • KiContext-SwapLock: bloqueo de intercambio de banda de rodadura
  • MmPfnLock: bloqueo de base de datos de marco de página física
  • MmSystemSpaceLock: el bloqueo del espacio de direcciones en modo kernel
  • CcMasterSpinLock: bloqueo global del Administrador de caché
  • CcVacbSpinLock: bloqueo de matriz de asignación del Administrador de caché

En un uniprocesador los spinlocks en cola funcionan exactamente como los spinlocks normales. En la compilación multiprocesador de NT, sin embargo, los spinlocks en cola son significativamente diferentes. Al igual que los spinlocks estándar, los spinlocks en cola se implementan en la HAL. El kernel llama a la función HAL KeAcquireQueuedSpinlock para adquirir un bloqueo por subproceso en cola e invoca KeReleaseQueuedSpinlock para liberar un bloqueo por subproceso en cola. KeAcquireSpinlock y KeReleaseSpinlock, las funciones HAL que el kernel usa para adquirir y liberar spinlocks estándar, requieren la dirección del spinlock especificado como parámetro. Por el contrario, las funciones de spinlock en cola toman el número de índice de un spinlock global. El kernel inicializa los spinlocks globales en una matriz, donde cada spinlock tiene un número de índice predefinido que el kernel usa para identificarlos ante HAL. Por lo tanto, los controladores de dispositivo no pueden definir y usar los spinlocks en cola, ya que no hay forma de aumentar la matriz global de spinlocks en cola.

En Windows 2000, cada región de control del procesador (PCR) en un SMP (hay un PCR para cada procesador) tiene una matriz con tantas entradas en ella como spinlocks en cola haya. Cada entrada de la matriz contiene dos campos: un puntero al spinlock en cola al que corresponde (el campo "spinlock") y el campo "queue". En la siguiente descripción, cuando me refiero a los campos de spinlock y cola, estoy hablando de los campos asociados a la entrada de la matriz para el spinlock que se está adquiriendo o liberando.

KeAcquireQueuedSpinlock funciona así: la función intenta adquirir el spinlock usando la instrucción de CPU interlocked-exchange para colocar la dirección del PCR del procesador actual en el spinlock. Si se mantiene el spinlock, la función tiene, como parte de la operación de intercambio, la dirección del PCR de otro procesador. Después, la función se identifica a sí misma como "en espera" alternando el bit bajo del campo spinlock en su propia PCR. A continuación, coloca la dirección de su propio PCR en el campo de cola del PCR que recuperó del spinlock. Por último, espera en un bucle ocupado hasta que se desactive el botón de alternancia bajo en su campo de spinlock. Cuando el botón está desactivado, se ha concedido el spinlock al procesador actual, por lo que vuelve al autor de la llamada de la función de adquisición.

Después de que un procesador haya adquirido un spinlock en cola y terminado el procesamiento que quería hacer mientras mantenía el bloqueo, llama a KeReleaseQueuedSpinlock. KeReleaseQueuedSpinlock examina el campo de cola para el spinlock especificado en el PCR del procesador actual. Si el campo de cola es distinto de cero, entonces otro procesador ha "puesto en cola" allí su PCR. KeReleaseQueuedSpinlock borra el bit bajo del campo spinlock para el PCR en espera, y después borra su propio campo de cola y regresa. Al borrar el bit bajo en el campo spinlock del PCR en espera acaba de indicar a la siguiente CPU de la fila que puede tener el bloqueo. Si el campo de cola era cero, entonces ningún otro procesador está esperando el bloqueo y KeReleaseQueuedSpinlock simplemente realiza una operación de intercambio interbloqueado para despejar el spinlock global.

En el funcionamiento de los spinlocks en cola, los procesadores se "alinean" a la espera de un spinlock retenido. Cada procesador se pone en cola diciéndole al que le precede en la fila que está esperando. Esto proporciona un orden determinista a la adquisición de un spinlock en cola. Los procesadores adquieren el spinlock en el orden en que lo solicitan. Para los spinlocks estándar no existe tal ordenación. Los spinlocks en cola tienen otra ventaja más significativa. Mientras un procesador gira esperando que su campo spinlock tenga el bit bajo despejado, está girando sobre memoria privada de su propio procesador. Cuando un procesador ocupado espera un spinlock estándar gira sobre el propio spinlock global, que es compartido por todos los procesadores. Así, los spinlocks en cola tienen mejores características de bus multiprocesador porque no hay acceso compartido a la línea de caché durante la espera. Además, debido a la naturaleza de cola de los spinlocks en cola, suele haber menos operaciones de bloqueo del bus que para los spinlocks estándar cuando un bloqueo está bajo la contención de varios procesadores.

Los spinlocks en cola son una de las varias mejoras que Microsoft ha introducido en la escalabilidad del multiprocesamiento de Windows 2000.

PRÓXIMAMENTE

Windows 2000 incluye numerosas características que lo hacen más resistente a los errores del operador y a las aplicaciones que se comportan mal. Una de ellas es que muchos de los DLL y controladores bajo el directorio %systemroot%\system32 y %systemroot%\system32\drivers están protegidos por un guardián llamado Protector de archivos del sistema (SFP). Puede verificar su existencia entrando en ese directorio de system32 y cambiando el nombre a ntoskrnl.exe. El guardián se despertará y le notificará que ha detectado la manipulación de un archivo protegido del sistema y que lo está reparando. Si vuelve a comprobar el directorio verá que ntoskrnl.exe ha sido reemplazado por arte de magia. La próxima vez le diré cómo funciona esto.

Gracias por leer el Boletín de Systems Internals.

Publicado el sábado 15 de mayo de 1999, 19:15 por ottoh

[Archivo de boletines ^][< Volumen 1, Número 1][Volumen 1, Número 3 >]