Abhorrent BSoDing - Asus G60JX i5

Page 2 of 4 FirstFirst 1234 LastLast

  1. Posts : 712
    Windows 7 x64, Windows XP SP3, Fedora
       #11

    ultranothing said:
    I haven't had a BSoD in about two hours, though it's only a matter of time. Until then, I can only say that when I'm getting the most recent BSoD's, it seems to hang at the part where it says something to the effect of "collecting" or "retrieving" or "something"...

    Whatever it says, it's not creating any new dumps, and I have no records after 7/27.
    Copy the minidumps somewhere else so that the Minidump folder is empty (I have seen a situation when it was not writing them unless the folder was empty).

    If you still do not get any more Minidumps created over the next day then run the full collection application again as this includes enough data to get a general idea of what the BSODs were caused by.
      My Computer


  2. Posts : 28,845
    Win 8 Release candidate 8400
       #12

    ultranothing said:
    reventon said:
    ultranothing said:
    I should add, that since I ran the "driver verifier" per Reventon's suggestion, It's been progressively harder to start up the system without a BSoD loop. After the most recent BSoD(about twenty minutes ago), the computer blued out and restarted itself three times, then froze at the startup logo animation screen.
    Ok, that is definitely a sign there is a driver problem here.

    However, as this crash was after you ran the BSOD info collection(?) there is no record of it in any of the files.

    You do not need to run the full collection application again, simply go to C:\Windows\Minidump , sort the files by date and copy any files dated newer than 07/27/10 to a zipped folder.
    I haven't had a BSoD in about two hours, though it's only a matter of time. Until then, I can only say that when I'm getting the most recent BSoD's, it seems to hang at the part where it says something to the effect of "collecting" or "retrieving" or "something"...

    Whatever it says, it's not creating any new dumps, and I have no records after 7/27.

    Well since this is obviously a driver (from the bugcheck, and the fact that it double faults at the same memory address) I have two suggestions. I havent been following this thread so they may have already been offered.

    The Usual causes: Memory corruption, Hardware (memory in particular), Installing a faulty or mismatched hardware (especially memory) or a failure after installing it, 3rd party firewall, Device drivers, SCSI/network/BIOS updates needed, Improperly seated cards, Incompatible storage devices, Overclocking, Virus scanner, Backup tool, Bad motherboard, Missing Service PackDownload a copy of

    First memory is mentioned several time so I would
    Download a copy of Memtest86 and burn the ISO to a CD using Iso Recorder or another ISO burning program. Boot from the CD, and leave it running for at least 5 or 6 passes.


    Beyond that, please run Verifier with these settings:
    [quote]
    Using Driver Verifier is an iffy proposition. Most times it'll crash and it'll tell you what the driver is. But sometimes it'll crash and won't tell you the driver. Other times it'll crash before you can log in to Windows. If you can't get to Safe Mode, then you'll have to resort to offline editing of the registry to disable Driver Verifier.

    So, I'd suggest that you first backup your stuff and then make sure you've got access to another computer so you can contact us if problems arise. Then make a System Restore point (so you can restore the system using the Vista/Win7 Startup Repair feature).

    Then, here's the procedure:
    - Go to Start and type in "verifier" (without the quotes) and press Enter
    - Select "Create custom settings (for code developers)" and click "Next"
    - Select "Select individual settings from a full list" and click "Next"
    - Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
    NOTE: You can use Low Resource Simulation if you'd like. From my limited experimentation it makes the BSOD's come faster.
    - Select "Select driver names from a list" and click "Next"
    Then select all drivers NOT provided by Microsoft and click "Next"
    - Select "Finish" on the next page.

    Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out. If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

    Reboot into Windows (after the crash) and turn off Driver Verifier by going back in and selecting "Delete existing settings" on the first page, then locate and zip up the memory dump file and upload it with your next post.

    If you can't get into Windows because it crashes too soon, try it in Safe Mode.
    If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.

    If that doesn't work, post back and we'll have to see about fixing the registry entry off-line:
    Code:
    Delete these registry keys (works in XP, Vista, Win7):
            HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
            HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel
    More info on this at this link: Using Driver Verifier to identify issues with Windows drivers for advanced users[/quote







    Code:
    Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
    Copyright (c) Microsoft Corporation. All rights reserved.
    
    
    Loading Dump File [C:\Users\K\Desktop\New folder\040510-21184-01.dmp]
    Mini Kernel Dump File: Only registers and stack trace are available
    
    Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols;srv*e:\symbols
    *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 Personal
    Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
    Machine Name:
    Kernel base = 0xfffff800`03018000 PsLoadedModuleList = 0xfffff800`03255e50
    Debug session time: Mon Apr  5 23:36:15.059 2010 (GMT-4)
    System Uptime: 0 days 1:03:50.651
    Loading Kernel Symbols
    .
    
    Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
    Run !sym noisy before .reload to track down problems loading symbols.
    
    ..............................................................
    ................................................................
    ...............................................
    Loading User Symbols
    Loading unloaded module list
    .....
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    Use !analyze -v to get detailed debugging information.
    
    BugCheck 7F, {8, 80050031, 6f8, fffff80003050e60}
    
    Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
    
    Followup: MachineOwner
    ---------
    
    2: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    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: fffff80003050e60
    
    Debugging Details:
    ------------------
    
    
    BUGCHECK_STR:  0x7f_8
    
    CUSTOMER_CRASH_COUNT:  1
    
    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
    
    PROCESS_NAME:  System
    
    CURRENT_IRQL:  2
    
    LAST_CONTROL_TRANSFER:  from fffff80003087b69 to fffff80003088600
    
    STACK_TEXT:  
    fffff880`03369ce8 fffff800`03087b69 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
    fffff880`03369cf0 fffff800`03086032 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
    fffff880`03369e30 fffff800`03050e60 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
    fffff880`03385fd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeAccessCheckFromState+0x60
    
    
    STACK_COMMAND:  kb
    
    FOLLOWUP_IP: 
    nt!KiDoubleFaultAbort+b2
    fffff800`03086032 90              nop
    
    SYMBOL_STACK_INDEX:  2
    
    SYMBOL_NAME:  nt!KiDoubleFaultAbort+b2
    
    FOLLOWUP_NAME:  MachineOwner
    
    MODULE_NAME: nt
    
    IMAGE_NAME:  ntkrnlmp.exe
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  4b88cfeb
    
    FAILURE_BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2
    
    BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2
    
    Followup: MachineOwner
    ---------
    
    2: kd> .tss
    Code:
    ASMMAP64.sys        fffff880`04940000    fffff880`04947000    0x00007000    0x45c63998    2/4/2007 15:52:56                        
    sncduvc.SYS        fffff880`02de2000    fffff880`02deaa80    0x00008a80    0x495894f2    12/29/2008 05:14:26                        
    AsDsm.sys        fffff880`014c0000    fffff880`014cd000    0x0000d000    0x49950fc2    2/13/2009 02:14:26                        
    mcdbus.sys        fffff880`0443b000    fffff880`04477880    0x0003c880    0x49a3cd1f    2/24/2009 06:34:07                        
    spldr.sys        fffff880`0184a000    fffff880`01852000    0x00008000    0x4a0858bb    5/11/2009 12:56:27                        
    ATK64AMD.sys        fffff880`04a4d000    fffff880`04a55000    0x00008000    0x4a0a1cb6    5/12/2009 21:04:54                        
    amdxata.sys        fffff880`01455000    fffff880`01460000    0x0000b000    0x4a12f2eb    5/19/2009 13:56:59                        
    snp2uvc.sys        fffff880`02c19000    fffff880`02dd0600    0x001b7600    0x4a13bb19    5/20/2009 04:11:05                        
    L1C62x64.sys        fffff880`04c46000    fffff880`04c59000    0x00013000    0x4a483ac7    6/28/2009 23:53:43                        
    rimspe64.sys        fffff880`04c2d000    fffff880`04c46000    0x00019000    0x4a4bf749    7/1/2009 19:54:49                        
    rixdpe64.sys        fffff880`10d76000    fffff880`10dcc000    0x00056000    0x4a4f2e74    7/4/2009 06:27:00
      My Computer


  3. Posts : 35
    Isn't
    Thread Starter
       #13

    Hi, Zigzag,

    It was already suggested by Reventon that I run "driver verifier".

    Right now, what I need to do, is figure out why Windows isn't creating a DMP file, and hasn't done so after the 27th (when I ran "driver verifier").

    Any suggestions on how to get my system to create the dumps?

    I also want to add, that since the driver verifier, my audio files have been sounding very warbled. They make the buzzing sound, and they actually slow down and speed back up. It's strange.

    What's my next step? Run the Memtest? Try to get the DMP files created? Do you all agree that I should remove the registry entries for Driver Verifier now? Any consensus from the pros?
      My Computer


  4. Posts : 35
    Isn't
    Thread Starter
       #14

    reventon said:
    ultranothing said:
    I haven't had a BSoD in about two hours, though it's only a matter of time. Until then, I can only say that when I'm getting the most recent BSoD's, it seems to hang at the part where it says something to the effect of "collecting" or "retrieving" or "something"...

    Whatever it says, it's not creating any new dumps, and I have no records after 7/27.
    Copy the minidumps somewhere else so that the Minidump folder is empty (I have seen a situation when it was not writing them unless the folder was empty).

    If you still do not get any more Minidumps created over the next day then run the full collection application again as this includes enough data to get a general idea of what the BSODs were caused by.
    Sorry, I read zigzag's post before I saw yours. I will remove the DMP files from the minidump folder, and keep using the computer until I get a few BSoD's, and see what I see.

    If I don't see any new DMP files after, say, 10pm (I get 2 BSoD's an hour, so 10 BSoD's should do it), I will re-run the full collection app, and upload the results.
      My Computer


  5. Posts : 13,354
    Windows 7 Professional x64
       #15

    Go ahead and upload the dumps manually, to save you 10 minutes. See this tutorial: https://www.sevenforums.com/tutorials...en-forums.html
      My Computer


  6. Posts : 35
    Isn't
    Thread Starter
       #16

    Jonathan_King said:
    Go ahead and upload the dumps manually, to save you 10 minutes. See this tutorial: https://www.sevenforums.com/tutorials...en-forums.html
    Per Reventon's request, I deleted all of the DMPs in the minidump folder. He had explained that he's experienced windows not creating new dumps in the minidump folder if it weren't empty, and the system hasn't been creating new DMP files since the 27th (when I ran driver verifier).

    Reventon asked that I remove the old (already analyzed) DMPs and wait for the system to create new DMPs. I told him that if I didn't see any new dumps in the minidump folder by 10p, I would run the collection app.

    Should I remove those two registry entries for Driver Verifier?
      My Computer


  7. Posts : 35
    Isn't
    Thread Starter
       #17

    Howard911s at Notebookreview.com said this a few months back:

    "The more I study about G60-JX and its restart and bsod issue, the more I think it is the audio and nvidia driver issue. G60 has intel HD audio on it by default, but at same time it disable that and use the Soundblaster Audigy software on it. NOW! with the New Nvidia video driver on it, it also came with HD AUDIO driver for its HDMI out. It would make sense that 3 audio driver may have caused the conflict and crash the computer over and over"

    Relevant?
      My Computer


  8. Posts : 13,354
    Windows 7 Professional x64
       #18

    No need to delete registry entries unless you cannot get into Windows. Just run verifier.exe and select "delete existing settings".

    You can trust reventon's advice, he really knows BSODs. Do as he says about deleting the dumps.

    When it comes time to upload them, use this tutorial: https://www.sevenforums.com/tutorials...en-forums.html

    It will save you the trouble of running the collection scripts.
      My Computer


  9. Posts : 35
    Isn't
    Thread Starter
       #19

    Jonathan_King said:
    No need to delete registry entries unless you cannot get into Windows. Just run verifier.exe and select "delete existing settings".

    You can trust reventon's advice, he really knows BSODs. Do as he says about deleting the dumps.

    When it comes time to upload them, use this tutorial: https://www.sevenforums.com/tutorials...en-forums.html

    It will save you the trouble of running the collection scripts.
    Understood. However, it seems that the instructions provided via that link only describe how to archive the DMP files in the minidump folder, and upload them to the site. I can do that all day long, but my concern is that my system isn't actually creating any dumps.

    What if the system continues to not create the dumps? From Reventon's description, it sounds like the "collection app" acquires suitable information about the BSoD's and system status, regardless of whether or not the dump files are present.

    At 10pm tonight, I'll check to see if there are any dump files. If there are, I will upload them according to those procedures.

    If not, I will run the collection app.

    Talk to you all in a few hours, and thanks again (and again!)
      My Computer


  10. Posts : 712
    Windows 7 x64, Windows XP SP3, Fedora
       #20

    ultranothing said:
    Jonathan_King said:
    No need to delete registry entries unless you cannot get into Windows. Just run verifier.exe and select "delete existing settings".

    You can trust reventon's advice, he really knows BSODs. Do as he says about deleting the dumps.

    When it comes time to upload them, use this tutorial: https://www.sevenforums.com/tutorials...en-forums.html

    It will save you the trouble of running the collection scripts.
    Understood. However, it seems that the instructions provided via that link only describe how to archive the DMP files in the minidump folder, and upload them to the site. I can do that all day long, but my concern is that my system isn't actually creating any dumps.

    What if the system continues to not create the dumps? From Reventon's description, it sounds like the "collection app" acquires suitable information about the BSoD's and system status, regardless of whether or not the dump files are present.

    At 10pm tonight, I'll check to see if there are any dump files. If there are, I will upload them according to those procedures.

    If not, I will run the collection app.

    Talk to you all in a few hours, and thanks again (and again!)
    Yes, if there are some then just upload them. If there are not, then run the full collection app.
      My Computer


 
Page 2 of 4 FirstFirst 1234 LastLast

  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 22:45.
Find Us