Random BSoDs

[ZeroCast]

Thank you all for your feedback.

To be honest, a couple of my friends did experience BSoD after installing 11.7 drivers and I am pretty sure that rolling back would solve this issue.

My major concern here isn't this one though, it's the other BSoDs that are happening randomly while the PC is left inactive. Today it happened again with a different stop message that says"IRQL_NOT_LESS_OR_EQUAL".

Here's the final dump file along side the error message details:

Problem signature:
  Problem Event Name:	BlueScreen
  OS Version:	6.1.7601.2.1.0.256.1
  Locale ID:	1033

Additional information about the problem:
  BCCode:	a
  BCP1:	FFFFFFFFFFFFFF8D
  BCP2:	0000000000000002
  BCP3:	0000000000000000
  BCP4:	FFFFF800030EEC26
  OS Version:	6_1_7601
  Service Pack:	1_0
  Product:	256_1

 

[deleted30]

It looks like a registry problem. I would download a registry fixer/cleaner to maybe solve the problem.

Try CCleaner here: http://www.piriform.com/ccleaner Which you probably already have.

I also know a more powerful one but I forgot it's name. I used to have it, but I lost it in my system reformat. I will get back to you when I get it's name.

 

[WindowsGeek]

In my experience, IRQL_NOT_LESS_OR_EQUAL has to do with interrupt requests on your system. An interrupt request is hardware related, it is an event between the CPU and a piece of hardware. You can check your IRQs in the BIOS, but more commonly this involves hardware drivers assigning the wrong IRQ. Sometimes an uninstall, reinstall or rollback of drivers should fix this issue. Rollback drivers in Device Manager, and it will take some time but it is most effective to look at each piece of hardware. Down in the bottom it should say something about whether or not there are any conflicts in IRQ or RAM allocation.

 

[Capt.Jack Sparrow]

Hello there!

I could use few more logs to figure out what's happening.
Run a Hardware Diagnostic (RAM, hard drive and GPU) : Hardware Diagnostic | Captain Debugger

Enable Driver Verifier to find out the culprit driver

Update the Sony driver

seehcri.sys  Wed Jan 09 14:11:35 2008

Bugcheck:

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: ffffffffffffff8d, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, 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: fffff800030eec26, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003317100
 ffffffffffffff8d 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!KiSignalSynchronizationObject+6
fffff800`030eec26 38488b          cmp     byte ptr [rax-75h],cl

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

BUGCHECK_STR:  0xA

PROCESS_NAME:  csrss.exe

TRAP_FRAME:  fffff880024e5850 -- (.trap 0xfffff880024e5850)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=fffff8800316a180
rdx=fffffa80086701b0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030eec26 rsp=fffff880024e59e8 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=ffffffffffffff7f
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
nt!KiSignalSynchronizationObject+0x6:
fffff800`030eec26 38488b          cmp     byte ptr [rax-75h],cl ds:0004:ffffffff`ffffff8d=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800030e72a9 to fffff800030e7d00

STACK_TEXT:  
fffff880`024e5708 fffff800`030e72a9 : 00000000`0000000a ffffffff`ffffff8d 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`024e5710 fffff800`030e5f20 : 00000000`00000000 fffff880`009b2180 00000000`00000000 fffffa80`086701b0 : nt!KiBugCheckDispatch+0x69
fffff880`024e5850 fffff800`030eec26 : fffff880`0316a180 fffffa80`086701b0 fffff800`030ebd06 00000000`00000001 : nt!KiPageFault+0x260
fffff880`024e59e8 fffff800`030ebd06 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000001 : nt!KiSignalSynchronizationObject+0x6
fffff880`024e5a00 fffff960`000cba2c : 00000000`00000000 fffff960`00000002 00000000`00000000 fffffa80`0823dc68 : nt!KeSetEvent+0x106
fffff880`024e5a70 fffff960`000c3343 : fffff900`c2910c10 00000000`00000001 00000000`00000004 fffff800`030f18f3 : win32k!SetWakeBit+0xf8
fffff880`024e5aa0 fffff960`000c3d57 : 00000000`00000000 fffff960`002e3cb0 00000000`00000004 00000000`00000001 : win32k!TimersProc+0x157
fffff880`024e5af0 fffff960`000547ac : fffffa80`0000007b 00000000`0000000f fffff880`00000001 ffffffff`80000288 : win32k!RawInputThread+0x9ab
fffff880`024e5bc0 fffff960`000d469a : fffffa80`00000002 fffff880`024caf40 00000000`00000020 00000000`00000000 : win32k!xxxCreateSystemThreads+0x58
fffff880`024e5bf0 fffff800`030e6f93 : fffffa80`09ff5b60 00000000`00000004 000007ff`fffd3000 00000000`00000000 : win32k!NtUserCallNoParam+0x36
fffff880`024e5c20 000007fe`fdbd1eea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0195fae8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7fe`fdbd1eea


STACK_COMMAND:  kb

CHKIMG_EXTENSION: !chkimg -lo 50 -db !nt
21 errors : !nt (fffff800030eec04-fffff800030eee3c)
fffff800030eec00  20  48  8b  cb *00  47  b8  fb  ff  eb  e3  90 *00  90  90  90  H...G..........
fffff800030eec10  90  90  90  90 *00  90  90  90  90  90  90  90 *00  90  90  90 ................
fffff800030eec20  ff  f3  57  48 *00  ec  38  48  8b  7a  08  48 *00  5a  08  48 ..WH..8H.z.H.Z.H
fffff800030eec30  3b  fb  75  07 *00  83  c4  38  5f  5b  c3  48 *00  6c  24  50 ;.u....8_[.H.l$P
...
fffff800030eed10  65  40  00  41 *00  44  24  2b  ff  c0  41  88 *00  24  2b  45 [email protected]$+..A..$+E
fffff800030eed20  84  f6  0f  84 *00  00  00  00  83  46  04  ff *00  85  f1  00 .........F......
fffff800030eed30  00  00  4c  8b *00  24  28  4c  8b  6c  24  30 *00  8b  64  24 ..L..$(L.l$0..d$
...
fffff800030eee00  00  00  00  72 *00  48  8b  54  24  58  e9  54 *00  ff  ff  45 ...r.H.T$X.T...E
fffff800030eee10  33  c9  41  b8  00  01  00  00  49  8b  d4  49 *00  cd  e8  3d 3.A.....I..I...=
fffff800030eee20  80  00  00  48 *00  fb  0f  84  06  ff  ff  ff *00  2e  fe  ff ...H............
fffff800030eee30  ff  85  c0  0f *00  69  2d  05  00  80  e1  fe *00  b6  01  80 .....i-.........

MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  STRIDE

FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_STRIDE

BUCKET_ID:  X64_MEMORY_CORRUPTION_STRIDE

Followup: memory_corruption

 

[deleted30]

Off topic but LOL at your name and picture!

 

[ZeroCast]

Hello there!

I could use few more logs to figure out what's happening.
Run a Hardware Diagnostic (RAM, hard drive and GPU) : Hardware Diagnostic | Captain Debugger

Enable Driver Verifier to find out the culprit driver

Update the Sony driver

Hey there. I checked both the Hardware Diagnostic blog and the Driver Verifier thread. Most of the tools mentioned there are of great use, I can safely say that I did run MemTest86+ two times, the first run gave me more than 400 errors and the second test didn't give me any.I also ran SeaTools and checked my HDD which resulted in no errors ( didn't run all tests yet, just SMART).

Last but not least, I just want to make sure before running Driver Verifier if there is any risk in harming my HDD after I follow the mentioned steps? Is this an important step? Or is the (jcgriff2) folder along side the System Health Report are enough?

On a side note: I removed my recently installed RAM piece (Slot #4) and so far its been a smooth sailing, I just want to know if the RAM I got is DOA or maybe because the difference in timings is whats causing the BSoD here.

 

[Elmer BeFuddled]

Ideally your RAM should be:
Same Manufacturer, Type, Model, Size, Batch, Timings, Etc. Preferably bought as a matched set.

So yes, "the difference in timings is what's causing the BSoD here." could well be your issue.

 

[ZeroCast]

Ideally your RAM should be:
Same Manufacturer, Type, Model, Size, Batch, Timings, Etc. Preferably bought as a matched set.

So yes, "the difference in timings is what's causing the BSoD here." could well be your issue.

What you said was spot on, the initial set that I bought was 6GB (3x2GB), at that time I didn't know that my 860 CPU only supported Dual-channel memory, so I installed 2 sticks.

This year I managed to get another stick, I made sure they had exactly the same specs, and since they do, I thought memory timings/speed on the single 4GB won't create an issue because my system already opted to use my first set @ a speed of 1333MHz.

Anyhow, I guess I need to mess with that in BIOS? Any tips, please?

 

[Capt.Jack Sparrow]

Download the Motherboard and RAM manuals there you'll find the correct timings and how to change in BIOS. As Elmer said make sure the timings and voltage is set correctly in BIOS. According to the site the timings are 9-9-9-24 and Voltage is 1.5V