BSOD random activities, ntoskrnl.exe+253d0

[aztekk]

Hi

I've started getting random BSOD's on one of out computers at home.
Windows is up to date and as far as I know, so are the drivers for everything.

I've run a quick memtest with no result and after this is posted, I'll start another one that will run for a few hours.

BlueScreenView shows nothing more to me, than an error with "ntoskrnl.exe+253d0", which tells me nothing much, so I'm hoping for you guys to find more info on this matter.

Thanks in advance!

 

[Arc]

Hello aztekk.

You are using a beta version of display driver.

fffff880`04a49000 fffff880`0556a000   nvlddmkm T (no symbols)           
    Loaded symbol image file: nvlddmkm.sys
    Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
[COLOR=Red]    Image name: nvlddmkm.sys
    Timestamp:        Sat Dec 01 08:54:02 2012[/COLOR] (50B97852)
    CheckSum:         00B0A675
    ImageSize:        00B21000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Unfortunately I cannot suggest you to update it to the latest WHQL, as it is known to be unstable and sometimes buggy. Better you roll it back to an earlier known stable version.

• Download and install Driver Fusion.
• Reboot the computer in Advanced Boot Options, safe mode. Search Driver Fusion in your start menu, and remove all components of your nVidia display driver.
• If it says the the free version of Driver Fusion cannot remove all the elements, stop there and follow Drivers - Clean Left over Files after Uninstalling
• Boot normally now. Go to Drivers - Download NVIDIA Drivers, Drivers > Beta and Legacy; search there with your cards particulars for GeForce 306.23 Driver, dated 13.9.2012 and install it.

Then watch the situation. If crashes continue to occur, 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.


If it comes problem free, but still there are crashes, 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.

 

[aztekk]

Thanks for a detailed reply.

I've followed all the instructions, but if Driver Verifier were active, I never got to the desktop. It gave me BSOD during windows load every time.

The computer crashed into BSOD once again now during playback of video in the browser (flash I think).

Attached is a new collection from the SF_Diagnostic_tool.

 

[Arc]

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

[COLOR=Red][B]CRITICAL_STRUCTURE_CORRUPTION (109)[/B][/COLOR]
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:
[COLOR=Red][B]1)[/B][/COLOR] [U][COLOR=Red]A driver has inadvertently or deliberately modified critical kernel code
 or data.[/COLOR][/U] See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
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.
[COLOR=Red][B]3)[/B][/COLOR] [U][COLOR=Red]A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
[/COLOR][/U] Arguments:
Arg1: a3a039d896cc5579, Reserved
Arg2: b3b7465ee94a2463, Reserved
Arg3: fffff80002c0b510, Failure type dependent information
Arg4: 0000000000000000, Type of corrupted region, can be
    0 : A generic data region
    1 : Modification of a function or .pdata
    2 : A processor IDT
    3 : A processor GDT
    4 : Type 1 process list corruption
    5 : Type 2 process list corruption
    6 : Debug routine modification
    7 : Critical MSR modification

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


FAULTING_IP: 
nt!_imp_NtOpenSymbolicLinkObject+8
fffff800`02c0b510 010401          add     dword ptr [rcx+rax],eax

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x109

PROCESS_NAME:  System

CURRENT_IRQL:  0

STACK_TEXT:  
fffff880`02fe75d8 00000000`00000000 : 00000000`00000109 a3a039d8`96cc5579 b3b7465e`e94a2463 fffff800`02c0b510 : nt!KeBugCheckEx


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!_imp_NtOpenSymbolicLinkObject+8
fffff800`02c0b510 010401          add     dword ptr [rcx+rax],eax

SYMBOL_NAME:  nt!_imp_NtOpenSymbolicLinkObject+8

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  503f82be

FAILURE_BUCKET_ID:  X64_0x109_0_nt!_imp_NtOpenSymbolicLinkObject+8

BUCKET_ID:  X64_0x109_0_nt!_imp_NtOpenSymbolicLinkObject+8

Followup: MachineOwner
---------

See the point 1 and point 3. It is either a device driver that is unidentified till now; or RAM.

For testing the RAM, you need to run memtest. I dont know if you have done it or not. But if you have done it, 4 hours is not enough time. You have to do it at least overnight, for 7 - 8 passes.

For driver verifier, dont select any driver provided by "microsoft" and "unknown", and let it run. Hopefully it will run, and will be able to find any cause.

Go for memtest first. It it comes clear, then and only then go for Driver Verifier.

 

[aztekk]

I'm currently running memtest86 again, this time it's been running for aprox 9 hours.
Yesterday it ran for 4 hours straight ...

I'm not conviced in running much more memtesting, as I'm thinking the system wont heat up as much, compared to something GPU intensive.

Are there any good ways to stress the system and still beeing capable in producing good enought logs on eventual ellerors and crashes?

Reason is that as far as I know, flash has been running most often when the crashes occurred before.
Video and gameplay using flash and yes of course, it's Candy Crush Saga ... GF's favourite .. =/

 

[Arc]

If 9+ hours of memtest haven't showed any red lines, stop it for now, and go for driver verifier. With DV enabled, do the crash prone jobs, try to replicate the crashes.

Sometimes, there is no other way than putting the stress to determine the source of the problem. It is the most widely followed method. We stress the drivers, so that they can be recorded as the failing modules in the crash dumps, and may be identified.

 

[aztekk]

Ok I'll try DV again.
Never got it to boot into desktop with it enabled, but I'll give it another go.

 

[Arc]

Make it sure that you are not selecting any driver provided by "microsoft" or "unknown".