Frequent BSOD Problems.

JohnAbyss · Jan 17, 2014

Ive been getting BSOD screens for awhile and have been trying to fix them myself, but now I give up. Any help would be greatly appreciated. Everything you guys asked for is in the rar file.

OS - Windows 8
· x64
· Windows 8
· OEM
· Less than a year
· Less then a year - No

· CPU - i7 4700k
· Video Card - GTX 660
· MotherBoard - Gigabyte GA-Z87-HD3
· Power Supply - Corsair 750w

· System Manufacturer - Cyberpower
Custom

Desktop

Patrick · Jan 18, 2014

Hi,

We have three dumps, two bug checks:

SYSTEM_SERVICE_EXCEPTION (3b)

This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.

This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.

Code:

STACK_TEXT:  
fffff880`1b3e9830 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#ff0000][I][B]dxgmms1!VIDMM_GLOBAL::BeginCPUAccess+0x16d[/B][/I][/COLOR]

^^ dxgmss1.sys is the DirectX MMS, a component of DirectX. VIDMM_GLOBAL::BeginCPUAccess - ??? Very hard to tell what's going on as I cannot find proper documentation, and it's a very uninformative stack. If maybe after the 'BeginCPUAccess' call we had an 'xWaitOnDMAReferences', then I could say we may have a DMA allocation problem, but we have a blank stack so there's very little information to get.

7: kd> !irql
Debugger saved IRQL for processor 0x7 -- 0 (LOW_LEVEL)

This seemed to occur at LOW_LEVEL.

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

This is the general bug check code for fatal errors found by Driver Verifier.

Despite the name of the bug check, Driver Verifier failed to detect a driver within violation.

BugCheck C4, {f6, 2dc, fffffa8014cdd940, fffff880056ee132}

The 1st parameter of the bug check is f6 which indicates the user handle was KernelMode. Aside from kernal-mode drivers, file system drivers, etc... Kernel Mode contains the HAL (Hardware Abstraction Layer) > Hardware. The HAL's main function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. With this occurring at LOW_LEVEL, Kernel Mode, etc, this looks like a hardware issue.

First off, ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

-------------------

Start with a Memtest for NO LESS than ~8 passes (several hours):

Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

Which should I download?

You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

How Memtest works:

Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

This information, if available to the program, can be displayed via a menu option.

Any other questions, they can most likely be answered by reading this great guide here:

FAQ : please read before posting

-------------------

If Memtest goes through all ~8 passes with no errors, if you have access to integrated video OR a 2nd GPU... uninstall your video card drivers, shut down and remove your GPU physically (install 2nd GPU if that's your method), turn system on and install latest drivers for either 2nd GPU or integrated video.

Regards,

Patrick

JohnAbyss · Jan 19, 2014

Patrick said:
Hi,

We have three dumps, two bug checks:

SYSTEM_SERVICE_EXCEPTION (3b)

This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.

This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.

Code:

STACK_TEXT: fffff880`1b3e9830 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : [COLOR=#ff0000][I][B]dxgmms1!VIDMM_GLOBAL::BeginCPUAccess+0x16d[/B][/I][/COLOR]

^^ dxgmss1.sys is the DirectX MMS, a component of DirectX. VIDMM_GLOBAL::BeginCPUAccess - ??? Very hard to tell what's going on as I cannot find proper documentation, and it's a very uninformative stack. If maybe after the 'BeginCPUAccess' call we had an 'xWaitOnDMAReferences', then I could say we may have a DMA allocation problem, but we have a blank stack so there's very little information to get.

7: kd> !irql
Debugger saved IRQL for processor 0x7 -- 0 (LOW_LEVEL)

This seemed to occur at LOW_LEVEL.

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

This is the general bug check code for fatal errors found by Driver Verifier.

Despite the name of the bug check, Driver Verifier failed to detect a driver within violation.

BugCheck C4, {f6, 2dc, fffffa8014cdd940, fffff880056ee132}

The 1st parameter of the bug check is f6 which indicates the user handle was KernelMode. Aside from kernal-mode drivers, file system drivers, etc... Kernel Mode contains the HAL (Hardware Abstraction Layer) > Hardware. The HAL's main function is to hide differences in hardware from most of the operating system kernel, so that most of the kernel-mode code does not need to be changed to run on systems with different hardware. With this occurring at LOW_LEVEL, Kernel Mode, etc, this looks like a hardware issue.

First off, ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

-------------------

Start with a Memtest for NO LESS than ~8 passes (several hours):

Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

Which should I download?

You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

How Memtest works:

Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

This information, if available to the program, can be displayed via a menu option.

Any other questions, they can most likely be answered by reading this great guide here:

FAQ : please read before posting

-------------------

If Memtest goes through all ~8 passes with no errors, if you have access to integrated video OR a 2nd GPU... uninstall your video card drivers, shut down and remove your GPU physically (install 2nd GPU if that's your method), turn system on and install latest drivers for either 2nd GPU or integrated video.

Regards,

Patrick

I havent had time to do the memtest but I did switch out my GPU. I got another BSOD not too long ago. Heres the updated .rar file.

x BlueRobot · Jan 21, 2014

Code:

[COLOR=#ff0000]BugCheck 1A[/COLOR], {[COLOR=#0000cd]3451[/COLOR], fffff6e8001c4160, ffffe0000a11f040, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+3f820 )

The bugcheck indicates that the PTEs (Page Table Entries) for a Kernel Stack which was paged out, have become corrupt.

Code:

2: kd> [COLOR=#008000]knL[/COLOR]
 # Child-SP          RetAddr           Call Site
00 ffffd000`213e29c8 fffff801`675af9c0 nt!KeBugCheckEx
01 ffffd000`213e29d0 fffff801`67544c5b nt! ?? ::FNODOBFM::`string'+0x3f820
02 ffffd000`213e2ba0 fffff801`6749f2e4 [COLOR=#ff0000]nt!KeSwapProcessOrStack+0xb3[/COLOR] <-- Performs Stack Swap
03 ffffd000`213e2c00 fffff801`675662c6 nt!PspSystemThreadStartup+0x58
04 ffffd000`213e2c60 00000000`00000000 nt!KiStartSystemThread+0x16

From my blog post - BSODTutorials: Kernel Stacks, User Stacks, DPC Stacks and Interrupt Stacks

Kernel Stacks

The Kernel Stack is used to store kernel-mode related information, and can only be accessed if given the privilege by the kernel, otherwise this is a protected data structure. A kernel stack is usually much smaller size, with about 12KB for the stack and 16KB if you count the size of the Guard Page, since it's excepted to have much less recursive function calls (which can cause stack overflows) and better management of local variables. Again, kernel stacks are allocated from virtual memory, and although quite uncommon can be paged out onto the disk. The stacks which are paged out, tend to be inactive stacks.

Kernel Stacks can also grow and shrink in size unlike User Stacks due to a size limitation. Another oddity with kernel stacks, is that they can move in both directions essentially. When data has been removed from the stack, then the stack moves upwards, and when data is added to the stack, the stack is able to move downwards in memory.

Please follow the other suggestions made by Patrick.

Code:

2: kd> [COLOR=#008000]u nt!KeSwapProcessOrStack+0xb3[/COLOR]
nt!KeSwapProcessOrStack+0xb3:
fffff801`67544c5b 488d542430      lea     rdx,[rsp+30h]
fffff801`67544c60 4533c0          xor     r8d,r8d
fffff801`67544c63 488bcf          mov     rcx,rdi
fffff801`67544c66 e8e967f8ff      call    [COLOR=#ff0000]nt!KeGetNextKernelStackSegment[/COLOR] (fffff801`674cb454)
fffff801`67544c6b 84c0            test    al,al
fffff801`67544c6d 75df            jne     [COLOR=#ff0000]nt!KeSwapProcessOrStack+0xa6[/COLOR] (fffff801`67544c4e)
fffff801`67544c6f 834f7401        or      dword ptr [rdi+74h],1
fffff801`67544c73 488bcf          mov     rcx,rdi

JohnAbyss · Jan 26, 2014

x BlueRobot said:
Code:

[COLOR=#ff0000]BugCheck 1A[/COLOR], {[COLOR=#0000cd]3451[/COLOR], fffff6e8001c4160, ffffe0000a11f040, 0} Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+3f820 )

The bugcheck indicates that the PTEs (Page Table Entries) for a Kernel Stack which was paged out, have become corrupt.

Code:

2: kd> [COLOR=#008000]knL[/COLOR] # Child-SP RetAddr Call Site 00 ffffd000`213e29c8 fffff801`675af9c0 nt!KeBugCheckEx 01 ffffd000`213e29d0 fffff801`67544c5b nt! ?? ::FNODOBFM::`string'+0x3f820 02 ffffd000`213e2ba0 fffff801`6749f2e4 [COLOR=#ff0000]nt!KeSwapProcessOrStack+0xb3[/COLOR] <-- Performs Stack Swap 03 ffffd000`213e2c00 fffff801`675662c6 nt!PspSystemThreadStartup+0x58 04 ffffd000`213e2c60 00000000`00000000 nt!KiStartSystemThread+0x16

From my blog post - BSODTutorials: Kernel Stacks, User Stacks, DPC Stacks and Interrupt Stacks

Kernel Stacks

The Kernel Stack is used to store kernel-mode related information, and can only be accessed if given the privilege by the kernel, otherwise this is a protected data structure. A kernel stack is usually much smaller size, with about 12KB for the stack and 16KB if you count the size of the Guard Page, since it's excepted to have much less recursive function calls (which can cause stack overflows) and better management of local variables. Again, kernel stacks are allocated from virtual memory, and although quite uncommon can be paged out onto the disk. The stacks which are paged out, tend to be inactive stacks.

Kernel Stacks can also grow and shrink in size unlike User Stacks due to a size limitation. Another oddity with kernel stacks, is that they can move in both directions essentially. When data has been removed from the stack, then the stack moves upwards, and when data is added to the stack, the stack is able to move downwards in memory.

Click to expand...

Please follow the other suggestions made by Patrick.

Code:

2: kd> [COLOR=#008000]u nt!KeSwapProcessOrStack+0xb3[/COLOR] nt!KeSwapProcessOrStack+0xb3: fffff801`67544c5b 488d542430 lea rdx,[rsp+30h] fffff801`67544c60 4533c0 xor r8d,r8d fffff801`67544c63 488bcf mov rcx,rdi fffff801`67544c66 e8e967f8ff call [COLOR=#ff0000]nt!KeGetNextKernelStackSegment[/COLOR] (fffff801`674cb454) fffff801`67544c6b 84c0 test al,al fffff801`67544c6d 75df jne [COLOR=#ff0000]nt!KeSwapProcessOrStack+0xa6[/COLOR] (fffff801`67544c4e) fffff801`67544c6f 834f7401 or dword ptr [rdi+74h],1 fffff801`67544c73 488bcf mov rcx,rdi

Okay, here is an update.

Ive run memtest and it found an error with ONE of me Ram sticks. So I took it out and only left two in my system that passed Memtest 15+ times with ZERO errors. I thought that was it. Didnt get a BSOD for about 12 hours. Then BAM. Got one. I dont know what else to do. Ive replaced my GPU, Run memtest, and everything. I had Driver Verifier enabled for the past few BSODs before you ask. Here is the dump file.

x BlueRobot · Jan 27, 2014

Code:

[COLOR=#ff0000]BugCheck C4[/COLOR], {[COLOR=#0000cd]f6[/COLOR], [COLOR=#008000]234[/COLOR], ffffcf80283c6900, fffff80358db65d5}

Probably caused by : [COLOR=#ff0000]nvlddmkm.sys[/COLOR] ( nvlddmkm+9b0a1 )

Code:

3: kd> [COLOR=#008000]lmvm nvlddmkm[/COLOR]
start             end                 module name
fffff800`01ef8000 fffff800`02b41000   nvlddmkm T (no symbols)           
    Loaded symbol image file: nvlddmkm.sys
    Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
    Image name: nvlddmkm.sys
    Timestamp:        [COLOR=#ff0000]Thu Dec 19 17:02:52 2013[/COLOR] (52B326BC)
    CheckSum:         00C19112
    ImageSize:        00C49000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

This is a common problem with the nVidia drivers, have you tried booting into Safe Mode and seeing how stable your system remains?

Code:

3: kd> [COLOR=#008000]knL[/COLOR]
 # Child-SP          RetAddr           Call Site
00 ffffd000`23b0c648 fffff803`590786a8 nt!KeBugCheckEx
01 ffffd000`23b0c650 fffff803`5907df98 nt!VerifierBugCheckIfAppropriate+0x3c
02 ffffd000`23b0c690 fffff803`58f45e73 [COLOR=#ff0000]nt!VfCheckUserHandle[/COLOR]+0x1b8
03 ffffd000`23b0c770 fffff803`58db65d5 nt! ?? ::NNGAKEGL::`string'+0x10503
04 ffffd000`23b0c810 fffff803`58dce2d6 [COLOR=#ff0000]nt!ObReferenceObjectByHandle[/COLOR]+0x25
05 ffffd000`23b0c860 fffff803`58b654b3 [COLOR=#ff0000]nt!NtQueryValueKey[/COLOR]+0x136
06 ffffd000`23b0cb10 fffff803`58b5d900 nt!KiSystemServiceCopyEnd+0x13
07 ffffd000`23b0cd18 fffff800`01f930a1 nt!KiServiceLinkage
08 ffffd000`23b0cd20 00000000`00000000 nvlddmkm+0x9b0a1

Frequent BSOD Problems.

JohnAbyss

New member

Attachments

Patrick

Sysnative Staff

JohnAbyss

New member

Attachments

x BlueRobot

Administrator

JohnAbyss

New member

x BlueRobot

Administrator