Miscellanées ...: juin 2008

lundi 23 juin 2008

... de code hexadécimal sur fond bleu

Durant quelques semaines, mon installation de Windows XP avait quelques ratés : un écran bleu après quelques heures de fonctionnement. J'ai voulu en savoir un peu plus et je me suis lancé dans le déchiffrement des différents messages.

Mais qu'est ce qu'un écran bleu ? Tout simplement un message d'alerte du coeur du système d'exploitation indiquant que quelque chose s'est mal déroulé. Windows affiche alors une série de code d'erreur. Dans mon cas tout les écrans avaient le même premier code :

0x0000008E == KERNEL_MODE_EXCEPTION_NOT_HANDLED

Microsoft faisant bien les choses, nous disposons d'une description complète de ce code sur msdn. Le deuxième paramètre indique l'adresse et le troisième un "trap frame". J'ai donc :

1 Except code : 0xC0000005
2 Address : 0x8062BFBF
3 trap frame : 0xBEE482E4
4 reserved : 0x00000000

Un autre écran bleu me donne :

1 Except code : 0xC0000005
2 Address : 0x8062BFBF
3 trap frame : 0xB71946D4
4 reserved : 0x00000000

Pour le code d'exception, rien de plus facile, il suffit de regarder dans le même article et j'ai :

0xC0000005 == STATUS_ACCESS_VIOLATION

En gros une violation d'accès mémoire. Le lecteur curieux pourra aller voir ntstatus.h pour le detail.

0xC0000005: STATUS_ACCESS_VIOLATION indicates that a memory
access violation occurred.

MSDN indique quelques pistes pour résoudre le problème:

Vérifiez l'espace disque : OK pour moi
Si il y a un driver identifé, désactivez le ou autre : pas de driver mentionné
Changez de carte vidéo : je n'en ai pas sous la main.
Mettez à jour le BIOS : j'ai fait çà il y a quelques années, je ne souhaite pas brancher ma puce à chaud sur un autre PC. Je n'ai plus le goût du risque.
Désactivez les options de cache mémoire dans le BIOS.

Bref, rien de transcendant là dedans. Je réendosse mon costume de mineur et je vais au fin fond d'internet à la recherche du deuxième paramètre 0x8062BFBF.Au détour d'un couloir mal éclairé, je découvre le message d'un utilisateur ayant le même problème. Dessous, une petite lanterne parle de minidump et indique que la cause est toujours la même nt!HvpGetCellMapped+5f :

>> All of the minidumps are crashed with same symptom.
>>
>> BugCheck 1000008E, {c0000005, 8062bfbf, b625598c, 0}
>> Probably caused by : ntkrnlpa.exe ( nt!HvpGetCellMapped+5f )
>> The registry is corrupted. Refer this problems :
>> http://www.techspot.com/vb/showthread.php?p=236454#post236454
>> http://www.techspot.com/vb/all/windows/t-63005-BSOD-Memory-Problems.html

La base de registre aurait donc un problème. Mais par quel moyen cette personne est elle arrivée à cette conclusion ?

La réponse est WinDBG, un utilitaire de Microsoft pour mener ce genre d'analyse. A chaque écran bleu, il est possible de garder une trace de l'étât du coeur de Windows au momment du plantage, c'est un fichier que l'on nomme minidump. WinDBG permet de le décrypter.

Je charge donc le dernier minidump et je me lance :

Debugging Details:
------------------

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - L'instruction "0x%08lx" emploie l'adresse m moire "0x%08lx". La m moire ne peut pas tre "%s".

FAULTING_IP:
nt!HvpGetCellMapped+5f
8062bfbf 8b4304 mov eax,dword ptr [ebx+4]

TRAP_FRAME: b71946d4 -- (.trap 0xffffffffb71946d4)
ErrCode = 00000000
eax=00001ff0 ebx=00001ff0 ecx=889ab6a0 edx=00000007 esi=e2525b60 edi=00000fff
eip=8062bfbf esp=b7194748 ebp=b7194790 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!HvpGetCellMapped+0x5f:
8062bfbf 8b4304 mov eax,dword ptr [ebx+4] ds:0023:00001ff4=????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: firefox.exe

LAST_CONTROL_TRANSFER: from 8062bed0 to 8062bfbf

STACK_TEXT:
b7194790 8062bed0 e2525b60 00ffffff e2525b60 nt!HvpGetCellMapped+0x5f
b71947a4 80630364 e2525b60 00ffffff d08f9664 nt!HvpGetHCell+0x10
b71947c0 80634e9c e2525b60 00ffffff e2525b60 nt!HvMarkCellDirty+0x30
b71947e0 80634fd6 e2525b60 002b8660 e1098170 nt!CmpMarkKeyDirty+0x68
b71947f8 8062ab42 e2525b60 002b8660 00000001 nt!CmpFreeKeyByCell+0x14
b7194828 806191a2 e2a4c4a8 b7194894 00128740 nt!CmDeleteKey+0x8c
b7194888 8053c808 00000540 00128768 7c91eb94 nt!NtDeleteKey+0x138
b7194888 7c91eb94 00000540 00128768 7c91eb94 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
00128768 00000000 00000000 00000000 00000000 0x7c91eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!HvpGetCellMapped+5f
8062bfbf 8b4304 mov eax,dword ptr [ebx+4]

SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!HvpGetCellMapped+5f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlpa.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1d
FAILURE_BUCKET_ID: 0x8E_nt!HvpGetCellMapped+5f
BUCKET_ID: 0x8E_nt!HvpGetCellMapped+5f
Followup: MachineOwner

Pour mémoire les quelques commandes que j'ai utilisées dans WinDBG sont:

.bugcheck : liste les données du code
.kb : liste la pile (stack trace)
.kv : liste les trap frames
.trap : récupére les registres au moment de l'erreur

ESI est le pointeur d'instruction, une valeur de zéro est logiquement un problème. On refait une demande de la pile (kb).

La base de registre de mon utilisateur est corrompu. J'ai donc créé un nouvel utilisateur, migré mes préférences applicatives et tout fonctionne correctement.

D'autres questions ?

mardi 17 juin 2008

... de types de disque mous

23FD, 8 pouces, 80 000 octets (IBM, 1971)
5 pouces un quart haute densité, 1,2 megaoctets (1982)
3 pouces, 360 kilooctets (1982)
3 pouces et demi haute densité, 1440 kilooctets (1987)
LS-120, 3 pouces et demi, 120 megaoctets (1996)

The Diskette Drive, IBM, http://www.research.ibm.com/journal/rd/255/ibmrd2505ZE.pdf

Firefox 3 et le zoom à la molette

La version finale de Firefox 3 est sortie ce 17 juin à 19H00 et je me suis empressé de l'installer sur mon poste Microsoft Windows.

Les navigateurs et d'autres applications ont souvent une fonctionnalité intéressante : le zoom à la souris. Lorsque je veux agrandir ou réduire le texte affiché, il me suffit de maintenir la touche CTRL et de faire glisser la molette de la souris. On y prend vite goût surtout lorsqu'on a eu une souris à deux boutons pendant de nombreuses années. Si dépendant que je n'y pense plus : c'est devenu un réflexe.

Bref, sous Firefox 3, à la première utilisation j'ai tout de suite remarqué un problème : ma souris fonctionne à l'envers !

Je pars donc à la recherche d'un paramètre caché qui pourrait me permettre de corriger ce problème. Pour cela je souhaite accéder au paramètre permettant de rétablir le fonctionnement attendu. J'indique dans ma barre d'adresse about:config et je me retrouve avec la liste de toute les préférences disponibles. Les plus pratiques et les moins dangereuses sont usuellement modifiées avec Outils -> Options, les autres sont dans cette longue liste. Voyons si nous pouvons trouver quelque chose permettant d'altérer le comportement de cette molette.

Tout d'abord, cet engrenage indispensable, se nomme en anglais mousewheel. Je tape ce mot dans le champ Filtre :

En défilant on peut voir les différentes sous-propriétés :

horizscroll : probablement pour les molettes permettant un mouvement de gauche à droite.
transaction : ça ne ressemble pas à ce que je recherche
withaltkey : littéralement «avec la touche ALT»
withcontrolkey : littéralement «avec la touche CONTROL», voilà !

Je complète donc ma recherche avec le terme withcontrolkey:

Il ne reste plus que trois propriétés : action, numlines et sysnumlines. L'action "3" est loin d'être parlante, quelques recherches s'imposent pour déchiffrer ces valeurs. Un manuel complet serait l'idéal.

La référence est bien sûr le site www.mozdev.org qui héberge tout un tas de ressources pour les adeptes de Mozilla. Dans mon cas, je m'intéresse plus particulièrement à preferential.mozdev.org qui décrit les arcanes du système de préférence et particulièrement la branche mousewheel.withcontrolkey :

mousewheel.withcontrolkey.action
Action to take:
0 : Scroll document by X lines
1 : Scroll document by one page
2 : Move back/forward in history
3 : Make text larger/smaller
mousewheel.withcontrolkey.numlines
Number of lines to scroll by (if relevant)

mousewheel.withcontrolkey.sysnumlines
Scroll by a number of lines equal to system default?

Du coup, je vérifie que la molette avec la touche CONTROL modifie effectivement la taille du texte. Dans ce cas, le paramètre numlines ne semble pas avoir de sens. Pourrait-il être utilisé d'une manière détournée ? Peut-être s'agit-il du facteur de zoom ? Si j'indique la valeur -1 je devrais pouvoir inverser le système.

Un simple double clic sur la ligne et voilà la valeur modifiable à souhait :

Je valide avec le bouton OK et je constate que le changement est effectif immédiatement. Ma présomption était correcte.

Mon zoom à la molette est corrigé. Nul besoin de changer de souris.

lundi 16 juin 2008

... de mots que j'ai utilisé dans quelques discussions IRC

... des types de fichier dans mon home

$ find ~ -exec file {} \; | cut -d\: -f2- | sort | uniq -c | sort -nr | head -10
22648 ASCII C program text
5620 ASCII text
4245 directory
3693 gzip compressed data
3015 ASCII English text
2437 HTML document text
1586 ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
602 ASCII text, with very long lines
522 XML
370 ASCII Pascal program text
$

Et non, je ne fais pas de Pascal ! La commande file se trompe parfois.

... de quelques fichiers dans le cache de firefox

$ file $FIREFOX_PROFILE/Cache/* | cut -d\ -f2- | sort | uniq -c | sort -nr | head -10
24 JPEG image data, JFIF standard 1.01
17 HTML document text
6 JPEG image data, JFIF standard 1.02
6 JPEG image data, JFIF standard 1.01, comment: "CREATOR: gd-jpeg v1.0 (using IJ"
5 gzip compressed data, from Unix
5 gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
4 ASCII C++ program text
4 ASCII C program text
3 Zip archive data, at least v1.0 to extract
2 UTF-8 Unicode C program text
$

... de mes commandes Linux

$ history | awk '{ print $2 }' | sort | uniq -c | sort -nr
138 ll
84 cd
50 vim
23 fgrep
21 ls
19 svn
14 cat
10 apt-cache
8 su
8 ./configure
$

Miscellanées ...