BSOD with no new hardware that I know about


  1. Posts : 1
    x64 Windows 7 Professional
       #1

    BSOD with no new hardware that I know about


    My girlfriend's computer has bad a few crashes this morning, starting only this morning when she was playing WoW. But later crashed using Google Chrome. I tried to look through the dump files, but I'm not very good at debugging them yet. Any advice is much appreciated. I'll attach the dump files from today. Thank you!
      My Computer


  2. Posts : 11,269
    Windows 7 Home Premium 64 Bit
       #2

    Code:
    1. Loading Dump File [D:\Kingston\BSODDmpFiles\varond\032312-24554-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.16917.amd64fre.win7_gdr.111118-2330 Machine Name: Kernel base = 0xfffff800`02e5d000 PsLoadedModuleList = 0xfffff800`03099e70 Debug session time: Fri Mar 23 08:38:25.655 2012 (UTC - 6:00) System Uptime: 0 days 0:03:11.403 Loading Kernel Symbols ............................................................... ................................................................ ...................... Loading User Symbols Loading unloaded module list ......... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A, {9, 2, 1, fffff80002ebb005} Probably caused by : memory_corruption ( nt!MiFlushSectionInternal+295 ) Followup: MachineOwner --------- 0: 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: 0000000000000009, 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: fffff80002ebb005, address which referenced memory Debugging Details: ------------------ WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800031040e0 0000000000000009 CURRENT_IRQL: 0 FAULTING_IP: nt!MiFlushSectionInternal+295 fffff800`02ebb005 498bc5 mov rax,r13 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xA PROCESS_NAME: Í TRAP_FRAME: fffff880075f7420 -- (.trap 0xfffff880075f7420) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffff8a0019a0910 rbx=0000000000000000 rcx=fffffa800881ab90 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff80002ebb005 rsp=fffff880075f75b0 rbp=0000000000000000 r8=0000000000000000 r9=fffffa800881ab90 r10=fffffa800881ab58 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!MiFlushSectionInternal+0x295: fffff800`02ebb005 498bc5 mov rax,r13 Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002eccaa9 to fffff80002ecd540 STACK_TEXT: fffff880`075f72d8 fffff800`02eccaa9 : 00000000`0000000a 00000000`00000009 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffff880`075f72e0 fffff800`02ecb720 : 00000000`00000150 fffffa80`0881ab10 00000000`000003d0 fffff880`075f7580 : nt!KiBugCheckDispatch+0x69 fffff880`075f7420 fffff800`02ebb005 : fffffa80`0881ab10 00000000`00000000 fffff800`03046e80 00000000`0000000f : nt!KiPageFault+0x260 fffff880`075f75b0 fffff800`02eb9794 : fffff8a0`019a0910 fffff8a0`019a09c8 fffffa80`0881ab90 fffffa80`0881ab90 : nt!MiFlushSectionInternal+0x295 fffff880`075f77f0 fffff800`02eb02dc : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmFlushSection+0x1f4 fffff880`075f78b0 fffff800`031c3fea : 00000000`00000000 00000000`00000006 00000000`01000000 00000000`00000000 : nt!MiFlushDataSection+0x190 fffff880`075f7920 fffff800`031b97e3 : fffff880`075f7b80 00000000`00000000 00000000`00000000 fffff880`075f7b78 : nt!MmCreateSection+0x2ce fffff880`075f7b30 fffff800`02ecc793 : fffffa80`07d689f0 00000000`0026db68 fffff880`075f7bc8 00000000`00000000 : nt!NtCreateSection+0x162 fffff880`075f7bb0 00000000`7720fb5a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 00000000`0026db48 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7720fb5a STACK_COMMAND: kb FOLLOWUP_IP: nt!MiFlushSectionInternal+295 fffff800`02ebb005 498bc5 mov rax,r13 SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: nt!MiFlushSectionInternal+295 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt DEBUG_FLR_IMAGE_TIMESTAMP: 4ec7a284 IMAGE_NAME: memory_corruption FAILURE_BUCKET_ID: X64_0xA_nt!MiFlushSectionInternal+295 BUCKET_ID: X64_0xA_nt!MiFlushSectionInternal+295 Followup: MachineOwner ---------
    2. Loading Dump File [D:\Kingston\BSODDmpFiles\varond\032312-29733-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.16917.amd64fre.win7_gdr.111118-2330 Machine Name: Kernel base = 0xfffff800`02e03000 PsLoadedModuleList = 0xfffff800`0303fe70 Debug session time: Fri Mar 23 07:57:09.558 2012 (UTC - 6:00) System Uptime: 0 days 0:31:15.932 Loading Kernel Symbols ............................................................... ................................................................ ...................... Loading User Symbols Loading unloaded module list ...... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck F7, {20f880014b81a4, 20f880014b81a4, ffff077ffeb47e5b, 0} Probably caused by : NETIO.SYS ( NETIO!NetioAllocateAndReferenceCloneNetBufferList+32 ) Followup: MachineOwner --------- 3: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_OVERRAN_STACK_BUFFER (f7) A driver has overrun a stack-based buffer. This overrun could potentially allow a malicious user to gain control of this machine. DESCRIPTION A driver overran a stack-based buffer (or local variable) in a way that would have overwritten the function's return address and jumped back to an arbitrary address when the function returned. This is the classic "buffer overrun" hacking attack and the system has been brought down to prevent a malicious user from gaining complete control of it. Do a kb to get a stack backtrace -- the last routine on the stack before the buffer overrun handlers and bugcheck call is the one that overran its local variable(s). Arguments: Arg1: 0020f880014b81a4, Actual security check cookie from the stack Arg2: 0020f880014b81a4, Expected security check cookie Arg3: ffff077ffeb47e5b, Complement of the expected security check cookie Arg4: 0000000000000000, zero Debugging Details: ------------------ DEFAULT_BUCKET_ID: GS_FALSE_POSITIVE_MISSING_GSFRAME SECURITY_COOKIE: Expected 0020f880014b81a4 found 0020f880014b81a4 BUGCHECK_STR: 0xF7_ONE_BIT CUSTOMER_CRASH_COUNT: 1 PROCESS_NAME: Í CURRENT_IRQL: 0 LAST_CONTROL_TRANSFER: from fffff8800146ac0a to fffff80002e73540 STACK_TEXT: fffff880`060a54b8 fffff880`0146ac0a : 00000000`000000f7 0020f880`014b81a4 0020f880`014b81a4 ffff077f`feb47e5b : nt!KeBugCheckEx fffff880`060a54c0 fffff880`0145e2a8 : fffffa80`09352660 fffffa80`05276e80 fffffa80`06f921b8 fffffa80`05276e80 : ndis!_report_gsfailure+0x26 fffff880`060a5500 fffff880`015508e2 : fffffa80`05202680 fffffa80`05202788 00000000`c27099e2 00000000`00000028 : ndis!NdisAllocateCloneNetBufferList+0x2c8 fffff880`060a5610 fffff880`016347c3 : fffff880`060a5668 00000000`00000028 fffff880`01768800 fffffa80`05276d50 : NETIO!NetioAllocateAndReferenceCloneNetBufferList+0x32 fffff880`060a5640 fffff880`016342b4 : 00000000`00000000 fffffa80`05276d50 fffff880`01768800 fffff880`0164f3ef : tcpip!IppCreateClonePacket+0x23 fffff880`060a5670 fffff880`016341e9 : fffffa80`0867a0e8 fffffa80`05276e80 fffffa80`0604f898 fffffa80`05276d50 : tcpip!IppCreateStrongClonePacket+0x54 fffff880`060a56b0 fffff880`0166895c : fffffa80`0604f898 fffffa80`0878f080 fffff880`01768800 fffffa80`0604f800 : tcpip!IppCreateLoopbackSplitList+0x99 fffff880`060a5710 fffff880`01664335 : 00000000`0000000a fffffa80`05276e80 fffff880`060a5820 fffff880`060a5828 : tcpip!IppDispatchSendPacketHelper+0x41c fffff880`060a57d0 fffff880`01665c84 : 00000000`00000011 fffff880`00000000 fffffa80`00000028 00000000`00000000 : tcpip!IppPacketizeDatagrams+0x2d5 fffff880`060a58f0 fffff880`0166ad4e : fffffa80`0878f080 fffff880`01549804 fffff880`01768800 fffffa80`0633dc60 : tcpip!IppSendDatagramsCommon+0x754 fffff880`060a5bc0 fffff880`01634f88 : fffffa80`0633dc60 fffffa80`05276d50 fffffa80`05276d50 fffffa80`0878f080 : tcpip!IpNlpSendDatagrams+0x3e fffff880`060a5c00 fffff880`016354fd : fffffa80`07aa3380 fffffa80`0876d0e0 fffff880`060a6540 00000000`00000000 : tcpip!UdpSendMessagesOnPathCreation+0x688 fffff880`060a5f80 fffff880`01635185 : fffff880`060a64b0 fffffa80`0938eb14 00000000`00000001 fffffa80`0938ad70 : tcpip!UdpSendMessages+0x35d fffff880`060a6370 fffff800`02e82bda : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15 fffff880`060a63a0 fffff880`01635748 : fffff880`01635170 fffff880`060a64b0 fffffa80`0938ad00 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xda fffff880`060a6480 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!UdpTlProviderSendMessages+0x78 STACK_COMMAND: kb FOLLOWUP_IP: NETIO!NetioAllocateAndReferenceCloneNetBufferList+32 fffff880`015508e2 488bd8 mov rbx,rax SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: NETIO!NetioAllocateAndReferenceCloneNetBufferList+32 FOLLOWUP_NAME: MachineOwner MODULE_NAME: NETIO IMAGE_NAME: NETIO.SYS DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc18a FAILURE_BUCKET_ID: X64_0xF7_ONE_BIT_MISSING_GSFRAME_NETIO!NetioAllocateAndReferenceCloneNetBufferList+32 BUCKET_ID: X64_0xF7_ONE_BIT_MISSING_GSFRAME_NETIO!NetioAllocateAndReferenceCloneNetBufferList+32 Followup: MachineOwner ---------
    3. Loading Dump File [D:\Kingston\BSODDmpFiles\varond\032312-24445-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.16917.amd64fre.win7_gdr.111118-2330 Machine Name: Kernel base = 0xfffff800`02e4f000 PsLoadedModuleList = 0xfffff800`0308be70 Debug session time: Fri Mar 23 07:21:05.247 2012 (UTC - 6:00) System Uptime: 0 days 0:08:34.995 Loading Kernel Symbols ............................................................... ................................................................ ...................... Loading User Symbols Loading unloaded module list ..... ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck D1, {fffff87fc26aaba1, 2, 8, fffff87fc26aaba1} Probably caused by : tcpip.sys ( tcpip!IpNlpFastSendDatagram+221 ) Followup: MachineOwner --------- 2: 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: fffff87fc26aaba1, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000008, value 0 = read operation, 1 = write operation Arg4: fffff87fc26aaba1, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030f60e0 fffff87fc26aaba1 CURRENT_IRQL: 0 FAULTING_IP: +3836663335663435 fffff87f`c26aaba1 ?? ??? CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0xD1 PROCESS_NAME: Í TRAP_FRAME: fffff88008840460 -- (.trap 0xfffff88008840460) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffffa8005a7ca70 rbx=0000000000000000 rcx=0000000028000000 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=fffff87fc26aaba1 rsp=fffff880088405f8 rbp=fffff880088409e0 r8=fffffa8007fb5e30 r9=000000000000bc90 r10=0000000000000022 r11=fffff8800176c9a0 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na po nc fffff87f`c26aaba1 ?? ??? Resetting default scope LAST_CONTROL_TRANSFER: from fffff80002ebeaa9 to fffff80002ebf540 FAILED_INSTRUCTION_ADDRESS: +3836663335663435 fffff87f`c26aaba1 ?? ??? STACK_TEXT: fffff880`08840318 fffff800`02ebeaa9 : 00000000`0000000a fffff87f`c26aaba1 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx fffff880`08840320 fffff800`02ebd720 : fffff880`00000008 fffffa80`08851580 00000000`00000000 fffffa80`073cd5e0 : nt!KiBugCheckDispatch+0x69 fffff880`08840460 fffff87f`c26aaba1 : fffff880`01676a91 ffff0000`09f2659d 00000000`0000003c 00000000`00000001 : nt!KiPageFault+0x260 fffff880`088405f8 fffff880`01676a91 : ffff0000`09f2659d 00000000`0000003c 00000000`00000001 00000000`00000000 : 0xfffff87f`c26aaba1 fffff880`08840600 fffff880`0165c82b : fffffa80`08cafc80 fffff880`01766101 00000000`00000014 fffff880`00000022 : tcpip!IpNlpFastSendDatagram+0x221 fffff880`08840990 fffff880`01675104 : 00000000`0000bc90 fffffa80`06175001 fffff880`01766102 fffffa80`06027fa0 : tcpip!TcpTcbHeaderSend+0x48b fffff880`08840b40 fffff880`0167cc1c : fffff880`0510e600 00000000`00000000 00000000`00000000 fffff880`0165f100 : tcpip!TcpFlushDelay+0x204 fffff880`08840c20 fffff880`0165e227 : fffffa80`06175000 fffffa80`06050820 fffffa80`06178c0e 00000000`00000000 : tcpip!TcpPreValidatedReceive+0x20c fffff880`08840cd0 fffff880`0165e2f9 : fffff880`08840e50 fffff880`0176c9a0 fffff880`08840e60 fffff880`01634d7b : tcpip!IppDeliverListToProtocol+0x97 fffff880`08840d90 fffff880`0165e7f0 : fffffa80`06175000 00000000`00000000 00000000`00000011 fffff880`08840e50 : tcpip!IppProcessDeliverList+0x59 fffff880`08840e00 fffff880`0165d681 : fffffa80`06175000 fffffa80`06175000 fffff880`0176c9a0 00000000`07f63201 : tcpip!IppReceiveHeaderBatch+0x231 fffff880`08840ee0 fffff880`0165c0f2 : fffffa80`07fb5e30 00000000`00000000 fffffa80`07f63201 00000000`00000001 : tcpip!IpFlcReceivePackets+0x651 fffff880`088410e0 fffff880`0167662a : fffffa80`07f63220 fffff880`08841210 fffffa80`07f63220 00000000`00000000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2 fffff880`088411c0 fffff800`02ecebda : fffffa80`07e077a0 fffff880`0883c000 00000000`00004800 00000000`00000000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xda fffff880`08841210 fffff880`01676052 : fffff880`01676550 fffff880`08841320 00000000`00000002 fffff800`03187fac : nt!KeExpandKernelStackAndCalloutEx+0xda fffff880`088412f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!FlReceiveNetBufferListChain+0xb2 STACK_COMMAND: kb FOLLOWUP_IP: tcpip!IpNlpFastSendDatagram+221 fffff880`01676a91 03d0 add edx,eax SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: tcpip!IpNlpFastSendDatagram+221 FOLLOWUP_NAME: MachineOwner MODULE_NAME: tcpip IMAGE_NAME: tcpip.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4e83eb7f FAILURE_BUCKET_ID: X64_0xD1_CODE_AV_BAD_IP_tcpip!IpNlpFastSendDatagram+221 BUCKET_ID: X64_0xD1_CODE_AV_BAD_IP_tcpip!IpNlpFastSendDatagram+221 Followup: MachineOwner ---------
    First crash points to memory problems, but may be misleading. The other two crashes point to a network issue. I suspect either the network adapter drivers are corrupted or the system security (antivirus) software is corrupted. Re-install them.

    If you follow the https://www.sevenforums.com/crashes-d...tructions.html on your girlfriend's computer, I may be able to help you find the appropriate drivers. You may also use the computer manufacturer's site to obtain the drivers.

    At this time, all I know is that I am dealing with a computer. I do not know what type, who made it, what hardware is installed, what software is installed, etc. It is very difficult to provide specific troubleshooting steps without more information: System Info - See Your System Specs can be used as a guide to fill in system specs to help us help you.
      My Computer


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 04:16.
Find Us