Entradas de la categoría ‘Informática en general’

Cómo funciona la pantalla azul de la muerte en Windows

BSOD

BSOD

Casi todos los usuarios de Windows han oído hablar —si no experimentado— la infame “pantalla azul de la muerte” (BSOD). Este término ominoso se refiere a la pantalla de fondo azul que se muestra cuando se bloquea Windows, o deja de ejecutarse, a causa de un fallo catastrófico o de una condición interna que impida al sistema continuar funcionando.

Windows se bloquea (se detiene la ejecución y se muestra la pantalla azul) por muchas razones posibles. Un ejemplo muy común es una referencia a una dirección de memoria que causa una infracción de acceso, ya sea por intentar escribir en memoria de sólo lectura o por una operación de lectura en una dirección que no está asignada o mapeada. Otra causa común, por ejemplo, es una excepción inesperada o un “cuelgue”. Los bloqueos también ocurren cuando el kernel de un subsistema (el administrador de memoria, el administrador de energía…) o un controlador (de pantalla, de red…) detectan inconsistencias en su propio funcionamiento.

Cuando un controlador o subsistema, pues, provoca una excepción ilegal, Windows se enfrenta a un difícil dilema: se ha detectado que una parte del sistema operativo con capacidades de acceso a cualquier dispositivo de hardware y a la memoria válida ha hecho algo que no se suponía que debería hacer. ¿Por qué significa eso que Windows tiene que fallar? ¿No podría, simplemente, ignorar la excepción y dejar que el controlador de dispositivo o el subsistema continuaran como si nada hubiera pasado?

Existe la posibilidad de que el error fuera aislado y de que el componente se recuperara de alguna manera. Pero, lo más probable, es que la excepción detectada resultara en problemas más profundos como, por ejemplo, una corrupción general de la memoria o un funcionamiento errático de un dispositivo de hardware. Permitir que el sistema continúe funcionando, probablemente, daría lugar a más excepciones, y los datos almacenados en el disco u otros periféricos podrían resultar corruptos; esto supone un riesgo demasiado elevado. Así que Windows adopta una política rápida de error al tratar de evitar que la corrupción en la RAM termine por extenderse al disco.

Pantalla azul de la muerte (con sorpresa)

Pantalla azul de la muerte (con sorpresa)

Independientemente de la razón de un bloqueo de sistema, la rutina que realmente realiza el bloqueo se conoce con el nombre de KeBugCheckEx. Esta función toma un código de parada (a veces llamado código de comprobación de errores) y algunos parámetros más. Una vez que KeBugCheckEx filtra todas las interrupciones del sistema, cambia la pantalla al modo de gráficos VGA de baja resolución (implementado por todos los sistemas Windows y soportado por todas las tarjetas de vídeo actuales), pinta el fondo de azul y, a continuación, muestra el código de detención, seguido de algún texto que sugiere lo que el usuario puede hacer.

La primera línea de la sección de información técnica enumera el código de parada y los parámetros pasados a KeBugCheckEx. Otra línea, cerca de la parte superior de la pantalla, proporciona el texto equivalente del identificador numérico del código de parada. Cuando un parámetro contiene una dirección de un código de sistema operativo o de dispositivo, Windows muestra también la dirección base del módulo en el que se encuentra la dirección del fallo, la fecha y hora (curiosamente con un valor hexadecimal en el formato timestamp de Unix) y el nombre del archivo del controlador de dispositivo. Esta información por sí sola podría ayudar al usuario a identificar el componente defectuoso.

Aunque existen más de 300 códigos de parada únicos, la mayoría son bastante raros de ver. En su lugar, sólo algunos pocos códigos de detención comunes representan la mayoría de los fallos de sistema de Windows.

Distribución de errores por fecuencia

Distribución de errores por fecuencia

Por último, el módulo KeBugCheckEx recurre a la llamada de comprobación de errores de todos los controladores de dispositivos (registrados en la función llamada KeRegisterBugCheckCallback), lo que permite a los controladores la oportunidad de detener esos dispositivos. Para terminar, accede al módulo KeRegisterBugCheckReasonCallback, el cual permite a los mismos controladores anexar datos en el volcado de bloqueo o escribir información de volcado del fallo en dispositivos alternativos.

El impacto del microprocesador Zilog Z80 (RetroEuskal 2016)

RetroEuskal 2016

RetroEuskal 2016

Bajo el paraguas de la Euskal Encounter 24, que se ha celebrado en el BEC vizcaíno del 22 al 25 de julio, se ha oficiado este año la decimotercera edición de la RetroEuskal, un evento retroinformático en el que se puede visitar un museo ambulante de cacharros antiguos, disfrutar de charlas, torneos, proyecciones y concursos, y hasta hacer uso de un juegódromo para deleitarse con ordenadores clásicos y videoconsolas viejunas. Y todo ello de la mano de la Asociación RetroAcción.

RetroEuskal 2016

RetroEuskal 2016

Este año, como de costumbre, nos hemos dado una vuelta por allí para disfrutar del evento. La exposición anual siempre atiende a un tema concreto, y esta vez se hace llamar “El impacto del microprocesador Zilog Z80“. En síntesis, un montón de vitrinas que guardan antiguas piedras preciosas de la tecnología (desde hace cuarenta años hasta nuestros días) en las que un Z80 tuvo o tiene cabida de alguna u otra manera, como un ZX Spectrum, un MSX, una Sega Mega Drive, una Game Boy o un reproductor de MP3.

RetroEuskal 2016

RetroEuskal 2016

Con respecto a las charlas, pudimos disfrutar del siempre genial Andrés Samudio con su ponencia titulada “XYZZY: 40 años de ‘Colossal Cave’, el comienzo de las aventuras“. En ella, Andrés (mítico director de Aventuras AD) desgranó la historia de ‘Colossal Cave‘, la primera aventura conversacional para un ordenador, y cómo llegó a convertirse en su ‘La Aventura Original‘. La segunda de las charlas se dio en llamar “Kasparov vs Deep Blue: la lucha del hombre contra la máquina“, ofrecida por Alberto Lozoya Rodríguez (físico por la UPV/EHU), en la que se desgranó la evolución de las primeras máquinas para jugar al ajedrez y se desembocó en el propio Deep Blue, el ordenador que consiguió derrotar a Gary Kasparov.

RetroEuskal 2016

RetroEuskal 2016

También tuvimos torneos de ‘Quake‘, ‘Duke Nukem 3D‘ y ‘Street Fighter II‘, un concurso de disfraces para conseguir imitar a la mascota del evento, Patxibot, y un montón de consolas antiguas, ordenadores, máquinas arcade y hasta un pinball para poder jugar y cacharrear a tope.

RetroEuskal 2016

RetroEuskal 2016

En fin, todo un lujazo de fin de semana que reunió a lo más retro del panorama en un evento muy bien organizado. ¡Nos veremos en la próxima RetroEuskal!

RetroEuskal 2016

RetroEuskal 2016

Cuando el rover Curiosity llevó un ‘bug’ informático terrestre a Marte

Curiosity en Marte

Curiosity en Marte

Hace un par de años se descubrió un error informático que tenía ya 20 años de edad en el momento y que se localizó en multitud de dispositivos como coches, aviones, teléfonos móviles Android, maquinas que usan código abierto y hasta en el mismísimo Curiosity, el vehículo que la NASA envió a Marte en noviembre del año 2011.

El error se encontraba en el algoritmo de compresión de datos Lempel-Ziv-Oberhumer (LZO), creado por Markus Oberhumer, que fue el que descubrió y dio a conocer el fallo y compiló la nueva versión 2.07 del código corregido.

El algoritmo LZO fue creado en 1994 y, desde entonces, ha sido incluido en infinidad de sistemas, como por ejemplo OpenVPN, FFmpeg y el kernel de Linux. Oberhumer aseguró en su momento que la vulnerabilidad en el antiguo código podría provocar desbordamientos de búfer, denegaciones de servicio y ejecución remota de código bajo las condiciones necesarias, las cuales requieren tamaños de búfer enormes, e infrecuentes, y donde haya que descomprimir más de 16 MiB (224 bytes) dentro de un sola llamada a una función.

El impacto más grave cayó sobre plataformas de medios populares de FFmpeg y Libav, y muchos proyectos dependientes de ellos, como VLC Media Player y Handbrake. Los usuarios no actualizados y afectados pudieron ver comprometidas sus máquinas cuando reproducían películas, o audio, desde sitios maliciosos. El fallo también afectó a microcontroladores Linux utilizados en muchos dispositivos y máquinas, como coches y otros vehículos.

Un bug en toda regla que los humanos llevamos hasta Marte y que podría haber causado un conflicto interplanetario. O no.

Cuando comprimíamos con ARJ en los noventa

ARJ

ARJ

No era el mejor empaquetador de archivos, ni el más eficiente, ni el más rápido, pero tenía una profusión de opciones y características que hacían de él el software de compresión más querido y utilizado por los retrofrikis de la era de MS-DOS del siglo pasado; lo que hoy llamarían los tecnocursis un must-have.

Desarrollado por un tal Robert K. Jung, ARJ (Archived by Robert Jung) tenía un amplio listado de comandos y parámetros que se podían utilizar para empaquetar ficheros y reducir su tamaño, algo que se hacía imprescindible en aquellos momentos de trapicheo de disquetes de 3½” y de módems que funcionaban a pedales en los albores de Intenet y en plena ebullición de las BBS. En la siguiente imagen se puede observar el listado de modificadores y comandos que tenía la versión 2.30 de 1992.

ARJ

ARJ

Una de las ventajas que tenía esta aplicación, es que permitía crear archivos comprimidos en varios volúmenes, es decir, en diversos ficheros partidos y relacionados entre sí. De esta manera, éramos capaces en aquel momento de partir un juego, un grupo de imágenes de chicas ligeras de ropa o un enorma plano de AutoCAD en muchos trozos, pudiendo especificar el tamaño de las partes para que cupiera cada una de ellas en un disco flexible. Y qué momentos aquellos de llegar a casa, descomprimir el conjunto y observar cómo fallaba el penúltimo disquete dando al traste con todo el trabajo y con nuestra completa paciencia.

Además de ello, los más avezados en el mundo del DOS de Microsoft, combinaban todas las capacidades de ARJ con sus conocimientos de comandos de archivos de proceso por lotes, los ya olvidados .BAT, para generar auténticos y fabulosos programas de instalación para juegos o software propio, posibilitando incluso que el ordenador te fuera pidiendo los distintos discos, haciendo pausas, descomprimiendo y copiando al disco duro. ¡Toda una gran época de bricolaje y cacharreo informático!

ARJ

ARJ

ARJ también permitía al usuario alterar el nivel de compresión de un archivo, haciéndolo popular en redes de correo de paquetes pequeños como WWIVnet y HOGnet, que usaban opciones de compresión más bajas para aprovechar el empaquetado basado en módems (como MNP o v.42bis) y así reducir las facturas de las llamadas a larga distancia que, invariablemente, conllevaban la membresía en dichas redes.

Desde aquellos momentos noventeros, ARJ fue perdiendo poco a poco su liderazgo como compresor de archivos en favor de otros mejores, más potentes y más bonitos, sobre todo los basados en el extendido ZIP y en el propietario RAR. Sin embargo, aún está activo su sitio web, y se puede comprobar que sus últimas versiones datan de enero de 2012 y son la 2.86 para DOS y la 3.20 para Windows de 32 y 64 bits. Vamos, que sigue dando guerra desde las trincheras electrónicas.

Por cierto, existe una versión open-source de este compresor del año 2010. ¡Larga vida, pues, a ARJ!

¿Por qué una tecnología de hace 40 años sigue controlando el tráfico aéreo estadounidense?

FAA

FAA

El 26 de septiembre del año 2014, un contratista del mundo de las telecomunicaciones llamado Brian Howard despertó temprano y se dirigió al Chicago Center, un centro de control de tráfico aéreo en Aurora (Illinois) donde había trabajado durante ocho años. Había decidido suicidarse y, como gesto de su última voluntad, planeó llevarse un pedazo del sistema del control de tráfico aéreo de Estados Unidos con él.

Las grabaciones confirmaron que Brian Howard entró en el Chicago Center a las 5:06 de la mañana y bajó al sótano, donde provocó un incendio en el compartimento de electrónica. Seguidamente se cortó el cuello. Los servicios médicos salvaron la vida de Howard, pero los sistemas del Chicago Center, que en ese momento controlaba el tráfico aéreo por encima de 10.000 pies y en un área de 91.000 kilómetros cuadrados, se apagaron.

El día del incendio

El día del incendio

Las aerolíneas cancelaron 6.600 vuelos; el tráfico aéreo se interrumpió durante 17 días. Howard había querido causar problemas, pero no había previsto una catástrofe de tal magnitud. Había publicado un mensaje en su cuenta de Facebook diciendo que el sabotaje “no tendría un alto costo para el sistema de control del espacio aéreo, pues todas las comunicaciones deberían cambiar a la ubicación alternativa“. Se equivocaba. Nadie sabe de qué lugar alternativo estaba Howard hablando, porque no existe tal cosa. Howard había trabajado en el centro durante casi una década, e incluso él no conocía eso.

En cualquier momento dado, alrededor de 7.000 aviones sobrevuelan los Estados Unidos. Durante los últimos 40 años, el mismo sistema informático ha controlado todo este tráfico de gran altitud, es una reliquia de la década de 1970 conocida como Host. El núcleo del sistema es anterior a la llegada del GPS, por lo que Host utiliza radares terrestres punto a punto. Cada día, miles de viajeros aéreos ponen sus teléfonos inteligentes con GPS en “modo avión”, mientras que sus vuelos son guiados por una tecnología que es anterior al ‘Speak & Spell‘ de Texas Instruments.

Si ahora mismo estás leyendo esto a 30.000 pies de altura, relájate, Host es todavía seguro en términos de conducir aviones de un punto A a un punto B, pero es increíblemente ineficiente. Puede manejar una cantidad limitada de tráfico, y los controladores no pueden ver nada fuera de su propio espacio aéreo; cuando un avión se traslada a un espacio aéreo contiguo, se desvanece en su radar.

La FAA (Federal Aviation Administration) estadounidense sabe todo esto perfectamente. Durante once años, la agencia ha ido migrando hacia un conjunto de actualizaciones conocidas como NextGen. En su núcleo porta un nuevo sistema informático que reemplazará a Host y permitirá que cualquier controlador, en cualquier lugar, pueda ver cualquier avión en el espacio aéreo estadounidense. En teoría, esto permitiría a un centro de control aéreo asumir el mando de otro con sólo tocar una tecla, como Howard parecía creer que ya era posible.

Esta tecnología es problemática y costosa, pero esa no es la mayor de las complicaciones. El problema principal es que NextGen es un proyecto de la FAA. La agencia es, principalmente, un órgano regulador, es la responsable de mantener la seguridad del espacio aéreo nacional y, además, también se encarga de operar el control del tráfico aéreo, un conflicto inherente que causa grandes problemas a la hora de completar las actualizaciones. Modernización, una lucha de cualquier agencia federal, es prácticamente la antítesis de la cultura operativa de la FAA, que es adversa al riesgo metódico y burocrático. A esto se suma que la FAA es la única consumidora del producto, por lo que no existen presiones por parte de los mercados.

La primera fase de NextGen es reemplazar Host con el nuevo sistema informático, la base para todas las futuras actualizaciones. La FAA pretendía terminar el trabajo para la pasada primavera, cinco años más tarde de lo previsto y, por lo menos, 500 millones de dólares por encima del presupuesto original.

La compañía Lockheed Martin comenzó a desarrollar el software en el año 2002, y la FAA proyectó que la transición desde Host estaría completa a finales de 2010. En 2007, el sistema actualizado se utilizaba sólo a través de pruebas internas, pero una vez instalado, era espantosamente inestable y contenía cientos de bugs. Por ejemplo, a veces vinculaba aviones a los datos de vuelo de una aeronave equivocada; otras veces los aviones desaparecían por completo de las pantallas de los controladores.

Recientemente, en abril de 2014, el sistema se vino abajo en Los Angeles Center cuando un jet militar U-2 entró en su espacio aéreo. El avión espía cruzó a 60.000 pies, el doble de la altitud de los aviones comerciales, y su plan de vuelo provocó un fallo de software que sobrecargó la sistema y lo tumbó.

En el sector privado, las empresas de tecnología se mueven rápido y actualizan sistemas sin poner en riesgo nuestra seguridad. Pero cuando el gobierno actualiza sus tecnologías, las regulaciones y la burocracia interceden antes de escribir una sola línea de código. El proceso de contratación pública está atada a mil reglas y normas, y la nueva tecnología en cuestión tiene que ajustarse a esas normas, si son o no son eficientes ni siquiera es relevante.

Y en esas estamos.

eBook ‘retroPLOF!’

retroPLOF!

Especifica tu dirección de correo electrónico y pulsa 'Comprar ahora'. Puedes pagar con tu cuenta de PayPal o con cualquier tarjeta bancaria.

E-mail envío eBook:

Sigue teknoPLOF! vía…
 
RSS
Twitter
Facebook
Google
 
Ready Set Click!

Utilizamos cookies propias y de terceros para mejorar la experiencia de navegación. Más información.

CERRAR