Windows 7 BSOD

[Lucleo]

Sinds deze week vertoont mijn laptop kuren waarbij Windows 7 geheel bevriest of alleen mijn muis en taakbalk nog reageren (geen enkel programma kan worden gestart door "onvoldoende werkgeheugen" of iets dergelijks in een pop-up). Waarna in een enkel geval Windows weer 'tot leven komt' maar meestal lang bevroren blijft en vervolgens een Blue Screen Of Death produceerd. Dit alles gebeurt bij de meest basale taken, zoals Microsoft word, internet(youtube, gmail etc), minesweeper en zelfs een keer na het opstarten zonder dat ik nog iets met de pc had gedaan.

Voor één crash heb ik gezien dat in taakbeheer van Windows alle threads van de processors voluitstonden en dat het RAM geheugen opeens verdubbelde! Van ca. 2GB naar 3,8GB. Voordat het blue screen weer te voorschijn kwam.

Voor deze week heb ik een Blue Screen gehad (hiervoor nog nooit) met deze laptop (laptopproject TUDelft 2011-2012). Sinds 1,5 jaar heb ik ook een beter opstelling waardoor de laptop "vrijhangt" in de ruimte. Sindsdien is deze laptop niet meer echt warm geworden. Bij geen enkele crash die ik deze week gezien heb(hiervoor nooit gehad) was de laptop warm + de fan is stil en werkt wel.

Als eerste heb ik mijn Hdd getest op fouten met HDTune, niet gevonden. Vervolgens heb ik mijn videokaart driver geupdate. Maar het probleem blijft bestaan.

Toen ben ik gaan kijken naar de dumpfiles van Windows, met de "Symbol File Path" heb ik nog problemen gehad. Met google las ik een reactie van dat Avast! problemen kon geven. Deze heb ik toen gedeinstalleerd. Heeft niet geholpen, toen maar weer geinstalleerd. Uit eindelijke wel een werkende Symbol server gevonden. (".sympath cache*c:\MySymbols;srv*http://msdl.microsoft.com/download/symbols;.sympath SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols").

Nu heb ik een werkend (volgens mij) dump read, maar het begrijpend lezen wil bij mij nog niet lukken. Ik zal aan het einde van deze post de uitdraaiplaatsen van winDBg van mijn laatste Blue Screen.

Mijn opstelling:

High end (HP EliteBook 8560w)
Processor: Intel i7-2630M QuadCore
Geheugen: 4 GB 1333 DDR3
Harde schijf: 500 GB 7200RPM
Optisch station: DVD RW UB Optical Drive vervangen door: 250GB SSD Samsung 840 EVO
Scherm: 15.6" FHD WVA f/CAM Display
Video: NVIDIA Quadro 1000M
Batterij: 8C 75Whr
Draadloos: 802.11 a/b/g/n
USB poorten: 2 USB 2.0 & 2 USB 3.0
Besturings-systeem: Windows 7 Home Premium 64 bit
Garantie: 3 jaar + 3 jaar garantie op batterij
Bluetooth: ja
Webcam: ja

Deze laptop zit in een dockingstation van HP waaraan twee Full HD schermen hangen.

---

uitdraai winDBg

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: .sympath cache*c:\MySymbols;srv*http://msdl.microsoft.com/download/symbols;.sympath SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.18409.amd64fre.win7sp1_gdr.140303-2144
Machine Name:
Kernel base = 0xfffff800`03262000 PsLoadedModuleList = 0xfffff800`034a5890
Debug session time: Wed Dec 3 20:44:40.960 2014 (UTC + 1:00)
System Uptime: 0 days 1:06:34.958
Loading Kernel Symbols
...............................................................
................................................................
.........................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {30, 2, 1, fffff800032e0f1f}

Probably caused by : afd.sys ( afd!AfdAbortConnection+20 )

Followup: MachineOwner
---------

4: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000030, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff800032e0f1f, address which referenced memory

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


WRITE_ADDRESS: 0000000000000030

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeAcquireInStackQueuedSpinLock+5f
fffff800`032e0f1f 488717 xchg rdx,qword ptr [rdi]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: UNS.exe

TRAP_FRAME: fffff880037cc8a0 -- (.trap 0xfffff880037cc8a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000000
rdx=fffff880037ccaa0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800032e0f1f rsp=fffff880037cca30 rbp=fffff880037ccae8
r8=fffff880037ccaa0 r9=0000000004879520 r10=0000000000000001
r11=fffffa80053f8c00 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KeAcquireInStackQueuedSpinLock+0x5f:
fffff800`032e0f1f 488717 xchg rdx,qword ptr [rdi] ds:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800032d7169 to fffff800032d7bc0

STACK_TEXT:
fffff880`037cc758 fffff800`032d7169 : 00000000`0000000a 00000000`00000030 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`037cc760 fffff800`032d5de0 : fffffa80`15b94501 00000000`00000000 fffff880`037cc960 fffffa80`080e7500 : nt!KiBugCheckDispatch+0x69
fffff880`037cc8a0 fffff800`032e0f1f : 00000000`0000001c fffff800`032b7d85 00000000`00000001 00000000`00000000 : nt!KiPageFault+0x260
fffff880`037cca30 fffff880`041bc870 : fffff880`037ccae8 fffffa80`080e7510 00000000`00000000 fffff880`0415ad46 : nt!KeAcquireInStackQueuedSpinLock+0x5f
fffff880`037cca80 fffff880`041c25c7 : fffffa80`049987c0 fffffa80`15b94878 fffffa80`04438100 fffffa80`080e7510 : afd!AfdAbortConnection+0x20
fffff880`037ccad0 fffff880`0192fa1a : fffffa80`be19d2f0 fffffa80`be19d2f0 fffffa80`be19d201 fffff880`00000010 : afd!AfdTLInspectEventHandler+0x4d7
fffff880`037ccb50 fffff880`018c2ea8 : 00000000`0e701bf5 fffff880`037ccde8 00000000`0e701bf5 fffffa80`15b94878 : tcpip!TcpInspectConnectionOnListener+0x13a
fffff880`037ccc00 fffff880`01862be2 : 00000000`0e701bf5 fffffa80`07e91010 fffffa80`04438100 fffffa80`0446da00 : tcpip! ?? ::FNODOBFM::`string'+0x3e784
fffff880`037ccc90 fffff880`018636cb : fffffa80`15b94878 fffffa80`07914080 00000000`00000000 fffff880`037cce00 : tcpip!TcpMatchReceive+0x442
fffff880`037ccde0 fffff880`0183e01a : fffffa80`0446da00 fffffa80`00009cc8 fffff880`00006042 fffff880`037c6042 : tcpip!TcpPreValidatedReceive+0x36b
fffff880`037cceb0 fffff800`032cf6b7 : fffff880`0196e9a0 0065002e`00610006 00000000`00000000 0043005c`003f003f : tcpip!IppLoopbackTransmit+0x11a
fffff880`037ccf60 fffff800`032cf678 : 00000000`00000000 00000000`00000000 fffff880`037cd000 fffff800`032e3a42 : nt!KySwitchKernelStackCallout+0x27
fffff880`0d145700 fffff800`032e3a42 : fffffa80`00000000 00000000`00000019 fffffa80`00000000 fffffa80`0503c400 : nt!KiSwitchKernelStackContinue
fffff880`0d145720 fffff880`0183e92f : fffff880`018916fc fffffa80`0503c450 fffff880`0d145900 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff880`0d145800 fffff880`0185d4ca : fffffa80`07914080 00000000`00000000 fffffa80`0503c400 fffffa80`05484010 : tcpip!IppLoopbackEnqueue+0x22f
fffff880`0d1458b0 fffff880`0185ebf5 : 00000000`00000000 00000000`00000000 fffffa80`04467900 00000000`00000006 : tcpip!IppDispatchSendPacketHelper+0x38a
fffff880`0d145970 fffff880`0185de7e : fffffa80`04467906 fffff880`0d145e00 00000000`00000014 fffffa80`00000000 : tcpip!IppPacketizeDatagrams+0x2d5
fffff880`0d145a90 fffff880`018621f1 : fffffa80`04160880 00000000`00000007 fffffa80`0503c450 fffffa80`05484010 : tcpip!IppSendDatagramsCommon+0x87e
fffff880`0d145c30 fffff880`01868895 : 00000000`00000350 00000000`00000001 00000000`00000001 00000000`00000000 : tcpip!IpNlpFastSendDatagram+0x7d1
fffff880`0d145fe0 fffff880`01877fcf : 00000000`4ee24952 fffffa80`0791b0a8 00000000`00000008 fffffa80`e02b3bdc : tcpip!TcpTcbSend+0x495
fffff880`0d146260 fffff880`01877637 : fffffa80`0791a080 00000000`00000000 00000000`00000000 00000000`00000002 : tcpip!TcpCreateAndConnectTcbRateLimitComplete+0x39f
fffff880`0d1463b0 fffff880`01877583 : 00000000`00000001 00000000`00000030 00000000`00009cc8 fffffa80`04160970 : tcpip!TcpCreateAndConnectTcbInspectConnectComplete+0x47
fffff880`0d146450 fffff880`01879ebc : 00000000`00000000 00000000`00000000 fffffa80`080ce010 fffffa80`080ce010 : tcpip!TcpContinueCreateAndConnect+0x373
fffff880`0d146550 fffff880`01879893 : fffffa80`04160880 fffffa80`080ce010 00000000`00000002 fffffa80`080ce268 : tcpip!TcpCreateAndConnectTcbInspectConnectRequestComplete+0x5c
fffff880`0d146580 fffff880`01879dd6 : 00000000`00000084 00000000`00000084 fffffa80`049981e0 00000000`00000000 : tcpip!TcpCreateAndConnectTcbWorkQueueRoutine+0x273
fffff880`0d146650 fffff880`041a51b6 : fffffa80`03d3f480 fffffa80`03d3f480 fffffa80`03d3f480 fffffa80`083164d8 : tcpip!TcpCreateAndConnectTcb+0x4c6
fffff880`0d146740 fffff800`035f4e67 : fffffa80`08316330 fffffa80`04dce870 fffffa80`05e57bd0 fffffa80`04981060 : afd!AfdSuperConnect+0x506
fffff880`0d1468d0 fffff800`035f56c6 : 00000000`7ef80000 00000000`00000000 00000000`00000001 00000000`0092ef80 : nt!IopXxxControlFile+0x607
fffff880`0d146a00 fffff800`032d6e53 : 00000000`74d62450 00000000`02cef170 00000000`02cefd20 00000000`74de4414 : nt!NtDeviceIoControlFile+0x56
fffff880`0d146a70 00000000`74d62e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`02cef0f8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74d62e09


STACK_COMMAND: kb

FOLLOWUP_IP:
afd!AfdAbortConnection+20
fffff880`041bc870 0fba6b0414 bts dword ptr [rbx+4],14h

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: afd!AfdAbortConnection+20

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: afd

IMAGE_NAME: afd.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5388291c

FAILURE_BUCKET_ID: X64_0xA_afd!AfdAbortConnection+20

BUCKET_ID: X64_0xA_afd!AfdAbortConnection+20

Followup: MachineOwner
---------

[PilatuS]

Misschien lees ik er overheen, maar ik zie nergens dat je het RAM geheugen getest hebt. Defect RAM is vrij vaak de oorzaak van BSOD's.

[Lucleo]

Goed dat je het zegt, ga ik nu doen!

[keur0000]

Memtest staat hier op t forum een linkje naar

[Lucleo]

met mdsched.exe geen geheugenfouten gevonden

[PilatuS]

Test het nog maar een keer goed en lang met Memtest. Een goede geheugentest is niet klaar in 11 minuten.

[Thralas]

Een hele dump van een enkele crash is minder interessant dan een overzichtje (BlueScreenView). Vaak kun je aan de hand van een overzicht bepalen of je last hebt van een instabiel systeem (willekeurige crashes) of een specifieke brakke driver (meestal niet het geval).

Een nullptr deref in een Microsoft-kernelmodule wijst in ieder geval naar het eerste (goh, verrassing!).

[wagenveld]

Mocht het vaker met afd.sys gebeuren (of andere netwerkmodules), ik zou eens beginnen met firewall en netwerk software verwijderen, denk ook aan Vmware etc. Tegelijk je netwerk driver bijwerken.
Maar wat Thralas al zegt dan moet je wel een trend zien.

[Lucleo]

na twee passes met memtest zijn er (gelukkig en tegelijkertijd ook jammer genoeg) geen errors gevonden.

BlueScreenView:




In alle dumps is ntoskrnl.exe in het rood te vinden.

zie dat de laptop toch eerder dit jaar al een keer bluescreen heeft gegeven.

[ Voor 63% gewijzigd door Lucleo op 03-12-2014 23:54 ]

[Thralas]

Lucleo schreef op woensdag 03 december 2014 @ 23:37:
na twee passes met memtest zijn er (gelukkig en tegelijkertijd ook jammer genoeg) geen errors gevonden.

Dat is niet bijzonder lang. Nachtje draaien (of een uur of 12) kan geen kwaad, helaas is niet al het stukke RAM zo brak dat bitjes onvoorwaardelijk omvallen.

En ja ik zeg helaas, want bij een systeem met memory corruption wil je juist het liefst meteen errors in memtest zien - in 95% van de gevallen (even wat handwaving) is je RAM namelijk de boosdoener (en het makkelijkst te vervangen).

Hoeveel RAM-modules heb je? Bij meer dan een kun je modules individueel testen. Of misschien kun je ergens een module lenen?

Uitwisselen is in ieder geval de makkelijkste manier om je RAM te testen.

[Brahiewahiewa]

Op basis van je Bluescreenview zou ik toch zeggen dat AVAST de schuldige is. Vier van de zes crashes zijn in ieder geval door Avast veroorzaakt, en het is nog niet zeker of die andere twee niet óók daar vandaan komen.

[Lucleo]

Ok de memtest heeft meer dan 20 uur gedraaid zonder ook maar een error, dus de kans dat de fout daar zit is zeer onwaarschijnlijk. Nu zit ik er al een tijdje over na te denken om met eens schone windows installatie te beginnen, hiermee zouden de problemen moeten oplossen, toch? Als de problemen bij Avast liggen.

er zit een module RAM in van 4gb 1333

[Lucleo]

Herinstallatie van Windows heeft alle problemen voorals nog opgelost!

[Verwijderd]

Lucleo schreef op dinsdag 09 december 2014 @ 00:09:
Herinstallatie van Windows heeft alle problemen voorals nog opgelost!

Oke , dat is mooi dan

[Hapkoek]

Excuses! Dacht dat dit probleem al ongeveer opgelost was, eigen topic in de maak!

[ Voor 103% gewijzigd door Hapkoek op 09-12-2014 12:37 ]

[Thralas]

Maak inderdaad even je eigen topic, met een overzicht van BlueScreenView. Dit is niet zo netjes

Brahiewahiewa schreef op donderdag 04 december 2014 @ 03:30:
Op basis van je Bluescreenview zou ik toch zeggen dat AVAST de schuldige is. Vier van de zes crashes zijn in ieder geval door Avast veroorzaakt, en het is nog niet zeker of die andere twee niet óók daar vandaan komen.

De kans dat een Avast-driver willekeurig kernelgeheugen omverfietst is vele malen minder waarschijnlijk dan instabiele hardware. Met de meestvoorkomende faulting driver eruitpikken en als schuldige aanwijzen schiet je dan niets op - drivers die het meeste werk verzetten lopen ook het grootste risico op omvallende bitjes.

Lucleo schreef op dinsdag 09 december 2014 @ 00:09:
Herinstallatie van Windows heeft alle problemen voorals nog opgelost!

Tja. Los van 3 december waren je problemen niet zo frequent, en dat zou ook kunnen verklaren waarom memtest niets oplevert.

Zolang het niet weer optreedt heb je mazzel, anders ontkom je niet aan het uitwisselen van je geheugen om te zien of dat helpt.

[Lucleo]

Thralas schreef op dinsdag 09 december 2014 @ 11:35:
Tja. Los van 3 december waren je problemen niet zo frequent, en dat zou ook kunnen verklaren waarom memtest niets oplevert.

Het duurde erg lang (>15 min) voordat het BSOD te voorschijn kwam, eerst bevroor de computer/de programma's reageerde niet meer. Erg hinderlijk en dus heb ik de pc elke keer afgesloten door de ON-knop ingedrukt te houden wanneer ik verder moest werken.

Thralas schreef op dinsdag 09 december 2014 @ 11:35:
Zolang het niet weer optreedt heb je mazzel, anders ontkom je niet aan het uitwisselen van je geheugen om te zien of dat helpt.

Tot nu toe geen BSOD meer gehad en gezien het hiervoor om het uur leek te gebeuren, zou ik zeggen dat het is opgelost (voor nu). Ik ben wel al aan het kijken naar een uitbreiding van RAM geheugen. (zie: http://gathering.tweakers.net/forum/list_messages/1616098)