Cicles de Vida dels Fabricants

Els fabricants de software tenen un cicle de vida pels seus productes. Això fa que la renovació sigui permanent, i també fa que puguin estalviar recursos en el manteniment de aplicacions obsoletes.

 Aquí podeu trobar alguns links on es mostren els cicles de vida dels productes:

Microsoft

Citrix (explicació / llistat)

HP (software)

Com realitzar un anàlisi d’una pantalla blava BSOD

Hem tingut una pantalla blava. I ara què?

 Està l’opció senzilla d’agafar el Stop ID, i buscar-lo al Google. Això no serveix de massa. Bé, serveix per detectar si es un tema de hardware, per exemple, però gairebé sempre no indica masses coses.

 Aleshores està la opció dels valents, agafar el MEMORY.DMP i analitzar-lo.

Cada vegada que tenim una pantalla blava, apareix un MEMORY.DMP (bé, no sempre, es poden donar casos que no, com podem veure aquí). Suposem que si que el tenim, situat a C:\windows\memory.dmp..

Aleshores necessitem l’eina de debug de Microsoft, el Windbg. El podem trobar aquí.

També necessitarem els simbols. Pels qui no coneixin què es això del simbols, podriem que els programes binaris que executem estan fets en codi màquina. El codi màquina és molt difícil d’analitzar. Per poder fer un anàlisi del codi, afegim els simbols que ha utilitzat el compilador per crear el codi binari. Aquests simbols es treuen en la versió final del programa per accelerar la seva execució. Ve a ser com els Comentaris que els programadors afegeixen al codi per poder fer un anàlisi.

Els simbols depenen del sistema operatiu. Ademés, també depenen del service pack, dels hotfix, etc. Per això el millor es no baixar els simbols, sino que el més interessant és fer que es baixin a mida que calen.

Un cop instal·lat el WinDBG, anem a File / Symbol File Path, i afegim la següent línia:

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

(suposant que tinguem una carpeta C:\WEBSIMBOLS amb espai suficient per anar descarregant els simbols)

Un cop especificat això, cal que carreguem el MEMORY.DMP. Anem a File / Open Crash Dump i especifiquem on esta l’arxiu.

Un cop carregat (i sense que apareixin errors), podem analitzar el crash:

!analyze -v

Aquí comença l’anàlisi. Ens mostrarà quin mòdul és el que falla a MODULE_NAME o a IMAGE_NAME. Un cop identificat, podem fer click directament o bé executar la comanda:

lmv

Aquesta comanda ens volcarà tots els drivers que estaven carregats en el moment de la “petada”. Aleshores podem buscar el mòdul que hem detectat abans per tal de saber quin fabricant és.

Un cop tenim el fabricant, ja es tracta de buscar algún driver més nou, etc.

Si el error que dona es Pool_Corruption, aleshores el problema és més complexe.

Podem fer dues coses:

1) O bé reinstal·lar tots els drivers amb versions més noves, i tornar a passar el service pack (vigilar amb antivirus, impressores, etc).

2) O bé passar el Driver Verifier (verifier.exe), que ens farà una prova d’stress de cada driver.

ATENCIÓ: Cal preveure que la màquina fallarà molt, que es poden perdre dades (controlar tema Backup). També cal tenir el compte que un cop fem Ctrl+Alt+Del del inici de sessió, perdem la possibilitat de tornar a l’estat Last Known Good Configuration, pel que un cop reiniciat amb el driver verifier, caldria esperar sense fer res uns 30 minuts abans d’iniciar sessió, per esperar que falli algún driver.

També caldria habilitat un mode especial del pool per poder rastrejar posteriorment quin és el driver que falla:
How to use the special pool feature to isolate pool damage

Això ja seria troubleshooting avançat, que potser caldria posar en mans de Microsoft, o bé millor reinstal·lar el servidor.