Discussion :

[benoit70]

J'ai un driver kernel(usb) ki écrit dans la base de registre les infos concernant le périph. connecté ou déconnecté.

Au dessus, une appli. qui polle la base de reg. : lecture et ecriture ne sont pas synhronisées.

D'ou peut venir cet écran bleu de plantage lors d'une déconnection?

N-B : bcp plus fréquent avec XP SP2.

Merci

[benoit70]

personne n'a la moindre idée....

snif..

[nico-pyright(c)]

ca doit venir d'un problème ...

blague à part, sans code, ca va etre difficile de t'aider

[farscape]

ton driver USB ne doit pas gerer correctement la deconnexion a chaud...
j'ai deja eu ça sur une clef usb sans fil netgear , a la deconnexion par le gestionnaire USB ecran bleu .
autant dire que le driver n'est pas certifié microsoft...

[benoit70]

oui mais j'oubliais de dire que la déconnexion toute seule ne plante jamais.
Ce n'est que lorsque la brique supérieure qui polle la base de registre est en marche que le plantage a lieu.
Donc le kernel est a priori OK(pour moi)
Qu'en pense tu maintenant farscape?

[mat.M]

Au dessus, une appli. qui polle la base de reg. : lecture et ecriture ne sont pas synhronisées.

Peux tu expliquer ce que signifie "Poller" ?
Ecrire dans un français correct et standard merci.
C'est irritant à chaque fois de faire ce genre de remarque.


Tu as un écran bleu parce qu'au risque de dire des aneries les drivers ne peuvent pas accéder aux API win 32 voilà le problème.
Parce que le mode kernel est en dessous du mode applicatif.
Un driver c'est fait pour gérer du matériel pas les couches applicatives.
Donc ce qu'il faut faire c'est développer une appi en C++, VB etc qui appelle le driver et effectue lectures et écritures dans la base de registres.

[benoit70]

C'est irritant à chaque fois de faire ce genre de remarque

Bein en fait "poller" est un terme très utilisé dans le vocable des développeurs, qui vient de "polling" qui signifie scrutation. Poller la base de registre est la lire en permanence pour détecter un changement.

Bref, c'est pourtant très clair.

Tu as un écran bleu parce qu'au risque de dire des aneries les drivers ne peuvent pas accéder aux API win 32 voilà le problème.

Concernant les écritures dans la base de registre dans le Kernel, tu y accède via les classes du DDK, qui ne sont en grande partie qu'une surcouche de Win32.

Avec un driver kernel sur WCE, tu utilise l'API WinCE sans aucun probleme.(évenements nommés, ....)

L'écran bleu n'apparait pas quand le driver kernel tourne tout seul.( voir ma derniere réponse )
Je pense que tu t'égares

[Aurelien.Regat-Barrel]

D'une manière générale le polling est une mauvaise pratique. On préfère utiliser des mécanismes de synchro pour avertir proprement d'un changement.
Dans ton cas, s'il y a écran bleu, ça vient du driver. Une appli user ne provoque pas d'écran bleu, de manière directe. Elle utilise mal un driver et fait planter ce dernier par exemple (mais là aussi c'est la faute au driver qui n'est pas bien protégé). L'écran bleu devrait te dire où a lieu le plantage. Je n'y connais pas grand chose, mais il me semble que tu dois pouvoir récupérer un dump et l'analyser, voire déboguer le driver sur un autre PC via la liaison série.

[benoit70]

Ce que j'ai du mal a saisir est que ce meme kernel ne plante JAMAIS avec un autre client. Comme
Pour le débogage ça risque d'etre dur.
T'a un lien sur le net par hasard ou je peux trouver des infos?
Le polling c'est de la daube, mais je dois maintenir cette appli. qui n'a pas été dév. par moi.

Elle utilise mal un driver et fait planter ce dernier par exemple (mais là aussi c'est la faute au driver qui n'est pas bien protégé).

Protégé contre quoi? Un client qui viens seulement lire la base de registre?? J'en doute un peu

[Aurelien.Regat-Barrel]

Ce que j'ai du mal a saisir est que ce meme kernel ne plante JAMAIS avec un autre client.

C'est bien que ce client fait quelque chose qui ne plait pas au driver, où à autre chose.

Pour le débogage ça risque d'etre dur.
T'a un lien sur le net par hasard ou je peux trouver des infos?

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Elle utilise mal un driver et fait planter ce dernier par exemple (mais là aussi c'est la faute au driver qui n'est pas bien protégé).

Protégé contre quoi? Un client qui viens seulement lire la base de registre?? J'en doute un peu

Protégé contre une mauvaise utilisation. C'est si simple de se tromper dans la manipulation des chaines de caractères.

[benoit70]

C'est bien que ce client fait quelque chose qui ne plait pas au driver, où à autre chose.

Qu'est-ce qui te prouve que tout simplement le bug n'est pas dans le client, indépendamment du driver?
Est-ce qu'un plantage applicatif de base peut provoquer ce type d'ecran bleu??

[Aurelien.Regat-Barrel]

La réponse à la 2° question répond à la première:

s'il y a écran bleu, ça vient du driver. Une appli user ne provoque pas d'écran bleu, de manière directe. Elle utilise mal un driver et fait planter ce dernier par exemple (mais là aussi c'est la faute au driver qui n'est pas bien protégé).

l'écran bleu est déclenché suite à une erreur en kernel land.

[mat.M]

Bref, c'est pourtant très clair.

non monsieur je parle français moi .

Avec un driver kernel sur WCE, tu utilise l'API WinCE sans aucun probleme.(évenements nommés, ....)

l'API WinCE PAS l'API win32

Tu as un écran bleu parce que le driver n'est pas stabilisé il ya un problème quelque part.
Comme l'a dit Aurélien en aucun cas ça ne vient de la couche applicative

Pour déboguer il faut acquérir SoftIce de Numega.
C'est un des rares outils à déboguer les Device Drivers

[benoit70]

j 'ai déja SoftIce mais il ne te dit pas ou est le bug.
Là est le souci. C'est un probleme N-P complexe comme on dit dans le langage des matheux

[mat.M]

j 'ai déja SoftIce mais il ne te dit pas ou est le bug.
Là est le souci. C'est un probleme N-P complexe comme on dit dans le langage des matheux

??? je connais pas trop SoftIce mais SoftIce donne l'adresse mémoire là où ça plante .
C'est un débogueur classique mais plus puissant et plus bas-niveau que autres parce qu'il débogue au niveau du noyau.