Multiple and varying BSOD's

S

SunnyDayCloud

New member
Joined
Jun 18, 2013
Posts
2
Hi guys,

My friend has been having this problem for a since his migration from linux to Windows seven. Since the aforementioned migration the only other significant change has been a new GPU. i have googled these BSOD's and been unable to solve the situation for him.

I have performed a full in depth scan of his comp with both his anti virus, ESET Smart Security,and MBAM (Malwarebytes Anti Malware) both came up blank.

Specs
Mobo: AsusTeK P5Ql/EPU
Proc: Intel Core 2 Quad Q8300
RAM: 2 x 2gb Kingston
GPU: Radeon HD 7800 series
Anti Virus: ESET Smart Security

mini dumps attached and zip'd

View attachment Mini Dumps.rar
 
Hi,

A few things:

First off, we're dealing with various different bugchecks here, varying from NTFS_FILE_SYSTEM (24) to SYSTEM_SERVICE_EXCEPTION (3b) to IRQL_NOT_LESS_OR_EQUAL (a), etc. Generally, I am going to assume for the moment we are dealing with a driver issue due to a few of the bugchecks and some memory corruption, as well as taking a look at the modules list. However, something interesting, in a few of these dumps CCC.exe is the process that faulted. Generally you don't pay too much attention to that, however I would like to note that's interesting considering you mentioned your friend has recently upgraded GPU's. Just something to note of.

1. ASACPI.sys is listed. This is a driver linked to various different Asus utilities. Asus utilities for the most part are huge causes of BSOD's on W7 based systems, and I would recommend your friend removes any and all Asus systems bundled onto his system that he may have installed from the disk, etc. These utilities don't offer too much of importance anyway, and given that one or more utilities can monitor and even change BIOS settings on the fly, there is a link between the EFI and OS... which to me, that's a little unsettling, and that's why issues I would imagine occur with these utilities. Also maybe just because they're coded horribly, who knows.

2. Make sure you friend is on the latest GPU drivers via AMD's website. If he is, ensure he is not on a BETA driver version. If he is not on a BETA driver version, but is on the latest, ask him to roll back a version or two to ensure it's not a driver related issue.

3. If still having problems after #1-2, I'd recommend enabling Driver Verifier to see if we can catch any software issues going on:

Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver by flagging it and causing your system to BSOD.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7)
- Concurrentcy Stress Test (Windows 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.
If this happens, do not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:
- Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
- Restart and boot into normal Windows.
How long should I keep Driver Verifier enabled for?
It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 36-48 hours. If you don't BSOD by then, disable Driver Verifier.
My system BSOD'd, where can I find the crash dumps?
They will be located in C:\Windows\Minidump
Any other questions can most likely be answered by this article:
[url]http://support.microsoft.com/kb/244617[/URL]
Click to expand...



4. Your friend has UltraMon's multi-monitor utility installed. If after every other test related thing we do, we are still having problems, I would tell your friend to uninstall this utility. It very may well be causing issues here given all of the CCC related crashes, general video problems, etc. Just a flag raiser for me, personally.

I think that's a good start!!! I am also sure many other BSOD analysts will pass through and chime in on anything I missed or add something of their own : )

Regards,

Patrick
 
In most of these crashes the address claimed to be referenced and the actual address that the instruction references are different. Not sure if this is because of hardware failure or if there is code corruption that isn't saved in the minidumps.

061213-26738-01.dmp:
Code: 
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:
[B]Arg1: 0000000000000000, memory referenced[/B]
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: fffff800030df6c4, address which referenced memory

TRAP_FRAME:  fffff88002f22680 -- (.trap 0xfffff88002f22680)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa8005d90bf0
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030df6c4 rsp=fffff88002f22810 rbp=0000000000019f79
 r8=fffff880009ec301  r9=0000000000000002 r10=0000000000000079
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!KiProcessExpiredTimerList+0xa4:
fffff800`030df6c4 4885f6          [B]test    rsi,rsi[/B]

1: kd> k
Child-SP          RetAddr           Call Site
fffff880`02f22538 fffff800`030d41a9 nt!KeBugCheckEx
fffff880`02f22540 fffff800`030d2e20 nt!KiBugCheckDispatch+0x69
fffff880`02f22680 fffff800`030df6c4 nt!KiPageFault+0x260
fffff880`02f22810 fffff800`030df5ce nt!KiProcessExpiredTimerList+0xa4
fffff880`02f22e60 fffff800`030df3b7 nt!KiTimerExpiration+0x1be
fffff880`02f22f00 fffff800`030d7d05 nt!KiRetireDpcList+0x277
fffff880`02f22fb0 fffff800`030d7b1c nt!KyRetireDpcList+0x5
fffff880`06709ba0 00000000`00000000 nt!KiDispatchInterruptContinue
This instruction doesn't access memory at all, only the rsi register.

052213-13244-01.dmp:
Code: 
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:
[B]Arg1: 0000000000000000, memory referenced[/B]
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff88004098cd4, address which referenced memory


TRAP_FRAME:  fffff88002f22a40 -- (.trap 0xfffff88002f22a40)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000004 rbx=0000000000000000 rcx=fffff88002f22b88
rdx=000000000000524c rsi=0000000000000000 rdi=0000000000000000
rip=fffff88004098cd4 rsp=[B]fffff88002f22bd0[/B] rbp=fffffa8005352b50
 r8=fffffa80027c6b1c  r9=fffff880040b2250 r10=000000000000001c
r11=fffff88002f22ba0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
HIDCLASS!HidpInterruptReadComplete+0x2dc:
fffff880`04098cd4 8a8424a0000000  [B]mov     al,byte ptr [rsp+0A0h][/B] ss:fffff880`02f22c70=01

1: kd> k
Child-SP          RetAddr           Call Site
fffff880`02f228f8 fffff800`030761a9 nt!KeBugCheckEx
fffff880`02f22900 fffff800`03074e20 nt!KiBugCheckDispatch+0x69
fffff880`02f22a40 fffff880`04098cd4 nt!KiPageFault+0x260
fffff880`02f22bd0 fffff800`0307a5c1 HIDCLASS!HidpInterruptReadComplete+0x2dc
fffff880`02f22c60 fffff880`0568a631 nt!IopfCompleteRequest+0x341
fffff880`02f22d50 fffff880`0568ab0f USBPORT!USBPORT_Core_iCompleteDoneTransfer+0xa15
fffff880`02f22e30 fffff880`0568866f USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x3a7
fffff880`02f22e90 fffff880`05679f89 USBPORT!USBPORT_Core_UsbIocDpc_Worker+0xf3
fffff880`02f22ed0 fffff800`030812fc USBPORT!USBPORT_Xdpc_Worker+0x1d9
fffff880`02f22f00 fffff800`03079d05 nt!KiRetireDpcList+0x1bc
fffff880`02f22fb0 fffff800`03079b1c nt!KyRetireDpcList+0x5
fffff880`06d30ba0 00000000`00000000 nt!KiDispatchInterruptContinue
Claimed: read from 0000000000000000.
Actually: read from rsp+0a0h (fffff88002f22c70)

052513-14211-01.dmp:
Code: 
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
[B]Arg1: fffff8a06f90e13c, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.[/B]
Arg3: fffff88001302afb, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 0000000000000005, (reserved)


TRAP_FRAME:  fffff88006f57a40 -- (.trap 0xfffff88006f57a40)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8a00990dd42 rbx=0000000000000000 rcx=fffff8a00990dd6a
rdx=000000000000009c rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001302afb rsp=[B]fffff88006f57bd0[/B] rbp=fffff88006f57e50
 r8=0000000000000000  r9=0000000000000013 r10=fffff88006f57c30
r11=fffff88006f57c10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
Ntfs!NtfsFindPrefix+0x22b:
fffff880`01302afb 488b442458      [B]mov     rax,qword ptr [rsp+58h][/B] ss:0018:fffff880`06f57c28=6add9009a0f8ffff

3: kd> k
Child-SP          RetAddr           Call Site
fffff880`06f578d8 fffff800`031535a3 nt!KeBugCheckEx
fffff880`06f578e0 fffff800`030d4d2e nt! ?? ::FNODOBFM::`string'+0x43801
fffff880`06f57a40 fffff880`01302afb nt!KiPageFault+0x16e
fffff880`06f57bd0 fffff880`012fa054 Ntfs!NtfsFindPrefix+0x22b
fffff880`06f57c80 fffff880`012f7701 Ntfs!NtfsFindStartingNode+0x6e4
fffff880`06f57d50 fffff880`0126140d Ntfs!NtfsCommonCreate+0x3e1
fffff880`06f57f30 fffff800`030ce6f7 Ntfs!NtfsCommonCreateCallout+0x1d
fffff880`06f57f60 fffff800`030ce6b8 nt!KySwitchKernelStackCallout+0x27
fffff880`03b6f1e0 00000000`00000000 nt!KiSwitchKernelStackContinue
Claimed: write to fffff8a06f90e13c
Actually: read from rsp+58h (fffff88006f57c28)

061713-13884-01.dmp:
Code: 
NTFS_FILE_SYSTEM (24)
    If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
    parameters are the exception record and context record. Do a .cxr
    on the 3rd parameter and then kb to obtain a more informative stack
    trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff88003c59ee8
Arg3: fffff88003c59740
Arg4: fffff8000309f942

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


EXCEPTION_RECORD:  fffff88003c59ee8 -- (.exr 0xfffff88003c59ee8)
ExceptionAddress: fffff8000309f942 (nt!MiObtainSystemCacheView+0x000000000000022e)
   ExceptionCode: [B]c000001d (Illegal instruction)[/B]
  ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT:  fffff88003c59740 -- (.cxr 0xfffff88003c59740)
rax=fffff88003c5a150 rbx=fffff6fcc00d3800 rcx=fffff08006eb1105
rdx=000000001801b440 rsi=fffff800032c3b00 rdi=0000000000003256
rip=fffff8000309f942 rsp=fffff88003c5a120 rbp=0000000000000000
 r8=000000000001c953  r9=0000000000000000 r10=fffff80003256f40
r11=fffff88003c5a488 r12=fffffa8000000001 r13=fffff6fc00000000
r14=0000000000000000 r15=0000000000000001
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
nt!MiObtainSystemCacheView+0x22e:
fffff800`0309f942 483bc1          [B]cmp     rax,rcx[/B]
Is this really an illegal instruction?
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top