Random Blank screen (BSOD detected after reboot),now frequent!

Hi its been about a year im getting random crashes and BSODs with my Vaio laptop, I recently restored the laptop to factory settings, hoping that it would fix the problem, but its just getting worse.
I am getting BSOD about two times a day , doing every thing : playing warcraft, skyrim ; copying files from a drive to other drive, listening to music ,etc..
before I restored to factory settings, a BSOD was sometimes shown saying : A clock on a secondary processor was not received or sth like that. I thought it was my graphics card so i started trying all kinds of drivers bot of no use.

Now with my new systems I get random Blank screens with Grrrrrr ing sound and when i reboot, windows sometimes says
Problem signature:
Problem Event Name: BlueScreen

and that's it, I'm hopeless. I even cleaned all the dust in my laptop , not even overheating

So what can I do now?

0x101 bugchecks (the "clock on secondary processor" one) cannot be analyzed with minidumps. Access to a kernel dump (the big MEMORY.DMP file in your Windows directory) are smallest dumps necessary to ascertain cause.

As for the other crashdump you provided, it was a 0x50 crashdump which is very common. What I can tell from looking at the minidump, it appears the contents in one of your CPU's registers got roughed up. What caused it, I cannot tell from this, but I would most likely venture to guess this is hardware, primarily your CPU at fault (especially since you just did a factory reset and it didn't resolve the problem). The CLOCK_WATCHDOG_TIMEOUT bugcheck from the other crashdump would also add as evidence to this. Unfortunately, given that this is a laptop, unless it's (doubtful) memory that's the problem here, you most likely have a failing CPU or motherboard, in which case the whole thing will need to be sent for servicing or replacement.

If you wish to be absolutely sure it's not memory, then run Memtest86+ on your system for at least 7 passes. Note that CPU problems can still potentially manifest themselves in this test, so don't take it as a 100% guarantee that it's your memory.



Analysts:

Code:

TRAP_FRAME:  fffff88009d065d0 -- (.trap 0xfffff88009d065d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000000000f400 rbx=0000000000000000 rcx=fffffa800b7c3000
rdx=000000000000005c rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec3fba rsp=fffff88009d06768 rbp=fffffa8003744290
 r8=0000000000000000  r9=fffffa800b7c2f80 r10=00360057004f0057
r11=fffffa800b7c2f80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
nt!wcsrchr+0x6:
fffff800`02ec3fba 0fb701          movzx   eax,word ptr [rcx] ds:fffffa80`0b7c3000=????
Resetting default scope

Instruction at address fffff800`02ec3fba attempted to read memory address held in the rcx register to copy a portion of its contents into eax register. The memory address read was bad. Minidumps can't tell why, and this looks like a legit address, so nothing initially appears wrong. Let's look at the code flow to see where rcx originally got this address in the first place (using Disassembly window and giving it the address of the faulting instruction as the offset):

Code:

nt!wcsrchr:
fffff800`02ec3fb4 4c8bc9          mov     r9,rcx < r9 has a copy of rcx's contents
fffff800`02ec3fb7 4533c0          xor     r8d,r8d
fffff800`02ec3fba 0fb701          movzx   eax,word ptr [rcx] < this is faulting instruction
...

While we haven't found where rcx got its contents, we did see that we should have an exact copy of rcx in the r9 register, as rcx moved its contents into r9. Let's see what r9 register says:

Code:

2: kd> r
Last set context:
rax=000000000000f400 rbx=0000000000000000 rcx=fffffa800b7c3000
rdx=000000000000005c rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ec3fba rsp=fffff88009d06768 rbp=fffffa8003744290
 r8=0000000000000000  r9=fffffa800b7c2f80 r10=00360057004f0057
r11=fffffa800b7c2f80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000

r9 does not match rcx. There is nothing that should've caused the contents to have changed, meaning the context of the thread got messed up or the register itself got messed up (most likely register). This is indicative of hardware failure (primarily CPU).

thanks Vir Gnarus , many thanks for your help!

thats sad ! crappy vaio laptop , I bought it 2 years ago.

I will run memtest this weekend and see if memory is the cause.


in case it is the CPU, i have heard it is possible to use specific cores of cpu if others are faulty , is that right ? is there any way to check cpu cores?


Thanks again for your help !
btw, Im studying digital systems (electronics) and we have all these registers and ASM stuff in BSc , and thanks for the debugging lesson , it was great ! :)

Erm, unless your BIOS somehow supports manual core locking (never seen such a thing), you won't be able to lock any faulting cores to prevent it from being used. OSes have something called core affinity where you can force certain cores to be used or not used, but this only applies to specific applications, and by default any available cores are used.

(Start menu -> type msconfig into search programs and files) msconfig's boot tab can be used to specify only one core for use. You cannot specify which core, though, so this may or may not help.

You are better off having the system repaired or replaced if it is a CPU/Motherboard hardware problem.

Yes, you could use it as a temporary resolution. Given that this issue occurred on core 3, you'll want to limit it to 2 cores only. Note that this may not be the only core suffering problems, so don't be sure of results by using this workaround.

Thanks for your help!

I have a Linux OS too (Ubuntu), and oddly the system has not crashed on Linux . (i am not 100% sure, though!)

That means there's a problem with win7, aint I right?

Not necessarily. A BSOD occurs when the OS actually detects a fault. Linux may not be straining the system as much as Windows to condition it to a fault, or it may be more picky and discover faults quicker than Linux (Linux is a very lightweight OS).

Have you tested with Memtest yet? You may also wish to try Prime95 on Torture Test with large FFTs for about 9 hours. Note that this is also available in Linux so if that OS happens to be more stable it'd be preferred to test it on that first before doing so on Windows.

I personally cannot see how anything other than a hardware failure would've altered the register's contents between those two cpu instructions when they're only a single instruction apart. I guess context may have switched during this time but I don't reckon that's the case.

Thanks A lot my friend!
I was on a vacation, and had absolutely no time for mem86 tests (had a lot of homework) ; but I was working with my Linux and system crashed the same as in windows. with what you said , now im sure that the problem is hardware related.cpu related , as you said.

so, case closed, i think. Have to cope with crashes :/
good luck to you all. cheerz

Yah, I figured as much. Sorry about that mate. You can mark this solved if you feel inclined too.