15 de mayo de 1999: en este problema:

  1. NOVEDADES DE SYSTEMS INTERNALS

    • SDelete
    • BlueScreen Screen Saver Win2K Update
    • "Linux y el Enterprise"
    • "Inside NT Utilities"
    • My May Windows NT Magazine Column
    • Cosas no tan nuevas
  2. NOTICIAS INTERNAS

    • Modales de la mesita de la guisa del dr. GUI
    • WinDev '99 Este
    • La versión de Numega Driver Works Es inminencia
    • Versión beta 3 del DDK publicada
    • Bloqueos por giros en cola de Win2K
  3. ¿QUÉ VA A LLEGAR?

    • Protector de archivos del sistema Win2K (SFP)

PATROCINADOR: SOFTWARE DE INVERNALS

El Boletín de información interna de los sistemas está patrocinioado por El software de Newsnals, en la Web en http://www.winternals.com. Winternals Software es el desarrollador y proveedor líder de herramientas de sistemas avanzados para Windows NT/2K. Los productos de Software de Horarios incluyen FAT32 para Windows NT 4.0, ERD Commander (funcionalidad de disco de arranque para Windows NT) y NTRecover.

Hola a todos:

Le damos la bienvenida a la segunda edición del boletín Systems Internals. El boletín tiene actualmente 2700 suscriptores, y las suscripciones siguen siendo fuertes.

Desde el último boletín, Microsoft ha publicado oficialmente Windows beta 3 de 2000. El número de compilación del kernel beta 3 es 2031, mientras que el del kernel de versión inicial de NT 4.0 era 1381 y NT 3.51 tenía un número de compilación de 1025. . Lo que me parece extraño (y algo molesto) es que Microsoft incrementa el número de compilación cada vez que hacen una compilación completa del sistema operativo (todos los días del trabajo), pero 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 notificando 1381 como número de compilación.

La versión Beta 3 de Windows 2000 está pensada para ser una llamada de reactivación para la comunidad de desarrolladores. Microsoft ha anunciado que enviará Windows 2000 en octubre y que beta 3 representa la versión completa de características de lo que se enviará, por lo que los desarrolladores pueden empezar a escribir nuevos productos sin miedo a que las cosas cambien desde debajo de ellos.

Windows 2000 incluye una gran cantidad de nuevas API, servicios por 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, el BSOD mostró información de tiempo de vínculo y dirección de carga para todos los controladores de un sistema, así como un volcado de la pila tal como existe en el momento del bloqueo. En Windows 2000 solo se muestran el código de detenerse y las líneas de direcciones asociadas (las líneas de dirección traducen uno o varios de los parámetros de código de detenerse en ubicaciones dentro de los controladores de dispositivos), junto con un mensaje detallado. El mensaje de soporte técnico sugiere que compruebe la configuración del BIOS y la unidad de disco duro, y deshabilite la desfragmentación de software y escáneres de virus para intentar evitar que se vuelva a bloquear. Microsoft soporte técnico Premier Services (PSS) determinó, en función de su experiencia y de los comentarios de los clientes, que el BSOD del estilo NT 4 no es útil para determinar la causa de un bloqueo.

Personalmente, he encontrado que la lista de controladores cargados y, en particular, el volcado de pila, son útiles al 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 memoria de varios megabytes. A menudo he aislado la causa del bloqueo en función del volcado de pila y he comprobado las versiones de controladores que los usuarios han cargado en función de la información de versión que se muestra en la lista de controladores. Tengo curiosidad por saber lo que piensa: ¿quiere ver que el BSOD de estilo NT 4 se ha realizado hasta Windows 2000 o es suficiente con el nuevo formato BSOD? Envíeme un correo electrónico si tiene una opinión. Notificaré los resultados de este sondeo informal en el siguiente boletín. Mientras estoy en el tema de los BSOD, asegúrese de consultar la actualización de Windows 2000 del siempre popular protector de pantalla BlueScreen de Systems Internals, que se trata en este problema.

Gracias

-Mark

NOVEDADES DE SYSTEMS INTERNALS

SDELETE

Como parte de Windows NT 4.0 que cumple los requisitos de clasificación de seguridad de C2, implementa la "protección de reutilización de objetos". Esto significa que NT cero los recursos de archivo y memoria que las aplicaciones asignan cuando las aplicaciones acceden a los recursos por primera vez. Esto impide que una aplicación, por ejemplo, cree un archivo grande y examine su contenido para ver lo que se almacenaba anteriormente en el disco. Sin embargo, la protección de reutilización de objetos no afecta en gran medida a la protección de 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 partes sin asignar de un disco. Esto le permite ver los datos que anteriormente pertenecían a los archivos eliminados.

Muchos entornos requieren una funcionalidad de "eliminación segura". Esta característica permite a los usuarios eliminar permanentemente datos confidenciales para que no sean visibles por las herramientas que omiten las instalaciones de protección del sistema operativo. La llegada de Sistema de cifrado de archivos (EFS) ha resaltado la necesidad de una instalación de eliminación segura en Windows 2000. Al cifrar un archivo previamente sin cifrar, EFS no borra el contenido de las asignaciones de disco que contenían los datos sin cifrar del archivo cuando libera las asignaciones de disco. Por lo tanto, aunque la versión activa de un archivo que se cifra es segura, la versión anterior del archivo sigue existiendo en las partes sin asignar de un disco hasta que se sobrescriban con los nuevos datos de archivo que NTFS asigna a esas partes.

Para rellenar este hueco, he escrito SDelete (Secure Delete). Se trata de una herramienta de línea de comandos que permite no solo eliminar archivos estándar de forma segura, sino también eliminar de forma segura los datos eliminados previamente que existen en las partes sin asignar de un disco. Además, funciona con archivos Windows NT/2000 comprimidos, cifrados y dispersos, algo que requiere el uso de la API de desfragmentación. SDelete se adhiere al estándar DOD 5220.22-M del Departamento de Defensa para que pueda asegurarse de que, una vez que elimine los datos, se haya eliminado para siempre.

Se proporciona a SDelete código fuente completo y una descripción de cómo funciona, para que pueda ver cómo usa la API de desfragmentación y para que pueda comprobar mis notificaciones de que impedirá que los datos eliminados confidenciales se puedan recuperar.

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

BLUESCREEN SCREEN SAVER WIN2K UPDATE

Los cambios que Microsoft ha realizado en la pantalla de inicio de NT y el diseño de Blue Screen of Death (BSOD) en Windows 2000 han hecho que el protector de pantalla azul de Systems Internals requiera una actualización importante. Para seguir proporcionando lo máximo en el realismo de BSOD, he publicado la versión 2.0 del protector de pantalla. No solo refleja los cambios en el formato BSOD, sino que también imita con precisión la pantalla de inicio de Windows 2000, completa con la franja de progreso rotativa y las actualizaciones de la barra de progreso. Es tan real que el protector de pantalla se engañe incluso Windows 2000 desarrolladores y usuarios expertos. Por supuesto, en NT 4.0 BlueScreen Screen Saver todavía se presentan las pantallas BSOD y de inicio de NT 4.0.

¿Cómo he recreado la pantalla de inicio Windows 2000 de forma tan perfecta y al mismo tiempo no infringir las leyes de copyright? No se incluyen los gráficos de mapa de bits Windows inicio de 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, a continuación, hago referencia a los recursos de mapa de bits del archivo de 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, que es un cambio de la forma Windows 9x de hacer cosas en las que los gráficos de inicio son realmente archivos independientes. No parece que los OEM del equipo tendrán la oportunidad de personalizar la experiencia de inicio en Windows 2000...

Puede descargar el protector de pantalla BlueScreen en http://www.sysinternals.com/bluescreen.htm. Si tiene una historia desastosa relacionada con la desfasación de alguien con el protector de pantalla, pásalo.

Puede obtener más información sobre cómo y por qué de los BSOD en mi columna de diciembre de 1997 Windows NT Magazine NT Internals, "Inside the Blue Screen". Un vínculo de la página Publicaciones internas de sistemas, , le llevará a la versión http://www.sysinternals.com/publ.htm 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 escrito.

"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 hecho que la revista publique la versión en línea del artículo antes de lo previsto. Puede encontrar un vínculo al artículo "Linux y el Enterprise", en la sección "Artículos" enhttp://www.sysinternals.com/publ.htm. En el artículo se describen varias limitaciones de la versión actual del kernel de Linux (2.2x), incluida la falta de un mecanismo eficaz de espera de eventos, una serialización significativa de llamadas del sistema, ninguna E/S asincrónica y una implementación deficiente de la API de socket sendfile (en NT su denominado TransmitFile). La combinación de estas limitaciones impide que Linux compita de frente 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.

"INSIDE NT UTILITIES"

Si ha usado Filemon, Regmon o HandleEx y quiere saber más sobre lo que le dicen y cómo se implementan, le interesará mi columna de febrero de Windows NT Magazine, "Inside NT Utilities". En esta columna se describen los elementos internos de estas herramientas y, para Regmon y Filemon, se indica un poco sobre los códigos de error y los tipos de solicitud que registra 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 estar disponible, se encuentra en http://www.sysinternals.com/publ.htm.

MI COLUMNA DE MAYO DE WINDOWS NT MAGAZINE

¿Alguna vez se ha Windows nt/2000 organizar el contenido del Registro en memoria o en disco? El problema actual (mayo) de Windows NT Magazine incluye mi columna , "Inside the Registry", que le indica esto y mucho más. Por ejemplo, obtenga información sobre cómo el subsistema en modo kernel de Administrador de configuración (el subsistema responsable de administrar el Registro) busca claves, almacena datos de valor, optimiza la búsqueda y protege la integridad de los archivos en disco del Registro. Windows NT Magazine, http://www.winntmag.com , está disponible en Borders and Faires andMentes.

COSAS NO TAN NUEVAS

No mucho después de que se publicara la versión beta 2 de Windows 2000, he tomado la compilación Checked (debug) del archivo de imagen de kernel (ntoskrnl.exe), he hecho una búsqueda de cadenas en el kernel y he creado una lista de los nombres de los archivos de origen usados para compilar el kernel. La compilación checked del kernel NT/2000 contiene numerosas instrucciones Assert (comprobaciones de coherencia) que incluyen el nombre de archivo del archivo en el que se encuentra Assert. Suponiendo que prácticamente todos los archivos de cualquier importancia en el origen del kernel tendrán al menos una aserción en él, la lista es bastante completa. Volcar la lista en un script de Java me dio una buena vista de árbol similar al explorador de la estructura de directorios del árbol de origen Windows 2000. Compruébelo en http://www.sysinternals.com/nt5src.htm..

NOTICIAS INTERNAS

Recuperación ante desastres. MANERAS DEFICIENTES DE LA INTERFAZ GRÁFICA DE USUARIO

En el problema de marzo y abril de Desarrollador de Microsoft Network News Dr. GUI, el dr. GUI muestra una pregunta de un lector que pregunta cómo un controlador puede afinidadar (forzar a usar una CPU específica) de sus subprocesos. La GUI del dr. responde que no hay ninguna manera de determinar el número de procesadores de un sistema desde un controlador y que un subproceso de controlador no puede saber en qué procesador se está ejecutando. Desafortunadamente, el dr. GUI ha realizado este diagnóstico (es posible que la GUI del dr. se dedgue a los GUID).

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

extern PCCHAR KeNumberProcessors;

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

CHAR    i;

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

    // do processor specific stuff
}

Para determinar en qué procesador se ejecuta un subproceso de controlador, use KeGetCurrentProcessorNumber(), otra exportación de kernel que no solo se define en NTDDK. H, pero en realidad está documentado en el DDK.

La guipuzcoana de dr. prescribía el tratamiento incorrecto para esta situación, por lo que lo he hecho saber de forma cómoda a través de un correo electrónico desatensado. Sorprendentemente, el dr. GUI nunca ha reconocido el correo electrónico. Veremos si el buen dr. se encuentra con el error en el siguiente problema...

WINDEV '99 ESTE

La edición 1999 de la costa este de Ee. UU. de la conferencia premier para desarrolladores Windows se aproxima rápidamente. WinDev '99 East tiene lugar del 14 al 18 de junio en Boston Boston Boston Marriot. Se habla de una serie de nombres Windows desarrollo, incluidos Jeff Richter, Jeff Prosise y Don Box. I'll be there withHan Hanrahan and Brian Catlin in the device driver's track. Mis presentaciones incluyen un tutorial de un día sobre los aspectos internos de NT, así como otro sobre la escritura de controladores de sistema de archivos NT/2K de Windows y otro sobre problemas avanzados de desarrollo de controladores de dispositivos. ¡Vamos y diga hola!

LA VERSIÓN DEL CONTROLADOR NUMEGA FUNCIONA DE INMEDIATO

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

La versión del controlador de dispositivo de BoundsChecker proporciona una supervisión completa de todas las API de kernel que usa el controlador, y puede usarla para supervisar las interacciones del controlador con cualquier otro controlador de dispositivo del sistema. FieldAgent permite implementar la versión del controlador de BoundsChecker en los sistemas cliente para que los clientes puedan recopilar los seguimientos que pueda analizar. Próximamente una actualización gratuita para los clientes de DriverStudio son TrueTime para controladores y TrueCoverage para controladores, herramientas que le permiten optimizar fácilmente el rendimiento y probar la cobertura de los controladores de dispositivos.

Este paquete es el kit de desarrollo de controladores final y lo recomiendo encarecidamente (estoy en el programa Beta). 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 de los usuarios la descarga gratuita del DDK de Windows Beta 3 (Device Driver Kit) de Windows 2000. Puede obtener el DDK en http://www.microsoft.com/ddk/ddk2kb3.htm. Estoy deseando que el SDK siga pronto, ya que hay varias API de Win32 en la versión beta 3 que no están documentadas en la edición de abril de MSDN.

BLOQUEOS POR GIRO EN COLA DE WIN2K

Windows 2000 usa un nuevo tipo de bloqueo por número denominado "bloqueo por número en cola" para sus bloqueos globales. Los bloqueos globales de Windows 2000 son los mismos que para Windows NT 4.0 e incluyen:

  • KiDispatcherLock: el bloqueo de base de datos del programador
  • KiContext-SwapLock: el bloqueo de intercambio de intercambio de intercambio
  • MmPfnLock: bloqueo de base de datos de marco de página físico
  • MmSystemSpaceLock: bloqueo de espacio de direcciones en modo kernel
  • CcMasterSpinLock: bloqueo por número global del Administrador de caché
  • CcVacbSpinLock: el bloqueo de la matriz de asignaciones del Administrador de caché

En un bloqueo por spinlocks en cola de un procesador, funcionan exactamente igual que los bloqueos por giro normales. Sin embargo, en la compilación de varios procesadores de NT, los bloqueos por número en cola son significativamente diferentes. Al igual que los bloqueos por giro estándar, los bloqueos por número en cola se implementan en LAN. El kernel llama a la función DEI para adquirir un bloqueo por número en cola e invoca para liberar un bloqueo por giro KeAcquireQueuedSpinlockKeReleaseQueuedSpinlock en cola. KeAcquireSpinlock y , las funciones DEI QUE usa el kernel para adquirir y liberar bloqueos por número estándar, requieren la dirección del bloqueo por giro especificado KeReleaseSpinlock como parámetro. Por el contrario, las funciones de bloqueo por giro en cola toman el número de índice de un bloqueo por giro global. El kernel inicializa los bloqueos por giro globales en una matriz, donde cada bloqueo por secuencias tiene un número de índice predefinido que el kernel usa para identificarlos en la SECUENCIA. Por lo tanto, los bloqueos por número en cola no se pueden definir ni usar en los controladores de dispositivos, ya que no hay ninguna manera de aumentar la matriz de bloqueos por giro en cola global.

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

KeAcquireQueuedSpinlock funciona de esta manera: la función intenta adquirir el bloqueo por giro mediante la instrucción de CPU de intercambio entrelazado para colocar la dirección del PCR del procesador actual en el bloqueo por giro. Si se mantiene el bloqueo por giro, la función tiene, como parte de la operación de intercambio, la dirección del PCR de otro procesador. A continuación, la función se identifica a sí misma como "en espera" al alternar el bit bajo del campo de bloqueo por giro en su propio PCR. A continuación, coloca su propia dirección de PCR en el campo de cola del PCR que recuperó del bloqueo por número. Por último, espera en un bucle ocupado hasta que el bit bajo se desactiva en su campo de bloqueo por giro cuando el bit está desactivado y, a continuación, se le ha concedido al procesador actual el bloqueo por giro y, por tanto, vuelve al llamador de la función de adquisición.

Una vez que un procesador ha adquirido un bloqueo por número en cola y ha finalizado el procesamiento que quería realizar mientras mantiene el bloqueo, llama a KeReleaseQueuedSpinlock . KeReleaseQueuedSpinlock busca en el campo de cola el bloqueo por número especificado en el PCR del procesador actual. Si el campo de cola es distinto de cero, otro procesador "pone en cola" su PCR allí. KeReleaseQueuedSpinlock borra el bit bajo del campo spinlock para el PCR en espera y, a continuación, borra su propio campo de cola y devuelve . Al borrar el bit bajo en el campo de bloqueo por giro del PCR en espera, acaba de indicar a la siguiente CPU en línea que puede tener el bloqueo. Si el campo de cola era cero, ningún otro procesador está esperando el bloqueo y simplemente realiza una operación de intercambio entrelazado para borrar el bloqueo por giro KeReleaseQueuedSpinlock global.

La operación de bloqueos por giro en cola es aquella en la que los procesadores se "alinean" a la espera de un bloqueo por giro que se mantiene. Cada procesador se pone en cola si se le dice al que está delante en línea que está esperando. Esto proporciona una ordenación determinista para la adquisición de procesadores de bloqueo por giro en cola que adquieren el bloqueo por giro en el orden en que lo solicitan. En el caso de los bloqueos por giro estándar, no hay ninguna ordenación de este tipo. Los bloqueos por número en cola tienen otra ventaja más significativa. A medida que un procesador gira a la espera de que su campo de bloqueo por giro tenga el bit bajo borrado, gira en la memoria privada a su propio procesador. Cuando un procesador ocupado espera un bloqueo por giro estándar, gira en el propio bloqueo por giro global, que comparten todos los procesadores. Por lo tanto, los bloqueos por número en cola tienen mejores características de bus multiprocesador porque no hay acceso compartido a la línea de caché durante la espera ocupada. Además, debido a la naturaleza de poner en cola los bloqueos por giro en cola, normalmente hay menos operaciones de bloqueo de bus que para los bloqueos por número estándar cuando un bloqueo está bajo contención de varios procesadores.

Los bloqueos por subproceso en cola son una de las varias mejoras que Microsoft ha hecho que la escalabilidad multiproceso Windows 2000.

¿QUÉ VA A LLEGAR?

Windows 2000 incluye numerosas características que hacen que sea más resistente a errores de operador y aplicaciones con comportamientos mal comportamientos. Una de ellas es que muchos de los archivos DLL y controladores del directorio y están protegidos por un watchdog denominado Protector de archivos del sistema %systemroot%\system32%systemroot%\system32\drivers (SFP). Puede comprobar su existencia si va a ese system32 directorio y cambia el nombre de ntoskrnl.exe . El watchdog se reactivará y le notificará que detectó la manipulación de un archivo del sistema protegido y lo está reparando. Si vuelve a comprobar el directorio, verá que ntoskrnl.exe se ha reemplazado mágicamente. La próxima vez le contaré cómo funciona esto.


Gracias por leer el Boletín de información interna de sistemas.

Publicado el sábado, 15 de mayo de 1999 a las 7:15 p. m. por

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

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

Volumen 1, número 2 del boletín de información interna del sistema

http://www.sysinternals.com