Ecran bleu seven lors d’accès réseau

[kikodingo]

Bonjour,

Je rencontre un soucis très génant avec windows seven (64 bits). Cela semble lié à la mise en réseau.

PC 1 : Windows seven
PC 2 : Ubuntu
PC 3 : Windows XP
+ Freebox

Lorsque je démarre une nouvelle machine sur mon réseau alors que le PC 1 est allumé ou lorsque je tente d'accéder aux fichiers partagés du PC 1, celui-ci crash avec un beau écran bleu !
Ce crash ne provient pas immédiatement (quelques minutes peuvent passer).
Par contre lorsque je tente d'accéder au fichiers des autres PC depuis le PC1, la aucun soucis.

Le PC1 dispose de deux cartes réseaux : une Wifi en PCI et une Ethernet intégrée à la carte mère.
Au début j'utilisais la carte Wifi pour la connexion réseau. Comme mon problème semble lié au fonctionnalités réseau, je suis passé par la connexion Ethernet mais sans succès.
J'ai donc décidé de mettre à jour les pilotes de la carte Ethernet, mais la encore pas d'amélioration...

Quelqu'un aurait-il une idée ?

[Neitsa]

Bonjour,

Un diagnostique de BSOD sans code d'erreur ou minidump c'est un peu un jeu de voyance...

Poste le dernier minidump en date. Il s'agit d'un fichier *.dmp présent normalement dans c:\windows\minidump.

[ram-0000]

Cela sent le driver réseau avec un bug.

Est-ce que tu peux désactiver (voire même démonter) ta carte Wifi et refaire les tests ?

[Viduc]

test aussi en désactivant IPV6 sur ton seven...

[kikodingo]

Ci-joint dans le post, le fichier minidump (dans le zip) de mon dernier crash ainsi qu'un dump fourni par windows après redémarrage du pc.

Sinon j'ai demonté la carte wifi depuis longtemps, mais cela n'avait rien changé.

Je vais tenter de désactiver totalement l'ipv6.

Merci pour vos différentes aides et idées

[Neitsa]

Hello,

j'ai regardé le dump mais complétement oublié de poster le résultat:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 6f8, fffff80002854ec0}

Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )

Donc il s'agit d'un bugcheck 0x7F (pas simple à diagnostiquer), qui vient d'une double faute:

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff80002854ec0

Le stack trace:

1: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`009f0ce8 fffff800`0288bca9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`009f0cf0 fffff800`0288a172 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009f0e30 fffff800`02854ec0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 (TrapFrame @ fffff880`009f0e30)
fffff880`02f15e70 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x58

Le trap frame:

1: kd> .trap fffff880`009f0e30
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffeddf6b9fd9d0 rbx=0000000000000000 rcx=fffff88002f15ef1
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002854ec0 rsp=fffff88002f15e70 rbp=fffffa8004e618f0
r8=000000000000030f r9=0000000000000001 r10=fffffa8004e618d0
r11=fffff88002f165c8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!SeAccessCheckFromState+0x58:
fffff800`02854ec0 c684248000000000 mov byte ptr [rsp+80h],0 ss:0018:fffff880`02f15ef0=??

A priori RSP (registre de cadre de pile courant), n'est pas mappé. Pourtout si on regarde au thread courant:

1: kd> !thread
GetPointerFromAddress: unable to read from fffff80002ac4000
THREAD fffff880009f4fc0 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 1
Not impersonating
GetUlongFromAddress: unable to read from fffff80002a02b74
Owning Process fffff80002a15140 Image: <Unknown>
Attached Process fffffa800366d890 Image: System
fffff78000000000: Unable to get shared data
Wait Start TickCount 1674572
Context Switch Count 3840207
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!KiIdleLoop (0xfffff80002894e90)
Stack Init fffff88002f1bdb0 Current fffff88002f1bd40
Base fffff88002f1c000 Limit fffff88002f16000 Call 0
Priority 16 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 0
Child-SP RetAddr : Args to Child : Call Site
fffff880`009f0ce8 fffff800`0288bca9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`009f0cf0 fffff800`0288a172 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009f0e30 fffff800`02854ec0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 (TrapFrame @ fffff880`009f0e30)
fffff880`02f15e70 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x58

On voit que RSP ( fffff880`02f15ef0) se trouve pourtant dans la limite de la pile, même s'il est très très proche de la fin (ça c'est plutôt étrange, mais pas forcément signe d'un réel problème):

Stack Init fffff88002f1bdb0 Current fffff88002f1bd40
Base fffff88002f1c000 Limit fffff88002f16000 Call 0

Donc, je crois qu'on peut éliminer le problème répertorié ici:

http://support.microsoft.com/kb/842465/en-us

A priori, je pencherais pour un problème hardware (mémoire notamment). N'ayant pas accès au "pcitree " (liste hardware de composant) je peux difficilement en dire plus sur ce problème. Peut être qu'un autre dump serait plus parlant.

Désolé de ne pas pouvoir pointer du doigt le problème...