Se aplica a: Windows 8.1 Pro Preview, Windows 8.1 Enterprise Preview.
El caso que pasaré a explicar durante todo este artículo, ha sido uno de los que más trabajo me ha costado solucionar, pero a la vez de los que más aporte a mi conocimiento me ha entregado y hasta ayer no podía determinar si era un bug o algo extraño de Windows, pero afortunadamente pude clarificarlo, así que paso a exponerlo:
He de empezar por recordar que Windows Defender existe hace muchos años dentro de Windows, pero hasta nuestro flamante Windows 7, era solo una solución Anti-Espía pues desde que salió Windows 8 hace poco más de un año –contando las liberaciones previas- Windows Defender fusionó todo lo que Microsoft ofrece con Security Essentials y pasó a ser una solución completa e integrada de Antivirus. Esto quiere decir que ya no es necesario adquirir software de protección de terceros, o corporativo –incluyendo EndPoint de MSFT- a menos que se esté en un entorno grande que requiera administración centralizada, aunque Defender también cuenta con una gran cantidad de políticas de grupo propias.
Aun así, particularmente hay quien confía por diferentes argumentos en otras soluciones, sepa o no que en Windows 8/8.1 está Windows Defender, por lo que es normal que si el antivirus no hace alguna validación a nivel de usuario o kernel sobre la versión del sistema operativo, pueda correr después de la actualización de Windows 8 a Windows 8.1. Pues bien, fue en uno de estos escenarios donde este artículo empezó a tomar vida, específicamente en los Foros de Windows 8.1 de Microsoft Community en inglés, se abrió un caso donde un usuario tenía instalado Malwarebytes PRO en su Windows 8 y después de actualizar a Windows 8.1, quizo acceder a la consola de Windows Defender pero se encontró con el siguiente mensaje al intentar funcionar con él:
Español: “No se puede iniciar el servicio, porque está deshabilitado o porque no tiene dispositivos habilitados asociados a él. Haga clic en Ayuda para obtener más información sobre este problema. Código de error: 0x80070422.”
Inglés: "The service cannot be started, either because it is disabled or because it has not enabled devices associated with it. Click help for more information about this problem. Error code: 0x80070422."
Todas las configuraciones de los Servicios – como casi todo en Windows- se almacenan en el Registro, específicamente, en la sub-clave Services ubicada en:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices
Con esto presente, una de los primeros caminos, y en general de los más eficaces para diagnosticar y solucionar problemas con la ejecución de Servicios de Windows, es observar el contenido que deberían tener los valores del correspondiente Servicio dentro de la sub-clave de Registro, pues siempre hay unos predeterminados que garantizan la funcionalidad. La forma más fácil para esto, es ir hasta la sub-clave, hacer clic derecho y seleccionar Exportar para que se cree el archivo .REG en un directorio que indiquemos. Esto lo debemos hacer desde un equipo funcional, es decir, que esté trabajando el Servicio y desde el equipo donde presenta el problema.
El siguiente paso es utilizar alguna aplicación que nos permita comparar exactamente cada valor y su correspondiente contenido, y como WinDiff que estaba incluido en el SDK de Windows despareció, la alternativa más recomendada por mi parte es KDiff3, una sencilla y útil herramienta de comparación, donde podemos indicar hasta tres archivos buscándolos en su respectivo directorio.
Lo que hice entonces fue pedir el archivo de registro desde el equipo donde ocurría el problema, exportar el registro de mi equipo funcional también y abrirlos desde KDiff3:
*Nota: La sub-clave que corresponde a Windows Defender es:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWinDefend
El resultado correspondiente al primer archivo lo ubicará en la izquierda, y en segundo archivo sobre la derecha respectivamente. KDiff nos indicará en diferentes colores y con un subrayado amarillo dónde encuentra la diferencia, sea en nombre, o contenido (Es Case Sensitive además). En este caso, el resultado fue bastante claro, pues sólo existía diferencia en el contenido de un valor llamado Start:
Como ven, en la izquierda (Registro bueno), el valor tenía contenido de “2”, y en la derecha (Registro malo), el contenido era “4”. ¿Qué quiere decir esto? Empecemos a entrar en detalle:
Cuando nosotros abrimos la Consola de Servicios, y entramos a las propiedades de cualquiera de los cientos que hay, podemos notar que existen 4 tipos de inicio: Automático (Inicio retrasado), Automático, Manual y Deshabilitado.
El orden por supuesto es de arriba hacia abajo, y esta configuración se almacena en el Valor de Start, ubicado en la sub-clave correspondiente a cada servicio. Los datos serían:
Automático (Inicio retrasado): 1
Automático: 2
Manual: 3
Deshabilitado: 4
El estado natural de Windows Defender es dos (2), que indica Automático, y por ende, en ejecución pero, el equipo donde estaba apareciendo el mensaje al intentar iniciarlo tenía el contenido de cuatro (4), es decir, el Servicio de Windows Defender se encontraba Deshabilitado.
La solución para este tipo de casos, suele ser cambiar el contenido del Valor (Si se identifica uno solo) o para mayor seguridad, importar nuevamente toda la sub-clave de registro exportada desde un sistema funcional. Lo que le propuse en primer instancia a la persona que expuso el problema fue descargar toda la sub-clave de registro que yo le había subido previamente a SkyDrive como normalmente lo hago, el problema es que no me fijé antes y cuando la intentó importar, obtuvo un error de permisos desde el Editor de Registro similar al siguiente:
Este tipo de errores suele darse cuando no tienes los permisos necesarios para escribir en la determinada sub-clave de registro, o bien porque aunque los tengas, no eres el propietario. Para el caso de WinDefend, aunque los que pertenezcan al grupo de Administradores tienen control total, el propieatario es el usuario SYSTEM:
*Nota: Para ver los permisos, hay que hacer clic derecho sobre la sub-clave, y seleccionar Permisos. Para ver el propietario, clic en el botón Opciones avanzadas en la parte inferior de la ventana de Permisos.
No suele ser recomendable modificar esto, pero en casos de Troubleshooting, es necesario hacerlo, así que le recomendé al usuario cambiar el propietario para que especificara su propio usuario, y luego verificar que todos los permisos estuvieran en control total para que pudiera importar el archivo de registro, o editar el contenido del valor Start, pero seguía con mensajes de acceso denegado:
Español: “No se puede editar Start: error al escribir el nuevo contenido de valor.”
Intenté entonces hacerlo yo pues en algunas ocasiones es necesario pasar por cada sub-clave verificando el propietario y control total, pero por más que edité, mantenía también el acceso denegado… aquí fue donde me empecé a preocupar, y en mi propia máquina fui hasta la Consola de Servicios a ver cómo es que se veía el Servicio de Windows Defender, pero para mi sorpresa, me encontré con algo que no había visto nunca antes:
Como ven, todas las posibles opciones que tiene un Servicio desde la Consola estaban completamente deshabilitadas, es decir, no podía ni siquiera deterlo yo mismo de la forma nativa y soportada. Esto no solo se veía así en mi equipo, sino en instalaciones nuevas y limpias tanto de Windows 8.1 Pro Preview como de Enterprise Preview. En otras palabras, nativamente en Windows 8.1 no se puede modificar el Servicio de Windows Defender desde la Consola; aquí empezó el verdadero dilema.
De alguna forma el Valor de Start se le había cambiado a la persona, ¿Pero cómo? Sabía que la solución estaba en volverlo a poner en dos (2), ¿pero de qué forma? Desde aquí tomé el caso personal así que empecé a buscar caminos alternativos para descubrir cómo se podía modificar la sub-clave de Registro WinDefend correspondiente al Servicio; por supuesto, pasaré a mostrar todos mis intentos fallidos a continuación:
Primer intento: PsExec para ejecución con usuario SYSTEM
Dentro de las impresionantes herramientas de Windows Sysinternals, existe una llamada PsExec, que permite ejecutar procesos de forma remota sin mayores complicaciones, y dentro de su sintaxis, es posible ejecutar también cualquier proceso utilizando el usuario de SYSTEM, que tiene mayores privilegios que el tan conocido Administrador integrado.
Si con mi usuario perteneciente al grupo de administradores en modo aprobación de administrador no podía hacer modificaciones de ninguna forma a la sub-clave de registro, tal vez ejecutando el Editor de Registro (Regedit.exe) con PsExec, y teniendo privilegios de SYSTEM, podría cambiar el contenido del valor Start.
Una vez se descargue y descomprima PsExec, Desde un Símbolo del Sistema con privilegios elevados (Clic derecho, Ejecutar como administrador), ubicados en la ruta donde se descargó, basta con ejecutar: PsExec –sid Regedit.exe
El Editor de Registro ahora tendrá privilegios totales, e incluso se puede verificar con Process Explorer desde la pestaña de Security en las propiedades de Regedit.exe:
Sin embargo, cuando muy confiando fui a intentar modificar el valor de cuatro (4) a dos (2), de nuevo acceso denegado:
Primer intento fallido.
Segundo intento: Utilizando la herramienta de SC.exe con PsExec
Windows incluye una herramienta llamada SC.exe que se comunica con el Service Control Manager, y claro está, con los Servicios para realizar diferentes tareas administrativas sobre éstos.
Aprovechando PsExec también, ejecuté el CMD.exe con el usuario SYSTEM y desde aquí intenté detener el servicio con la herramienta SC.exe, pues esta vez no intentaría realizar un cambio sobre el Registro directamente, sino que lo intentaría hacer sobre el propio Servicio. El comando es: SC.exe Stop WinDefend
Para mi mala fortuna, este fue el resultado:
Nuevamente, a pesar de estar sobre SYSTEM, el resultado fue Access is denied. ¿Cómo es que se me denegaba al acceso al usuario más fuerte de todos?
Segundo intento fallido.
Tercer intento: Utilizando las funciones de Servicios desde la API de Windows
De forma desesperada, mi último intento tenía que ser interactuar yo mismo con el Service Control Manager desde la API de Windows, de esta forma, yo controlaría todo el proceso, y como se supone que Windows nativamente lo hace de esta forma, quizá podría tener resultados positivos.
Las Funciones de Registro, proveen la forma correcta de trabajar con los Servicios desde la API, y el proceso sería:
Abrir el Service Control Manager con OpenSCManager.
Abrir el servicio que se va a controlar con OpenService.
Utilizar la función de ControlServiceEx con el parámetro de SERVICE_CONTROL_STOP para detener el servicio.
Operaciones adicionales para reiniciar y cerrar, que no vale la pena por ahora tocar.
No entraré mucho en detalle sobre el código, porque la idea es escribir sobre cada una de estas funciones cuando termine la serie de operaciones con el Registro más adelante y no es el foco de este post.
A grandes razgos, el pequeño código que escribí abría el Service Control Manager, verificaba que se abriera correctamente y si esto sucedía, pasaba a abrir el Servicio con la función OpenService, hacer la misma verificación y si pasaba, detener el servicio con la función ControlServiceEx. Este es el fragmento que realizaba todo hasta la abierta del Servicio:
SC_HANDLE serviceDbHandle = OpenSCManager(lpMachineName, lpDatabaseName, dwDesiredAccess); if (serviceDbHandle == NULL ) { MessageBox(NULL,
L"No se abrió el Service Control Manager", L"Servicio", MB_ICONEXCLAMATION); }
else { SC_HANDLE serviceHandle = OpenService(serviceDbHandle, lpServiceName, dwDesiredAccess2); if (serviceHandle == NULL ) { //GetLastError(void); MessageBox(NULL, L"No se abrió el Servicio", L"Servicio", MB_ICONEXCLAMATION); }
Noten que si serviceHandle, que contiene el puntero al Service Control Manager, que se encuentra en el equipo local – Es decir, sabe que trabajará sobre los servicios locales- y que devolverá el resultado de la operación OpenService como NULL si no se abre por X o Y razón (Que incluye Acceso Denegado), mostraría el mensaje: “No se abrió el Servicio”, y de lo contrario, es decir, que se pudiera abrir, pasaría a detenerlo.
El resultado, como no me lo esperaba, fue:
En otras palabras, Windows no pudo abrir el Servicio, ni siquiera desde la API y si no se abría, no podría modificarlo.
Tercer intento fallllido.
Hasta aquí habían llegado mis pruebas, pues incluso haciendo otras pruebas que no describiré aquí como hacer uso de Autoruns, o de herramientas de terceros para intentar tomar permisos, o modificar el Serivicio, siempre obtenía Acceso Denegado.
La conclusión era por supuesto, que desde Windows 8.1 por lo menos, no es posible modificar el Servicio de Windows Defender.
Sin embargo, no me di por vencido, pues quedaba una última cosa por hacer, que para fortuna de todos, resultó ser el único camino positivo para volver el estado del servicio a como debería de estar.
¿Y la solución es?
Como dije, desde Windows 8.1 había confirmado que no es posible modificar el servicio de ninguna forma, aunque lo más extraño, es que si se instala un Antivirus, sera de terceros o de Microsoft (EndPoint Protection), Windows Defender se desactiva sin ningún tipo de problema e internamente, el valor de Start se modifica de dos (2) a tres (3):
El caso aquí es que el usuario deseaba tener Windows Defender funcional, y esto solo era un escape.
¿Qué se puede hacer? La “solución” pasa por algo que corresponde más al tema de Implementación de Windows, pero es más que perfecta para escenarios complejos de solución de problemas y me estoy refiriendo a un Entorno de Preinstalación, como se le llama oficialmente: Windows PE.
Recordemos que Windows PE representa un mini sistema operativo que corre en memoria RAM, y se usa normalmente para iniciar el proceso de instalación de Windows, pero a la vez es bastante flexible como para nosotros integrar aplicaciones o realizar diferentes operaciones como una fundamental que es capturar una imagen de sistema operativo (.WIM).
Lo estupendo de Windows PE aquí, es que al ser sistema operativo, yo puedo ejecutar aplicaciones, acceder a funciones de red, entre otras, y para este caso, es posible acceder a casi todo lo que tiene mi sistema local, aún siendo otro sistema operativo, como el Editor de Registro. Sin embargo, el Windows PE se debe crear y configurar, además de hacerse un procedimiento específico desde el Entorno de Preinstalación al iniciar el equipo, así que procederé a explicar el paso a paso como una mitigación para las personas que les presente este mismo comportamiento en Windows 8.1:
Creando un Windows PE
Para generar un Windows PE, necesitamos primero que todo:
– Instalar los compomentes de implementación (Deployment Tools, Windows Preinstallation Environment (PE)) desde el ADK para Windows 8.1. Si no lo tienen, pueden descargarlo desde el sistio oficial de Microsoft:
http://www.microsoft.com/en-us/download/details.aspx?id=39306
Desde la Pantalla de Inicio, ejecutamos la consola de Deployment and Imaging Tools Environment como administrador (Clic derecho, ejecutar como administrador). Necesitamos copiar los archivos necesarios del Windows PE localmente, y hay que tener en cuenta aquí la arquitectura del equipo donde haremos el cambio, es decir, si es de 32 o de 64 bits.
Si es de 32 bits, ejecutamos: Copype x86 C:WinPE
Si es de 64 bits, ejecutamos: Copype AMD64 C:WinPE
Veremos copiar muchos archivos necesarios para construir el Entorno de Preinstalación, y al terminar, construiremos la imagen ISO haciendo uso de la nueva herramienta MakeWinPEMediaISO incluida en el ADK desde Windows 8.
Ejecutamos desde la misma consola:
MakeWinPEMedia /ISO C:WinPE C:WinPE.ISO
A continuación, debemos grabar el ISO llamado WinPE.ISO que nos quedó en la unidad raíz C: en un CD/DVD o memoria USB. Para las dos primeras alternativas podemos utilizar el asistente integrado en Windows para grabar en un medio y para la última, requerimos hacer los mismos pasos como si fueramos a configurar el dispositivo para instalar Windows. Si no sabemos el procedimiento, les dejo un enlace donde explico el paso a paso:
http://www.fermu.com/es/articulos/windows/articulos-y-tutoriales/831-preparar-dispositivo-usb-manualmente-para-instalaci%C3%B3n-de-windows-8
*Nota: Cabe aclarar que en vez de copiar los archivos de instalación de Windows, copiamos todos los de C:WinPE.
Modificando el estado del Servicio desde el Windows PE
Volviendo otra vez al caso, y como paso a seguir, es necesario iniciar el equipo donde necesitamos cambiar el valor de registro desde el Windows PE y realizar lo siguiente:
1. Cuando aparezca el Símbolo del Sistema, estaremos en la unidad X: que representa la unidad del sistema virtual del Windows PE, así que nos debemos ubicar primero en la unidad del sistema operativo local, que muy seguramente será la D: pues en un entorno de WinPE, probablemente el C: pase a ser la partición reservada del sistema.
Para identificar la unidad del sistema operativo local, solo debemos encontrar la letra (En caso de no ser la D:) donde existan los directorios protegidos por el sistema operativo como Windows, Archivos de Programa, Usuarios, etc.
Navegamos hasta la unidad con el comando de CD, y luego hasta el directorio de Windows y ejecutamos Regedit.exe, así:
D:
cd Windows
Regedit.exe
*Nota: Si por alguna razón están en un Windows PE para 32 bits, y no les abre el Editor de Registro desde el directorio de Windows, pueden devolverse hasta la raíz D: y ejecutar Regedit.exe nuevamente.
Cuando el Editor de Registro nos abra, notaremos todas las mismas claves con las que ya tal vez estemos familiarizados, pero corresponden a las del Windows PE y no a las del sistema operativo local, así que debemos recurrir a los famoso Hives de Registros que si recordamos, contienen todas las claves y subclaves con las que Windows funciona desde que se instala. La más común que hemos visto modificar es la de NTUSER.DAT de la carpeta C:UsersDefault que nos permite editar personalizaciones para el perfil predeterminado de Windows, pero HKEY_LOCAL_MACHINE también tiene una para todo lo que esté en la sub-clave de SOFTWARE y otra para la de SYSTEM. Nos corresponde la segunda.
*Nota: Intentaré preparar un artículo aparte sobre todos los Hives de Windows con el fin de detallar el tema.
Desde el Editor de Registro, nos situamos en la clave HKEY_LOCAL_MACHINE y hacemos clic en el menú File y seleccionamos Load Hive…
Navegamos hasta la partición del sistema local, que como les dije, en la mayoría de los casos será D:WindowsSystem32Config, seleccionamos la de SYSTEM y clic en el botón de Open:
En la ventana de Load Hive, le indicamos el nombre de Sys (Puede ser cualquiera) y clic en el botón de OK para que se cargue el Hive:
Dentro de la sub-clave de Sys, veremos todo lo que corresponde a HKEY_LOCAL_MACHINE de nuestro sistema local, así que debemos por fin navegar hasta la sub-clave que contiene la configuración del Servicio de Windows Defender, es decir:
HKEY_LOCAL_MACHINESysControlSet001ServicesWinDefend
Ahora que tenemos poder absoluto sobre estas modificaciones del sistema local, desde Windows PE, procedemos a hacer doble clic en el valor de Start, que para este caso como expuse tiene contenido de “4” y desde la ventana de Edit DWORD (32-bit) Value se lo cambiamos a “2”:
Como verá, haciendo clic en el botón OK ahora no indicará acceso denegado y nuestro valor habrá quedado cambiado:
Después de esto, seleccionamos nuevamente la sub-clave que cargamos Sys, vamos al menú de File nuevamente y clic en Unload Hive… para que el Hive se guarde y no se tenga peligro a fallos en el inicio de Windows:
*Nota: Debemos hacer clic en el botón de Sí (Yes) cuando Windows lo solicite la confirmación de la descarga del Hive:
¡Todo listo! Basta con cerrar el Editor de Registro, el Símbolo del Sistema y una vez dejemos reiniciar a Windows completamente, el Servicio de Windows Defender estará funcionando otra vez y por ende, la Consola propia también:
Este mismo procedimiento se lo expuse al usuario en el Foro y por fin, Windows Defender estuvo funcional nuevamente.
¿Entonces, es un Bug?
La respuesta corta es: NO.
Aunque en un principio, y tal cual mencioné al principio, hasta antes de este post estaba muy convencido que lo era, logré escalar el caso hasta Mark Russinovich de Microsoft, que finalmente me aclaró el porqué esto sucede en 8.1:
Básicamente, Windows Defender tiene un controlador en modo-kernel (wdfilter.sys) que registra un filtro de Registry Callback que protege las sub-claves de Windows Defender.
La rutina de Registry Callback puede bloquear operaciones a nivel de Registro, y como esto funcional a nivel de modo-kernel, es bastante complicado de detectar, y para el caso de 8 e inferiores, no parece estar liberado la actualización del controlador a bajo nivel.
Aquí pueden leer más sobre Registry Callback:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545879(v=vs.85).aspx
Conclusión, aquí aplica aquella frase: “No es un bug, es una característica”.
¡Comentarios bienvenidos!
PD. No olviden seguirme en Twitter: https://twitter.com/secalderonr
Saludos,
Checho