Mostrando entradas con la etiqueta drivers. Mostrar todas las entradas
Mostrando entradas con la etiqueta drivers. Mostrar todas las entradas

lunes, 22 de diciembre de 2014

pnputil: Mucho cuidado... O te quedas sin dispositivos

Hace tiempo, jugando un poco con los drivers, e intentando instalar uno para un dispositivo Android... Conseguí que apenas se detectara. Si no recuerdo mal, fue por instalar unos drivers que al final no eran para dicho gadget. El problema está en que gracias a eso conseguí que tampoco se detectara correctamente mi móvil, por lo que no podría acceder a la tarjeta SD desde el ordenador.

Y ahí me veis, instalando un montón de controladores para Android, descargados de páginas oficiales (tanto del propio Android como del fabricante) y que no hay manera. Hasta que me encuentro con que se me repiten muchas entradas.

Por lo tanto, no se me ocurrió otra cosa que buscar cómo podía quitármelos de encima. Y ahí es donde encontré esta página, el que usando el comando de Windows pnputil te permitía quitar los drivers deseados.

Total, que me puse como loco a eliminar los que me parecieron... Y ahí estoy, desde hace un tiempo, desde mi Windows, sin acceso a los datos del cacharro.

Sí, he probado a instalar de nuevo las paqueterías, pero nada.

Sí, he probado a ejecutar

sfc /scannow

pero tampoco...

Sí, le he dicho que se descargue los controladores por Windows Update.

Si es que, ya me lo decía el maestro Vicente: los experimentos se hacen con gaseosa.

Cosas que acabo de probar, siguiendo los consejos de esta otra página:

  1. Ir cambiando los distintos modos en los que se puede poner la conexión USB: Almacenamiento masivo (la que no me funcionaba), multimedia y.... Cámara PTP. En las dos últimas ha instalado algún driver, sobretodo porque nunca los he necesitado.
  2. Poner el modo USB debug desde las opciones de desarrollo. Aquí la cosa ha mejorado, porque sí que me han aparecido las dos unidades que debían de salir, pero, en el momento de activar el almacenamiento, sólo me ha permitido entrar a ver los datos de la partición de la tarjeta externa. Al menos, algo es algo. Eso sí, en el momento en el que se desactiva el debug, volvemos a tener invisibles las unidades. 

Pero, la verdad, como ahora mismo estoy metido en veinte mil proyectos y cosas, de momento no me voy a pegar mucho más con esto. Aún así, si a alguien se le ocurre otra forma de volver a instalarlos...  Además de poder escribir alguna cosa que le pueda servir de ayuda a alguien que quiera poder manipular (léase, instalar y desinstalar controladores por consola o cmd), también continúo dándole vida al blog, que llevaba tiempo sin escribir algo técnico.

miércoles, 27 de marzo de 2013

Arreglando Sandboxie, que está kaputt.

En algún momento creo que ya os he hablado de Sandboxie (por ejemplo, aquí). Y, recientemente, también os he hablado de verifier y de cómo resolví un problema que tenía con el equipo. Bueno, pues en este proceso, y sin darme cuenta, sandboxie dejó de funcionar. Y, para resumir, todo este proceso tuvo algo que ver en que su panel de control, SbieCtrl.exe, sólo me pusiera mensajes parecidos a:

- SBIE1114 No es posible encontrar el servicio de sistema Zw, motivo 36
- SBIE1108 No se pudo analizar el procedimiento NTDLL.ZwCreateToken
- SBIE1103 El controlador de Sandboxie (SbieDrv) version 3.76 no ha conseguido iniciarse
- SBIE9153 No es posible iniciar el controlador (SbieDrv)
- SBIE1102 El controlador de Sandboxie (SbieDrv) se está descargando

Te encuentras con estas cosas (que  me salen después de haber estado trasteando un buen rato), y dices: ¿Qué hago? Pues empiezas a investigar. Si lo primero que has visto, antes de obtener estos mensajes, es que   puede tenga que ver con el servicio en sí mismo, SbieSvc, se intenta lanzar de diversas maneras, desde utilizando el comando sc, hasta yendo a la consola de administración de servicios de Windows.

Claro. Estos mensajes que estoy mostrando me han ido saliendo después de, incluso, haber reinstalado todo el programa con una desinstalación de por medio, porque una actualización no sirvió de nada.

Y, si se mira el autoruns de sysinternals, se puede ver que sí se deberían de estar cargando en el inicio.

Por lo que, si volvemos a la parte en la que iniciamos el servicio, que se encuentra parado, desde la consola de servicios, podremos ver cómo se empieza a arrancar, y a los pocos segundos, se para. Ahí se lanzan las alertas. ¿Y si miro en el visor de eventos de Windows a ver qué me sale? Si miramos en los registros de sistema, podremos ver que están exactamente las mismas líneas que nos muestra el panel de control. Al iniciar una de las primeras búsquedas, nos encontraremos que el registro
SBIE1114 Cannot find Zw system service, reason 36
nos indica que la razón 36 se produce cuando en un sistema 64 bits se está utilizando el driver verifier manager con SbieDrv.

Como ya dije en su momento, qué casualidad que no usé sandboxie después de haberlo activado. Por lo tanto, voy a lanzar esta herramienta y eliminaré la configuración actual (acordaros de elevar privilegios y de reiniciar).

Una vez reiniciado, ya tendremos otra vez sandboxie funcionando. Evidentemente, si has reinstalado entero, tendrás que volver a configurar las cosas de nuevo.

lunes, 25 de marzo de 2013

Mi propio black screen of death

Este es un error que lleva mucho, mucho, mucho tiempo pasándome. He intentado hacer de todo y de momento no he conseguido saber qué es lo que sucede. Cuando creo que ya lo he arreglado, vuelve a pasarme. Lo peor de todo es que es aleatorio. Estas haciendo cualquier cosa (o te vas, y dejas el ordenador encendido) y el equipo se le pone la pantalla negra (que no apagada, y no es el salva pantallas) y no responde nada: ni el sonido (si estabas escuchando algo), ni el teclado ni el ratón... nada. Niente.

¿Cosas que he probado? Probé a cambiar los drivers de la tarjeta gráfica (que pueden ir por ahí los tiros): Una ATI de la que hay que  instalar los drivers de Windows Vista.

Probé a lanzar un

sfc /scannow

con privilegios de administrador para examinar y reparar los ficheros del sistema que pudieran producir este error. Y vuelve a suceder. Lo peor de todo es que los logs que suelta esta herramienta no se pueden seguir. Horas y horas de logs. Imposible de leer por la gran cantidad de información que sueltan. Pero tampoco lo acaba de solucionar. Muchos días después de haber lanzado este comando, me lo sigue haciendo.

Tengo varias ideas en mente.

Una: buscar alguna herramienta que sea capaz de poner en orden estos logs. Así, podría intentar quitar toda la paja y ver lo que realmente es importante. Al buscar algún sitio que diga cómo se pueden leer, me he encontrado uno que, aunque también lo cuenta, dice que para más detalles vayamos al KB de Microsoft. En general, vienen a decir lo siguiente. Después de lanzar la herramienta:

sfc /scannow
sfc /scannow
podremos encontrarnos los resultados en el fichero %windir%\CBS\CBS.log. Pero, como no es exclusivo de esta herramienta, hay que localizar sus resultados buscando el flag [SR] dentro del log. Para no tener que estar buscando, una forma sería hacer una búsqueda de éste utilizando la consola y forzar la salida a otro fichero en vez de a pantalla. El ejemplo que ponen (y que utilizaré cuando termine la ejecución) sería:

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

y a mirar lo resultados. Pero, no tengo mucha esperanza de que pueda encontrar el problema. Si así fuera, ya habría dejado de hacerlo. Vamos a ver: el resultado que he obtenido es más o menos similar a la anterior vez que lo lancé. Dice que hay "archivos dañados".  Y que "los reparó correctamente". Pero sigo igual:

sfc /scannow - finalizado
sfc /scannow - finalizado
Por lo tanto, una vez he creado el fichero sfcdetails.txt, y siguiendo el consejo de Microsoft, me he puesto a buscar la cadena Repairing corrupted file para ver qué encontraba. En efecto, han aparecido algunas cosas: una reparación de diskmgt.chm (un fichero de ayuda). Sale 4 veces, en 2 bloques de 2. Esto no puede ser lo que hace que se caiga el sistema. Además, el log es mucho, mucho más pequeño (sólo como reseña).

¿Qué otras cosas he hecho? He pasado un memtest. De esos que tienen los liveCDs. Tampoco me ha dicho que se hubiese producido algún error. Lo que sí que he visto que es que en vez de mostrar los 4096MB, mostraba unos 3962 (o por ahí). Vamos, la diferencia era más o menos de 128 MB. Cuando me puse a buscarlo hace una semana (cuando pasé ese memtest) me dio la sensación de haber encontrado que si la memoria gráfica está compartida con la RAM, podía suceder. Pero, a decir la verdad, no me ha quedado del todo claro si eso es cierto. O, al menos, que en ese caso eso sea posible. Si no fuera cierto, ya tendríamos la posible razón por la que me estuviese pasando.

Otra opción que se me ha ocurrido: algún driver no está del todo bien. O algún programa que se está ejecutando todo el rato. Sí recuerdo que me llegó a suceder al principio de los tiempos, cuando tenía el Norton instalado. Fue quitarlo y dejó de suceder. Esa sería otra vía de búsqueda. Lo primero que intentaría hacer el buscar algún software de workbench para ver si va logueando cada parámetro y se rompe en el punto que me está fallando.

Para esta opción de los drivers, lo primero que he encontrado ha sido el driver verifier manager, y después el driverquery. Pues he hecho las pruebas en sentido inverso. Primero he probado el driverquery, y después he configurado el driver verifier manager en mi equipo, con sus dos posts correspondientes. Con respecto a la primera herramienta mencionada en este párrafo, comentan los BSODs. A mi de momento no me salen, pero por si las moscas, voy a ver si consigo obtener información sobre qué está pasando para que me suceda este error.

Un buen tiempo después de haber escrito los párrafos anteriores (justo cuando escribí mis posts que referencio ahí), he descubierto que Sandboxie ha dejado de funcionar, y a su vez, no me ha vuelto a suceder el "apagón" a pantalla negra. Por lo tanto, puedo deducir que Sandboxie es el responsable de que la pantalla de mi Windows se quede de repente en negro, como si de un BSOD se tratase, pero en negro y sin letras.

Por lo tanto, y para resumir, las posibles soluciones a un comportamiento de este tipo son:
- Lanzar el sfc /scannow y mirar sus logs.
- Lanzar driverquery y revisar los drivers disponibles con sus estados.
- Tener activado una temporada el driver verifier manager.

miércoles, 6 de marzo de 2013

Drivers problemáticos: driver verifier manager

Haciendo una búsqueda para comprobar los drivers, me he encontrado con una herramienta del sistema que se llama driver verifier manager. Todo esto que estoy haciendo es para (intentar) solucionar un problema que me lleva trayendo de cabeza durante mucho tiempo y del que más adelante tendréis un post al respecto. De hecho, iba a pasar un poco por encima para explicarla y al final, voy a escribir este artículo explicitamente para contarla.

Para lanzar esta herramienta hay que ejecutar (por ejemplo, desde inicio-->buscar--> verfier verifierverfier.exe verifier.exe:

Driver verifier manager, Administrador del comprobador de controlador
Driver verifier manager, Administrador del comprobador de controlador
Como habréis podido comprobar, es la primera vez que la voy a utilizar, con todo lo que ello conlleva. Mi idea es la siguiente: crearé una configuración estándar:

Creando una configuración estandar
Creando una configuración estandar
Hay alguna que otra cosa que me interesa comprobar. Puedo tener mis sospechas de por dónde pueden ir los tiros. Por lo que, aún pudiendo tener controladores no firmados, voy a obviar esa opción. También podría seleccionar la opción de "controladores para versiones anteriores de Windows". Pero, sólo me sale uno. Por lo que también lo voy a obviar. Aunque me he sentido tentado, no voy a poner todos los controladores. Por lo tanto, seleccionaré de una lista los que me interesen:

Seleccionando drivers
Seleccionando drivers
Aquí también estará el único que se encontraba como "para versiones anteriores de Windows".

Una vez terminada la configuración, habrá que reiniciar el equipo para que los cambios sean efectivos (yo, de momento, me esperaré a otro momento para reiniciar). Una vez configurado, habrá que esperar que se produzca el error y cruzar los dedos que sea alguno de los drivers que he seleccionado. 

Pase lo que pase, hay que acordarse de desactivar esta configuración en el momento en el que se de por perdido o cuando se obtenga la información deseada. 

lunes, 4 de marzo de 2013

Buscando drivers con DriverQuery

Realizando una investigación para publicar aquí, me he encontrado con un comando que se llama driverquery. Este comando, según he podido averiguar, hace un listado de los drivers que hay en el sistema que se le pase como parámetro (o sin el, será el mismo equipo donde se esté lanzando). Los parámetros son sencillos. Así lo ejecutaríamos:

driverquery [/s Computer] [/u Domain\User /p Password] [/fo {TABLE|LIST|CSV}] [/nh] [/v] [/si]
Por poner un ejemplo, podríamos lanzar

driverquery /fo CSV /v

Al ejecutar ese línea, obtendríamos esto:

driverquery /fo CSV /v
driverquery /fo CSV /v
Tal y como se puede ver, no hay quien se entere de nada. ¿Y si en vez de CSV lo hicíesemos con salida en formato table?

driverquery /fo table /v

Por lo que la salida sería esta:

driverquery /fo table /v
driverquery /fo table /v
Y obteniendo la salida en formato lista:

driverquery /fo list /v

tenemos:

driverquery /fo list /v
driverquery /fo list /v
El mayor problema que podemos tener a la hora de sacar estos datos es que el buffer del cmd se puede acabar antes de terminar de mostrar toda la información, por lo que perderíamos las primeras líneas. Así, si tomamos de partida la primera prueba que hemos hecho, podríamos redirigir la salida a un fichero y después abrirlo con otro programa. Por ejemplo:

driverquery /fo CSV /v > driverquery.csv

Y lo abrimos con algún programa de edición de hojas de cálculo:

Abriendo fichero CSV: driverquery.csv
Abriendo fichero CSV: driverquery.csv
La verdad, está muy bien tener en cuenta este comando. Sobretodo si se necesita información sobre los drivers que hay en el sistema. La verdad, a simple vista parece mucho mejor este comando que no ejecutar

sc query type= driver

en el que obtendremos un resultado en bloques similar a tercer ejemplo de arriba:

sc query type= driver
sc query type= driver
Si lo ejecutas, ojo al espacio (es importante). 

Así, a ojos vista, parece que es mucho más manejable la información utilizando driverquery y enviándola a un fichero externo. 

Espero que si en algún momento os hace falta buscar los drivers instalados, os sea de mucha utilidad.