19 de junio de 1999: en este problema:

  1. NOVEDADES DE SYSTEMS INTERNALS

    • SDelete v1.1
    • Cadenas v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "Dentro de redes NT"
    • "NT Internals" de junio
    • NTFrob Update Status
    • Cosas no tan nuevas
  2. NOTICIAS INTERNAS

    • Numega DriverStudio publicado
    • SDK de plataforma de junio disponible
    • Protector de archivos del sistema win2K (SFP)
    • Cerrar archivos abiertos desde la red
  3. LO QUE VIENE

    • Una API "AWE"-some Win2K

PATROCINADOR: SOFTWARE DE HORARIOS DE VERANO

El Boletín de systems internals está patrocinioado por Newsnals Software, 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 Deserción incluyen FAT32 para Windows NT 4.0, ERD Commander (funcionalidad de disco de arranque para Windows NT) y NTRecover.

El software Desalmón anuncia el lanzamiento de Regmon y Filemon Enterprise Edition. Estas utilidades proporcionan toda la funcionalidad de filemon y regmon, y agregan estas eficaces características:

  • ver la actividad del registro y del sistema de archivos que tiene lugar en sistemas Win9x/NT remotos
  • registro de salida en un archivo en tiempo real
  • copiar líneas de salida en el Portapapeles
  • resaltar líneas que coinciden con un filtro
  • ver la salida de distintos equipos simultáneamente
  • imprimir la salida directamente en una impresora
  • recuperar fácilmente las últimas 5 selecciones de filtro

Obtenga información sobre pedidos y precios en http://www.winternals.com.


Hola a todos:

Le damos la bienvenida a la tercera edición del boletín de Systems Internals. El boletín tiene actualmente 4400 suscriptores.

En el último boletín, señalé cómo Microsoft ha terminado con la pantalla azul de la muerte, ya que sabemos que avanza a Windows 2000 (Win2K). La nueva pantalla azul win2K no tiene el controlador cargado y la información de volcado de pila que está presente en la pantalla azul de versiones anteriores de Windows NT. Le pregunte si encuentra la información que Microsoft ha quitado útil y le gustaría que hubieran dejado las cosas solas. La respuesta fue prácticamente positiva, y todos los encuestados (excepto uno) se preguntan por qué Microsoft va por el denominador común más bajo. Esta es una opinión típica, enviada por Antonio Lavinio:

Por lo tanto, en otras palabras, esta es la respuesta del cliente en la que Microsoft basa su decisión:

"No lo sé, por lo que debe ser malo; hacer que se vaya".

¿Por qué no quitan toda la pantalla y ponen un mensaje que dice "Pull Plug, Reinsert Plug, Start Over"? ¿Por qué quitan una de las pocas pistas que tenemos sobre por qué las cosas salió mal?

Al menos antes, si fuera un escáner de virus, un desfragmentador o un controlador defectuoso, tendríamos un punto desde el que empezar a buscar.

Si esta herramienta solo ayuda a 1 de cada 10 000 de nosotros, con la amplia base de implementación de NT, merece la pena. Especialmente porque el 01 % admite una buena parte del otro 99,99 %.

Quién sintrona el solo disidente? No es muy sorprendente que sea alguien de Microsoft el que fields Blue Screen crash reports (Informes de bloqueo de pantalla azul). Este es su desenlaz en el cambio, que confirma la especulación de Antonio sobre el motivo:

Trabajo en el grupo de instalación de NT en PSS en MS (que controla la solución de problemas de pantalla azul). Puedo asegurarle que la mayoría de las personas con las que hable no saben qué hacer con la información de una pantalla azul 4.0. Estoy seguro de que si ha visto una detección de 0xA con NAIFILTR.SYS en toda la pila, sabrá actualizar el antivirus, pero la mayoría de las personas no establece esa conexión y realmente no se dan cuenta de que el código de detección y los params son útiles para ellos. Es probable que las personas que entiendan cómo interpretar los datos de la pantalla azul estén desatendadas, pero desafortunadamente son una minoritaria.

Como he indicado en el último boletín, creo que Microsoft debe llevar la pantalla azul NT 4.0 hacia delante, manteniendo la lista de controladores cargados y el volcado de pila. También creo que podrían mejorar la pantalla azul proporcionando más información, no menos. Por ejemplo, ¿por qué no mostrar el nombre del proceso que se está ejecutando actualmente en el momento del bloqueo? O bien, ¿tienen más llamadas BugCheck que pasen la dirección del error, no solo la dirección que ha defectuoso? Una razón principal por la que PSS se encontró con tantos clientes que no tienen pistas sobre la pantalla azul es que Microsoft nunca escribió documentación sobre cómo leerla. Por lo tanto, al menos una parte de la responsabilidad de la omisión del usuario depende del propio gobierno de Microsoft.

Si desea obtener más información sobre cómo se producen las pantallas azules y lo que hay en (NT 4). Pantalla azul, consulte mi artículo de diciembre de 1997, "Inside the Blue Screen", de Windows NT Magazine (puede acceder a la versión en línea desdehttp://www.sysinternals.com/publ.htm).

Como de costumbre, pase el boletín a los amigos que cree que le pueden interesar.

Gracias

-Mark

NOVEDADES DE SYSTEMS INTERNALS

SDELETE V1.1

En el último boletín, presenté SDelete, una utilidad de eliminación segura que puede usar para destruir irrecuperablemente los datos de archivo, así como para limpiar el espacio libre de un disco de datos eliminados previamente. La primera versión de SDelete no pudo sobrescribir de forma segura los nombres de los archivos que se eliminan con él. El nombre de un archivo a menudo revela información confidencial y el uso de SDelete para eliminar un archivo con un nombre revelador podría dejar esa información expuesta. Para solucionar este bucle, he actualizado SDelete para no solo sobrescribir de forma segura los datos de archivo, sino también los nombres de archivo. SDelete elimina de forma segura un nombre de archivo cambiando el nombre del archivo 26 veces, reemplazando cada letra del nombre del archivo por letras sucesivas del alfabeto, de "A" a "Z".

Descargue SDelete v1.1 con código fuente completo en http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Los archivos ejecutables y dll a menudo tienen cadenas incrustadas que pueden revelar valores del Registro no documentados y mensajes de error que suenen la funcionalidad no documentada. Desafortunadamente, la mayoría Windows archivos DLL y EXE del sistema NT/2K se escriben para usar cadenas de caracteres Unicode, mientras que las herramientas de búsqueda de cadenas tradicionales, como Grep, solo extraen cadenas ASCII. He escrito la primera versión de la utilidad Strings hace unos años para examinar archivos binarios en busca de cadenas de caracteres ASCII o Unicode. Lo he usado muchas veces en mi investigación sobre los aspectos internos de NT para ayudar a averiguar las cosas que Microsoft no documenta.

Sin embargo, las cadenas siempre tenían un error importante y esa era su incapacidad de tomar una expresión comodín como especificador de archivo para poder examinar varios archivos en una sola toma. Quería esta característica para que, dado el nombre de un valor del Registro, por ejemplo, pudiera determinar fácilmente qué archivos DLL del sistema hacen referencia a ella.

Por último, he actualizado Cadenas para que tome nombres de archivo comodín completos, así como directorios recursos. Si especifica una expresión comodín Strings prefida automáticamente las líneas de salida con el nombre del archivo en el que se encuentra una cadena, por lo que puede hacer algo parecido a esto:

strings *.dll | grep SafeBoot

La visualización de la salida de esta expresión (una versión de Grep está disponible en las utilidades posix del Kit de recursos de WINDOWS NT) le informa de qué archivos DLL del sistema comprueban la clave del Registro SafeBoot en Windows 2000. Las cadenas también son muy útiles para ver qué nuevos valores del Registro usan los archivos DLL, controladores y ejecutables del sistema win2K. Por ejemplo, usé Cadenas para comparar los valores del Registro a los que se hace referencia en la pila TCP/IP de NT 4.0 SP4 (tcpip.sys) con los a los que hace referencia la pila TCPIP de Windows 2000. Estos son aproximadamente la mitad de los valores que son nuevos en la pila TCPIP de Win2K (todos los cuales se supone que se encuentran en HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters ):

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

No voy a esperar a que Microsoft documente todos los nuevos parámetros de configuración de la pila.

Puede descargar Strings v2.0 en http://www.sysinternals.com/misc.htm.

LOGGEDON

¿Alguna vez ha deseado saber quién ha iniciado sesión en un sistema NT remoto? Si es así, querrá descargar LoggedOn. LoggedOn es una utilidad sencilla que le mostrará qué usuarios han iniciado sesión interactivamente en el equipo local o en uno remoto, así como qué usuarios han iniciado sesión a través de conexiones de recursos (por ejemplo, un recurso compartido de archivos o impresoras). Esta es la salida de LoggedOn de ejemplo:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT y Win2K no proporcionan una API que las aplicaciones pueden usar para determinar quién ha iniciado sesión en un equipo, pero LoggedOn HKEY\USERS lo determina consultando las claves del Registro que se cargan en un sistema. Árbol del Registro. Los perfiles de cualquier usuario que haya iniciado sesión de forma interactiva se cargan en esta clave y los perfiles tienen nombres que identifican el SID (identificador de seguridad) de la cuenta de usuario asociada del perfil. Por ejemplo, si abre Regedit y mira HKEY_USERS debajo, verá algo parecido a lo siguiente:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

En este caso, solo un usuario ha iniciado sesión de forma interactiva. Puede decir a su administrador local o de dominio porque el RID (identificador relativo) es 500, que es el RID NT reserva para las cuentas de administrador.

Mediante el uso de API que permiten que un sistema busque en el Registro de otro sistema, LoggedOn lee la clave HKEY_USERS de un equipo remoto y convierte los SID que encuentra en nombres de cuenta. Para determinar quién ha iniciado sesión a través del recurso compartido de recursos LoggedOn, usa la API de NET, que se documenta en el SDK. La herramienta de línea de comandos net hace un uso amplio de la API de NET. Un efecto secundario del acceso de LoggedOn al Registro de un sistema remoto es que la cuenta que ejecuta LoggedOn en siempre aparecerá como iniciada en un sistema remoto a través de un recurso compartido de recursos en la salida de LoggedOn.

Puede descargar LoggedOn con código fuente completo en http://www.sysinternals.com/misc.htm.

FILEMON V4.13

Filemon v4.13 se acaba de publicar, una actualización que refleja los cambios en el controlador del filer de Windows NT y corrige un error que inadvertidamente se introdujo en el controlador 4.12. El controlador de filtro 4.13 tiene estos cambios:

  • usa el tipo de sincronización de recursos para proteger algunas de sus estructuras de datos internas.
  • controla el nuevo IRP de Win2K, IRP_MJ_PNP_POWER

El tipo de sincronización de recursos está prácticamente sin documentar en los kits de desarrollo de controladores de dispositivo (DK) Windows NT 4.0 y Win2K. La Guía de diseño ni siquiera menciona los recursos, mientras que sus funciones se documentan en la referencia de la sección "Rutinas de soporte ejecutivo". Los recursos son un mecanismo útil para proteger estructuras de datos que se pueden leer simultáneamente por subprocesos diferentes, pero que requieren acceso exclusivo por parte de un subproceso durante una actualización. Por lo tanto, son bloqueos de lector/escritor que los lectores adquieren para el acceso compartido y el acceso exclusivo por parte de los escritores. Los controladores del sistema de archivos hacen un uso amplio de los recursos, por lo que me parece adecuado actualizar Filemon para usarlos cuando corresponda.

Filemon v4.13 también controla el nuevo IRP de IRP_MJ_PNP_POWER para que sea un controlador de filtro descriptivo de power and plug-and-play cuando se ejecuta en Win2K. El único requisito de un controlador de filtro del sistema de archivos para controlar los IRP de este tipo es pasarlos a los dispositivos del sistema de archivos a los que está asociado el filtro.

Puede descargar Filemon v4.13 con código fuente completo en http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE es un monitor de salida de depuración versátil que puede usar para capturar la salida de depuración local o remota generada por programas Win32 o controladores de dispositivo en modo kernel en Win95, Win98, WinNT y Win2K. Su utilidad está limitada en entornos en los que un usuario experimenta un bloqueo mediante un controlador de dispositivo; sin embargo, toda la salida de depuración que DebugView captura antes de que se pierda un bloqueo. La versión más reciente de DebugView/EE soluciona este problema en Windows NT/2K. Si un usuario captura la salida en modo kernel generada por un controlador de dispositivo y el usuario ha configurado NT para guardar un volcado de memoria, DebugView/EE puede extraer la salida de depuración del archivo de volcado cuando se reinicie el sistema. Use DebugView/EE's Edit| Seleccione el menú Procesar volcado de memoria para que analice un volcado de memoria para la salida de depuración. Esta característica permite a los usuarios devolver un archivo de texto que contiene la salida de depuración generada por el controlador hasta el momento del bloqueo.

Descargue DebugView/EE v3.1 enhttp://www.sysinternals.com/debugview.htm.

"INSIDE NT NETWORKING"

Mi columna "NT Internals" Windows de marzo de 1999 está en línea. Obtenga información sobre la arquitectura de red de NT de arriba abajo, incluidas las API que implementa, cómo las pilas de protocolos se interfacen con las API y cómo los proveedores de hardware escriben controladores de red para trabajar con controladores de protocolo. Además, descubra algunas características nuevas de las redes de Win2K, incluida la compatibilidad con NDIS y ATM deserialización.

Lea "Dentro de redes NT" y otras columnas internas de NT anteriores en línea en http://www.sysinternals.com/publ.htm.

JUNIO "NT INTERNALS"

La instalación de junio de la columna Windows NT Magazine es "Inside EFS, Part 1" (Dentro de EFS, parte 1). En este artículo se describe la arquitectura de Sistema de cifrado de archivos (EFS) de Microsoft y se le guía por los pasos que EFS sigue al cifrar un archivo. EFS proporciona una instalación de cifrado transparente para unidades NTFS Win2K y Microsoft la desarrolló específicamente para abordar la capacidad de nuestra herramienta NTFSDOS de leer archivos NTFS sin tener en cuenta su seguridad. Esta columna estará disponible en línea en tres meses.

Hace dos boletines hablamos de cómo las API de EFS necesarias para realizar copias de seguridad y restaurar archivos cifrados no están documentadas. Desafortunadamente, estas API todavía no están documentadas en la edición actual de MSDN. Sin embargo, se me ha informado de que Microsoft envía la documentación, que está marcada como "Microsoft Confidencial", a sus asociados y a los proveedores de software de copia de seguridad. Además, David Golds, administrador de programas de sistemas de archivos de Microsoft, presentó una charla sobre las mejoras del sistema de archivos para Win2K en la reciente conferencia de Microsoft TechEd en Dallas. En la presentación, las diapositivas para las que puede ver en línea en , menciona que las API de copia de seguridad no están documentadas, pero que puede darle un error si quiere la http://www.teched99.com/slides/1-337.ppt documentación. Desafortunadamente, su dirección de correo electrónico no aparece en las diapositivas.

Visite http://www.winntmag.com para obtener Windows de suscripción de NT Magazine.

NTFROB UPDATE STATUS

NTFrob es una utilidad que publicé hace un par de años y que permite configurar con precisión las longitudes cuánticas de los procesos de primer plano y de segundo plano en NT 4.0. NTFrob modifica las estructuras de datos internas del kernel de NT, por lo que es muy específico de Service Pack. Desde el lanzamiento de NT 4.0 Service Pack 5, he recibido consultas que me preguntan cuándo voy a publicar NTFrob v1.5, la actualización de SP 5. La respuesta es que la actualización está próxima: estoy esperando a que Microsoft proporcione a los suscriptores de MSDN sp5, incluida la información de depuración. Necesito información de depuración para actualizar NTFrob para los nuevos Service Packs.

Puede descargar NTFrob para NT 4 SP0-4 en http://www.sysinternals.com/ntfrob.htm.

COSAS NO TAN NUEVAS

Hace unos meses he publicado un monitor de puerto serie y paralelo Win9x/NT/2K en Systems Internals. Portmon permite ver exactamente cómo interactúan las aplicaciones con los puertos serie y paralelo, incluidos los datos que envían y reciben. Puede usarlo para ver sesiones de acceso telefónico, conexiones serie laplink o actividad de impresora. Portmon ha sido un gran éxito y recientemente obtuvo 5 estrellas de la biblioteca de software de Ziff-Vmm, la clasificación más alta posible. Otras herramientas de Systems Internals que han ganado 5 estrellas son Regmon, NTFSDOS y BlueSave.

Descargue Portmon en http://www.sysinternals.com/portmon.htm.

NOTICIAS INTERNAS

DRIVERSTUDIO PUBLICADO

NuMega Labs de CompuWare ha publicado DriverStudio, un kit de herramientas completo para Windows desarrolladores de controladores de dispositivos 9x/NT/2K. Incluye SoftICE 4.0, BoundsChecker para controladores, VtoolsD, DriverAgent, DriverWorks, FieldAgent para controladores y, en el futuro, agregará TrueTime para controladores y TrueCoverage para controladores. Como he dicho en el último boletín, se trata de un kit de herramientas para desarrolladores que debe tener. NuMega también ha lanzado un sitio web orientado al desarrollador de controladores de dispositivos denominado "Driver Central": http://www.numega.com/drivercentral/default.asp.

SDK DE LA PLATAFORMA DE JUNIO PUBLICADO

Ahora puede descargar la versión de junio del SDK de plataforma de Microsoft en http://www.msdn.microsoft.com/developer/sdk/platform.asp.

PROTECTOR DE ARCHIVOS DEL SISTEMA WIN2K (SFP)

Uno de los mayores grupos de administradores y usuarios de sistemas NT es el "demonio dll" de NT. Dll hell es el resultado de que muchas aplicaciones actualicen archivos DLL clave del sistema con versiones que agrupan. Normalmente, las aplicaciones lo hacen para que puedan garantizar que funcionan correctamente; sin embargo, cuando reemplazan un archivo DLL, muchas veces se interrumpirán otras aplicaciones instalando versiones incompatibles o incluso "actualizar" un archivo DLL a una versión anterior.

Microsoft ha solucionado problemas de control de versiones de ARCHIVOS DLL en Win2K con la introducción del Protector de archivos del sistema (SFP). En realidad, su nombre cambiará pronto a Windows File Protector (WFP), pero a partir de beta 3 (compilación 2031) sigue siendo SFP. SFP se implementa en un archivo DLL denominado sfc.dll que el proceso winlogon (winlogon.exe) carga cuando se inicia el sistema. SFP incluye una lista integrada de aproximadamente 3000 archivos DLL estándar del sistema Win2K, ejecutables (.exe), archivos de instalación (.inf), controladores (.sys) y archivos de fuente (.fon) instalados en 30-40 directorios diferentes. Cuando SFP inicializa, ejecuta una operación de directorio change-notify en cada directorio que contiene archivos que protege. Cuando detecta la manipulación de un archivo, aparece un cuadro de diálogo que informa al usuario actual, escribe un elemento par en el registro de eventos y reemplaza el archivo modificado por una copia de seguridad almacenada en %systemroot%\system32\dllcache. Si falta el archivo de copia de seguridad que busca SFP en dllcache o también se ha alterado, SFP recupera una copia nueva del medio de instalación de Win2K.

Para ver qué archivos protege SFP, puede usar la utilidad Strings mencionada en otra parte de este boletín para volcar los nombres de cadena Unicode insertados en %systemroot%\system32\sfc.dll.

Las únicas utilidades que pueden actualizar archivos del sistema son hotfix.exe, Service Pack (update.exe), instalaciones de actualización y el servicio de actualización win2K. ¿Cómo omiten estas herramientas el SFP? Lo deshabilitan temporalmente llamando a la función sfc.dll exportada SfcTerminateWatcherThread y se aseguran de reflejar las actualizaciones en el subdirectorio dllcache. Debe tener en cuenta que Win2K requiere que Microsoft firme digitalmente todos los archivos del sistema, por lo que generalmente no es posible actualizar un archivo del sistema con una versión arbitraria propia.

Los programas Win32 pueden buscar cambios en un directorio mediante las API FindFirstChangeNotification y FindNextChangeNotification win32. Sin embargo, estas API simplemente informan a una aplicación de que algo ha cambiado. no le dicen a la aplicación exactamente lo que ha cambiado. Por lo tanto, es necesario que una aplicación analice todo un directorio para determinar qué archivos o subdirectorios pueden haber cambiado. SFP usa NT Native API para realizar una solicitud de notificación de cambios en la que NT le indica exactamente qué archivos o subdirectorios cambian en los directorios supervisados. La función que usa SFP se denomina NtNotifyChangeDirectoryFile y, al igual que el 90 % de la API nativa de NT, no está documentada. Busque un applet en Systems Internals en un futuro próximo que muestre cómo usar NtNotifyChangeDirectoryFile.

Mi columna "NT Internals" de septiembre, "Inside Win2K Reliability Enhancements, Part 2" (Mejoras de confiabilidad de Win2K, parte 2) describe SFP con más detalle.

CERRAR ARCHIVOS ABIERTOS DESDE LA RED

Una de las preguntas más frecuentes que tengo de los visitantes de Systems Internals es "¿cómo se cierran los archivos que los usuarios tienen abiertos desde la red?". Si un usuario tiene un archivo o directorio abierto de forma remota, no es posible eliminar, cambiar el nombre o actualizar el archivo o directorio localmente. Una pregunta similar es"¿Cómo ver qué archivos han abierto los usuarios desde la red?". Ambas preguntas se responden con la utilidad de línea de comandos Net que se incluye Windows NT/2K. Para ver qué archivos se abren, simplemente escriba "net file". Verá una lista de nombres de archivo abiertos, los identificadores de nombre de archivo correspondientes y los nombres de los usuarios que tienen archivos abiertos. Para cerrar uno de los archivos que ve abiertos, escriba net file <id> /close . Para ver los archivos abiertos localmente, puede usar mis herramientas NTHandle o HandleEx.

Las API que subyacen a la funcionalidad de visualización y cierre de archivos del comando Net se documentan en el SDK de plataforma y en MSDN Library. Use netFileEnum API para enumerar los archivos abiertos y la API NetFileClose para cerrar un archivo abierto. En realidad, las API permiten enumerar los archivos abiertos en servidores remotos, algo que el comando Net no permite.

NTHandle está disponible en http://www.sysinternals.com/nthandle.htm. HandleEx está disponible en http://www.sysinternals.com/handleex.htm.

¿QUÉ VA A LLEGAR?

UNA API "AWE"-SOME WIN2K

Win2K presenta una nueva API denominada AWE (extensiones de ventana de direcciones) que las aplicaciones que consumen mucha memoria pueden usar para acceder directamente y administrar grandes cantidades de RAM física, incluso más de 3 GB, el límite superior de RAM que una aplicación de Windows NT puede abordar en su espacio de direcciones virtuales. De hecho, si un sistema x86 tiene PSE (extensiones de tamaño de página) y más de 4 GB de RAM, una aplicación puede usar AWE para aprovechar toda la memoria del equipo. Por lo tanto, esta API es ideal para aplicaciones con mucha memoria, como servidores web y servidores de bases de datos. La próxima vez le voy a decir cómo usar las API, tanto desde aplicaciones Win32 como desde controladores de dispositivos.

Mientras estoy en el tema de las aplicaciones con mucha memoria, esta es una sugerencia para cualquier persona que escriba una aplicación que almacena en caché archivos (como un servidor web). El Windows NT Cache Manager divide su memoria caché en ranuras de 256 KB denominadas "vistas". Si se almacena en caché un archivo de menos de 256 KB, el Administrador de caché debe seguir asignando al archivo una ranura completa de 256 KB, lo que significa que parte de la memoria virtual de la memoria caché se desperdicia. Por lo tanto, por lo general es más eficaz para almacenar en caché archivos de menos de 256 KB en la memoria virtual de su propia aplicación y para confiar en el sistema de archivos para almacenar en caché archivos de más de 256 KB de tamaño. IIS 5.0 usa este truco.


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

Publicado el sábado, 19 de junio de 1999 a las 7:14 p. m. por

[Archivo de boletín ^][ Volumen 1, número 2][Volumen 1, número 4 ]

[Archivo de boletín ^][ Volumen 1, número 2][Volumen 1, número 4 ]

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

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinvl