BSOD..again and again on win7 x64

Installed windows 7 x64 after installing new hardwares one week ago. And Blue screen errors kept popping..sometimes I got errors when opening explorer, shutting down, starting win7, right click on toolbar...even idle...

Update bios, clean install win7, install the latest drivers, sfc /scannow, repair install. check harddisk, try 2G ram not dual...no overclock..bios default setting..
I tried above methods, the system still crashes.

Here is my system information

BIOS: BIOS Date: 10/14/09 14:43:46 Ver: 05.01
CPU: AMD Athlon(tm) II X2 245 Processor
MB: ASUS M4A785TD-V EVO
Physical Memory: kingstone DDR3 1333, 2GBx2 (dual)
Hard Disk X 2
Maxtor 6L160M0 ATA Device (152.66GB)
WDC WD6401AALS-00L3B2 ATA Device (596.17GB)<--OS installed
Video Card: NVIDIA GeForce 9600 GT (latest version 191.07 from nvidia website)
Audio Device: VIA High Definition Audio (latest version a7400 from asus website MB driver)
Network Adapter: Realtek PCIe GBE Family Controller (latest..from asus website)

and minidumps...
Maybe hardwares cause BSOD..but maybe minibumps can show something?

need help

Nick9090 said:

Installed windows 7 x64 after installing new hardwares one week ago. And Blue screen errors kept popping..sometimes I got errors when opening explorer, shutting down, starting win7, right click on toolbar...even idle...

Update bios, clean install win7, install the latest drivers, sfc /scannow, repair install. check harddisk, try 2G ram not dual...no overclock..bios default setting..
I tried above methods, the system still crashes.

Here is my system information

(BIOS): BIOS Date: 10/14/09 14:43:46 Ver: 05.01
(CPU): AMD Athlon(tm) II X2 245 Processor
MB: ASUS M4A785TD-V EVO
Physical Memory: kingstone DDR3 1333, 2GBx2 (dual)
Hard Disk X 2
Maxtor 6L160M0 ATA Device (152.66GB)
WDC WD6401AALS-00L3B2 ATA Device (596.17GB)<--OS installed
Video Card: NVIDIA GeForce 9600 GT
Audio Device: VIA High Definition Audio
Network Adapter: Realtek PCIe GBE Family Controller

and minidumps...
Maybe hardwares cause BSOD..but maybe minibumps can show something?

need help

3 very different crashes. Unfortunately, one of them is strongly indicative of a hardware fault, perhaps the memory. The other 2 are more ambiguous, but it's a bit pointless to troubleshoot what might be software while the hardware is unreliable.

I'd suggest you run some heavy duty memory diagnostics (MDSCHED & memtest86).

3 very different crashes. Unfortunately, one of them is strongly indicative of a hardware fault, perhaps the memory. The other 2 are more ambiguous, but it's a bit pointless to troubleshoot what might be software while the hardware is unreliable.

I'd suggest you run some heavy duty memory diagnostics (MDSCHED & memtest86).

ok, back. just ran the "memtest86+ v4.00" about 8 hours, and 8 passes, 0 error..wonder at the hardware x64 compatibility prob..I tried win7 x86 and XP x86 , no BSOD in several days. But...those hardwares should support x64 well:/

I'll try "Memtest" on Win7 x64, and wait for another crash.

thx for replying :)

Nick9090 said:

After several days...running memtest and memtest86+ about 30 hours...0 errors, also tested CPU

Win7 x86 works properly without BSOD, but x64..crash all the time..sometimes system restore works, sometimes I even can't do the system restore ( It crashed when doing restore)

Reading lots posts here and other forums about crash, still don't know how to repair it, so post here again (stll pray that it's not because of hardwares )

I'll try to reinstall win7 x64 with only 2G and see how it goes. Before that, I got some BSOD. Deeply appreciate someone analyzes minidumps for me.

ps. If someone got the same issue like mine, and there're similar hardwares ( try to find out if the MB, or memory or others get "compatibility" issue) plz send me a private message.

I know it probably doesn't feel that way, but in a way you're fortunate. Unlike many people in a similar position, your minidumps virtually guarantee that yours is a hardware problem, and that may save you a lot of (software) troubleshooting time.

Memory diagnostics utilities will readily detect problems in RAM which is completely broken, to the point where the address ranges in question are entirely "stuck" or random. What they won't necessarily find is the type of corruption which is either periodic (the RAM is not always unreliable), or caused by external factors such as voltage irregularities, a damaged motherboard, overheating...

You probably don't believe me that your hardware is the most likely culprit (I wouldn't believe me either ), given that it doesn't seem to crash under a 32-bit OS, so I'll show you why I think your hardware is borked based on one of your recent minidumps:

0: kd> r
Last set context:
rax=00000000050500e2 rbx=0000000000000000 rcx=00000000050500e2
rdx=0000000000000020 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000198a53 rsp=fffff88003589f80 rbp=00000000050500e2
r8=0000000000000000 r9=0000000000000000 r10=00000000000000f3
r11=fffff88003589ff0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=0082 es=0013 fs=0000 gs=0000 efl=00010246
win32k!GreExtGetObjectW+0x187:
fffff960`00198a53 493b7e0f cmp rdi,qword ptr [r14+0Fh]ds:0082:00000000`0000000f=????????????????

The instruction attempted to "read" memory pointed at by the "r14" register plus another 0xF (15) bytes. Unfortunately, the r14 register was just zero at the time, and the resultant address of 0+f=f is entirely invalid, hence the crash.

The debugger's automated analysis recognises that all is not as it seems, because it's not the r14 register but the instruction itself which is faulty. The suggestion is to verify the contents of memory which currently stores the win32k.sys driver:

0: kd> !chkimg -lo 50 -d !win32k
fffff96000198a55 - win32k!GreExtGetObjectW+189
[ fe:7e ]
1 error : !win32k (fffff96000198a55)

An error is detected! At virtual address fffff96000198a55, the byte that should be 0xFE is instead 0x7E at the time of the crash. Let's look at those two numbers in binary. Here is what the contents of memory should be (FE):

0: kd> .formats fe
Evaluate expression:
...
Binary: 11111110

And here is what they are instead on your machine at the time of the crash (7E):

0: kd> dyb fffff96000198a55 l1
76543210 76543210 76543210 76543210
-------- -------- -------- --------
fffff960`00198a55 01111110 7e

Only a single byte is different (the zero should be a one), but that's enough to cause the memory to be interpreted as a completely different instruction. Here's what the "real" instruction should have been:

0: kd> eb fffff960`00198a55 fe // editing the memory to "fix" the flipped bit
0: kd> r
Last set context:
rax=00000000050500e2 rbx=0000000000000000 rcx=00000000050500e2
rdx=0000000000000020 rsi=0000000000000000 rdi=0000000000000000
rip=fffff96000198a53 rsp=fffff88003589f80 rbp=00000000050500e2
r8=0000000000000000 r9=0000000000000000 r10=00000000000000f3
r11=fffff88003589ff0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=0082 es=0013 fs=0000 gs=0000 efl=00010246
win32k!GreExtGetObjectW+0x187:
fffff960`00198a53 493bfe cmp rdi,r14

The r14 register was not intended to be used as a pointer at this time. Its contents were getting compared to RDI, and that would not have resulted in a crash. The machine executed an instruction that doesn't exist because of a single bit being corrupted.

Conclusion: this is a condition known as a "bitflip". The physical range in question is possibly never being touched by a 32-bit OS, or the memory is unreliable because of transients we can't even envisage at this level. The chances of a software cause are exceedingly small

Thx!! H2SO4, dont know if it takes u lots time to analyze this, Aprreciate it.

That ram analysis is same as what I think, and u really DO prove it! great job. Next step, I'll change the ram first, and hope it works.:)

Nick9090 said:

Thx!! H2SO4, dont know if it takes u lots time to analyze this, Aprreciate it.

That ram analysis is same as what I think, and u really DO prove it! great job. Next step, I'll change the ram first, and hope it works.:)

No problem! The debugger did all the work. I just chose the pretty colours :)

Here's a straight copy/paste out of the debugger's automated analysis, obviously without personal bias:

"FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT"

Before spending money, I'd suggest you thoroughly test what happens with every combination of RAM sticks - test just two, then the other two (if possible), then 1 & 3, then 2 & 4... that sort of thing.

Question: You ran Windows 7 x86 with your 4GB RAM and it recognized ALL those 4GB, not less? Because I have BSOD problems too on x64 and I can't seem to get rid of them... posted a thread too here. I just can`t seem to pin-point the problem, but if x86 recognizes all 4GB RAM, then I give up on x64.

Before spending money, I'd suggest you thoroughly test what happens with every combination of RAM sticks - test just two, then the other two (if possible), then 1 & 3, then 2 & 4... that sort of thing.

Thx for advise.
I got 2G x 2, I'll try them separately, and find out which one is "cursed". glad that the ram is in the warranty period

To BizkitBoy

My x64 OS(win7) recognized 4G(all). and unfortunately, x86 cant support over 3.25G, that's why ppl prefer x64 now.

In my case, I had used PAE to let win7 x86 recognize more than 3.25G (u can google it "Readyfor4GB" but not suggest patching it if actually ram causes crashing.) My win7 x86 got the issue "memory could not be read" after patching (looks like my ram is really broken.)
You can try anyway. It's safe.