Abhorrent BSoDing - Asus G60JX i5

[ultranothing]

Hello, all,

I've been doing some research here on various BSoD's and their associated stop errors, and while I haven't been able to discover a solution to my particular issue(s), I must say I was absolutely impressed with the level of professionalism and sincerity shown by the sevenforums community in helping others. For that, I thank you all.

I've attached the archive of my minidump files. There are 51 of them, and it's been rather frustrating to say the least.

In the middle of any random activity, but usually when I'm listening to audio, the BSOD will occur. I've noticed several different stop codes, but the DMPs will give you more info than I can remember offhand.

The BSOD will almost always occur after a buzzing sound which I can't quite describe here. Forgive the metaphor, but I can only describe it as a sustained "boner" sound effect...you know..."sproing!"

Anyway, it's driving me insane. I've tried multiple things, such as driver updates and rollbacks, bios updates, chipset driver updates and rollbacks...

Please, guide me to a solution!

 

[reventon]

Hi,

All are near identical 0x7f_8 (usually software) BSODs but no 3rd party driver is specifically mentioned. Because of this you should run Driver Verifier.

Driver Verifier

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).

In Windows 7 you can make a Startup Repair disk by going to Start....All Programs...Maintenance...Create a System Repair Disc - with Windows Vista you'll have to use your installation disk or the "Repair your computer" option at the top of the Safe Mode menu .

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"
- 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).

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.

Other things you can do:

1. Uninstall Avast

Avast has been known to cause BSODs before, I would uninstall it if I were you just in case.

Download the Avast Removal Tool (ART) from here -> save to desktop.

Boot into SAFEMODE - NO Networking. Then go to desktop, RIGHT-click on the ART icon and select Run as Administrator.

When complete - re-boot.

Install MS Security Essentials --> http://www.microsoft.com/Security_Essentials/

Then reset the Windows Firewall to its default settings -
START -> type cmd.exe -> right-click -> run as administrator -> type netsh advfirewall reset press enter

2. Out of Date Driver

[font=lucida console]
[B]ASMMAP64.sys[/B] Mon Feb 05 08:52:56 [COLOR=Red]2007[/COLOR] (45C63998)
[/font]

The above driver appears to be an ASUS ACPI UTILITY Driver. It's 'brother' ASACPI.sys causes lots of trouble, so I am really suspicious of this one too.

ASMMAP64.sys - Update link here, update instructions (slideshow) here (note that in the last step you select the ATK0101 ACPI driver in the list instead of the one mentioned)

Regards,
Reventon

BUGCHECK SUMMARY

[font=lucida console]
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed Jul 28 13:54:38.540 2010 (GMT+12)
System Uptime: 0 days 1:35:54.758
BugCheck 7F, {8, 80050031, 6f8, fffff80003090e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Wed Jul 28 12:18:11.029 2010 (GMT+12)
System Uptime: 0 days 20:23:51.621
BugCheck 7F, {8, 80050031, 6f8, fffff80003098e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Tue Jul 27 15:53:48.102 2010 (GMT+12)
System Uptime: 0 days 1:03:25.694
BugCheck 7F, {8, 80050031, 6f8, fffff8000303ae58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Tue Jul 27 14:49:25.149 2010 (GMT+12)
System Uptime: 0 days 1:35:27.741
BugCheck 7F, {8, 80050031, 6f8, fffff80003057e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Tue Jul 27 13:12:59.968 2010 (GMT+12)
System Uptime: 0 days 19:51:51.560
BugCheck 7F, {8, 80050031, 6f8, fffff80003055e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Mon Jul 26 17:20:06.153 2010 (GMT+12)
System Uptime: 0 days 1:35:59.371
BugCheck 7F, {8, 80050031, 6f8, fffff80003098e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Mon Jul 26 13:35:13.092 2010 (GMT+12)
System Uptime: 0 days 1:21:58.555
BugCheck 7F, {8, 80050031, 6f8, fffff80003048e58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Sat Jul 24 12:56:34.710 2010 (GMT+12)
System Uptime: 0 days 1:03:26.302
BugCheck 7F, {8, 80050031, 6f8, fffff8000303be58}
Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )
BUGCHECK_STR:  0x7f_8
PROCESS_NAME:  System
  
  
 
[/font]

 

[ultranothing]

Hi there,

First of all, thank you - so - much. It's assistance like this that makes me feel there's hope, not just for my computer, but for humanity as well (not to sound too sappy, or anything).

It's this kind of attention that I might expect from, say, the manufacturer of the notebook which is still under warranty. Ironically, they've remained silent in response to my repeated requests for assistance. Thanks, ASUS!

Alright, Reventon, I completed all the steps for driver verifier last night. I also removed Avast!, and replaced it with Security Essentials.

Regarding the out of date driver, and the suspect module, I attempted to install the latest "Cool and Quiet" software from the manufacturers website, but the computer COMPLETELY freezes at about 50% completion, each of the three times I made the attempt.

I am no longer getting the buzzing sound before the BSOD (though we're still BSoDing), but I am noticing that when the PC is attempting to play more than one audio stream, the audio (and video) will slow down, and I can hear the remnants of the sustained springy sound, as if my PC is going into some type of time-warp.

I believe the STOP code is different. I will update this post with new DMPs within the hour.

 

[reventon]

Regarding the out of date driver, and the suspect module, I attempted to install the latest "Cool and Quiet" software from the manufacturers website, but the computer COMPLETELY freezes at about 50% completion, each of the three times I made the attempt.

I am no longer getting the buzzing sound before the BSOD (though we're still BSoDing), but I am noticing that when the PC is attempting to play more than one audio stream, the audio (and video) will slow down, and I can hear the remnants of the sustained springy sound, as if my PC is going into some type of time-warp.

I believe the STOP code is different. I will update this post with new DMPs within the hour.

Ok.

Re: The ASUS driver update - try installing it in Safe Mode

 

[ultranothing]

Re: The ASUS driver update - try installing it in Safe Mode

Tried. Failed. Some .DLL fails to load. Would it help to try it again and give you the specific filename?

As for the new DMPs, the system doesn't appear to be creating them. There are no dump files in the minidump folder.

From what I remember, the initial STOP code ends in C. 0009C, I want to say. The BSoD refers to a file called "iastor.sys".

Apparently, IASTOR.SYS refers to the Intel Matrix Storage Manager. I am going to update that software from the ASUS website, and report the outcome.

In the meantime, if you have any more suggestions, I'm ready...

UPDATE:

Installed the new Intel Matrix Storage Manager. BSoD's continue. Since I did the driver verifier and uninstalled Avast!, I have been getting intermittent BSoD's at start-up. Quite a few times, the system would just halt completely at the "Starting Windows" screen. The last BSoD didn't reference any specific file, but here are the codes:

0x000000C4
0x0000000000000081
0xFFFFFA800720C7C0
0x000000000000008A
0x0000000000000000

How deep IS the rabbit-hole?

 

[Jonathan_King]

Could you please follow these directions?

http://www.sevenforums.com/crashes-debugging/96879-blue-screen-death-bsod-posting-instructions.html

 

[ultranothing]

Could you please follow these directions?

http://www.sevenforums.com/crashes-debugging/96879-blue-screen-death-bsod-posting-instructions.html

You're in the "BSOD Squad"? I would submerge this computer in the tub, if you told me to

I'm on it...

Update: (Possibly important information)

The only file in my minidump folder was the RAR I had created initially of the DMPs, which were uploaded here.


The "BSOD Dump & System File Collection app", which is running now, has detected this "Minidump.rar" and has, from what I can see, copied this archive and is now in the process of "copying mini-kernel dimp(sic) files".

Assuming the app was supposed to process the actual DMP files (which were CUT, not copied, and pasted into a folder on the desktop), should I return those dump files to the minidump folder, and re-run the application?

Another update:

Since the DMP files are supposed to be in the minidump folder, I'm going to go ahead and return them to the minidump folder, and re-run the BSOD Dump & System File Collection App.

 

[ultranothing]

Hi,

I ran the BSoD app from step one as instructed. This may be normal, but I wanted to say that the BSoD app never actually "stopped". It stayed on the "Copying mini-kernel dump files" screen, until inevitably I'd get another BSoD.

The app did produce an output folder with quite a few files in addition to what appear to be the original dump files.

I'm running the health report now...

Update:

I've attached the JGriff folder and the HTML document from the health report. As for the system information:

- Windows 7 x64
- Re-installed version from the restore partition
- OEM
- System debuted in March 2010
- I reinstalled the OS (from the restore partition) at the beginning of
June because the system was freezing when I tried to launch newer PC games.
I suspect that the freezing was a BSoD without the blue.

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.

I wanted to add, it seems quite a few people who purchased the ASUS Republic of Gamers G60JX-RBBX05 (BestBuy edition) have been experiencing not only rampant BSoD issues, but a substantial lack of support from the manufacturer. Appeals to various community forums from frustrated owners have yielded, from my research, mostly dead-ends and more questions than solutions. I'll do my best to see this through to the end, in the hopes that it may help others.

 

[reventon]

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.

 

[ultranothing]

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.

 

[reventon]

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.

 

[zigzag3143]

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:

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:

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

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

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

 

[ultranothing]

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?

 

[ultranothing]

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.

 

[Jonathan_King]

Go ahead and upload the dumps manually, to save you 10 minutes. See this tutorial: http://www.sevenforums.com/tutorials/83172-dump-files-upload-seven-forums.html

 

[ultranothing]

Go ahead and upload the dumps manually, to save you 10 minutes. See this tutorial: http://www.sevenforums.com/tutorials/83172-dump-files-upload-seven-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?

 

[ultranothing]

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?

 

[Jonathan_King]

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: http://www.sevenforums.com/tutorials/83172-dump-files-upload-seven-forums.html

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

 

[ultranothing]

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: http://www.sevenforums.com/tutorials/83172-dump-files-upload-seven-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!)

 

[reventon]

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: http://www.sevenforums.com/tutorials/83172-dump-files-upload-seven-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.