Version imprimable
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
personne n'a la moindre idée....
snif..
ca doit venir d'un problème ...
blague à part, sans code, ca va etre difficile de t'aider
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...
:D
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?
Peux tu expliquer ce que signifie "Poller" ?Citation:
Envoyé par benoit70
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.
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.Citation:
C'est irritant à chaque fois de faire ce genre de remarque
Bref, c'est pourtant très clair.
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.Citation:
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.
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 :wink:
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.
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.
Protégé contre quoi? Un client qui viens seulement lire la base de registre?? J'en doute un peuCitation:
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é).
C'est bien que ce client fait quelque chose qui ne plait pas au driver, où à autre chose.Citation:
Envoyé par benoit70
http://www.microsoft.com/whdc/devtools/debugging/default.mspxCitation:
Pour le débogage ça risque d'etre dur.
T'a un lien sur le net par hasard ou je peux trouver des infos?
Protégé contre une mauvaise utilisation. C'est si simple de se tromper dans la manipulation des chaines de caractères.Citation:
Protégé contre quoi? Un client qui viens seulement lire la base de registre?? J'en doute un peuCitation:
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é).
Qu'est-ce qui te prouve que tout simplement le bug n'est pas dans le client, indépendamment du driver?Citation:
C'est bien que ce client fait quelque chose qui ne plait pas au driver, où à autre chose.
Est-ce qu'un plantage applicatif de base peut provoquer ce type d'ecran bleu??
La réponse à la 2° question répond à la première:
l'écran bleu est déclenché suite à une erreur en kernel land.Citation:
Envoyé par Aurelien.Regat-Barrel
Citation:
Envoyé par benoit70
non monsieur je parle français moi .
l'API WinCE PAS l'API win32Citation:
Avec un driver kernel sur WCE, tu utilise l'API WinCE sans aucun probleme.(évenements nommés, ....)
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
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 .Citation:
Envoyé par benoit70
C'est un débogueur classique mais plus puissant et plus bas-niveau que autres parce qu'il débogue au niveau du noyau.