ASUS N53SV-XV1 experiencing BSOD at random

[st0kEd]

I have an ASUS N53SV-XV1 that has been getting BSOD during normal (browser, outlook). It goes BSOD at random and happens 1-2 a day, during an 8 hour work period.

Make and Model
ASUS N53SV-XV1

Display
15.6-inch LED-backlit Full HD display (1920 x 1080)

Graphics Card
NVIDIA® GeForce® GT 540M with 1GB DDR3 VRAM and NVIDIA Optimus Technology

Processor
Type : 2nd gen Intel® Core™ i7-2630QM
Speed : 2.0 GHz (with Turbo Boost 2.0 up to 2.9 GHz)
Cache : 3 MB L3

Chipset
Intel® HM65

Memory
Corsair 8GB (2x 4GB) 1333mhz PC3-10666 204-pin DDR3 SODIMM
NOTE: In 2012 I ran Memtest 10+ passes on each stick and there were no errors found.

Storage
Crucial M4 SSD 256GB, 2.5" SATA

Optical Drive
Super Multi DVD drive

Communication
LAN : 10/100/1000 Mbps Ethernet
WLAN : Integrated 802.11 b/g/n (@2.4GHz)

Bluetooth
Built-in Bluetooth™ 2.1

Audio
Bang & Olufsen ICEpower®
Built-in Speakers And Microphone
SonicFocus
(Realtek High Definition Audio)

Interface
1 x USB 3.0 ports
3 x USB 2.0 ports
1 x RJ45 LAN Jack for LAN insert
1 x HDMI
1 x Microphone-in jack
1 x Line-in Jack
1 x VGA port/Mini D-sub 15-pin for external monitor

Power
Output : 19 V DC, 6.3 A, 120 W (Quad Core) / 4.74 A , 90 W (Dual Core)
Input : 100 -240 V AC, 50/60 Hz universal

 

[YoYo155]

Hello .

All of the bugchecks are the same.

BugCheck 109, {a3a039d8a31a7ad5, b3b7465ef5974a2b, fffff80005022590, 1}

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption

Usual causes: Device driver, Breakpoint set with no debugger attached, Hardware (Memory in particular).

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:

1) A driver has inadvertently or deliberately modified critical kernel code
 or data.

2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.

3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    fffff80005022a39 - nt!WmiQueryTraceInformation+4a9
    [ 01:00 ]
1 error : !nt (fffff80005022a39)

MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  ONE_BIT

FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT

Although I suspect the usual out-dated OEM drivers to be at fault in this case, also the fact that RAM
issues usually generate a wide range of stop-codes the following quote demonstrates the ideal
course of action to be taken at this time, please follow through in the order it appears .

Your crash dumps are not showing any finite probable cause.

Test your RAM modules for possible errors.
How to Test and Diagnose RAM Issues with Memtest86+
Run memtest for at least 8 passes, preferably overnight.

First run it with all the existing/installed RAM modules. If it comes with no error, all is good.

But if it starts showing errors, Stop testing. Errors/red lines means one or more RAM is faulty. But the fault may occur due to a faulty DIMM slot, too, which is a motherboard component. Using memtest86+, you can discriminate between a faulty RAM and a faulty motherboard.

How? Say you have two RAM sticks and two DIMM slots. You obtained errors at the test with all RAM sticks installed. Now, remove all the sticks but one. Test it in all the available slots, one by one. Continue the same procedure for all the available sticks.
How to make the inference that is it a RAM issue or it is a motherboard issue? Suppose you have got the result like that:

test|Slot1|Slot2
RAM1| Error | Error
RAM2|Good|Good

It is a RAM, a bad RAM.

But if you have got a result like that:

test|Slot1|Slot2
RAM1| Error |Good
RAM2| Error |Good

It is a motherboard issue. The particular slot is bad.

If memtest comes free from errors, enable Driver Verifier to monitor the drivers.
Driver Verifier - Enable and Disable
Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.

   Information

Why Driver Verifier:
It puts a stress on the drivers, ans so it makes the unstable drivers crash. Hopefully the driver that crashes is recorded in the memory dump.

How Can we know that DV is enabled:
It will make the system bit of slow, laggy.

   Warning

Before enabling DV, make it sure that you have earlier System restore points made in your computer. You can check it easily by using CCleaner looking at Tools > System Restore.

If there is no points, make a System Restore Point manually before enabling DV.

   Tip

• If you fail to get on the Desktop because of DV, Boot into Advanced Boot Options > Safe mode. Disable DV there. Now boot normally again, and try following the instruction of enabling DV again.
• If you cannot boot in Safe mode too, do a System Restore to a point you made earlier.

Let us know the results, with the subsequent crash dumps, if any.

 

[st0kEd]

Thanks for the detailed response.

I'll run Memtest and check the RAM again in case something has happened since I tested both sticks last year.

Also, I had to RMA the machine last year for what turned out to be a defective motherboard. Hopefully the issue something other that this time. :/

 

[YoYo155]

Keep us posted .

 

[st0kEd]

Also, I'll check that the drivers are up to date.

I did do a clean OS install and driver update a couple months ago, but I'll check the ASUS site to see if any updates are available.

ANOTHER ISSUE I'VE BEEN ENCOUNTERING WHICH IS OF NOTE: Resuming Windows after the computer has been in sleep mode takes 5+ minutes. That is, I sit and stare the 'Resuming Windows' screen for 5+ minutes until I'm back into Windows.

 

[YoYo155]

We will deal with that once the BSODs are a thing of the past .
Any updates on such / tests results?

 

[st0kEd]

We will deal with that once the BSODs are a thing of the past .
Any updates on such / tests results?

Agreed, that sounds like a good strategy. It's been a busy week, I'm going to start the RAM testing this evening.

Thanks!

 

[YoYo155]

Any updates ?

 

[st0kEd]

Any updates ?

I left the machine at work on Friday so I won't be done with testing until Tuesday.

 

[st0kEd]

So I ran MemTest for 10 passes and encountered only a single (1) error which seems odd. Previously I've had a bad stick it finds thousands of errors. Thoughts? Motherboard issue? The MB was replaced ~18 months ago under warranty so this wouldn't be the first time it's given me problems. See attached.

 

[YoYo155]

So I ran MemTest for 10 passes and encountered only a single (1) error which seems odd. Previously I've had a bad stick it finds thousands of errors. Thoughts? Motherboard issue? The MB was replaced ~18 months ago under warranty so this wouldn't be the first time it's given me problems. See attached.

That was a very long weekend....

This a tricky situation as RAM shouldn't have any errors whatsoever on the other hand Memtest isn't perfect.
For now keep the current modules.

Have you had any more crashes during this entire time?
If so continue with Driver Verifier.

 

[st0kEd]

So I ran MemTest for 10 passes and encountered only a single (1) error which seems odd. Previously I've had a bad stick it finds thousands of errors. Thoughts? Motherboard issue? The MB was replaced ~18 months ago under warranty so this wouldn't be the first time it's given me problems. See attached.

That was a very long weekend....

This a tricky situation as RAM shouldn't have any errors whatsoever on the other hand Memtest isn't perfect.
For now keep the current modules.

Have you had any more crashes during this entire time?
If so continue with Driver Verifier.

Yeah, it's going BSOD at least once a day since I last posted. I'll run the driver verifier and report what happens.