New
#1
Please help me analyze this BSOD (Firefox/Video issue)
I always get BSOD when viewing videos in Firefox. My cpu is slightly overclocked but I had it overclocked even more in Vista with absolutely no problems. I'd rather not put it back to normal speeds just to watch videos when everything else works fine. Can someone tell me what I can do besides going back to normal speeds?
Code:Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\Minidump\111109-21652-01.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Kernel Version 7600 MP (4 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16385.amd64fre.win7_rtm.090713-1255 Machine Name: Kernel base = 0xfffff800`02c0a000 PsLoadedModuleList = 0xfffff800`02e47e50 Debug session time: Wed Nov 11 02:33:45.101 2009 (GMT-8) System Uptime: 0 days 12:24:11.771 Loading Kernel Symbols ............................................................... ................................................................ .................................... Loading User Symbols Loading unloaded module list ........... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck D1, {fffffffffffe7988, 2, 1, fffff8800186b443} Probably caused by : tcpip.sys ( tcpip!TcpUpdateIsnGenerator+73 ) Followup: MachineOwner --------- 3: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) 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 kernel debugger is available get stack backtrace. Arguments: Arg1: fffffffffffe7988, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, value 0 = read operation, 1 = write operation Arg4: fffff8800186b443, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80002eb20e0 fffffffffffe7988 CURRENT_IRQL: 2 FAULTING_IP: tcpip!TcpUpdateIsnGenerator+73 fffff880`0186b443 43874c8104 xchg ecx,dword ptr [r9+r8*4+4] CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xD1 PROCESS_NAME: firefox.exe TRAP_FRAME: fffff880009b0510 -- (.trap 0xfffff880009b0510) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=0000000000000003 rbx=0000000000000000 rcx=0000000000442a00 rdx=0000000087cc40bc rsi=0000000000000000 rdi=0000000000000000 rip=fffff8800186b443 rsp=fffff880009b06a0 rbp=fffff8800198bfd0 r8=0000000000000009 r9=fffffffffffe7960 r10=fffff88002fd4180 r11=0000000000000003 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei ng nz na po cy tcpip!TcpUpdateIsnGenerator+0x73: fffff880`0186b443 43874c8104 xchg ecx,dword ptr [r9+r8*4+4] ds:ffffffff`fffe7988=???????? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002c7b469 to fffff80002c7bf00 STACK_TEXT: fffff880`009b03c8 fffff800`02c7b469 : 00000000`0000000a ffffffff`fffe7988 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`009b03d0 fffff800`02c7a0e0 : 00000000`00002000 fffff880`0198bfd0 00000000`00008000 fffff880`048a2f14 : nt!KiBugCheckDispatch+0x69 fffff880`009b0510 fffff880`0186b443 : 00000000`004429c4 fffff800`02c89b91 fffff880`01966128 ffffffff`ffd9da60 : nt!KiPageFault+0x260 fffff880`009b06a0 fffff880`0187dad2 : 00000000`00000000 00000000`00000600 00000000`00442a00 fffffa80`06062e98 : tcpip!TcpUpdateIsnGenerator+0x73 fffff880`009b06f0 fffff880`0187145d : fffffa80`06062e98 00000000`00000003 00000000`0035e36e 00000000`00000001 : tcpip!TcpTimerUpdateOnDemandQuotas+0x32 fffff880`009b0720 fffff800`02c87fa6 : fffff880`009b0830 fffffa80`002af7e5 00000000`00000001 00000000`00000000 : tcpip!TcpPeriodicTimeoutHandler+0x1fd fffff880`009b07a0 fffff800`02c87326 : fffffa80`06062f68 00000000`002bacc2 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x66 fffff880`009b0810 fffff800`02c87e7e : 00000067`f68797f9 fffff880`009b0e88 00000000`002bacc2 fffff880`02fd7dc8 : nt!KiProcessExpiredTimerList+0xc6 fffff880`009b0e60 fffff800`02c87697 : fffffa80`062241c1 fffffa80`002bacc2 00000000`00000000 00000000`000000c2 : nt!KiTimerExpiration+0x1be fffff880`009b0f00 fffff800`02c82065 : 000004d8`00000000 fffffa80`07bf1190 00000000`00000000 fffffa80`05ee40a0 : nt!KiRetireDpcList+0x277 fffff880`009b0fb0 fffff800`02c81e7c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxRetireDpcList+0x5 fffff880`0b441be0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue STACK_COMMAND: kb FOLLOWUP_IP: tcpip!TcpUpdateIsnGenerator+73 fffff880`0186b443 43874c8104 xchg ecx,dword ptr [r9+r8*4+4] SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: tcpip!TcpUpdateIsnGenerator+73 FOLLOWUP_NAME: MachineOwner MODULE_NAME: tcpip IMAGE_NAME: tcpip.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc26e FAILURE_BUCKET_ID: X64_0xD1_tcpip!TcpUpdateIsnGenerator+73 BUCKET_ID: X64_0xD1_tcpip!TcpUpdateIsnGenerator+73 Followup: MachineOwner ---------