Apuntes de un loco

Windows Vista no es capaz de instalar el Service Pack 1 mediante Windows Update

Ramón Sola — Sat, 24 Nov 2012 18:00:00 GMT

An English version of this article is available.

Algunos usuarios, tras instalar de nuevo el sistema operativo Windows Vista sin ningún service pack integrado (versión RTM), han informado de un problema para actualizar al Service Pack 1 a través de Windows Update. Después de aplicar un número considerable de actualizaciones, aparece el SP1 con un tamaño extrañamente reducido de 1,9 MB. Si se elige para instalar se inicia el asistente, pero el proceso de instalación termina demasiado rápido y no provoca el típico reinicio. La información de versión de Windows revela que en realidad no ha tenido lugar la instalación del Service Pack 1. En otras palabras, Windows Update ofrece el Service Pack 1 de Windows Vista reiteradamente.

El número de versión de Windows Vista sin service packs es 6.0.6000, donde 6000 es el número de compilación. La versión con Service Pack 1 es 6.0.6001 y con Service Pack 2 es 6.0.6002. Lugares típicos en los que se puede consultar los números de versión y service pack de Windows:

Herramienta de información del sistema, Msinfo32.exe.
El intérprete de órdenes y símbolo del sistema, Cmd.exe, que muestra el número de versión de Windows en el encabezamiento y también usando la orden VER.
Información de versión de Windows, Winver.exe.
Panel de control, Seguridad y mantenimiento, Sistema. También se puede abrir con la combinación de teclas Windows+Pausa o haciendo clic con el botón secundario sobre Equipo y eligiendo Propiedades.

Desconozco qué induce a Windows Update a ofrecer e instalar de forma incorrecta el Service Pack 1 de Windows Vista. Sin embargo, el arreglo parece bastante sencillo: descargar el SP1 completo e instalarlo manualmente. Existen cuatro variantes del service pack. Además de la separación entre 32 bits y 64 bits, Microsoft lanzó en primer lugar una edición que solo contemplaba los idiomas inglés, francés, alemán, español y japonés, seguida pocos días después por el SP1 completo en todos los idiomas admitidos.

La descarga en cinco idiomas es un poco más pequeña que la completa, con una diferencia en torno a 100 MB en la versión x86 (32 bits) y unos 150 MB en la versión x64 (64 bits). Si el equipo tiene instalado un paquete de idioma distinto del inglés, francés, alemán, español o japonés, es necesario el SP1 completo. Para escoger el SP1 adecuado según la plataforma sea de 32 o de 64 bits consúltese “¿Qué versión de Windows tengo en mi PC: la de 32 bits o la de 64 bits?”.

El Service Pack 1 es un requisito del Service Pack 2, que a su vez es condición indispensable para instalar muchos programas recientes y poner al día correctamente el sistema operativo Windows Vista. Después de la instalación del SP1, Windows Update aplicará actualizaciones adicionales y posteriormente deberá ofrecer el SP2, que se instalará con normalidad si no se presentan otros impedimentos. De todas formas ofrezco los enlaces de descarga completa, válidos también para Windows Server 2008 (no R2):

Tras aplicar un service pack de Windows Vista, el almacén de componentes del sistema conserva los archivos anteriores para permitir la desinstalación. Se puede liberar el espacio ocupado por estos componentes antiguos ejecutando una herramienta específica en una ventana de símbolo del sistema como administrador: Vsp1cln.exe en el caso del SP1 y Compcln.exe con respecto al SP2.

No hace falta usar Vsp1cln.exe después de instalar el Service Pack 1 para eliminar los archivos de la versión RTM si se va a aplicar el Service Pack 2 a continuación, pero sí podría resultar beneficioso si se requiriera espacio libre adicional en disco antes de llevar a cabo la actualización. Una vez instalado el SP2, Compcln.exe reemplaza a Vsp1cln.exe, siendo capaz de eliminar los archivos antiguos tanto de la versión RTM como del SP1. Una vez iniciado o completado el proceso de limpieza no será posible deshacerlo ni desinstalar el service pack.

Este contenido procede de http://geeks.ms/blogs/rsola. El hecho de que la totalidad o parte de este artículo aparezca en otra página no implica que el autor tenga relación con ese lugar o apoye el uso que se hace allí de la información publicada.

Errores 0x80240036 y 0x8024400A u otros problemas con Windows Update en reinstalaciones de Windows XP

Ramón Sola — Fri, 17 Aug 2012 17:46:00 GMT

An English version of this article is available.

Vengo observando en los foros bastantes consultas de usuarios que, por las razones que fueran, tuvieron que volver a instalar su Windows XP y constataron que no funcionaban correctamente las actualizaciones automáticas o el sitio web de Windows Update. Actualización (30/03/2012): además de los códigos 0x80240036 y 0x8024400A, también puede aparecer el error 0x80244019.

Nota: Windows 2000, sin actualizaciones nuevas desde julio de 2010, Windows XP x64 Edition y Windows Server 2003 también podrían estar afectados por este problema.

Los sucesos relacionados con el malware Flame obligaron a Microsoft a llevar a cabo algunos ajustes en su infraestructura de actualizaciones. Como consecuencia aparente de los cambios, el cliente de Windows Update integrado en los Windows XP recién instalados es incapaz de entenderse con los servidores incluso para obtener la versión más reciente y actualizarse a sí mismo. Aunque el sistema esté habilitado para buscar, descargar o instalar automáticamente las actualizaciones, el icono nunca aparece en el área de notificación y el sitio web de Windows Update muestra alguno de los códigos de error referidos en el título.

Nota: la solución propuesta solo se aplica a los síntomas y circunstancias expuestos, y probablemente no servirá de nada en muchos otros casos. Si los códigos de error recibidos son distintos o los síntomas no se aplican a su equipo, puede buscar en otras fuentes o acudir a los foros de Microsoft Answers o TechNet.

La solución que he encontrado hasta ahora es instalar manualmente la versión 7.4.7600.226 del cliente de Windows Update para Windows x86 de 32 bits o bien Windows x64 de 64 bits. ¿Mi Windows es de 32 bits o de 64 bits? Este cliente de Windows Update se actualizará en algún momento a la versión vigente, que al publicar esta entrada es la 7.6.7600.256. Microsoft todavía no ha proporcionado la descarga completa de la última versión.

Incluso después de instalar el cliente, es posible que la búsqueda de actualizaciones automáticas no tenga lugar de forma inmediata, sino después de una hora al menos o la próxima vez que se inicie Windows. Se puede forzar la búsqueda ejecutando wuauclt /detectnow mediante Inicio, Ejecutar, o por otro medio. Sin embargo, el sitio web de Windows Update debería funcionar con normalidad.

Insólita modalidad de estafa con la excusa de préstamos particulares

Ramón Sola — Wed, 30 May 2012 18:16:36 GMT

Hace unos días recibí un mensaje de correo electrónico que me pareció muy sospechoso, una proposición de préstamo en la línea de los timos nigerianos y las ofertas de trabajo falsas pero bastante más sutil. Es la primera vez que veo tal cosa. Además, la crisis económica constituye un pretexto inmejorable para los delincuentes, pues los individuos más expuestos a estos engaños son quienes se hallan en una situación precaria: aceptarían casi cualquier propuesta con tal de mejorar sus condiciones de vida.

El remitente, el asunto y algunos detalles de la redacción pueden variar.

De: JUAN CARMEN <bechinigiacomo@alice.it>
Responder a: juan_carmen@hotmail.fr
Asunto: oferta de préstamo

Buenos días

soy la Sra. JUAN Carmen de nacionalidad Francesa. de Primer accionista Crédit Mutuel FINANDEB ofrezco préstamos a todas personassinceras y honesto los que tienen necesidad.Puedo concederle de los préstamos que van de30.000 Dólares a 25.000.000 Dólares incluso más sabiendo que estamos entre particulares mi tipo deinterés soy muy correcto, varía un 2% por año cualquiera que sea la suma pedida, la duración de reembolso es de 1 años a 50 años por supuestosegún la suma prestada.Me contactar me para su besion de financiación solicitud de préstamo estoy a su disposición.

Transferencia sobre su cuenta bancaria y se efectúa por mensualidad.
No dudan en contactarme por correo electrónico para más información si tiene necesidad.
correo electrónico: juan_carmen@hotmail.fr
Gracias atentamente.

Se deduce que es una mala traducción del francés. La búsqueda de fragmentos del texto revela mensajes similares en diversos portales de anuncios clasificados, tanto españoles como hispanoamericanos. Un préstamo con unas condiciones tan ventajosas a primera vista debe presentar necesariamente alguna trampa: demasiado bueno para ser cierto. La difusión indiscriminada e impersonal, sin destinatario explícito, acentúa la impresión de “gato encerrado”.

La sección de fraudes de la Oficina de Seguridad del Internauta, dependiente de Inteco, presenta una guía general para informarse sobre los timos predominantes en Internet y reconocerlos. Más vale desconfiar por sistema que despistarse un momento y resultar víctima de un engaño que suponga una pérdida económica o una suplantación de identidad.

Posibles motivos de “registrador del kernel de NT ya en uso” al ejecutar Powercfg /energy

Ramón Sola — Sat, 31 Dec 2011 21:24:54 GMT

La herramienta Powercfg.exe de las versiones recientes de Windows permite gestionar la configuración de energía mediante órdenes de línea de comandos. Apareció por primera vez en Windows Server 2003, más tarde Microsoft la incorporó al Service Pack 2 de Windows XP (también disponible, por tanto, con el Service Pack 3), y su repertorio de opciones se ha ido ampliando en consonancia con las novedades en la gestión energética de los sistemas operativos. Una de las novedades más destacadas en Windows 7 y Windows Server 2008 R2 es la opción /energy.

La mayoría de las funciones requiere privilegios de administrador. A partir de Windows Vista, se recomienda abrir una ventana de intérprete de línea de comandos elevada para usar PowerCfg de forma interactiva. La opción /energy genera un informe sobre la configuración y gestión de energía en Windows con el propósito de diagnosticar problemas e intentar resolverlos. Un documento de Microsoft explica en inglés su funcionamiento y cómo interpretar los resultados: “Using PowerCfg to Evaluate System Energy Efficiency”.

La ejecución de PowerCfg /energy puede mostrar el siguiente mensaje en algunas ocasiones:

Habilitando el seguimiento durante 60 segundos...
Observando el comportamiento del sistema...
No pudo abrirse el Registrador del kernel de NT. El Registrador del kernel de NT ya está en uso. Asegúrese de que no se esté usando ninguna de las demás utilidades de supervisión de rendimiento, incluido el Monitor de confiabilidad y rendimiento.

PowerCfg recopila datos de configuración y comportamiento del sistema a través de la infraestructura de seguimiento de sucesos de Windows (ETW), que apareció por primera vez en Windows 2000 y se renovó en Windows Vista. Concretamente, PowerCfg depende del registrador del núcleo (NT Kernel Logger). En cuanto a una aplicación se le concede acceso a este registrador, ninguna otra va a poder usarlo hasta que quede libre.

El monitor de rendimiento de Windows es tan solo una de las muchas herramientas de análisis que se apoya en ETW y particularmente en el registrador del núcleo. Si el monitor de rendimiento no está activo, cabe la posibilidad de que el motivo sea la aplicación más insospechada. Process Explorer y Process Monitor son dos ejemplos de programas muy conocidos, no incluidos en Windows, que normalmente provocan esta situación, como recoge la entrada “ProcExp and XPerf tracing” del blog de Maarten van de Bospoort (Microsoft). Basta cerrarlos para liberar el registrador del núcleo.

XPerf es otra herramienta de Microsoft que permite registrar diversos parámetros del comportamiento del sistema para su análisis posterior. Forma parte del Windows Performance Analysis Toolkit que se incluye en el SDK de Windows y trabaja sobre la línea de comandos. Sin embargo, el error que emite XPerf cuando el registrador está ocupado es diferente y algo confuso:

xperf: error: NT Kernel Logger: No se puede crear un archivo que ya existe. (0xb7).

Esto se prueba por ejemplo con la orden “xperf -on diageasy”. DiagEasy es un identificador que agrupa varios proveedores de información del núcleo; la lista completa de estos proveedores se puede consultar con “xperf -providers k”. La captura en curso se detiene con “xperf -stop” o “xperf -d archivo.etl”.

La descripción del error sugiere que hay algún archivo involucrado, pero no es cierto. El código 0xB7 (183 decimal, de nombre simbólico ERROR_ALREADY_EXISTS) resulta de traducir la constante 0xC0000035 (de tipo NTSTATUS). El núcleo de Windows devuelve este valor, que corresponde con la constante STATUS_OBJECT_NAME_COLLISION (“Ya existe ese nombre de objeto”), si un programa solicita el registrador del núcleo y este ya está en uso. Esta circunstancia se registra como un suceso de error de Kernel-EventTracing con el identificador 2, en el almacén Microsoft-Windows-Kernel-EventTracing/Administrativo, y con la descripción “No se pudo iniciar la sesión "NT Kernel Logger" por el siguiente error: 0xC0000035”.

Como ya es 31 de diciembre, aprovecho para desear una feliz salida y entrada de año.

Dennis Ritchie o el arte de cambiar el mundo pasando desapercibido

Ramón Sola — Tue, 18 Oct 2011 17:54:05 GMT

Tan solo unos días después del fallecimiento del mediático cofundador y líder de la compañía Apple, Steve Jobs, nos enterábamos la semana pasada de la muerte de otra personalidad de la computación. Había cumplido 70 años el pasado mes de septiembre y según se cuenta era muy reservado y poco amigo de la popularidad. No obstante, participó decisivamente en la creación de dos piezas fundamentales que revolucionaron la informática del último cuarto del siglo XX: el sistema operativo Unix y el lenguaje de programación C.

Rob Pike, ingeniero que coincidió con Ritchie en varios proyectos de los laboratorios Bell al menos durante los años 80 y actualmente empleado de Google, publicó el pasado miércoles día 12 (madrugada del 13 en España) una breve anotación en su perfil de la red Google+.

I just heard that, after a long illness, Dennis Ritchie (dmr) died at home this weekend. I have no more information.

I trust there are people here who will appreciate the reach of his contributions and mourn his passing appropriately.

He was a quiet and mostly private man, but he was also my friend, colleague, and collaborator, and the world has lost a truly great mind.

A esta nota siguieron numerosos comentarios de condolencia y pesar por la desaparición de tan influyente y sin embargo discreto genio. Pike agradeció al día siguiente las incontables muestras de afecto. La blogosfera tecnológica reaccionó de forma inmediata y las ediciones digitales de importantes medios tradicionales la secundaron rápidamente.

Hay dos nombres invariablemente unidos al de Ritchie: sus contemporáneos Ken Thompson (nacido en 1943) y Brian Kernighan (n. 1942). Thompson ha sido el colaborador más cercano a Ritchie y la otra gran figura del desarrollo de Unix, además del creador del lenguaje B precursor de C. Kernighan, por su parte, construyó algunas de las primeras herramientas de software de Unix, elaboró los primeros tutoriales de C (probable origen del tradicional “hola, mundo”) y escribió con Ritchie uno de los libros más prestigiosos sobre programación de todos los tiempos: The C Programming Language (1978). El estilo del lenguaje expuesto en el libro se conoce popularmente como el C de Kernighan y Ritchie (K&R).

La repercusión de Unix y C en la informática contemporánea es de una magnitud incalculable. Los derivados de Unix y semejantes son casi ubicuos, sistemas operativos en apariencia tan ajenos como MS-DOS y Windows también le deben algo, y prácticamente no hay plataforma de software o hardware (microcontroladores) para la que no exista compilador de C. Innumerables proyectos y productos de software de uso común y no tan común están codificados total o parcialmente en C o algún derivado. Los lenguajes C++, C# y Java tomaron de él buena parte de sus elementos sintácticos y su semántica. Además, puede apreciarse un trasfondo sintáctico de C en otros lenguajes imperativos de uso frecuente que “no se le parecen mucho” (aunque, en el fondo, todos los lenguajes imperativos estructurados y procedimentales “se asemejan” unos a otros de algún modo).

Dennis Ritchie y Ken Thompson han obtenido varios reconocimientos relacionados con la innovación tecnológica, incluido el prestigioso premio Turing en 1983, el máximo galardón de las ciencias de la computación que otorga la ACM (Association for Computing Machinery).

Concesión de la Medalla Nacional de Tecnología estadounidense en 1999.
Fuente de la imagen: Wikimedia Commons. Original: Laboratorios Bell.

main() {
printf("RIP Dennis Ritchie (1941-2011)\n");
}

Otra vuelta de tuerca a las estafas “nigerianas”

Ramón Sola — Wed, 05 Oct 2011 12:43:29 GMT

El otro día estuve revisando la carpeta de correo no deseado en una cuenta de correo electrónico. Una mezcla de estupor y repugnancia se apoderó de mí al ojear una peculiar variante del timo “nigeriano” clásico. Parece ser que lo del desconocido gestor financiero o alto cargo del gobierno de un país lejano ya no funciona tan bien como al principio, así que, ¿qué mejor forma de llamar la atención que un sátrapa que ocupa la atención de todos los noticiarios desde hace varios meses?

La versión más típica de timo nigeriano consiste en un supuesto alto cargo de un país lejano, normalmente de África, que ofrece un trato ventajoso en relación con los bienes de un presunto millonario perseguido por la justicia, hecho preso, incapacitado, fallecido o simplemente muy generoso. Estos bienes por lo general han permanecido olvidados en un banco durante un largo periodo de tiempo sin que nadie los haya reclamado. El objetivo del engaño, conocido en el mundo anglosajón como “advance-fee fraud”, es convencer al afectado de que solo podrá conseguir la suma acordada si accede a efectuar diversos pagos en concepto de trámites, sobornos a funcionarios, etc. Al final, la víctima no recibe siquiera una mínima porción de lo prometido y el timador termina embolsándose una cuantía nada despreciable procedente de varios perjudicados.

Si confiamos en las cabeceras, el mensaje en cuestión se remitió desde una IP nigeriana a través de un servicio coreano de correo web. Sin embargo, el dominio de la dirección que consta como remitente pertenece a la Universidad Mazandaraní de Ciencias Médicas de la ciudad de Sari, provincia de Mazandarán, al norte de Irán en la costa meridional del mar Caspio. Esta desconcertante mezcolanza se completa con la supuesta identidad de la persona que solicita la colaboración.

Reply-To: <muammargaddafi12@hotmail.com>
From: "MR.GADDAFI"<Contact@mazums.ac.ir>
Subject: HELLO !!!
Return-Path: Contact@mazums.ac.ir

Greeting.

I am Gaddafi from Libya, pls don’t be upset with this letter from me. I sincerely need your help now very urgent. I have 78 million pounds with a firm in London. England, I want this fund to be moved to you for better safe keeping, I promised you 20% out of the total fund as soon as you are able to help me safe the money from the hands of my peoples. And also invest the fund in big business in your country as well.
Take a look at the following link:

http://www.dailymail.co.uk/news/article-2030012/Libyan-rebels-break-Gaddafis-secret-underground-tunnels.html

Kindly get back to me urgently. I want the fund to be moved before the week runs out.

Best regard
Mr. Gaddafi.
E-mail:muammargaddafi12@hotmail.com

Estoy como le dijo el árbol al leñador según Ned Flanders: “¡Perplejito!”. El décimo doctor (David Tennant) de la serie británica Doctor Who habría exclamado un sonoro “WHAT????”. Los amigos de lo ajeno juegan con la controversia sobre la ubicación y el montante de las riquezas de Gadafi y su familia, considerando la delicada situación de Libia cuya resolución todavía no se ve próxima. Resulta muy sospechoso que la dirección de contacto pertenezca a Hotmail, ¿verdad?

Ahí va una traducción aproximada en la que he intentado reproducir más o menos las incoherencias gramaticales:

Saludos.

Soy Gaddafi, desde Libia, por favor no se moleste con esta carta mía. Necesito de veras su ayuda con gran urgencia. Tengo 78 millones de libras en una empresa de Londres, Inglaterra. Deseo transferirle estos fondos para mantenerlos a buen recaudo, le prometí un 20% del total tan pronto como usted sea capaz de ayudarme a mantener a salvo el dinero de las manos de mi gente. Y también invertir los fondos en grandes negocios de su país. Eche un vistazo al siguiente enlace:

http://www.dailymail.co.uk/news/article-2030012/Libyan-rebels-break-Gaddafis-secret-underground-tunnels.html

Sea amable de responderme lo antes posible. Quiero que el dinero se transfiera antes de que acabe la semana.

Mis mejores deseos.
Mr. Gaddafi.

Tiene su “gracia” que los receptores potenciales del mensaje sean ciudadanos de países occidentales, ahora tan enemistados con el régimen libio, y que los presuntos fondos estén guardados en el Reino Unido (recuérdese el gravísimo atentado de Lockerbie en 1988, del que se responsabilizó a autoridades libias). En fin, si ustedes se encuentran algo similar a esto en sus cuentas de correo no hagan ni caso. De lo contrario podrían perder buena parte de sus ahorros o ver suplantada su identidad de alguna forma. Mucha precaución.

La compatibilidad con programas DOS y Windows de 16 bits en Windows 8 x86

Ramón Sola — Fri, 30 Sep 2011 17:46:00 GMT

Mucho se está hablando del nuevo sistema operativo Windows 8 de Microsoft, sobre todo del cambio de modelo que implica, tanto para usuarios como para desarrolladores, el protagonismo de la nueva interfaz gráfica “Metro” y su entorno de ejecución subyacente. Pero hay un detalle novedoso en relación con el escritorio clásico en el que poca gente suele reparar porque pertenece a una funcionalidad muy antigua, cada vez menos usada y condenada a desaparecer.

Nota: las funcionalidades que se van a describir corresponden a un sistema en fase de desarrollo, por lo tanto podrán sufrir variaciones importantes con respecto a la versión final o incluso desaparecer por el camino. Tómese la información aquí expuesta con la máxima prudencia.

Microsoft presentó hace unas dos semanas la versión preliminar Developer Preview, un anticipo para desarrolladores. Su intención es que los creadores de aplicaciones se familiaricen ya con la filosofía de desarrollo de “Metro”, de forma que el lanzamiento oficial del sistema operativo vaya acompañado de suficientes aplicaciones “Metro” compatibles y de calidad. Esta versión no incluye algunas de las características previstas en la versión final del producto ni tiene calidad de “beta”, por lo que a veces puede exhibir algún comportamiento extraño.

Jugando un poco con la edición x86 de 32 bits de Developer Preview probé a abrir el viejo editor de MS-DOS, Edit.com. También podría haber usado Command.com, Mem, Debug, el denostado Edlin que tiene más años que un servidor (¿lo echará en falta alguien cuando ya no esté?), o incluso, como aplicación Windows de 16 bits, el vetusto y actualmente inservible editor de archivos de configuración Sysedit.exe que apareció primero en Windows 3.0. Me llevé una sorpresa.

La capacidad de ejecutar aplicaciones antiguas basadas en MS-DOS y Windows de 16 bits está presente exclusivamente en las ediciones x86 de Windows, a través de los subsistemas NTVDM (NT Virtual DOS Machine) y WOW respectivamente. No confundir este WOW, en ocasiones también llamado WOW32 o Windows on Win32, con WOW64, que en los sistemas de 64 bits constituye la capa de compatibilidad con aplicaciones Windows de 32 bits, ni con —nota friki superflua— el videojuego World of Warcraft.

NTVDM y WOW dependen casi completamente del modo 8086 virtual exclusivo de la arquitectura x86 de 32 bits. Su traslado a otras arquitecturas, como x64 o Itanium, habría supuesto reescribir estos componentes como emuladores completos del modo real y de un subconjunto del modo protegido de los procesadores x86. Solamente merece la pena dedicar recursos a añadir o mejorar una característica del sistema si se estima que el uso o el beneficio superará con creces el esfuerzo empleado. Por tanto, Microsoft abandonó esta posibilidad en todas las ediciones de 64 bits de Windows.

En la ventana de la imagen anterior, la opción “Enable” permite el uso de aplicaciones de 16 bits de aquí en adelante.

Por el contrario, si se selecciona “Disable”, se anula la compatibilidad y aparece el consiguiente mensaje de error cada vez que se intenta usar un programa de 16 bits.

La configuración actual no cambia si se cierra la ventana de confirmación sin haber elegido “Enable” o “Disable”. En caso de no tener un valor definido, Windows decide como opción más segura (secure by default) no ejecutar tampoco la aplicación. La próxima vez se volverá a mostrar la ventana.

¿Qué ha influido supuestamente en esta decisión? A lo largo de la historia de Windows NT, la familia de la que procede Windows 8, se han descubierto varias vulnerabilidades en el subsistema NTVDM y la sección del núcleo de Windows que le sirve de apoyo. Un usuario limitado local podría obtener de forma directa privilegios de administrador o sistema local, incluso eludiendo el control de cuentas de usuario de Windows Vista y sus sucesores, ejecutando de forma intencionada o fortuita un programa de 16 bits especialmente preparado en un Windows vulnerable. Algunos de estos fallos de seguridad han permanecido latentes durante mucho tiempo, posiblemente desde el origen mismo de Windows NT (versión 3.1, año 1993). El más grave o quizá más mediático fue el que divulgó el investigador Tavis Ormandy a principios de 2010, seis meses después de comunicar el informe a Microsoft de forma privada y esperar una solución. Finalmente, Microsoft publicó la corrección del problema unas pocas semanas más tarde en el ciclo de febrero de 2010 con la actualización KB977165, que describió en el boletín de seguridad MS10-015. Las ediciones de 64 bits, salvo Windows 7 y Windows Server 2008 R2, no están afectadas por esta vulnerabilidad pero sí por otra resuelta en la misma actualización.

La configuración de la compatibilidad con aplicaciones de 16 bits está contenida en el archivo Ntvdmcpl.cpl, un elemento clásico del panel de control. El equipo de desarrollo de Windows habrá tenido sus motivos para presentarlo de este modo, tal vez disimularlo un poco, en lugar de empaquetarlo en un archivo EXE tal como se recomienda a partir de Windows Vista. La navegación habitual del panel de control no muestra este elemento, así que para encontrarlo hay que cambiar a una vista de iconos (todos los elementos) o usar la función de búsqueda. También se puede invocar explícitamente mediante la ventana Ejecutar con la combinación Windows+R.

Dos valores del registro determinan si la ejecución de programas de 16 bits está permitida. El primero es el valor DisallowedPolicyDefault de la clave HKLM\System\CurrentControlSet\Control\WOW. El segundo, que se puede hallar en HKLM\Software\Policies\Microsoft\Windows\AppCompat y se denomina VDMDisallowed, forma parte de la directiva de grupo “Impedir el acceso a aplicaciones de 16 bits” (Configuración del equipo, Plantillas administrativas, Componentes de Windows, Compatibilidad de aplicaciones) y tiene preferencia sobre el anterior.

La siguiente tabla muestra las combinaciones de ambos valores y su efecto sobre la ejecución:

VDMDisallowed (directiva de grupo)	DPD no definido	DPD = 0	DPD <> 0
No configurado	Preguntar al usuario*	Permitido	Acceso denegado
Cero (directiva deshabilitada)	Permitido	Permitido	Permitido
Distinto de cero (directiva habilitada)	Acceso denegado	Acceso denegado	Acceso denegado

* En versiones anteriores a Windows 8, ejecución permitida.

La elección de “Enable” o “Disable” en la ventana de configuración vuelve a llamar a Ntvdmcpl.cpl con un parámetro especial. La operación necesita privilegios administrativos para escribir en la rama HKEY_LOCAL_MACHINE.

Cuando se opta por “Disable”, Ntvdmcpl recibe el parámetro /setdpd:1 para establecer DisallowedPolicyDefault a 1.

Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:1

Análogamente con “Enable”: en este caso el parámetro es /setdpd:2. DisallowedPolicyDefault se pone a cero.

Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:2

¿Por qué se utiliza /setdpd:2 para establecer a cero el valor DisallowedPolicyDefault? Resulta que /setdpd:0 está reservado para otra finalidad.

¿Qué hace “Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:0”? Si abrimos Ntvdmcpl.cpl a continuación o ejecutamos un programa de 16 bits, y además la directiva VDMDisallowed no está definida, veremos que los dos botones “Enable” y “Disable” vuelven a estar activos. ¿Y si usamos /setdpd:0 dos veces seguidas?

El mensaje de error es confuso: el sistema no puede hallar el archivo especificado. La explicación es muy sencilla. El parámetro /setdpd:0 indica que se borre el valor DisallowedPolicyDefault, sea cual sea su contenido. Windows no contempla códigos de error específicos para las operaciones relacionadas con el registro, de modo que sus funciones devuelven errores coherentes con la idea de que el registro se organiza en directorios (claves) y ficheros (valores). Ntvdmcpl.cpl no comprueba si el valor DisallowedPolicyDefault existe antes de eliminarlo, así que la segunda vez la función de borrado fracasa con el error “fichero no encontrado”.

Ntvdmcpl.cpl admite otro parámetro, /originalapp, seguido de dos puntos y un texto entrecomillado, que se muestra en la ventana de configuración a continuación de “You are attempting to run”. Windows usa este parámetro para indicar qué programa de 16 bits se ha intentado ejecutar cuando no están definidos los valores VDMDisallowed y DisallowedPolicyDefault. Una demostración:

Rundll32 Shell32.dll,Control_RunDLL Ntvdmcpl.cpl,,/originalapp:"c:\windows\system32\command.com"

Para terminar, diversos rumores señalan que Microsoft podría no publicar una edición x86 del sucesor de Windows 8, por tanto éste constituiría la última versión de 32 bits capaz de ejecutar programas de 16 bits de forma nativa e integrada sin tener que emplear máquinas virtuales o emuladores como DOSBox.

Por cierto, ¿sabías que la versión de DOS emulada en la familia Windows NT es MS-DOS 5.0? La información de copyright de los archivos ejecutables y la función 30h de la INT 21h (AX=0005h) así lo atestiguan.

Mensaje de correo de WordPress.com aconseja a usuarios restablecer su contraseña

Ramón Sola — Tue, 23 Aug 2011 00:37:30 GMT

El popular servicio de blogs basado en la plataforma WordPress remitió el pasado fin de semana un aviso de seguridad importante a un número indeterminado de sus usuarios. El comunicado informa de que, entre julio de 2007 y abril de 2008, y entre septiembre de 2010 y julio de 2011, las contraseñas se han estado almacenando de un modo poco seguro, por tanto recomienda a los usuarios afectados modificarlas lo antes posible para prevenir posibles usos inadecuados de sus cuentas.

Comprensiblemente ha habido quien ha dudado de la legitimidad del aviso; también un usuario del foro de ayuda de WordPress.com quiso saber si era auténtico. Lo inesperado de la misiva, su carácter de urgencia, la ambigüedad de la dirección de envío (fácil de falsificar, además de que passwordcoupon suena a chiste, si se me permite la comparación) y la baja calidad de la redacción, una traducción aparentemente hecha deprisa y corriendo con evidentes fallos ortográficos y gramaticales, hacían sospechar de un posible ataque de phishing. Sin embargo, la observación de dos detalles significativos debilita la sensación de fraude. En primer lugar, los enlaces internos señalan directamente al dominio wordpress.com usando una conexión HTTPS, de modo que la información de restablecimiento de la contraseña viaja cifrada a través de la red. Por otra parte, muchos mensajes de phishing se caracterizan por incorporar saludos genéricos como “Estimado usuario” o cliente, o una dirección de destino diferente de la nuestra. En este caso ocurre al contrario: la comunicación se dirige al destinatario por el nombre y la dirección de correo registrados en su perfil. No obstante, los delincuentes podrían aprovecharse en cualquier momento de las “miguitas de pan” que vamos dejando aquí y allá para conferir mayor verosimilitud a sus campañas de phishing, o construir enlaces aparentemente inocuos que en realidad, a través de vulnerabilidades en aplicaciones web, inyecten falsos formularios de solicitud de credenciales que envíen los datos a un lugar distinto.

He aquí el texto:

Remite: "WordPress.com" <passwordcoupon@wordpress.com>
Asunto: Actualización de seguridad y descuento del 15% en WordPress.com

Hola <Usuario>,

Recientemente hemos encontrado y arreglado un fallo del que nos gustaría hablarte. Las contraseñas en WordPress.com se guardan de forma extremadamente segura, de forma que ni siquiere nuestros empleados pueden ver tu contraseña – esa con al que entras en tu cuenta de WordPress.com. Sin embargo, entre julio de 2007 y abril de 2008, y entre septiembre de 2010 y julio de 2011, un fallo en uno de los sistemas que se utilizan para encontrar y corregir errores den WordPress.com accidentalmente guardó contraseñas de algunos usuarios en un formato menos seguro.

Hemos actualizado nuestros sistemas para prevenir que las contraseñas se guarden de esta forma en el futuro, para que no vuelva a ocurrir. No tenemos ninguna evidencia de que se haya utilizado esta información de forma maliciosa, pero tu cuenta está entre las afectadas por este fallo y por seguridad vamos a resetear tu contraseña.

Por favor, cambia aquí tu contraseña o copia y cola este enlace en tu navegador:

<Enlace eliminado>

Si la contraseña que utilizaste cuando te registraste en WordPress.com es la utlizas en todos sitios, deberías cambiarla también. En el futuro, recuerda que es una buena práctica utilizar contraseñas diferentes y únicas para cada servicio.

Sentimos mucho el fallo. A nadie le gusta tener que crear nuevas contraseñas y queremos incluir un descuento del 15% para pediros perdón. este descuento puede utilizarse para dominios personalizados, mejoras de diseño, VideoPress o ampliación de espacio. Sólo tienes que utilizar el código que acompaña a este texto en cualquiera de las mejoras en la tienda de WordPress.com:

<Código de descuento eliminado>

Si tienes cualquier pregunta, contesta este mensaje para que nuestro equipo de Happiness te ayude.

Gracias
El equipo de WordPress.com

Una ingeniera de WordPress.com publicó el domingo la nota original en inglés para evitar más suspicacias. De todos modos, la forma más segura de convencerse es entrar directamente en WordPress.com e identificarse con la contraseña vigente, en vez de usar el enlace incluido en el mensaje. La página de escritorio de WordPress muestra un aviso al usuario afectado para que modifique la contraseña en la configuración de su perfil. Si no se ha recibido nada o no se observa ninguna nota especial al acceder al servicio, no se requiere llevar a cabo acción alguna aunque es aconsejable variar las contraseñas cada cierto tiempo.

Una cuenta de WordPress quizá no sea botín suficiente como para que un malhechor inicie una campaña de phishing, pero podría ayudarle a perpetrar otras actividades poco lícitas. Si recibimos repentinamente en nuestro correo electrónico alguna advertencia urgente relativa a problemas de contraseñas, cambios en la forma de operar algún servicio o cierres en breve plazo de cuentas inactivas o que no cumplan determinadas condiciones, deberíamos investigar si otras personas o medios de confianza confirman la autenticidad de la nota con pruebas suficientes o, por el contrario, evidencian la sospecha de un fraude. Si el mensaje contiene enlaces extraños a páginas web que se parecen mucho a las originales, no debemos confiar en las apariencias. En caso de duda, tecleemos en el navegador la dirección exacta del servicio aludido.

Raymond Chen y el misterio del JPG testarudo

Ramón Sola — Tue, 31 May 2011 19:07:53 GMT

The Old New Thing es uno de los blogs más populares de Microsoft. Chen habla sobre todo de la historia de Windows y de aspectos complejos, confusos o poco corrientes de la programación de software bajo esta gran familia de sistemas operativos. Además es capaz de transformar hábilmente verdaderos tostones, como la intrincada plataforma COM, en piezas interesantes y amenas. Sus escritos no pueden considerarse, sin embargo, fragmentos de documentación formal (como él dice, “only for entertainment purposes”, solo para diversión).

Otra faceta quizá algo menos conocida del autor es su columna Windows Confidential en la revista de Microsoft TechNet. En el número de abril de este año, Chen dedicó su espacio a la resolución de un curioso enigma con un fondo de pantalla empresarial que no se distribuía correctamente mediante directivas de grupo. Os animo a leer la historia en The Mystery of the Recalcitrant JPG. La entradilla sintetiza el argumento: una extensión de archivo incorrecta puede causar muchos problemas, especialmente cuando se sospecha que el problema se halla en otro sitio. Si no os manejáis bien con el inglés podéis consultar la versión en español, una traducción automática en la que se puede colaborar.

Curiosidad: pantallazos azules de otros colores con NotMyFault

Ramón Sola — Sat, 22 Jan 2011 17:30:00 GMT

NotMyFault es un programa de demostración de Mark Russinovich para los libros Microsoft Windows Internals, de los que es coautor, y que él mismo usa ocasionalmente en sus presentaciones técnicas. Su propósito es exhibir las consecuencias de algunos errores de programación típicos en controladores, tales como bloqueos, fugas de memoria de núcleo, procesos zombis y especialmente la temida pantalla azul.

Nota: esta entrada no contiene ningún método de diagnóstico o resolución de problemas. Se recomienda encarecidamente ensayar el funcionamiento de NotMyFault exclusivamente en un sistema de pruebas (para mayor comodidad, una máquina virtual de usar y tirar), ya que su uso entraña el riesgo de corromper archivos y perder datos. En algún caso puede ocasionar que el sistema operativo no vuelva a arrancar.

La denominación de NotMyFault (“la culpa no es mía”) surge del supuesto de que un programa en modo usuario no puede derribar el sistema por sí mismo, de modo que se sirve de un controlador en modo núcleo, MyFault.sys, para tan vil propósito. Este es el agente ejecutor que lleva a cabo realmente la orden escogida en la ventana de la aplicación, acción que se compara con la elección de un veneno. Puesto que el privilegio de la carga de controladores de núcleo se restringe a las cuentas de usuario con mayor poder, la aplicación requiere credenciales de administrador para funcionar correctamente. En verdad, la utilidad práctica de NotMyFault es limitada y su relevancia igualmente escasa por tratarse de una herramienta de demostración. Sin embargo, Russinovich ha ido ampliando poco a poco sus funciones para exponer problemas típicos adicionales.

Uno de los acontecimientos que más diversión suele producir entre el público de una charla técnica, así como una indescriptible sensación de bochorno en los ponentes, es la aparición de un error inesperado en la pantalla de proyección, cuanto más espantoso mejor. Todo el mundo recuerda la pantalla azul durante la presentación de Windows 98 en la exposición Comdex de 1998 con Bill Gates como maestro de ceremonias. Pues bien, parece ser que a Mark Russinovich le gusta agradar al auditorio con una pantalla azul auténtica en algunas de sus sesiones sobre investigación de problemas en Windows. Aún puede darse una vuelta más de tuerca convirtiendo lo “cotidiano” en excepcional; vale, lo he destripado en el título. ¿Y si la pantalla azul ya no tuviese fondo azul o texto blanco?

Windows 3.1 y sus sucesores (Windows 3.11, Windows 95, Windows 98 y Windows Millennium) permitían modificar los colores del texto y el fondo de sus “pantallas azules” a través de los valores MessageTextColor y MessageBackColor de la sección [386Enh] del archivo System.ini. No obstante, en la familia Windows NT los valores de color están especificados directamente (hardcoded) en el código fuente del núcleo y por tanto incorporados al flujo de instrucciones de código máquina, así que variarlos no resulta fácil. El mes pasado, Russinovich explicó en su blog un método bastante complicado para modificar directamente en memoria estos números mediante el depurador del núcleo. Por supuesto, el éxito de esta empresa es efímero y, desde luego, alterar el archivo Ntoskrnl.exe con un editor hexadecimal tampoco es una opción por diversos motivos.

Entonces, ya que NotMyFault es tan “útil” para generar errores de sistema a propósito, el experto Alex Ionescu sugirió la idea de añadir esta peculiaridad de algún modo al programa. La implementación, según ha relatado hace unos días Russinovich, consiste en una rutina que manipula la paleta de colores VGA del controlador básico de vídeo. Para conseguir que el núcleo la invoque inmediatamente después de mostrar el texto de la pantalla azul, se inserta en una lista específica mediante la función KeRegisterBugCheckReasonCallback. Este mecanismo de retrollamada (callback) es totalmente opcional y está concebido particularmente para agregar datos al volcado de memoria, restablecer un dispositivo a un estado seguro o copiar la información del volcado a otro sistema de almacenamiento.

Por cierto, también hablaron de forma más resumida sobre este tema en Softzone.es: Cambiar el color de los pantallazos azules (BSOD) ahora es posible. Si alguien desea probar la aplicación, insistiré en la advertencia de la nota de arriba (únicamente en entornos de pruebas o pondrás en serio riesgo tus datos). La descarga se encuentra en la página oficial del libro Microsoft Windows Internals, Fifth Edition, incluye código fuente además de los archivos binarios firmados digitalmente, y es compatible con las ediciones x86 y x64 a partir de Windows XP. No obstante, al momento de publicar esta entrada, el código fuente del controlador MyFault distribuido en el archivo ZIP está anticuado: no se corresponde con los archivos compilados, sino que continúa siendo el de la actualización de marzo de 2009.

En fin, que os divirtáis provocando fallos a diestro y siniestro con pantallas de colorines, pero sin hacer maldades, ¿eh? ;-)

Se inicia el cierre de los grupos de noticias NNTP públicos de Microsoft

Ramón Sola — Mon, 31 May 2010 18:07:14 GMT

En cuanto se supo hace unos años que Microsoft eliminaría el componente de servidor NNTP en sus productos Exchange 2007 y Windows Server 2008, sus grupos de noticias públicos de colaboración entre usuarios estarían condenados a desaparecer. Tarde o temprano su plataforma subyacente quedaría obsoleta. Este día ha llegado ya.

La falta de flexibilidad de la plataforma NNTP para implantar mejoras, la dificultad de controlar el spam y moderar a los trolls, y la potenciación de los foros basados en web relegaron a los grupos de noticias a un rol muy discreto en la estrategia de comunidades técnicas de Microsoft. Así, a partir de mañana 1 de junio de 2010 y tras varios mensajes publicados a lo largo de esta primavera (boreal) a modo de recordatorio, Microsoft desconectará los grupos con menos actividad. El cierre se llevará a cabo de forma progresiva hasta el 1 de octubre, día de la terminación total del servicio.

Algunos hemos cultivado grandes amistades en esos grupos, que continúan activas a través de otros foros, redes sociales, correo electrónico y demás sistemas de comunicación. Hemos aprendido muchas cosas y aportado granitos de nuestro conocimiento. También hemos vivido oleadas de insidioso spam, y ataques furibundos de trolls y otras alimañas, que intentaban desestabilizar el ambiente de los grupos. Finalmente estamos asistiendo a su decadencia. Quede el saludo inicial de los servidores NNTP de Microsoft como recuerdo de esta época que termina:

200 NNTP Service 6.0.3790.3959 Version: 6.0.3790.3959 Posting Allowed

Y ahora vamos con las alternativas que ofrece Microsoft. A mí personalmente los foros web me parecen lentos y complicados de seguir. En español existen estas cuatro grandes comunidades:

MSDN, orientada al desarrollo de software con tecnologías Microsoft.
Microsoft TechNet, principalmente orientada a profesionales de Tecnologías de la Información (TI), aunque da cabida a consultas de usuarios no técnicos, para entendernos.
Microsoft Answers, respuestas orientadas a usuarios no técnicos.
Microsoft Office System y Dynamics.

Ah, de paso este blog cumple hoy tres años, sin fastos ni alharacas.

205 closing connection - goodbye!

Adobe rectifica la modificación de permisos del registro en Reader 9.2

Ramón Sola — Sun, 18 Oct 2009 06:24:20 GMT

Hace algo más de dos semanas publiqué una entrada que manifestaba la relación entre instalaciones fallidas de Internet Explorer 7 y Adobe Reader 9. Llevaba planeando su redacción durante varios meses, sin embargo otras personas ya habían informado acerca del fenómeno algún tiempo antes en diversos blogs y foros.

Baste introducir los términos 34a715a0 adobe en un buscador para obtener algunas referencias coherentes. Se pueden encontrar comentarios de marzo, abril o mayo de este año 2009, o incluso de octubre o diciembre de 2008. El primer informe de error en una instalación de Internet Explorer 7 del que tuve noticia, a propósito de la clave HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}, surgió en un foro de Windows XP en español en agosto del año pasado.

La versión definitiva en inglés de Adobe Reader 9.0 apareció hacia junio de 2008 y la versión en español le siguió un poco más tarde. Pues bien, Adobe ha publicado estos días la versión 9.2 de su lector de documentos PDF, en la que ha corregido varios fallos de seguridad. Esta nueva versión no tendría mayor relevancia si no fuera por un detalle: se ha retirado la clave {34A715A0-6587-11D0-924A-0020AFC7AC4D} de la lista de claves del registro a las que se les aplican nuevos permisos más restrictivos durante la instalación. Esto significa, al fin, que Adobe Reader 9.2 no contribuirá más al fracaso de una instalación de Internet Explorer 7 sobre un sistema basado en Windows XP o Windows Server 2003 (con el nombre del grupo Administradores distinto del inglés). Si existe una instalación previa de Adobe Reader 9, la versión 9.2 eliminará la clave de forma transitoria, como parte de la desinstalación de la versión antigua, y la creará nuevamente conservando los permisos heredados.

Mención especial merece un artículo de asistencia técnica de Adobe, con fecha del 21 de agosto de 2009, en el que se admite la modificación intencionada de permisos en la instalación de Reader 9 y se aportan varias soluciones: Reader 9: Permissions in registry keys are altered during installation. El texto puede variar con el tiempo, así que presento una traducción basada en la edición original.

Reader 9: los permisos de claves del registro se modifican durante la instalación

Problema

Si se instala Internet Explorer u otra aplicación basada en el navegador (como aplicaciones SAP) después de haber instalado Reader 9, la instalación podría fallar con errores relativos a permisos en el registro o mensajes como el siguiente:

"No se disponen de los permisos necesarios para cambiar la configuración del sistema."

Causa

Reader 9.1 cambia los permisos en algunas claves del registro requeridas por Internet Explorer. Estos permisos se establecen en sólo lectura para los administradores. Para instalar Internet Explorer correctamente, el administrador necesita control total sobre las claves.

Después de instalar Reader 8, la clave HKEY_CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} presenta los siguientes permisos:

Administradores: Control total, lectura

System: Control total, lectura

Tras instalar Reader 9, la clave HKEY_CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} presenta los siguientes permisos:

Administradores: Sólo lectura

System: Control total, lectura

Solución

1. Desinstale Reader 9.1, instale Internet Explorer y después instale Reader 9.1 otra vez. Siguiendo este orden de instalación evitará el problema.

2. Cambie los permisos de la siguiente clave para permitir "Control total" a los administradores:

HKEY_CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}

3. Cree un archivo MST usando el Asistente de Personalización 9 (Customization Wizard 9), que permite transformar la instalación normal de Reader para despliegues en entornos empresariales.

    a) Abra el MSI de Reader en el Asistente de personalización y seleccione el editor directo.

    b) En la columna Tablas, seleccione 'LockRegPermissions'.

    c) Localice estas tres filas bajo la columna Path:

Path User Permission

CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} 1 131097

CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} 22 983103

CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} 26 131097

    d) Cambie las celdas Permission para los usuarios 1 (admin) y 26 (usuario) de '131097' a '983103'.

    e) Agregue otras personalizaciones si fuera necesario.

    f) Genere el archivo MST.

    g) Instale Acrobat o Reader con el archivo MST.

Información adicional

Este problema se ha resuelto en Acrobat/Reader 9.2.

Observación: los valores de la columna User se corresponden con la enumeración WELL_KNOWN_SID_TYPE del API de Windows. De esta manera, el número 1 se refiere al grupo Administradores, el 22 a la cuenta SYSTEM (LocalSystem) y el 26 al grupo Todos.

En mi opinión, la rectificación de Adobe llega un poco tarde pero es bienvenida de todos modos.

IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}

Ramón Sola — Wed, 30 Sep 2009 18:06:00 GMT

Ahora que la versión principal de Internet Explorer que se está distribuyendo es la 8, han disminuido mucho en los foros, si no han desaparecido, las consultas sobre los problemas de instalación de la versión 7 por falta de permisos en algunas claves del registro. Sin embargo, desde agosto de 2008 hasta casi mediados de este año, estas preguntas eran bastante habituales, especialmente en foros de Windows XP.

En los informes, una rama del registro destacaba sobre todas las demás. Un ejemplo:

0.250: IECUSTOM: Scanning for proper registry permissions...
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\ProxyStubClsid
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\ProxyStubClsid32
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\TypeLib
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\TypeLib
0.656: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.922: IECUSTOM: Scanning for proper registry permissions...
1.125: IECUSTOM: Scanning for proper registry permissions...
1.375: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
1.437: IECUSTOM: Backing up registry permissions...
1.437: IECUSTOM: Finished backing up registry permissions...
1.437: IECUSTOM: Setting new registry permissions...
1.453: IECUSTOM: Unable to clear DACLs HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
1.453: IECUSTOM: Finished setting new registry permissions...
1.453: IECUSTOM: An error occured verifying registry permissions. ERROR: 0x80070534
1.453: DoInstallation: CustomizeCall Failed: 0x3f5
1.453: IECUSTOM: Restoring registry permissions...
1.453: IECUSTOM: Finished restoring registry permissions...
1.453: No se puede escribir la clave del Registro de configuraciones.
1.453: La instalación de Internet Explorer 7 no ha finalizado.
1.453: Update.exe extended error code = 0x3f5

Ya expliqué en una entrada anterior la causa del error 0x80070534 en esta situación concreta y la consiguiente interrupción de la instalación, que ocurren si el grupo de administradores tiene un nombre diferente de Administrators. Este problema ya está solucionado en Internet Explorer 8.

Ahora bien, hay una aplicación muy usada que contribuye decisivamente a que los permisos de una clave específica del registro acaben resultando demasiado restrictivos. En honor a la verdad, lo que influye en el problema no es la propia aplicación en funcionamiento, sino las instrucciones que ejecuta su proceso de instalación. En su afán por proteger varias ramas del registro relativas a componentes de la aplicación, limita los permisos de una clave que realmente es propiedad de un componente de Windows y concretamente de Internet Explorer. Como es de esperar, dicha clave resulta ser HKEY_CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}, o más propiamente HKEY_LOCAL_MACHINE\Software\Classes\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}.

¿De qué aplicación se trata? No era un antivirus o un producto de seguridad, como señalaban mis primeras e infundadas sospechas. Tampoco pertenece a Microsoft. La aplicación es… tachán, tachán… redoble…

ADOBE READER 9

Podéis comprobarlo. Instalad Windows XP con SP2 o SP3 en español en un sistema de pruebas (una máquina virtual, por ejemplo), e instalad Internet Explorer 7. Veréis que no da ningún problema. Después, desinstalad Internet Explorer 7, instalad Adobe Reader 9 y luego Internet Explorer 7. ¡Catacroc! Fallo de instalación. Os invito a observar con Regedit los permisos de la clave HKEY_LOCAL_MACHINE\Software\Classes\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D} y sus descendientes, antes y después de Adobe Reader.

En fin, un misterio menos. Quizá relate en un futuro cercano cómo llegué a esta conclusión.

Próxima retirada de las herramientas Regmon y Filemon de Sysinternals

Ramón Sola — Sun, 23 Aug 2009 06:25:57 GMT

El pasado mes de julio el blog de Microsoft Windows Sysinternals anunció, a través de una escueta nota, que a partir del próximo 1 de septiembre de 2009 dejarían de ofrecerse las viejas herramientas Registry Monitor y File Monitor: “Filemon and Regmon End of Life on 9/1/09”.

Regmon y Filemon se consolidaron durante mucho tiempo como herramientas imprescindibles para resolver determinados problemas o simplemente para la investigación básica de la actividad interna de aplicaciones o módulos del sistema. Numerosos artículos en Internet y particularmente en la Knowledge Base de Microsoft las recomendaban encarecidamente, incluso desde antes de que Microsoft comprara la empresa hace unos tres años. Su popularidad era enorme.

Regmon y Filemon solían seguir una evolución paralela: los cambios que se le hacían a un programa se trasladaban igualmente al otro, ya fuera en forma de nuevas funciones, mayor compatibilidad con algunos sistemas o correcciones de bugs. Sin embargo, Process Monitor se alzó como sucesor en noviembre de 2006, reuniendo la funcionalidad en una sola aplicación y añadiendo nuevas capacidades de análisis de actividad en los sistemas basados en Windows. Este hecho, que coincidió más o menos con el final del ciclo de vida de Windows 98 y Windows Millennium, marcó el principio del fin para las dos venerables herramientas anteriores, cuyo último número de versión fue el 7.04.

Para acabar, simplemente como recordatorio: a partir del próximo 1 de septiembre de 2009, Regmon y Filemon ya no podrán descargarse desde el sitio de Microsoft Sysinternals. No obstante, para alivio de aquellos que aún tengan que dar cierto nivel de asistencia técnica a versiones de Windows obsoletas, probablemente existan abundantes réplicas en los sitios que recopilan programas de todo tipo. Podréis verificar las copias auténticas mediante sus firmas digitales. ;-)

Regmon y Filemon han muerto. ¡Viva Process Monitor!

Actualización 19 de septiembre de 2009: finalmente, la retirada anunciada no se llevó a cabo el día 1 sino ayer, viernes 18. Se han eliminado las referencias a las herramientas Regmon y Filemon del sitio principal de Sysinternals en inglés y del repositorio http://live.sysinternals.com, aunque sus páginas particulares aún existen. Sin embargo, su descripción se ha reemplazado por el siguiente texto:

RegMon and FileMon are no longer available for download. They have been replaced by Process Monitor on versions of Windows starting with Windows 2000 SP4, Windows XP SP2, Windows Server 2003 SP1, and Windows Vista.

Todavía se pueden descargar mediante enlaces directos y a través de las ediciones del sitio en otros idiomas (por ejemplo, aquí Sysinternals en español), pero pienso que esa situación no va a durar mucho tiempo más. Además, también se ha informado de la próxima supresión de NewSID a partir del 2 de noviembre, una herramienta que aportaba una solución al problema de la duplicación de identificadores de seguridad (SID) en las clonaciones de unidades de disco de sistemas Windows y que Microsoft nunca había apoyado oficialmente.

El caso del Internet Explorer que acaparaba la CPU al abrir una página

Ramón Sola — Fri, 31 Jul 2009 21:58:43 GMT

Recientemente, como “técnico de soporte familiar”, me ha tocado investigar y resolver un problema con Internet Explorer 6 en un perfil de usuario de Windows XP. El navegador se iniciaba correctamente, pero al intentar entrar en una página cualquiera la carga no avanzaba y el proceso Iexplore.exe comenzaba a consumir un tiempo de CPU excesivo.

La ventana respondía a las acciones de ratón y teclado, se podía detener el intento de carga de la página o cerrar la ventana. No obstante, era imposible usar Internet Explorer en estas condiciones. El problema no se daba en otros navegadores dentro de la misma sesión de usuario (¡hola, fanáticos anti-IE!), ni en otros perfiles.

Puesto que el contratiempo ocurrió de forma repentina y requería una solución urgente, no tuve ocasión de guardar información sobre instantáneas de pila, capturas de pantalla o claves del registro posiblemente involucradas. Por lo menos un detalle que recuerdo me ha permitido construir a posteriori una secuencia parcial de llamadas para ilustrar la situación:

ChildEBP RetAddr 040dfc18 771e2e82 WININET!CCookieSettings::CCookieSettings 040dfc40 771e2fa2 WININET!CCookieSettings::GetSettings+0x29 040dfc54 771e55e6 WININET!CCookieSettings::GetSettings+0x24 040dfdc0 771b1957 WININET!EvaluateCookiePolicy+0xfd 040dfe68 7718cf94 WININET!HTTP_REQUEST_HANDLE_OBJECT::ExtractSetCookieHeaders+0xb9 040dfe84 7718cc4d WININET!HTTP_REQUEST_HANDLE_OBJECT::HttpSendRequest_Start+0x4a9 040dfe98 7718cb44 WININET!CFsm_HttpSendRequest::RunSM+0x59 040dfeb0 771a737b WININET!CFsm::Run+0x39 040dfee0 77f49588 WININET!CFsm::RunWorkItem+0x79 040dfef8 7c938182 SHLWAPI!ExecuteWorkItem+0x1d 040dff40 7c9381c3 ntdll!RtlpWorkerCallout+0x70 040dff60 7c938285 ntdll!RtlpExecuteWorkerRequest+0x1a 040dff74 7c93825c ntdll!RtlpApcCallout+0x11 040dffb4 7c80b6d9 ntdll!RtlpWorkerThread+0x87 040dffec 00000000 kernel32!BaseThreadStart+0x37

A primera vista una pila como esta no me sugería mucho; pensé que la causa sería alguna cookie almacenada que estuviera dañada. Sin embargo, eliminar las cookies no solucionó nada. Además borré los archivos temporales, sin apreciar mejora. Una traza de red tampoco mostraba anomalías; las peticiones HTTP y las respuestas del servidor web eran correctas. Introduje algunos nombres como EvaluateCookiePolicy o CCookieSettings en varios buscadores, esperando ver algún caso similar o remotamente relevante, y los resultados no fueron esclarecedores.

Al repasar una vez más la secuencia de llamadas, el nombre de la rutina EvaluateCookiePolicy adquirió sentido. Debía de estar relacionada con la evaluación de la configuración del filtro de cookies que se introdujo en Internet Explorer 6, que determina qué cookies se aceptan y cuáles no. Entonces fui a la pestaña Privacidad de Opciones de Internet, donde encontré que la configuración vigente era Personalizada, por lo que no correspondía a ninguno de los seis niveles preestablecidos. No obstante, en la ventana de Opciones avanzadas no se encontraba marcada la casilla Sobrescribir la administración automática de cookies ni se recordaba haber importado archivo XML alguno con preferencias de privacidad especiales. Después de restablecer la configuración predeterminada de privacidad, el navegador recuperó sus funciones habituales.

¿Cómo es posible que el fallo ocurriera de un modo tan repentino, teniendo en cuenta que Internet Explorer había estado funcionado anteriormente ese día? Además, puesto que la configuración del filtro se almacena en el registro de Windows (de una manera un tanto misteriosa, eso sí), ¿qué clase de confusión había en los valores como para interpretarlos en general como configuración personalizada y que su análisis, que en condiciones normales invierte muy poco tiempo, desencadenara un bucle infinito? ¿Qué cambios concretos llevó a cabo la restauración de la configuración predeterminada para revertir la situación? Como solía decir el presentador de un antiguo programa de televisión en España, “eso… nunca lo sabremos”.

Por otra parte, el bucle infinito no bloqueaba la interfaz de usuario porque se originaba en un hilo auxiliar de trabajo (worker thread), como sugiere la aparición de la rutina RtlpWorkerThread en la base de la pila (obviando la rutina de inicio BaseThreadStart). La función principal del API de Windows para la creación de estos hilos auxiliares es QueueUserWorkItem, en Kernel32.dll, aunque el componente WinInet recurre a una función interna de Shlwapi.dll que ejecuta una labor similar, SHQueueUserWorkItem, apoyándose en la rutina anterior.

ChildEBP RetAddr 00126fec 7c830a2e ntdll!RtlQueueWorkItem 00127000 77f49640 kernel32!QueueUserWorkItem+0x14 00127020 771a72fc SHLWAPI!SHQueueUserWorkItem+0xcf 00127048 771a90de WININET!CFsm::QueueWorkItem+0x1c

Y colorín colorado, este cuento se ha acabado.

Galletitas indigestas

Ramón Sola — Tue, 30 Jun 2009 17:57:00 GMT

Hace unos meses, un familiar me explicó que tenía problemas para visitar un diario digital desde su perfil de usuario y con el navegador Internet Explorer: cualquier dirección del diario que se intentara cargar daba lugar al clásico mensaje de “no se puede mostrar la página”.

El típico consejo facilón ante un fallo como este, teniendo en cuenta sobre todo el programa implicado (el muy controvertido Internet Explorer), es el que sugiere “abandonar ese navegador y acostumbrarse a otro”. Sin embargo, la sugerencia es buena en parte, pues probar otro navegador sí resulta útil para delimitar el alcance del problema. Efectivamente, las páginas del diario se cargaban de forma correcta en Mozilla Firefox u Opera, e incluso usando herramientas como Wget para Windows (una potente aplicación basada en la línea de comandos para descargar archivos y construir peticiones HTTP), así como en otros perfiles de usuario del sistema. Había que averiguar qué tenía de particular la configuración de Internet Explorer en ese perfil concreto de usuario.

Se comprobaron los complementos cargados sin observar nada fuera de lo común. ¿Y la limpieza de cookies y archivos temporales? Esa habría sido la solución fácil para salir rápidamente del apuro, pero dificultaba la investigación del motivo subyacente. ¿Algún cambio reciente en la configuración del sistema? No, y de haberlo, ¿por qué tendría que afectar a un único sitio web?

Dada la falta de ideas, decidí capturar una traza de red. Algunos problemas de comunicación en red se entienden con más facilidad si se capturan paquetes, pero para exprimir su potencial hay que conocer al menos los protocolos habituales, aunque sea a un nivel básico. No obstante, el volumen de información puede llegar a ser considerable en función de la actividad en la red. Para controlar este volumen conviene que el programa de captura de paquetes ofrezca filtros de captura o de visualización.

Un famoso analizador de protocolos de red es Wireshark, antiguo Ethereal, multiplataforma y de código abierto. Yo usé la herramienta Network Monitor de Microsoft en su versión 3.2 (la versión 3.3 se ha publicado recientemente), que solo es compatible con Windows. Aislé los paquetes pertinentes y subí la captura a mi almacén de Windows Live SkyDrive: 20minutos.cap. Es fundamental la precaución a la hora de publicar capturas de red, ya que es comprensible que contengan contraseñas, cookies u otra clase de datos delicados que no deberían divulgarse alegremente, como nombres o direcciones que sirvan para saber cómo está organizada la red. Dedicaré otra entrada a analizar los paquetes de la captura con detalle.

La conclusión fue la siguiente: puesto que la cookie del diario 20 Minutos en el navegador había alcanzado una longitud aproximada de cuatro kilobytes, el servidor HTTP forzaba el corte de la conexión como medida de protección. ¿La solución? Cerrar todas las ventanas de Internet Explorer, entrar en el directorio de las cookies y borrar un archivo con un nombre parecido a <usuario>@20minutos[1].txt. Desde entonces, el navegador ya no enviaba la cookie problemática y las páginas del diario se cargaban sin inconvenientes.

FIN, FIN/ACK, ACK

Segundo aniversario sin pena ni gloria

Ramón Sola — Sun, 31 May 2009 06:18:41 GMT

Ya se cumplen dos años de la creación de este humilde blog y aún no he logrado solventar los males que expuse en la entrada de celebración del primer año, aunque mantengo la esperanza de combatirlos con éxito.

El ritmo de publicación sigue siendo escaso, todavía mantengo algunos frentes abiertos (ya hubo algún comentario recordándome que debía algo) y la carpeta de borradores no hace más que crecer con ideas nuevas sin oportunidad de darles forma. Bueno, no está entre mis objetivos conseguir una popularidad enorme con muchas visitas diarias o múltiples comentarios nuevos cada semana, y hasta es posible que haya ahuyentado a lectores potenciales a causa de mis múltiples peticiones de no usar las posibilidades de interacción del blog como consultorio técnico.

De todas formas, la mayoría de las visitas procede de buscadores y a veces los términos de búsqueda no tienen mucho que ver con los artículos a los que dirigen, dándose la casualidad de que las palabras elegidas están distribuidas a lo largo de la página. En los casos en que el buscador acierta con el artículo correcto, me da la impresión de que la gente es reacia a aportar su opinión (contando con que no fuera yo mismo el que desactivara los comentarios como medida transitoria contra el spam). Además hay que considerar que algunas entradas se van quedando anticuadas, pero es normal.

En fin, no cedo en mi propósito de ofrecer información útil, de calidad, novedosa y veraz en la medida en que me sea posible, con toques de opinión en forma de alabanzas o reproches cuando los considere oportunos. Estoy pensando en cambiar el rumbo publicando entradas más cortas, directas al grano, frente a artículos largos y desarrollados que suponen un tiempo de preparación mucho mayor. El tiempo dirá.

Los males del sobrecalentamiento

Ramón Sola — Wed, 27 May 2009 17:32:36 GMT

Hace más de año y medio hablé de una experiencia personal con el ventilador y el disipador del microprocesador. Y es que, para mantener el PC en perfecto estado de revista, no solo basta con aplicar buenas prácticas con respecto al software, sino que también deben examinarse de vez en cuando sus “tripas” (o pedírselo a alguien de confianza) por si necesitan una limpieza urgente de polvo.

El caso es que volvió a aparecer el fantasma del ventilador acelerado más de la cuenta y, ahora que llegan los calores por estas tierras, vino acompañado de algunos fallos que por las circunstancias se atribuían fácilmente a la tarjeta gráfica. De repente el monitor dejaba de recibir señal de vídeo, se corrompía la pantalla, Windows cambiaba repentinamente a modo VGA y mostraba el mensaje “el controlador de pantalla no responde”, o el PC se colgaba de tal forma que ni la técnica del volcado de memoria forzoso mediante la tecla Ctrl derecha más la tecla Scroll Lock dos veces, con un teclado PS/2, resultaba eficaz. De vez en cuando, tras algún cuelgue de esos, Windows registraba en el siguiente arranque varios sucesos de Machine Check (uno de esos mensajes genéricos Application Popup, número 26), de contenido indescifrable con información interna del estado del microprocesador y de la arquitectura del sistema.

Entonces se volvió a desmontar y limpiar tanto el disipador de calor como el ventilador del microprocesador y se renovó la pasta térmica. Al montarlos de nuevo y encender el equipo, mejoraron dos aspectos fundamentales: menos ruido y más estabilidad.

De todas formas, la observación de la placa base ha revelado un hecho preocupante. Varios de los condensadores electrolíticos situados en las cercanías del microprocesador, cuya función básica es estabilizar el voltaje de alimentación, están hinchados en su parte superior. Esta consecuencia del envejecimiento, o también del calor, reduce su eficacia y puede favorecer comportamientos erráticos del sistema. El PC tiene algo menos de cinco años, que ya es tiempo en este mundillo.

En fin, hay cosas más importantes en la vida de las que preocuparse que la incertidumbre sobre el funcionamiento y la fiabilidad de una máquina o de cualquiera de sus componentes.

Remedio rápido para algunas instalaciones fallidas de Internet Explorer 7 en Windows XP y Windows Server 2003

Ramón Sola — Mon, 27 Apr 2009 18:28:28 GMT

El proceso de instalación de Internet Explorer 7, en determinadas versiones de Windows XP o Windows Server 2003 cuyo idioma difiere del inglés, no consigue agregar permisos de control total para el grupo predefinido Administradores sobre claves del registro que los han perdido.

Este problema se manifiesta en el archivo \Windows\Ie7.log de la siguiente manera:

IECUSTOM: Scanning for proper registry permissions...
IECUSTOM: Unwriteable key xxxxxxxx
IECUSTOM: Unwriteable key yyyyyyyy
IECUSTOM: Unwriteable key zzzzzzzz
IECUSTOM: Backing up registry permissions...
IECUSTOM: Finished backing up registry permissions...
IECUSTOM: Setting new registry permissions...
IECUSTOM: Unable to clear DACLs xxxxxxxx
IECUSTOM: Finished setting new registry permissions...
IECUSTOM: An error occured verifying registry permissions. ERROR: 0x80070534
DoInstallation: CustomizeCall Failed: 0x3f5
IECUSTOM: Restoring registry permissions...
IECUSTOM: Finished restoring registry permissions...
No se puede escribir la clave del Registro de configuraciones.

Nota: un código de error diferente a 0x80070534 en la línea An error occured verifying registry permissions indicaría un fallo de otra naturaleza que no tendría relación con lo aquí expuesto.

¿Qué significa el código 0x80070534? La herramienta Err dice:

C:\>err 0x80070534
# as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x534
# for hex 0x534 / decimal 1332 :
ERROR_NONE_MAPPED winerror.h
# No mapping between account names and security IDs was done.
# 1 matches found for "0x80070534"

C:\>net helpmsg 1332

No se ha efectuado ninguna asignación entre los nombres de cuenta y los identificadores de seguridad.

El motivo del error de instalación de Internet Explorer 7 es un defecto de programación en el archivo Iecustom.dll. Se asumió que el grupo de administradores se llama Administrators, lo que no siempre es cierto puesto que, según el idioma de Windows, los nombres de los grupos de seguridad predefinidos pueden venir traducidos: Administradores en portugués y español, Administrateurs en francés, Administratoren en alemán… Ejemplos más exóticos son Järjestelmänvalvojat en finlandés o Rendszergazdák en húngaro. En su lugar debió usarse el identificador de seguridad del grupo, que se definió como S-1-5-32-544.

Las versiones beta y RC1 de Internet Explorer 8 también presentaban este defecto, aunque Microsoft lo corrigió afortunadamente en el programa de instalación de la versión definitiva (RTM). Esta vez se le solicita correctamente a Windows, mediante la función CreateWellKnownSid, la estructura de datos que representa el identificador de seguridad del grupo predefinido Administradores.

Sin embargo, el descuido da una idea para una solución, a mi entender, más rápida que la revisión manual de los permisos de las claves afectadas y menos agresiva que la aplicación de herramientas como SubInACL sobre ramas completas del registro. Podemos crear un nuevo grupo con el nombre Administrators y agregarle el usuario que va a ejecutar la instalación de Internet Explorer. Este cambio en la pertenencia de grupo se aplicará por primera vez en el siguiente inicio de sesión del usuario, por lo que no tiene un efecto inmediato.

Importante: las instrucciones están pensadas para entornos domésticos. Desconozco las implicaciones del procedimiento sobre un controlador de dominio basado en Windows Server 2003 (por el contrario, no debería haber inconveniente en un servidor miembro o un servidor independiente), o si podría interferir con despliegues automáticos de Internet Explorer 7 en entornos empresariales. Para esos casos particulares se ruega una evaluación cuidadosa, probando sobre un grupo limitado de sistemas si hace falta.

Es más largo explicar bien el método que llevarlo a cabo.

Abrir una ventana de símbolo del sistema: Inicio, Ejecutar, CMD. O Inicio, Todos los programas, Accesorios, Símbolo del sistema.
Crear el grupo Administrators, con un comentario opcional para recordar su propósito.
net localgroup administrators /add
O bien,
net localgroup administrators /add /comment:"Grupo provisional para facilitar la instalación de Internet Explorer 7"
Agregar el usuario que iniciará la instalación de Internet Explorer 7, que puede ser el mismo que ejecuta estas órdenes. Si el nombre está formado por varias palabras, es imprescindible entrecomillarlo (lo normal y más recomendable en primer lugar es que no contenga espacios). Por ejemplo:
net localgroup administrators /add Frankenstein
O bien,
net localgroup administrators /add "Hombre Lobo"
Comprobar que la pertenencia al grupo es correcta.
net localgroup administrators
Cerrar la sesión y abrirla con el usuario agregado anteriormente.
Instalar Internet Explorer 7.
Si la instalación ha terminado correctamente, se puede eliminar el grupo (únicamente si lo hemos creado nosotros, ojo, no vaya a ser que borremos por equivocación un grupo predefinido). Esto no implica la supresión de las cuentas de usuario, tan solo su condición de pertenencia.
net localgroup administrators /delete
Si ocurrió un error, se recomienda dejar en un foro el contenido del archivo \Windows\Ie7.log para recibir más ayuda.

Resumen:

Crear grupo: net localgroup administrators /add
Agregar usuario: net localgroup administrators /add Fulano
Cerrar la sesión e iniciarla con Fulano.
Instalar Internet Explorer 7.
Borrar el grupo: net localgroup administrators /delete

Espero que esto sea útil.

¡Arréglalo por mí!

Ramón Sola — Sun, 22 Mar 2009 07:30:54 GMT

El pasado mes de noviembre, Microsoft puso en marcha una iniciativa para proporcionar una solución sencilla a varios problemas específicos, tan solo ejecutando una pequeña herramienta creada para tal fin. La iniciativa se denomina Fix it for me.

Este conjunto de medidas nace con el propósito de que los usuarios, para resolver algunos pequeños inconvenientes, no necesiten buscar ayuda externa ni ahondar en los misterios de la verborrea técnica que suele acompañar a los artículos de la Knowledge Base. Únicamente quieren obtener el remedio lo antes posible, con un riesgo y esfuerzo mínimos. Al fin y al cabo, un ordenador (y más específicamente un PC) debe ser una herramienta de trabajo o de ocio, no una máquina que se transforma en un terrible instrumento de tortura psicológica en cuanto algo deja de funcionar como está previsto.

Por el momento las soluciones de los artículos de Fix it for me se reducen a pequeñas modificaciones en el registro para activar o desactivar ciertas funcionalidades, o sencillas secuencias de comandos (scripts) que introducen algún cambio en el sistema. Los vehículos de transmisión son generalmente paquetes de Windows Installer (MSI). Antes de aplicar cualquiera de estos archivos, es muy recomendable repasar el artículo asociado para prevenirse contra posibles efectos no deseados y otras sorpresas desagradables. Los usuarios avanzados encontrarán, además, los procedimientos manuales equivalentes a las soluciones automáticas para comprender mejor qué hacen y cómo funcionan, e incluso llevarlos a cabo si les incomoda ejecutar una herramienta de la que no saben muy bien lo que hace.

A continuación traduzco a mi manera la entrada de presentación del blog Fix it for me, que constituye la declaración de intenciones del personal responsable del proyecto:

¿Alguna vez se ha encontrado con un artículo de la Knowledge Base de Microsoft, o se le ha presentado una solución del informe de errores de Windows (WER), y se ha preguntado “por qué Microsoft no puede resolver el problema por mí”? Hoy en día, los artículos de la KB y las soluciones de WER le proporcionan una lista de pasos que puede seguir para solucionar el contratiempo. Sin embargo, el futuro se presenta muy diferente y esperamos que le ayude a resolver más rápido y con más facilidad las dificultades que encuentre al usar nuestros productos.

El objetivo de nuestro equipo es automatizar los pasos de las soluciones en los artículos de la KB de Microsoft y los informes de errores de Windows (WER), de forma que usted solo tenga que pulsar un botón para aplicar el remedio.

Al momento de publicar esto, ya hay cerca de un centenar de artículos disponibles en esta modalidad con sus correspondientes soluciones automáticas. Las novedades se pueden ir conociendo a través de las fuentes RSS y Atom del blog Fix it for me. También es posible enviar comentarios y sugerencias al grupo Microsoft Product Quality Online de Facebook, después de hacerse miembro, claro.

Espero que Fix it for me suponga a la larga una mejora notable en la satisfacción de los usuarios de productos de Microsoft. No obstante, muchos fallos aún seguirán requiriendo algo más que la ejecución de simples programitas para su resolución definitiva, como por ejemplo la intervención de un experto.

Path	User	Permission
CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}	1	131097
CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}	22	983103
CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}	26	131097