Internet Explorer se cuelga por algunos segundos

A diferencia de los otros casos descritos, en esta oportunidad quien estaba en problemas era yo mismo, con un síntoma que seguro a alguno de ustedes le ha ocurrido antes. Veamos de que se trata.


Síntomas


Cada vez que abría una nueva instancia de Internet Explorer, como también al abrir una nueva pestaña de una instancia que ya llevase corriendo, algunas veces se demoraba una buena cantidad de segundos (entre 10 y 15 segundos) en quedar disponible para poder usarla. Si bien el proceso se creaba y se pintaba rápidamente (menos de 1 segundo), quedaba como “esperando” algo.


Esta es una ventana del navegador en ese estado intermedio de espera.



Una vez que la espera termina, el navegador funciona como se espera. Sin embargo, si se deja pasar un tiempo sin hacer nada en la ventana de éste, al tratar de usarlo nuevamente, ya sea creando un tabulador nuevo o incluso cerrando el proceso, otra vez debo esperar una cantidad de segundos similar a la anterior.


En resumen, mientras esté usando la ventana (haciendo clics), todo bien. Dejo de usarla un rato, hay que esperar para que reaccione.


Intención de detección del problema


Aunque sabía que no sería nada fácil encontrar el problema, hice mi intento usando [windbg] y atachándome al proceso una vez creara un nuevo tab mientras estaba “esperando”.


Un listado de los threads relevantes (0 y 5) y sus stacks correspondientes en el momento de espera mostraba lo siguiente.





   0  Id: 12f0.123c Suspend: 1 Teb: 7efdd000 Unfrozen
ChildEBP RetAddr
002ce690 7d4e286c ntdll!NtWaitForMultipleObjects+0x15
002ce738 7d94d299 kernel32!WaitForMultipleObjectsEx+0x11a
002ce794 02596029 user32!RealMsgWaitForMultipleObjectsEx+0x152
002ce7b4 0259632d ieui!CoreSC::Wait+0x49
002ce7dc 025960d8 ieui!CoreSC::WaitMessage+0x54
002ce7e8 4640994d ieui!WaitMessageEx+0x33
002ce818 463fabcc ieframe!CBrowserFrame::FrameMessagePump+0x199
002ce824 463fbc3b ieframe!BrowserThreadProc+0x3f
002ce848 463fbb89 ieframe!BrowserNewThreadProc+0x7b
002cf8b8 463fba39 ieframe!SHOpenFolderWindow+0x188
002cfae8 00401464 ieframe!IEWinMain+0x2d9
002cff2c 004012ff iexplore!wWinMain+0x2c1
002cffc0 7d4e7d2a iexplore!_initterm_e+0x1b1
002cfff0 00000000 kernel32!BaseProcessStart+0x28

5 Id: 12f0.12e8 Suspend: 1 Teb: 7efa9000 Unfrozen
ChildEBP RetAddr
02fee038 7d4d8c82 ntdll!ZwWaitForSingleObject+0x15
02fee0a8 7da3936a kernel32!WaitForSingleObjectEx+0xac
02fee0c4 7da3ba11 rpcrt4!UTIL_WaitForSyncIO+0x20
02fee0e8 7da3b9eb rpcrt4!UTIL_GetOverlappedResultEx+0x1d
02fee104 7da3b9a9 rpcrt4!UTIL_GetOverlappedResult+0x17
02fee124 7da3ad05 rpcrt4!NMP_SyncSendRecv+0x73
02fee14c 7da3af2d rpcrt4!OSF_CCONNECTION::TransSendReceive+0x7d
02fee1d4 7da3aea2 rpcrt4!OSF_CCONNECTION::SendFragment+0x2ae
02fee22c 7da3b1b9 rpcrt4!OSF_CCALL::SendNextFragment+0x1e2
02fee274 7da3b834 rpcrt4!OSF_CCALL::FastSendReceive+0x148
02fee290 7da3b7b7 rpcrt4!OSF_CCALL::SendReceiveHelper+0x5b
02fee2c0 7da37d3e rpcrt4!OSF_CCALL::SendReceive+0x41
02fee2cc 7da37cf0 rpcrt4!I_RpcSendReceive+0x24
02fee2e0 7dac01b6 rpcrt4!NdrSendReceive+0x2b
02fee6c8 71c4b685 rpcrt4!NdrClientCall2+0x22e
02fee6e0 71c4b644 netapi32!NetrLogonGetTrustRid+0x1c
02fee720 7da4af08 netapi32!I_NetlogonGetTrustRid+0x1e
02fee768 7da4ae60 rpcrt4!GetMachineAccountSid+0xcb
02fee780 7da3f97e rpcrt4!NormalizeAccountSid+0x4c
02fee88c 7da4aaa4 rpcrt4!LRPC_CASSOCIATION::OpenLpcPort+0x1e9
02feeb88 7da4a40b rpcrt4!LRPC_CASSOCIATION::CreateBackConnection+0x74
02feebc4 7da456fb rpcrt4!LRPC_CASSOCIATION::ActuallyDoBinding+0x32
02feec3c 7da3843a rpcrt4!LRPC_CASSOCIATION::AllocateCCall+0x190
02feec70 7da38366 rpcrt4!LRPC_BINDING_HANDLE::AllocateCCall+0x1f2
02feec9c 7da37a1c rpcrt4!LRPC_BINDING_HANDLE::NegotiateTransferSyntax+0xd3
02feecb4 7778c956 rpcrt4!I_RpcGetBufferWithObject+0x5b
02feecf8 7778c629 ole32!CRpcChannelBuffer::ClientGetBuffer+0x31c
02feed08 776c0e9e ole32!CRpcChannelBuffer::GetBuffer+0x20
02feed28 776c0f7a ole32!CAptRpcChnl::GetBuffer+0x209
02feed8c 7dac0fda ole32!CCtxComChnl::GetBuffer+0x1e5
02feeda8 7dac0f89 rpcrt4!NdrProxyGetBuffer+0x47
02fef190 776a3717 rpcrt4!NdrClientCall2+0x173
02fef1a8 7778b6e4 ole32!IClassFactory_RemoteCreateInstance_Proxy+0x1c
02fef1c4 776ad8ac ole32!IClassFactory_CreateInstance_Proxy+0x41
02fef24c 776aaf7e ole32!CServerContextActivator::CreateInstance+0x175
02fef28c 776ad9b6 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fef2e0 776ad92d ole32!CApartmentActivator::CreateInstance+0x110
02fef300 776acb27 ole32!CProcessActivator::CCICallback+0x6d
02fef320 776acad8 ole32!CProcessActivator::AttemptActivation+0x2c
02fef35c 776ada17 ole32!CProcessActivator::ActivateByContext+0x4f
02fef384 776aaf7e ole32!CProcessActivator::CreateInstance+0x49
02fef3c4 776aaf19 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fef614 776aaf7e ole32!CClientContextActivator::CreateInstance+0x8f
02fef654 776ab10f ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
02fefe08 776a679a ole32!ICoCreateInstanceEx+0x3f8
02fefe3c 776a6762 ole32!CComActivator::DoCreateInstance+0x6a
02fefe60 776a6963 ole32!CoCreateInstanceEx+0x23
02fefe90 4635a747 ole32!CoCreateInstance+0x3c
02fefec0 4638f691 ieframe!SHCoCreateInstanceAC+0x9e
02feff08 463c167a ieframe!WinList_RegisterPending+0x2c
02feff4c 463ee4b9 ieframe!CTabWindow::_RegisterPendingWindow+0x149
02feffb8 7d4dfe21 ieframe!CTabWindow::_TabWindowThreadProc+0x99
02feffec 00000000 kernel32!BaseThreadStart+0x34


El thread 0 es el thread principal y aparentemente no está haciendo mucho, salvo esperar que el kernel le avise que ciertos eventos han ocurrido.


Sin embargo, el thread 5 sí está haciendo algo y es exactamente lo que yo le había pedido. Crear un tabulador. Esto lo puedo inferir por las llamadas a las funciones con nombres acordes, como se puede apreciar ahora





<cortado …>
02feff4c 463ee4b9 ieframe!CTabWindow::_RegisterPendingWindow+0x149
02feffb8 7d4dfe21 ieframe!CTabWindow::_TabWindowThreadProc+0x99
02feffec 00000000 kernel32!BaseThreadStart+0x34

Ok, tenemos el thread que crea el tabulador. ¿qué más?


Mirando el stack, se puede observar creación de objetos COM, posiblemente una creación de contexto de COM o una reutilización de uno existente (no estoy del todo seguro de cual opción), una llamada RPC, interacción con el sub-sistema de Windows (kernel32.dll) y el kernel (ntdll.dll).


A diferencia de una revisión de aplicaciones como asp.net o asp tradicional, donde uno espera encontrar código del cliente que no está optimizado y que consume recursos, en esta oportunidad no había código de terceros. El camino se veía difícil.


Golpes de suerte


Con dos sucesivos golpes de suerte logré dar con el problema, pero jamás podría haberlo detectado sin un post de Mark Russinovich, donde él experimentó un problema similar. El primer golpe de suerte fue elegir alguna función que pareciese sospechosa y luego, livear en internet. La función elegida fue GetMachineAccountSid y la búsqueda retornó este post en primera opción.


http://blogs.technet.com/markrussinovich/archive/2006/08/31/453100.aspx
The Case of the Process Startup Delays


Con ese título del post, claramente estábamos enfrentando el mismo problema. Eso sí, la diferencia es que Mark sabe reconocer el problema, pero uno debe apelar a la suerte y a los buscadores de internet. [:)]


Haciendo pruebas similares a las del post mencionado, obtuve respuestas similares.



Bien. Traté de atacharme a lsass.exe (local security authority subsystem) con nefastos resultados. Una vez atachado windbg a lsass, hice una mala maniobra y windbg dejó de responder, haciendo que el sistema quedase medianamente bloqueado (respondía muy lento) ya que muchos procesos depende de lsass.exe. Como no hubo más opción que matar windbg, esto traería como consecuencia que el proceso que se estaba debugueando también moriría. Y si muere lsass.exe, el sistema operativo te pide amablemente reiniciar, con una pantalla similar a la pantalla del virus que atacaba XP antes de SP2 y que te daba 48 segundos para cerrar todo.


La consecuencia.



Como dirían en algunos programas de televisión; “niños, no traten de hacer esto en casa,” o mejor dicho, no lo hagan mientras visitan a un cliente y deben trabajar con su equipo.


Resolución


A diferencia del post de Mark, en donde el causante del problema era Defender, en este caso no había un tercer involucrado que remover del sistema.


La solución no fue la más elegante, pero no tuve más alternativa que ejecutar Internet Explorer en el contexto de un usuario local de la máquina, para así evitar que se trate de obtener información desde el dominio, el cual no puede ser alcanzado.


Lamentablemente esto trajo como consecuencia que no pudiese accesar a mi historial ni favoritos. Espero que cuando logre conectarme al dominio se acaben los problemas.


Saludos,
Patrick

Signos vitales de un servidor: Parte III (disco)

Después de unos días de descanso debido a las fiestas ampliamente conocidas, continuamos con la tercera entrega de la serie de monitoreo de signos vitales de un servidor, en la cual presentaremos la información necesaria para detectar problemas de rendimiento en las unidades lógicas de disco de un servidor.


Si bien es posible determinar problemas en unidades físicas, las diferentes configuraciones físicas de arreglos RAID 0, 1, 5, 1+0 y 0+1 y la creación posterior de unidades lógicas en el arreglo, hace muy difícil, si es que no imposible, el determinar si es o no un disco físico específico.


Antes de comenzar, hago un mini corte para recomendar este link de una presentación de David Solomon sobre cómo maneja la memoria Windows y como hacer un troubleshooting básico de los problemas. Además, se da tiempo de romper algunos mitos. Definitivamente un video imperdible. Está en inglés y dura 1 hora y 37 minutos.


http://www.microsoft.com/uk/technet/itsshowtime/sessionh.aspx?videoid=64


Diferentes caminos


Para la verificación de los contadores de disco, existen dos caminos conocidos. Uno de ellos el difícil y otro mucho más simple y agnóstico del hardware.


El primer camino, el cual NO veremos aquí corresponde a obtener información de los IOs de los discos, calcular la cantidad de operaciones de lectura y escritura que se realizan por cada tipo de RAID, la cantidad de discos físicos (ejes) involucrados en el RAID y hacer una cantidad importantes de cálculos y asumir con poca certeza algunas constantes o valores.


El segundo camino, mucho más simple, es agnóstico del tipo de RAID, la cantidad de discos y otras variables. ¿Qué es lo que mide? muy simple y básico:


¿Cuánto tiempo se demora el sistema de discos en realizar una operación de escritura o lectura?


Si se demora “mucho,” hay un problema. Si se demora “poco,” estamos bien. Si tienes picos elevados constantes, podemos estar en presencia de algún inconveniente o escasez de capacidad de procesamiento.


Además de la información relacionada con escrituras y lecturas, se debe complementar con información general del disco como el porcentaje de tiempo disponible y largo de la cola de requerimientos.


Veamos los contadores y contra qué compararlos, es decir, que es “bueno” y “malo.”


Nota: Antes de comenzar aclaro que cuando digo disco “malo,” no estoy mencionando que el disco está malo físicamente o que presenta alguna falla sino que realmente me refiero a que el disco no responde de acuerdo a lo que es espera de él, generalmente producto de una tasa muy elevada de requerimientos.


Contadores


Los contadores a medir del objeto Logical Disk, para la instancia específica (c:, d:, etc.), son los siguientes:




  • Avg Disk Sec/read: milisegundos en que una operación de lectura es llevada a cabo.



  • Avg disk Sec/write: milisegundos en que una operación de escritura es llevada a cabo.



  • % Idle time: porcentaje de tiempo que el disco está desocupado.



  • Avg disk queue length: largo promedio de la cola de requerimientos del disco



  • Current disk queue length: largo actual de la cola de requerimientos del disco


¿Contra que los comparamos?


Los dos primeros contadores se comparan contra la misma tabla de valores, la cual despliego a continuación:















Valor medido Significado
entre 1 milisegundo y 15 milisegundos Perfecto estado
entre 16 milisegundos y 25 milisegundos Se debe monitorear
más de 25 milisegundos Disco degradado

Se deben considerar valores promedios. Es esperable que un disco tenga picos por sobre los 25 milisegundos pero el valor promedio debe ser bajo.


Nota: Si tienes un storage con caché de escritura, deberás ser más estricto en las comparaciones y reducir un poco los valores. Esto se debe a que el caché de escritura mejora sustancialmente el rendimiento. Si antes 15 ms era el tope para considerar el valor como perfecto, entonces si mides 15 ms y tienes caché habilitado, no estarás dentro del grupo de perfecto estado sino que el rendimiento será medio y deberás monitorear la actividad.


Anécdota: El valor más alto que he presenciado en algunos casos ha sido de más de 900 milisegundos. Por supuesto, el servicio que se estaba exponiendo estaba severamente afectado, con tiempos de respuesta muy bajos.


El contador del tiempo porcentaje de tiempo disponible es simple también. Más de 50%, perfecto estado. Entre 20% y 50%, se deberá monitorear y menor a 20%, el disco está degradado.


Por último, para los contadores de largo de cola de requerimientos promedio y actual, estos dos valores se comparan y calculan de la misma forma. Si la cantidad de discos físicos que componen el arreglo de discos es conocida, se deberá comparar contra el valor medido menos la cantidad de discos y dividirlo por dos.


Por ejemplo: Si el valor medido del largo promedio de la cola de requerimientos es 25 y tengo 10 discos en el arreglo, la formula nos retorna: (25-10)/2 = 7,5.


Este valor es menor a 1, el rendimiento es excelente. Entre 1 y 3, se deberá monitorear. Mayor a 3, crítico o degradado.


Por supuesto, la formula presenta inconvenientes cuando los valores medidos son menores a la cantidad de discos, pero en ese caso el disco claramente no tiene problemas.


¿Qué sucede si no conozco la cantidad de discos? y bueno, en ese caso se recomienda dividir por 2 el valor medido en el contador y aplicar la misma regla de comparación. Entendemos que no es un valor fidedigno, pero tampoco es “tan errado.” Para el mismo ejemplo, 25/2  es 12,5, un valor mayor a 7,5, pero igual de malo de acuerdo a el parámetro de comparación.


Como pueden ver, monitorear un disco es muy simple. Si no responde en tiempos breves, claramente le estamos pidiendo más de lo que puede dar.


Queda pendiente una o dos entregas más de signos vitales, las que llegarán espero durante este mes.


Saludos,
Patrick

Signos vitales de un servidor: Parte II (procesador)

Continuando con los signos vitales de un servidor, hoy día veremos en la segunda parte, el procesador.


El análisis del procesador es bastante más simple que el de la memoria. Hay dos contadores importantes. Uno de ellos corresponde al uso del procesador, con dos matices especiales; uso del procesador en modo usuario y el otro en modo kernel. El otro contador corresponde a la cantidad de requerimientos encolados del procesador.


Como ya hemos visto en otros posts, Windows utiliza dos modos de ejecución. Uno de ellos es el modo usuario, donde corren las aplicaciones que nosotros ejecutamos y el otro es el modo Kernel, en el cual corre el kernel del sistema operativo.


¿Por qué es importante esta explicación?


Si logramos identificar quién está consumiendo el procesador, podremos inferir y tener mejores pistas para encontrar al culpable del consumo de éste.


Si te preguntas ¿para qué necesitas saber el modo (usuario o kernel) que está consumiendo el procesador, si mirando el task manager sabrás fácilmente qué aplicación es responsable?


Bueno. Hay un par de razones. Veamos cada una de ellas.


1.- Task manager te dirá la aplicación que está consumiendo el procesador, pero no te dirá más. Solo la aplicación. Perfmon por otra parte te podrá entregar más información. [procexp] de Sysinternals es una excelente herramienta.
2.- Task manager no muestra siempre el consumo del kernel.


El segundo punto no está tan relacionado con aplicaciones, pero vale la pena aclarar que hay ciertas actividades del kernel que no son cuantificadas por Task Manager, o son cuantificadas pero no desplegadas. Recordemos que el kernel corresponde al proceso llamado System, siempre con el PID 4. Entonces puede parecer que tu sistema tiene bajo uso del procesador, pero el kernel está trabajando activamente. Para mejores resultados en el despliegue de los recursos consumidos, puedes utilizar [procexp].


Resumiendo


Podemos decir que para una aplicación específica:


El porcentaje de consumo en modo kernel corresponde a las actividades que debe realizar el kernel para cumplir con los requerimientos de la aplicación, como por ejemplo, trabajar con archivos, mover memoria, escribir en sockets, pintar ventanas, etc.


El porcentaje de consumo en modo usuario corresponde a la ejecución de código sin interacción con el kernel, es decir, algo así como “el código sin acceso a recursos externos.” Si estuviésemos utilizando un profiler, diríamos entonces que corresponde a lo que se llama “exclusive time.”


Contadores


La siguiente es la lista de contadores de perfmon a utilizar, que como podrán notar, es muy breve, repetitiva y casi no requiere mayor explicación.




  • Objeto System, contador Processor Queue Length: muestra la cantidad de requerimientos encolados para el procesador.



  • Objeto Processor, contador % Privileged Time: muestra el porcentaje de tiempo utilizado por el kernel, para todo el procesador



  • Objeto Processor, contador % User Time: similar al anterior, pero para modo usuario



  • Objeto Process, contador % Privileged Time, instancia específica. muestra el porcentaje de tiempo utilizado por el kernel, para la aplicación seleccionada en el campo instancia



  • Objeto Process, contador % User Time, instancia específica: similar al anterior, pero para modo usuario



  • Objeto Thread, contador % Privileged Time, instancia específica: muestra el porcentaje de tiempo utilizado por el kernel, para un thread especifico de la aplicación seleccionada



  • Objeto Thread, contador % User Time, instancia especifica: similar al anterior, pero para modo usuario


Probablemente te podrás estar preguntando la utilidad de la información de los últimos 2 contadores. ¿de que te serviría saber cuál es el thread responsable si no se puede hacer mucho con esa información?


Si se puede hacer bastante. Puedes determinar si es un único thread que está ocupando mucho el procesador o es un conjunto de ellos en que todos aportan. Te sirve para obtener pistas.


Podría ser el thread o los threads del GC, el thread del Finalizador, un thread que se quedó pegado en un ciclo, etc. [procexp] entrega mucha información referente a tipos de procesos e informacón de los threads.


Ok, ya tengo todos los datos…


¿Contra qué comparar la información?


Salvo para el primer contador, no hay punto de comparación. Si el uso del procesador llega a 80% o más, probablemente sea hora de proveer alivio al servidor, ya sea corrigiendo el código o haciendo un upgrade del hardware.


El primer contador no debe ser mayor a 2 multiplicado por la cantidad de procesadores (cores) de tu servidor. Para el caso de HT (Hyper Threading), no estoy seguro, pero creo que no se deben contabilizar.


Ya vendrá una tercera entrega relacionada con el disco duro.


Saludos,
Patrick

Pantallas Azules, ¿hasta cuando?

Seguramente al leer el título de este post pensaste en que me voy a referir a las pantallas azules de Windows. Correcto. También puedes haber pensado que es un post para criticarlas. Bueno, eso no será así. Este post tiene como objetivo explicarlas.


Historia


Hace ya un par de años, leí un recorte en el típico mural de las empresas, que estaba escrito por alguien conocido por mí y un referente nacional en muchos aspectos.


El artículo escrito se llamaba “El software nuestro de cada día” y estaba escrito por José Miguel Piquer.


Jo y Microsoft


José Miguel, o “Jo” como le dicen los más cercanos, fue profesor mío en algunos cursos en la carrera de “Ingeniería Civil en Ciencias de la Computación e Informática,” en la Universidad de Chile.


Siempre un gusto ir a sus clases, magister, doctorado y varios títulos más que pueden leer en su página personal del Departamento de Ciencias de la Computación (DCC), le recuerdo como acérrimo detractor de Microsoft y Windows.


Artículo


Bueno, el inicio del artículo escrito por él, esboza la siguiente frase:


Hay que aceptar que resulta extremadamente frustrante enfrentarse a sistemas que se caen: desde las pantallas azules clásicas de Windows, pasando por los sitios webs bancarios que no responden, hasta las agendas y sus fatal exceptions que se están volviendo más norma que excepción.


Después, el artículo va realmente a lo importante que él quiere exponer, pero con ésta introducción cae lamentablemente en facilismos con una frase que no aporta mucho, más que exacerbar el cuento de “nunca acabar” de las pantallas azules.


El artículo está escrito en julio del 2005, diez años después del festín de pantallas azules que nos daban Windows 95, Windows 98, Windows 98 segunda edición y finalmente (por suerte!) Windows Millenium Edition.


En mis años de estudiante (93-99) nunca hubo un PC en la universidad (salvo el de la secretaria del DCC), así que dudo que él personalmente se haya enfrentado a un sistema de estos, aunque no es por ahí donde quiero llevar este post.


Profesor, todos esperamos mucho de usted. Por favor, no caiga en frases fáciles. No las necesita. Usted está lejos de ser un político.


En el año 2005, ya existía Windows 2003, sistema operativo que casi no presentaba pantallas azules. Más aún, en 4 años, no recuerdo haber visto una pantalla azul en Windows 2003, experiencia que seguramente tú compartes.


¿Son las pantallas azules exclusivas de Windows?


Casi. En los otros sistemas operativos no son necesariamente azules.


Pantallas azules de diferentes sistemas operativos


 Hagamos una revisión de las pantallas y los sistemas operativos.


Tenemos la clásica de Windows 9X.


¿Mac OS?, por supuesto que sí, aunque tienen una diferencia con las de Windows. Son más bonitas y mejor logradas, pero el mensaje no dice nada útil, y que el usuario no pueda intuir que tiene que hacer.







Bueno, no siempre son bien logradas, aunque el mensaje es de mayor utilidad que la pantalla anterior.



¿Linux?, claro que sí, en variadas distribuciones, aunque son llamadas Kernel Panic (un nombre más realista para el problema que analizaremos más adelante).





¿Quién esté libre de pecado…


…que lance la primera piedra?, o como dice mi amigo Luisón, el sol sale para todos, y la noche también.


Como ven, no hay sistemas operativos sin fallas, aunque Apple crea y venda lo contrario. Todos enfrentan los mismos problemas. Apple tiene una ventaja en este aspecto sobre Microsoft, la cual se minimizará en el tiempo, mientras se pueda instalar Windows Vista o XP sobre hardware homologado por Apple.


Además, es cosa de leer foros para darse cuenta de que Apple funciona bien con software Apple. Cuando empiezas a instalar software de terceros que no cuentan con buenos procesos de certificación, la situación se equipara.


Vamos a la teoría


Considerando la arquitectura de procesadores x86, en el año 1982, con el lanzamiento del 80286, se comienzan a dar los primeros pasos en lo que hoy se conoce como protected mode.


Protected mode, provee dentro de un conjunto de características, la existencia de cuatro niveles de privilegio, conocidos también como anillos (rings), numerados desde el 0 al 3.



El anillo 0 tiene acceso irrestricto a todo. El anillo 3 tiene accesos restringidos y acotados. El anillo 1 tiene más restricciones que el 0, pero menos que el 2 y menos que el 3 obviamente.


Anillos y Windows


Hoy en día, un sistema Windows 2003 ejecuta código en dos anillos. El 0 y el 3. También corre para XP y 2000. Tengo entendido que Vista utiliza el 0, 2 y 3, pero no lo puedo garantizar.


En el anillo 0 se ejecuta el Kernel de Windows, el cual realiza algunas de las actividades listadas a continuación. Administración de memoria, acceso al hardware a través del HAL, acceso a dispositivos utilizando drivers, priorización de actividades, plug and play, acceso a redes utilizando protocolos como TCP/IP o HTTP, etc.


En el anillo 3 se ejecutan las aplicaciones. Cada vez que una aplicación necesita de alguno de los elementos anteriormente mencionados, y que maneja el Kernel, necesita solicitárselo a éste ya que la aplicación no tiene permiso para acceder directamente.


Esta solicitud y cambio de contexto entre la aplicación y el Kernel tiene un costo, el cual fue tratado de minimizar en el pasado, pero las lecciones aprendidas fueron duras.


¿Por qué se producen?


Una pantalla azul en Windows se produce cuando se produce una falla en código que se ejecuta en el Kernel.


Si una aplicación se cae (anillo 3), nuestro amigo Dr. Watson la atiende y la mata, pero el sistema operativo sigue funcionando sin problema. Hoy en día, Windows te pregunta si deseas enviar el reporte de error a Microsoft, utilizando la aplicación Windows Error Reporting.


Si el Kernel falla (anillo 0), no hay remedio ni doctor que te salve. Bueno, Dr. Watson no salvaba las aplicaciones sino que les aplicaba la eutanasia. Con un Kernel con alguna excepción, no se puede seguir funcionando. Cualquier intento (teórico) de seguir funcionando podría implicar que se corrompan archivos en el disco, por ejemplo.


Mencionaba hace un rato que en Linux, la pantalla azul se llama Kernel panic. En efecto, eso es. Es un problema en el Kernel y no hay mucho más que hacer, salvo entrar en pánico.


En los SO Windows de hoy, versión 2000 en adelante, los motivos de las pantallas azules son los siguientes. Este gráfico fue generado con datos hasta el mes de Abril del 2004, obtenido del libro Windows Internals de Solomon y Russinovich.



El 15% desconocido se debe a que el nivel de corrupción en la información obtenida después de la caída es tan grande que no permite identificar ningún responsable.


Windows 9X y el festín de las pantallas azules


Por algún motivo de diseño, que jamás sabremos el origen, debido al costo del cambio de transición entre el anillo 3 y el 0, los diseñadores de ese sistema operativo consideraron que para mejorar el rendimiento, mucho código del sistema y aplicaciones correrían en el anillo 0.


Debido a esto, el más mínimo error en cualquier aplicación, podría comprometer el sistema completo, como ocurrió en la archiconocida presentación de Windows 98 de Bill Gates.


Esa fue una lección de duro aprendizaje.


Drivers


Como se pudo ver en el gráfico, el 70% de los problemas son producto de drivers de terceros que corren en el Kernel, y sólo el 5% es código defectuoso de Microsoft. Me gustaría saber cuál es la tasa actual, al final del 2007.


Cuando nosotros como usuarios instalamos un driver que no está certificado, estamos generando un potencial problema con nuestro computador. Por supuesto, ese driver puede estar muy bien desarrollado y jamás tendremos una pantalla azul.


En mi caso particular, el driver de mi webcam tiene problemas serios en Windows XP 64 bits. En Windows XP 32 bits funciona sin problema. En 64 bits, cada vez que abro el Messenger y la activo, pantalla azul. ¿Puede ser Messenger el responsable de la caída de mi equipo? Claro que no. Messenger corre en el anillo 3, pero el driver de mi webcam corre en el 0.


Windows Vista


Según tengo entendido, en Windows Vista, algunos o todos los drivers de terceros se ejecutan en el anillo 2, es decir, con mayor privilegio que las aplicaciones, pero con menor privilegio que el Kernel. Esto ayudaría enormemente a minimizar los problemas de pantallas azules producto de drivers defectuosos. Ya sabemos que para abril del 2004, el 70% de los errores reportados era por problemas de drivers defectuosos.


Parte de ésta información se puede encontrar aquí (sección Driver stability in Windows Vista), pero nada menciona de anillos. Sí menciona que parte del driver corre a nivel de usuario (anillo 3).


Ventaja de Apple


Apple tiene una gran ventaja sobre Microsoft, sin embargo, la posibilidad de instalar Windows sobre un equipo Apple mostrará nuevos aspectos en esta materia.


Como sabemos, el gran problema de Windows son los drivers de terceros.


Windows está hecho para que funcione sobre casi cualquier hardware que sea x86, x64 e IA64 compatible. Como hardware me refiero a placas madre, tarjetas de video de dudosa procedencia, memoria de dudosa procedencia, procesadores de segunda generación de Intel, tarjetas de red y cuanto hardware se pueda construir en el mundo.


Por otra parte, el hardware de los equipos Apple está homologado, probado y garantizado para que funcione bien, como piezas de una buena orquesta.


¿Qué sucede si quiero expandir la memoria de mi Apple? tengo que ir a Apple e instalar la que ellos dicen que funciona.


¿Qué sucede si quiero expandir la memoria de mi PC?. Voy y compro en la esquina la más económica.


Lo mismo para el resto del hardware, y por ende, los drivers.


Drivers malos, problemas de Kernel. Problemas de Kernel, pantallas azules.


Mi amigo Luisón ya instaló Vista en su Mac (también tiene un PC) y dice que anda mucho mejor que en el PC. Yo no puedo atestiguarlo, pero le creo.


Anillo 1


Antes de finalizar, una nota anecdótica. El anillo 1 estuvo mucho tiempo sin utilizarse, o al menos eso es lo que yo tengo entendido. Sin embargo, en estos últimos años se ha usado bastante, aunque probablemente no sepas cómo.


Si utilizaste Virtual Server o Virtual PC, las máquinas virtuales se ejecutan en el anillo 1. Esto significa que tienen más privilegios que tus aplicaciones, pero menos que el Kernel del sistema operativo host. Así, una maquina virtual no podrá hacer caer  tu sistema operativo de host.


¿Anillo -1?


Otra nota curiosa. En hardware que soporta virtualización, quien controla la administración de las máquinas virtuales (Hypervisor en Windows 2008) se ejecuta en el anillo -1, para que las máquinas virtuales se ejecuten en los anillos correspondientes a como ha funcionado siempre (0 y 3). Más información en Ponicke Bloguea.


Espero haber arrojado un poco más de luz sobre el cuénto de nunca acabar de las pantallas azules.


Todos los sistemas operativos mencionados las tienen, y en todos el problema es el mismo.


Saludos, desde Santiago de Chile
Patrick

¿Microsoft y Van Halen?

Siendo un fanático de Van Halen, bueno, no tanto, pero me gusta mucho la música de ellos, en especial de la era Hagar, he estado revisando últimamente el sitio web para saber que ha pasado con la banda.


Además de los tradicionales problemas de drogas y de relación entre seres humanos, la última visita a www.vanhalen.net entregó este peculiar mensaje.


If you have registered for our newsletters in the past, please re-register your information, as Microsoft has deleted our database.


Para los escépticos, pueden visitar el sitio y verlo por sus propios ojos, o ver la siguiente imagen capturada desde este.



Que yo sepa, Microsoft no anda borrando bases de datos, ni menos de un grupo de música. A lo mejor no sé toda la historia.


desde Santiago
Patrick.