*Nota: Si se hace por actualizaciones automáticas, es necesario primero instalar Windows Internet Explorer 9, para luego implementar la versión 10.

No obstante, para algunas personas puede ser necesario desinstalar completamente la versión de Internet Explorer 10 en Windows 7, por alguna razón, sea compatibilidad, política, gusto, etc. Este artículo pretende explicar dos procedimientos sencillos para desinstalar IE10 en Windows 7, y se divide así:

- Desinstalación manual utilizando el Panel de Control.

- Desinstalación manual utilizando la herramienta DISM, embebida en Windows.

Para tener en cuenta: Internet Explorer se puede desactivar desde el Panel de Control, Activar o desactivar características de Windows, pero esto NO desinstala el navegador de Windows, sólo elimina su referencia.

Desinstalación manual utilizando el Panel de Control

Para desinstalar Internet Explorer 10 desde el Panel de Control, se debe seguir el siguiente procedimiento:

- Clic en el Menú de Inicio > Panel de Control > Programas > Programas y Características.

- En la ventana de Programas y Características, clic en el enlace izquierdo de “Ver actualizaciones instaladas”. para ver todas las actualizaciones que tiene actualmente Windows.

Seleccionar la actualización: "Windows Internet Explorer 10” y clic en el botón de “Desinstalar (Unistall)”:

Iniciará una pequeña ventana que indica el proceso de desinstalación. Después de esto, Windows se reiniciará e IE 10 estará desinstalado.

Desinstalación manual utilizando la herramienta DISM, embebida en Windows

Para desinstalar Internet Explorer 10, a través de línea de comandos, utilizando la herramienta DISM, se debe seguir el siguiente procedimiento:

- Clic en el menú de Inicio, buscar CMD, clic derecho sobre el resultado y seleccionar: “Ejecutar como administrador”.

- En la ventana del símbolo del sistema, se debe ingresar:

Dism /Online /Get-Package.

El comando anterior mostrará una lista completa de todos los paquetes instalados en el sistema operativo. Se debe buscar el correspondiente a Internet Explorer:

Una vez se tenga el nombre completo, se debe copiar desde el Símbolo del sistema y ejecutar:

Dism /Online /Remove-Package /PackageName: Microsoft-Windows-InternetExplorer-Package-TopLevel~31bf3856ad364e35~x86~~10.2.9200.16521

*Nota: El nombre del paquete puede variar, sobre todo en la arquitectura, pues es posible que se tenga la versión de 32 bits (x86) o la versión de 64 bits (AMD64/x64). Se debe verificar siempre el nombre con el primer comando.

Al finalizar la ejecución del comando, debe solicitar permiso para reiniciar el equipo. Después de hacerlo, Internet Explorer 10 se habrá quitado del sistema.

Sergio Calderón (Checho)
Twitter | LinkedIn

IMPORTANTE: Responsabilidad

El contenido de este sitio es provisto “como está” sin garantías expresas o implícitas de ninguna índole. Microsoft no se responsabiliza por ninguna de ellas. Los procedimientos y soluciones que aquí se escriban no constituye una recomendación oficial de Microsoft.

Todo se generará desde La Comunidad para La Comunidad.

¡Hola nuevamente!

Quisiera contar como un Off-topic que estoy muy contento con las últimas máquinas virtuales con las que he tratado de trabajar porque me han dado la oportunidad de darme un poco más de aprendizaje que he tratado de compartir aquí.

A continuación detallaré otro problema que no es demasiado común pero suele pasarle a varias personas, como siempre seguiré la línea de: El problema, la causa y su solución.

*Nota: Para los que tengan el inconveniente y no deseen ver el desarrollo de todo el artículo para solventarlo pueden ir directamente a “La solución” en la última parte del artículo y seguir los pasos.

El problema

El error empezó cuando estaba tratando de instalar un paquete .MSI (Windows Installer) del Cliente de Windows Intune en una de las máquinas para que fuera reconocido por la Consola de administración (Espero pronto tratar algunos temas de estos).

Cuando le di doble clic para iniciar la instalación, obtenía este mensaje de error:

“No se tiene acceso al servicio de Windows Installer. Esto puede suceder si Windows Installer no está correctamente instalado. Póngase en contacto con el personal de soporte técnico para obtener ayuda”.

En Inglés, el mensaje sería similar al siguiente:

“The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance”.

*Nota: El mensaje de error puede variar con algun código de error incluido, pero suelen referirse a lo mismo.

No tenía idea a qué se podría deber este problema porque ni en física ni en virtual acostumbro a instalar aplicaciones de mantenimiento que suelen ser las primeras causantes de estos inconvenientes pero como había utilizado tanto la máquina en los anteriores contenidos, probáblemente “algo” había hecho. Aunque algo había visto del problema en los Foros, quería aprovechar la oportunidad para tratar de investigarlo y solucionarlo, por supuesto, había que hacer uso de la única herramienta que puede dar una completa visión de lo que esté pasando: Process Monitor de Sysinternals.

La causa

Procedí entonces a reproducir el mensaje de error mientras tenía Procmon activo, así cualquier actividad que sucediera mientras me entregaba el mensaje la podría rastrear.

Después de reproducirlo, paré Process Monitor y empecé a buscar algo que me ayudara a identificar la causa del problema pero tuve una gran mala suerte y es que no aparecía nada relacionado con operaciones faltantes o que tuvieran acceso denegado como normalmente lo hace. Lo segundo fue entonces comparar el error y el primer pantallazo que debía salir en un equipo funcional pero de nuevo, nada anormal y de hecho, todas las operaciones relacionadas con Windows Installer las estaban cumpliendo los dos equipos con resultados satisfactorios.

Antes de seguir con Process Monitor, pensé que podría entonces estar el problema relacionado con el servicio propio de Windows Installer, así que abrí la Consola de Servicios en el PC que presentaba el error, pero al buscar Windows Installer me sorprendí con que el Servicio no estaba:

Revisé en uno de los equipos funcionales y en efecto, el Servicio debía estar disponible:

El Servicio probáblemente entonces no estaba registrado (No sabía cómo se le había perdido), aquí el hecho que al intentar instalar algun paquete no pudiera acceder a éste. Debía encontrar era como volverlo a su funcionalidad.

Volví a Process Monitor y pensé que quizá al correr el paquete en el equipo que corría correctamente, Process Monitor podría darme un poco más de información o por lo menos alguna pista útil.

Empecé parte de la instalación, abrí Procmon y busqué esta vez por el nombre interno del servicio (msiserver) y esta vez, el primer resultado fue la pista contundente:

Windows estaba haciendo uso de la función RegOpenKey para abrir la clave:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\msiserver

Después de esto empezaba a realizar consultas a varios de sus valores, unos con buen resultado y otros no tanto, pero como era en el equipo funcional era totalmente normal. Por último cerraba completamente la clave que había abierto (msiserver).

Bajo esta clave están alojados todos los Servicios de Windows, como éste de Windows Installer está establecido a manual, probáblemente estas operaciones incluían la inicialización y su respectivo trabajo, el problema era que bajo la Consola de servicios del equipo con el error no aparecía el Servicio, al no aparecer no podía hacer la consulta, al no poder hacer la consulta no podía proceder con la instalación y era cuando da el molesto mensaje.

Ahora, como estos son claves y valores de Registro, debía ver qué sucedía en el equipo con el problema, procedí entonces a abrir el Editor de Registro, navegué esta la clave y me encontré con esto:

Habían algunos valores pero en ninguna parte hacía referencia al Servicio de Windows Installer (msiserver), abrí la misma clave en el equipo funcional y esta fue la grata sorpresa:

A parte del valor ImagePath que referencia la ruta del Servicio, era obvio que en el equipo que presentaba el problema hacían falta varios valores más, por ahí podría estar el problema.

Comparando con WinDiff

Leyendo el fantástico libro de Sysinternals Administrator’s Reference de Mark Russinovich y Aaaron Margosis; entre uno de los problemas que precísamente había documentado aquí hace ya algun tiempo sugerían utilizar WinDiff cuando se tratara de hacer comparación de archivos.

WinDiff, es una herramienta incluida en el SDK de Windows, entre todos los tipos de archivo plano que permite comparar, se encuentran los de Registros de Windows.

Aproveché esta gran característica, además de que tenía WinDiff instalado, así que exporté las dos claves de Registro, tanto del equipo funcional como del no funcional, abrí WinDiff fui al menú File y seleccioné Compare files…

Lo siguiente es abrir los dos ficheros a comparar y en unos segundos, WinDiff entregará un resultado preciso de la diferencia entre lo que hayamos puesto a comparar. Para este caso, el resultado fue el siguiente:

*Nota: Hacer clic en la imagen para verla en tamaño completo.

Normalmente, WinDiff diferencia el contenido de los dos archivos asignándoles un color, por lo general Rojo y Amarillo, o bien Rojo y negro, entre otros.

Cuando sólo aparece un sólo color, y el signo de <! , indica que cada una de esas lineas difiere del archivo contra el que se está comparando

Para este caso, ya podía estar seguro de que hacía falta los valores: ImagePath, ObjectName, Start, Type, ServiceSidType y RequiredPrivileges.

Esto por supuesto, abría de nuevo la esperanza de solucionar el problema.

La solución

Ya sabía la causa, y como en la mayoría de las ocasiones, probáblemente el volver a importar estos valores o bien a crearlos me podría solventar el problema.

Lo que hice sin embargo, fue exportar toda la clave de:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver

A continuación, la pasé al equipo que presentaba los problemas, la ejecuté, la importé y como el error persistía, procedí a reiniciar el equipo.

Después del reinicio, intenté ejecutar el paquete de instalación y ¡Problema solucionado! Bastaba con reiniciar para que el Servicio se volviera a registrar e hiciera el trabajo que le correspondía al momento de su llamado.

La razón por la que detallara tan rápido la solución es que aproveché este inconveniente también para automatizar el proceso.

Para las personas que vean este artículo entonces y tengan este mismo problema, les dejo dos alternativas:

Solución automática: Presentando FixMSI

FixMSI, es una pequeña aplicación que he desarrollado utilizando la API de Windows, utiliza las función RegKeyCreateKeyEx para crear el valor de msiserver en la ubicación correspondiente y luego hace uso de la función RegSetValueEx para establecer todos los valores correspondientes y que requiere el Servicio de Windows Installer para funcionar.

Por último, FixMSI reinicia el equipo para que todos los cambios surtan efecto y que cualquier paquete (.MSI) se pueda instalar sin obtener el error.

Este proceso es totalmente transparente para el que ejecute FixMSI, sólo se verá la pantalla de confirmación y la de posterior aviso de reinicio:

*Nota: FixMSI incluye un manifiesto para solicitar la elevación de permisos si está activo el Control de Cuentas de Usuario (UAC).

Pueden descargar FixMSI desde aquí:

Solución manual: Importando Registro

El método anterior es el que personalmente recomiendo porque como ven, es sólo aceptar el mensaje y la aplicación hará el resto de una forma rápida y segura.

Si no llega a funcionar, pueden bajar e importar el archivo de Registro original del Servicio de Windows Installer desde aquí:

Después de esto, reinician manualmente y deberían poder realizar las instalaciones sin problemas.

Espero que esto les pueda servir de ayuda.

Los que prueben FixMSI, les agradecería que me entregaran el feedback comentando en este post para saber si efectivamente les solucionó este problema.

¡Muchas gracias!

Saludos,

Sergio Calderón (Checho)

Hola a todos,

Quizá este caso les pueda parecer un poco extraño por el posible causante, pero es una excelente oportunidad de ver que cuando hasta en el más fatal de los casos siempre quedará “algo” por hacer.

*Nota: El contenido que verán a continuación es exactamente igual al que puse en mi Blog: Checho’s Blog, por aquello de los títulos =)

Como he venido escribiendo en los anteriores artículos que guardan similitud con este, lo dividiré en “El Problema”, “La posible causa” y “La solución”. El objetivo es como siempre, poder compartir todo lo que más pueda hasta donde mi conocimiento me lo permita y claro está, dejar abierto el espacio para que compartan sus comentarios al respecto si así lo desean.

El problema

Desde hace unos días estaba escribiendo un artículo del que estoy muy agradecido porque por fin, tenía la oportunidad de ver una característica muy interesante del fantástico Process Monitor llamada Boot Logging.

Básicamente, consiste en activar el monitoreo de Process Monitor para que en el próximo reinicio de Windows, su controlador se active como uno de Arranque de inicio, lo que le permite correr como uno de los primeros en la secuencia de inicio, mucho antes que la mayoría de los demás controladores. Al poder hacer esto, Process Monitor podrá monitorear toda la primera actividad, incluyendo lo que se carga adicionalmente mientras Winlogon hace su tarea y podrá estar disponible la próxima vez que se ejecute Process Monitor.

Este log es muy útil porque podríamos llegar a diagnosticar y reparar problemas que no se podrían detectar fácilmente mientras Windows ya está en ejecución.

Para activar esta funcionalidad, basta con abrir Process Monitor, ir al menú Options y habilitar “Enable Boot Logging”:

Al hacer esto, basta con cerrar Process Monitor y reiniciar el sistema para que funcione. El problema en mi caso es que después de activarlo y reiniciar el sistema me encontré con este grata sorpresa:

*Nota: El proceso lo estuve realizando en una máquina virtual, lo que me permitió tener todas las capturas de una forma clara.

Como ven, lo que obtuve fue el famoso Pantallazo Azul o Blue Screen Of Death (BSOD) como se le conoce. En la mayoría de las ocasiones, el equipo presenta muy esporádicamente este comportamiento y por lo general al segundo reinicio Windows entra normalmente.

Lamentablemente para mí, esto no pasó y sin importar de qué forma intentara iniciar (Modo seguro, Modo de consola, Mido de depuración, sin funciones de red), siempre volvía a dar el pantallazo azul justo después de la animación inicial.

Un Pantallazo Azul como tal, realmente es un mecanimos de protección que nos indica que por lo general, se están produciendo operaciones a nivel de kernel no permitidas como que un controlador está intentando acceder a un espacio de memoria privado. Este tipo de inconvenientes por controladores causan casi un 90% o más de los Pantallazos Azules, otro pequeño porcentaje se da por fallos de Hardware como energía o cuando algun componente está dañado.

Windows entonces, para proteger su propia integridad detiene todas las operaciones, dibuja el BSOD con un formato estándar (Operación, información, código, etc) y posteriormente colecta los datos para general el Volcado de memoria (Dump File) que guarda en el próximo reinicio en el directorio de Windows con el nombre MEMORY.DMP, además de otros Minidumps que guarda en la carpeta con el mismo nombre y que son útiles para un análisis muy general puesto que el volcado de memoria completo puede llegar a ser muy pesado ya que almacena todo lo que había en RAM hasta el momento del Pantallazo Azul.

La posible causa

Así como Windows se protege así mismo con el Pantallazo Azul, también tiene una serie de herramientas embebidas para hacer diagnóstico y reparación sobre todo para casos en que el sistema operativo no inicia normalmente.

Para esto basta con presionar varias veces F8 al prender el equipo para que en las opciones avanzadas podamos entrar en la Reparación de equipo. En estos casos, como Windows es lo suficientemente inteligente, después de un reinicio forzado presenta la opción de reparación sin que presionemos alguna tecla:

Al iniciar Reparación de equipo, normalmente Windows busca problemas en los archivos de arranque de Windows, si los encuentra y está en la posibilidad de repararlos lo hace, si no encuentra sin embargo y existe un punto de restauración lo presenta para que volvamos a ese estado de imagen donde el equipo estaba funcionando correctamente:

*Nota: El entorno de Reparación de equipo está basado en un Windows PE.

Como estaba sobre un entorno virtual y no era mi prioridad reparar el problema, decidí restaurar el sistema para poder continuar escribiendo el contenido que había dejado pendiente. En efecto, Windows se restauró y estaba operacional nuevamente, así que realicé otras operaciones para el artículo y como ví que reiniciaba correctamente de nuevo pensé en activar la función de Boot Logging puesto que aún no lo había podido ver en acción y lo requería.

Confiado entonces, lo habilité reinicié mi equipo pero para mi gran sorpresa, nuevamente obtuve el mismo Pantallazo Azul, y otra vez recurrente, así que no podía iniciar Windows normalmente.

¿A qué se debía?

Definitivamente, la característica que estaba activando en Process Monitor tenía algo que ver con que al próximo reinicio de Windows siempre volviera a ocurrir el Pantallazo Azul.

Me costaba creer que la mejor herramienta que existe en mi concepto para hacer Windows Troubleshooting y que tanto me ha ayudado, esta vez estuviera en la lista negra.

A pesar de todo me inclinaba más porque fuera otro controlador pero, me acordé que cuando se activa el Boot Logging, el controlador de Process Monitor pasa a ser uno de los primeros en iniciar en el orden de arranque de Windows (Como lo describí anteriormente). En este orden de ideas, si era uno de los primeros en iniciar (Tal vez el primero) con más seguridad sí sería culpable.

Para comprobarlo debía entonces lograr desactivar ese controlador pero, con Windows impidiéndome reiniciar y la reparación de inicio sin darme muchas alternativas ya que ni el Volcado de memoria (MEMORY.DMP) se estaba creando sólo quedaba una posible forma.

Paradógicamente, para reparar el problema que estaba generando una herramienta de Sysinternals, requería otra de las que componen la suite; me estoy refiriendo por supuesto a Autoruns.

La solución

Autoruns, entre sus tantas estupendas funcionalidades provee una única que consiste en realizar un análisis de lo que está iniciando con Windows aun cuando el equipo se encuentra apagado u offline. A esta característica se le llama “Analyze Offline System” y se activa desde el menú File de Autoruns.

Para esto, debo garantizar que Autoruns tenga acceso al equipo afectado y que está Offline y como no puedo entrar a Windows requiero recurrir al mismo método que utiliza Windows para reparar el equipo y es a un Windows PE (Entorno de Preinstalación).

Como el que está en el medio de Windows y de forma embebida con su instalación puesto que no tiene ninguna herramienta de Sysinternals, Autoruns en este caso, debía proceder a crear mi propio Windows PE y asegurarme de que la herramienta estuviera disponible una vez hecha la imagen.

Esta gran ventaja me la da el Kit de Instalación Automatizada para Windows 7 (WAIK); específicamente el Deployment Tools Command Prompt que es desde donde puedo copiar los archivos necesarios para el Windows PE.

Como el Windows PE es un mini sistema operativo que carga en memoria RAM, tiene la ventaja de que sigue siendo un sistema operativo y cuenta con varias funciones como las de red, además de poder interactuar con varias aplicaciones que soporten esta ejecución. Así, podría ejecutar Autoruns desde el Windows PE corriéndolo en el Equipo afectado y podría hacer uso de su característica de análisis sin conexión para desactivar el controlador de Process Monitor y ver si en verdad había ocasionado todo.

Construyendo el medio Windows PE + Autoruns

Como dije antes, para construir el Windows PE necesitamos tener WAIK instalado, ya he mostrado cómo es todo el procedimiento en otros artículos pero lo repetiré aquí por el valor agregado de que no usaremos esto para despliegue sino para solución de problemas.

*Nota: Si no tienen WAIK, lo pueden descargar desde Aquí.

Debemos instalar el WAIK en un equipo, ir a Inicio, Todos los programas, Microsoft Windows AIK, clic derecho sobre Deployment Tools Command Prompt y seleccionar “Ejecutar como administrador”

En la consola ejecutamos: Copype.cmd x86 <DirectorioPE>

Donde <DirectorioPE> es una ruta local o de red donde queremos guardar los archivos del Windows PE. Para mi caso, no me compliqué mucho y lo creé en el directorio C:\ con el nombre WinPE, el comando quedaría entonces así: Copype.cmd x86 C:\WinPE

*Nota: Sin importar que sea para reparar un problema utilizando Autoruns en un sistema de 32 o 64 bits, se debe crear el Windows PE de 32 bits.

Dentro de la carpeta que se crea (En este artículo por ejemplo WinPE) veremos dos carpetas (ISO y Mount) y dos archivos (etfsboot.com y winpe.wim). En la carpeta ISO es donde debemos guardar todo lo que deseamos que tenga el Windows PE ya que es desde la que generaremos la imagen .ISO.

En entornos de implementación, normalmente copiabamos la herramienta de ImageX.exe desde los archivos del WAIK a la carpeta ISO, en este caso lo que haremos será copiar Autoruns.exe, por supuesto, previamente lo debemos descargar desde la página oficial.

La carpeta ISO debería verse así:

Una vez copiamos el ejecutable de Autoruns (Autoruns.exe) volvemos a abrir el Deployment Tools Command Prompt y esta vez haremos la copia del winpe.wim a la carpeta \Sources renombrandolo a boot.wim para que el Windows PE pueda arrancar correctamente cuando se cargue.

Para esto, ejecutamos:
copy <DirectorioPE>\winpe.wim <DirectorioPE>\ISO\Sources\boot.wim

Para este artículo, sería:
copy C:\WinPE\winpe.wim C:\WinPE\ISO\Sources\boot.wim

*Nota: Desde el Explorador también podemos hacer la copia, además de esto podemos verificar que la carpeta Sources sí tenga el archivo boot.wim.

Ejecutamos por última vez el Deployment Tools Command Prompt y ya que tenemos los archivos necesarios para hacer Troubleshooting (Solución de problemas) podemos crear la imagen .ISO del Windows PE con el siguiente comando:

oscdimg –b<DirectorioPE>\etfsboot.com –u2 –h <DirectorioPE>\ISO <DirectorioISO>\WinPE.iso

Donde <DirectorioISO> es también una ubicación donde deseemos guardar la imagen .ISO del Windows PE.

Para mi caso, el comando sería:

oscdimg –bC:\WinPE\etfsboot.com –u2 –h C:\WinPE\ISO C:\WinPE.iso

¡Listo! Con esto ya podemos analizar cualquier sistema offline con sólo arrancar desde el Windows PE, obviamente debemos grabarlo sea en una USB o bien en un medio CD/DVD.

Esto fue lo que yo hice, posteriormente inicié el equipo en el que tenía el Pantallazo Azul que no dejaba arrancar correctamente.

Volviendo al caso…

Una vez entró al Windows PE, lo primero que hice fue identificar cuál era la unidad que le había asignado ya que es la que contiene todos los archivos del medio. Normalmente, X: es la unidad temporal del Windows PE, C:\ la del sistema operativo y si no hay más dispositivos, la unidad D:\ será la del Windows PE.

*Nota: Si hay más dispositivos que requieran tener letras de unidad, se debe seguir buscando en orden alfabetico para hallar la del Windows PE o bien utilizar la línea de comandos de Diskpart para identificar los volúmenes que estén disponibles.

Para verificar el contenido, basta con ejecutar Dir una vez estemos en la unidad:

En mi caso, procedí a ejecutar Autoruns.exe desde la raiz de mi Windows PE, al abrir me dirigí al menú File y seleccioné “Analyze Offline System” para poder tener control de lo que estaba arrancando con Windows:

En la ventana de Offline System siempre se debe especificar el directorio donde está instalado Windows (Normalmente C:\Windows) y el directorio del usuario a analizar. Para este caso, como ocurría para todos (Ya que era antes de iniciar sesión inclusive), le indiqué el directorio donde están todos los usuarios, es decir: C:\ProgramData

Después presioné F5 para que actualizara los resultados que estaba arrojando Autoruns y me fui directamente a la pestaña de Drivers para poder ver todos los controladores que estaban iniciando con Windows.

En caso de que estemos realizando este proceso y no sepamos por qué controlador empezar, lo más normal es desactivar primero los controladores que no hacen parte de Microsoft, para hacerlo basta con quitar la selección sobre el controlador específico y cerrar Autoruns, el trabajo de él será hacer los cambios pertinentes para que Windows no tome el controlador en el próximo reinicio.

Lo que yo hice, sabiendo que algo tendría que ver Process Monitor (Más específicamente su controlador) fue utilizar la función de búsqueda (CTRL + F) e indicarle el nombre del proceso interno “procmon”:

Como pensé, el controlador estaba iniciando con Windows (Por haber activado el Boot Logging claro está):

Lo que hice fue quitarle la selección para arriesgarme a realizar la prueba otra vez iniciando Windows:

Cerré Autoruns, cerré la ventana de Consola de comandos para que Windows reiniciara automáticamente, esta vez no entré al Windows PE sino que dejé iniciar Windows normalmente y ¡Oh sorpresa!

Ahora no hubo ningun pantallazo azul, Windows entonces inició normalmente y sin ningún tipo de problema:

Quizá en este caso tuve mucha suerte puesto que pude identificar rápidamente un posible causante y de ahí tener una base, pero en estos casos suele ser muy útil deshabilitar todo lo que no sea de Microsoft al inicio (Aunque este en parte lo era) e ir probando el arranque. A menos de que sea problema de máquina, podríamos llegar a tener esta suerte en la mayoría de las ocasiones cuando ni Windows deja iniciar.

He aquí otra gran ventaja de Windows PE y de Windows Sysinternals, espero que les pueda ser de utilidad a algunos.

Estaré actualizando el post en caso de que obtenga más información sobre lo que me sucedió con Process Monitor.

Saludos,

Sergio Calderón (Checho)

Personalmente me encuentro muy contento y agradecido con Kun Li de Microsoft por brindarme la oportunidad de tener Co-Autoría en este Blog e iniciar este proyecto personal que espero y anhelo se convierta en algo global.

Sé que esto es lo menos interesante pero, viéndose el caso paso a presentar tanto a mi persona como al objetivo que quiero tener con este Blog:

Mi nombre es Sergio Calderón y antes que nada, debo especificar de acuerdo a lo que comenté anteriormente que no soy empleado Microsoft,  actualmente soy uno de los  Moderadores en los Foros de Microsoft TechNet y MSDN en Español, aparte de otro usuario que felizmente aprende y comparte todos los días en estas estupendas comunidades tanto en estas como en los estupendos Foros de Microsoft Answers.

Me encuentro actualmente en el programa de Microsoft Student Partners en Colombia y hace unos pocos meses hago parte también del grupo de Microsoft Community Contributors.

Tanto en estas comunidades y programas como en Mi propio Blog (Checho’s Blog) trato de compartir y de aprender constantemente lo que me apasiona en el mundo Microsoft referente a Windows Cliente, enfocándome lo más posible a Troubleshooting e Implementación.

Esto es todo sobre mí, ahora, ¿Qué pretendo con este Blog?

La intención de este Blog es que desde la comunidad de los Foros (Incluyendo MMC, MVPs, MSPs, y todo gran colaborador) logremos reunir una buena base de soluciones, consejos y artículos que salgan directamente de los diferentes Foros (TechNet, Answers y MSDN) para que todas las personas que ingresen a estas estupendas comunidades Microsoft en busca de ayuda, logren encontrar este contenido productivo y pueda ojalá seguir creciendo.

Personalmente, espero compartir la gran cantidad de soluciones como me sea posible y que provengan de los problemas recurrentes o importantes reportados en los Foros, pero además espero (Contando con la colaboración de todos los que puedan) escribir aquí también este tipo de ayuda escrita por otras personas.

Espero entonces poder conseguirlo.

¡Muchas gracias a todos!

Sergio Calderón-

IMPORTANTE: Responsabilidad

El contenido de este sitio es provisto “como está” sin garantías expresas o implícitas de ninguna índole. Microsoft no se responsabiliza por ninguna de ellas. Los procedimientos y soluciones que aquí se escriban no constituye una recomendación oficial de Microsoft.

Todo se generará desde La Comunidad para La Comunidad.