Hi,
The attached DMP file is of the
SYSTEM_SERVICE_EXCEPTION (3b) bug check.
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:
1: kd> .trap fffff880`088878f0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8006bcfa60 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000040002200 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002c885fe rsp=fffff88008887a80 rbp=0000000000000000
r8=ffffffffb1121700 r9=0000000000000040 r10=00000000034af9a0
r11=fffff88008887b08 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
nt!ExEnterCriticalRegionAndAcquireFastMutexUnsafe+0x26:
Code:
1: kd> knL
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 fffff880`08887a80 fffff960`006d6d3f nt!ExEnterCriticalRegionAndAcquireFastMutexUnsafe+0x26
01 fffff880`08887ab0 fffff960`001dd365 cdd!DrvAssociateSharedSurface+0x7b
02 fffff880`08887b10 fffff960`00200749 win32k!GreSetRedirectionSurfaceSignaling+0x125
03 fffff880`08887b60 fffff800`02cbdad3 win32k!NtGdiHLSurfSetInformation+0x209
04 fffff880`08887be0 000007fe`ff6d4efa nt!KiSystemServiceCopyEnd+0x13
05 00000000`034af978 00000000`00000000 0x7fe`ff6d4efa
^^ We have a cdd.dll routine (Canonical Display driver) called into
ExEnterCriticalRegionAndAcquireFastMutexUnsafe. This puts the caller into a wait state if the specified fast mutex cannot be acquired immediately. Otherwise, the caller is given ownership of the mutex and exclusive access to the resource that the mutex protects until the caller releases the mutex.
Essentially, drivers can use fast mutexes if they require a low-overhead form of mutual exclusion for code that runs at IRQL <= APC_LEVEL. A fast mutex can protect a code path that must be entered by only one thread at a time. To enter the protected code path, the thread acquires the mutex. If another thread has already acquired the mutex, execution of the current thread is suspended until the mutex is released. To exit the protected code path, the thread releases the mutex.
What appears to have happened here is the mutex was never acquired, therefore the system bugchecked.
1. Update to Service Pack 1 ASAP:
Learn how to install Windows 7 Service Pack 1 (SP1)
2. Remove and replace avast! with Microsoft Security Essentials for temporary troubleshooting purposes:
avast! removal - avast! Uninstall Utility | Download aswClear for avast! Removal
MSE - Microsoft Security Essentials - Microsoft Windows
3. Uninstall SmartDefrag.
4. 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.
5. If
all of the above fail to stop the crashes, please run 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).
Do note that some older generation motherboards do not support USB-based booting, therefore your only option is CD (or Floppy if you really wanted to).
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
Regards,
Patrick
