Hi,
We have various bug checks:
DRIVER_CORRUPTED_EXPOOL (c5)
This indicates that the system attempted to access invalid memory at a process IRQL that was too high.
If we take a look at the call stack:
Code:
STACK_TEXT:
6: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`061fb198 fffff800`0308e169 : 00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`061fb1a0 fffff800`0308cde0 : 00000000`00000000 00000000`000007ff fffffa80`197dcf40 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`061fb2e0 fffff800`031c3a9b : 00000000`00000001 00000000`000007ff fffff8a0`3f1b4010 fffffa80`0f332000 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`061fb2e0)
fffff880`061fb470 fffff800`031c24f1 : fffffa80`1c553000 fffffa80`192b0a50 00000000`00000000 fffffa80`1b575520 : nt!ExDeferredFreePool+0x1df
fffff880`061fb500 fffff880`0ff50ecc : 00000000`00000000 00000000`00000000 fffffa80`6d4d6956 00000000`00000174 : nt!ExFreePoolWithTag+0x411
fffff880`061fb5b0 fffff880`0fe92ccc : 00000000`00000000 fffff8a0`0ee12000 fffff8a0`0ee12000 00000000`00000001 : dxgmms1!VidMmCloseAllocation+0x44
fffff880`061fb5e0 fffff880`0fe9265f : fffff8a0`0ee12000 00000000`00000000 fffffa80`00000000 00000000`00000000 : dxgkrnl!DXGDEVICE::DestroyAllocations+0x248
fffff880`061fb6d0 fffff880`0fe92a03 : fffff8a0`0ee12000 fffff8a0`0ee12000 00000000`00000001 00000000`00000000 : dxgkrnl!DXGDEVICE::ProcessTerminationList+0xa3
fffff880`061fb720 fffff880`0fe96aec : 00000000`00000000 fffff880`061fbb60 fffff8a0`3d30fb80 fffff880`0fe5d3af : dxgkrnl!DXGDEVICE::TerminateAllocations+0x1db
fffff880`061fb770 fffff880`0fe99285 : fffff8a0`0ee12000 fffff880`061fb850 00000000`4b677800 00000000`00000701 : dxgkrnl!DXGDEVICE::DestroyAllocation+0x44c
fffff880`061fb800 fffff960`0019144a : 00000000`ffea8000 fffffa80`1c313b50 00000000`00000020 00000000`733c6168 : dxgkrnl!DxgkDestroyAllocation+0xa9d
fffff880`061fbab0 fffff800`0308de53 : fffffa80`1c313b50 00000000`00000494 fffff880`061fbab8 fffffa80`199d9f50 : win32k!NtGdiDdDDIDestroyAllocation+0x12
fffff880`061fbae0 00000000`733e141a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`061fbae0)
00000000`0c3be2d8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x733e141a
We can see various Direct X Kernel routine calls. If we run a !poolval on the 4th parameter of the bug check which is the address which referenced memory, we get:
Code:
6: kd> !poolval fffff800031c3a9b
Pool page fffff800031c3a9b region is Unknown
Validating Pool headers for pool page: fffff800031c3a9b
Pool page [ fffff800031c3000 ] is __inVALID.
Analyzing linked list...
[ fffff800031c3000 ]: invalid previous size [ 0x48 ] should be [ 0x0 ]
[ fffff800031c3000 --> fffff800031c3400 (size = 0x400 bytes)]: Corrupt region
BAD_POOL_HEADER (19)
This indicates that a pool header is corrupt.
If we take a look at the call stack here:
Code:
5: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`0234b3b8 fffff800`031f8cae : 00000000`00000019 00000000`00000020 fffff8a0`106821d0 fffff8a0`106821f0 : nt!KeBugCheckEx
fffff880`0234b3c0 fffff880`0fd3a06f : fffff8a0`0d62c9d0 00000000`00000000 fffff8a0`6d4d6956 00000000`00000174 : nt!ExDeferredFreePool+0x12da
fffff880`0234b470 fffff880`0fd4c8b8 : 00000000`00000001 00000000`00000000 00000000`00000000 fffff8a0`00000799 : dxgkrnl!DXGDEVICE::DestroyAllocations+0x5eb
fffff880`0234b560 fffff880`0fd31815 : 00000000`fffffeda fffff8a0`0b717160 fffff8a0`0c213000 fffffa80`0f327000 : dxgkrnl!DXGDEVICE::~DXGDEVICE+0x19c
fffff880`0234b5d0 fffff880`0fd6fffa : 00000000`00000001 fffffa80`0f327000 fffff8a0`0b717160 fffff8a0`0b7171e0 : dxgkrnl!DXGADAPTER::DestroyDevice+0x1c9
fffff880`0234b600 fffff880`0fd6f990 : fffff900`c3b8c010 00000000`00000000 00000000`00000001 fffff900`c3b8c010 : dxgkrnl!DXGPROCESS::Destroy+0xba
fffff880`0234b6b0 fffff960`00186e24 : 00000000`000018e0 fffff900`c3b8c010 00000000`00000000 fffff900`c3b8c010 : dxgkrnl!DxgkProcessCallout+0x268
fffff880`0234b740 fffff960`00186527 : 00000000`00000000 fffff880`0234bae0 fffffa80`12a3e060 00000000`00000000 : win32k!GdiProcessCallout+0x244
fffff880`0234b7c0 fffff800`0339a0c1 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`12a3e000 : win32k!W32pProcessCallout+0x6b
fffff880`0234b7f0 fffff800`033802ed : 00000000`00000000 00000000`00000001 fffffa80`78457300 fffffa80`12ae7b50 : nt!PspExitThread+0x4d1
fffff880`0234b8f0 fffff800`030b86fa : 00000000`00000100 fffffa80`12a3e120 00000000`00000001 fffff800`030bb7fd : nt!PsExitSpecialApc+0x1d
fffff880`0234b920 fffff800`030b8a40 : 00000000`00000246 fffff880`0234b9a0 fffff800`03380260 00000000`00000001 : nt!KiDeliverApc+0x2ca
fffff880`0234b9a0 fffff800`030c4ef7 : fffffa80`12a3e060 00000000`000006a0 00000000`00000000 fffffa80`0e579c30 : nt!KiInitiateUserApc+0x70
fffff880`0234bae0 00000000`73b02e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExit+0x9c (TrapFrame @ fffff880`0234bae0)
00000000`196cead8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x73b02e09
Again, more Direct X Kernel routines.
PFN_LIST_CORRUPT (4e)
This indicates that the page frame number (PFN) list is corrupted.
If we take a look at the call stack:
Code:
0: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`0a8d24f8 fffff800`03152a4c : 00000000`0000004e 00000000`00000099 00000000`0026ff34 00000000`00000002 : nt!KeBugCheckEx
fffff880`0a8d2500 fffff800`0306fbc7 : 00000000`0003f92c fffff680`007f6e78 a5900002`6f733025 00000000`00000002 : nt!MiBadShareCount+0x4c
fffff880`0a8d2540 fffff800`030f4e27 : 00000000`00000000 fffff680`007f6ff8 fffffa80`10f02060 a1600002`6ec63025 : nt! ?? ::FNODOBFM::`string'+0x320fd
fffff880`0a8d26f0 fffff800`030f67d9 : 00000000`00000000 00000000`fef11fff fffffa80`00000000 00000000`00000000 : nt!MiDeleteVirtualAddresses+0x41f
fffff880`0a8d28b0 fffff800`033dc631 : fffffa80`0d138010 00000000`00000000 fffffa80`0f470f90 fffffa80`0f470f90 : nt!MiRemoveMappedView+0xd9
fffff880`0a8d29d0 fffff800`033dca33 : 00000000`00000000 00000000`feb30000 fffffa80`00000001 fffff800`033b9c01 : nt!MiUnmapViewOfSection+0x1b1
fffff880`0a8d2a90 fffff800`030c2e53 : fffffa80`11052060 00000000`00000464 fffffa80`10f02060 fffffa80`0e889f40 : nt!NtUnmapViewOfSection+0x5f
fffff880`0a8d2ae0 00000000`775e155a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0a8d2ae0)
00000000`0022deb8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x775e155a
We have a lot of virtual memory routine calls here.
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.
The stack is pretty straightforward...
Code:
STACK_TEXT:
fffff880`08f71450 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : atikmpag+0xcf8b
All we have is an ATI/AMD video driver call, other than that it's a blank stack.
KMODE_EXCEPTION_NOT_HANDLED (1e)
This indicates that a kernel-mode program generated an exception which the error handler did not catch.
If we take a look at the call stack:
Code:
1: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`06d75a28 fffff800`03128748 : 00000000`0000001e ffffffff`c0000005 fffff880`0fdafec0 00000000`00000001 : nt!KeBugCheckEx
fffff880`06d75a30 fffff800`030dd202 : fffff880`06d76208 fffff8a0`11580980 fffff880`06d762b0 fffffa80`0f5e8000 : nt! ?? ::FNODOBFM::`string'+0x487ed
fffff880`06d760d0 fffff800`030dbd7a : 00000000`00000001 00000000`00000087 00000000`00000000 fffff8a0`11580980 : nt!KiExceptionDispatch+0xc2
fffff880`06d762b0 fffff880`0fdafec0 : 00000000`00000000 fffffa80`00000000 00000000`6d4d6956 00000000`00000174 : nt!KiPageFault+0x23a (TrapFrame @ fffff880`06d762b0)
fffff880`06d76440 fffff880`0fcf1ccc : 00000000`00000000 fffff8a0`10d91000 fffff8a0`10d91000 00000000`00000001 : dxgmms1!VidMmCloseAllocation+0x38
fffff880`06d76470 fffff880`0fd048b8 : 00000000`00000001 00000000`00000000 00000000`00000000 fffff8a0`00000799 : dxgkrnl!DXGDEVICE::DestroyAllocations+0x248
fffff880`06d76560 fffff880`0fce9815 : 00000000`fffffeda fffff8a0`040d6580 fffff8a0`10d91000 fffffa80`0f5c8000 : dxgkrnl!DXGDEVICE::~DXGDEVICE+0x19c
fffff880`06d765d0 fffff880`0fd27ffa : 00000000`00000001 fffffa80`0f5c8000 fffff8a0`040d6580 fffff8a0`040d6600 : dxgkrnl!DXGADAPTER::DestroyDevice+0x1c9
fffff880`06d76600 fffff880`0fd27990 : fffff900`c2784ae0 00000000`00000000 00000000`00000001 fffff900`c2784ae0 : dxgkrnl!DXGPROCESS::Destroy+0xba
fffff880`06d766b0 fffff960`000f6e24 : 00000000`000008a8 fffff900`c2784ae0 00000000`00000000 fffff900`c2784ae0 : dxgkrnl!DxgkProcessCallout+0x268
fffff880`06d76740 fffff960`000f6527 : 00000000`00000000 fffff880`06d76ae0 fffffa80`0fb0d060 00000000`00000000 : win32k!GdiProcessCallout+0x244
fffff880`06d767c0 fffff800`033b3991 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0fb0d000 : win32k!W32pProcessCallout+0x6b
fffff880`06d767f0 fffff800`03399b3d : 00000000`00000000 00000000`00000001 00000000`78457300 fffffa80`101c0b50 : nt!PspExitThread+0x4d1
fffff880`06d768f0 fffff800`030d06da : 00000000`00000000 fffff800`03026ae7 00000000`0013ea40 00000000`0013fd20 : nt!PsExitSpecialApc+0x1d
fffff880`06d76920 fffff800`030d0a20 : 00000000`00000246 fffff880`06d769a0 fffff800`03399ab0 00000000`00000001 : nt!KiDeliverApc+0x2ca
fffff880`06d769a0 fffff800`030d08bb : 00000000`00000246 00000000`00000000 fffff800`03399ab0 00000000`00000000 : nt!KiInitiateUserApc+0x70
fffff880`06d76ae0 00000000`73612e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiApcInterrupt+0x10b (TrapFrame @ fffff880`06d76ae0)
00000000`0013e9c8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x73612e09
Once again, various Direct X Kernel routines in addition to a Direct X MMS.
-----------------------------------------------------------------------
Overall, when I see a *4E bug check it breaks things down a bit for us, even though in your case this is pretty straightforward. Just looking at this now, it appears we're either dealing with a video card driver issue causing corruption, a 3rd party driver causing corruption (not as likely but still possible), or faulty RAM.
1. Remove your Asus PC Probe software (contains their buggy charger software, etc). It's just unnecessary buggy bloatware.
2. 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.
3. Remove and replace Norton with Microsoft Security Essentials for temporary troubleshooting purposes:
Norton removal tool - https://support.norton.com/sp/en/us/home/current/solutions/kb20080710133834EN_EndUserProfile_en_us;jsessionid=841A6D40BA6872C47697C6C6B19C8E11.4?entsrc=redirect_pubweb&pvid=f-home
MSE - Microsoft Security Essentials - Microsoft Windows
-----------------------------------------------------------------------
If you're still crashing after all of the above, please enable Driver Verifer:
Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 -
Restore Point - Create in Windows 8
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is
NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.
If this happens, do
not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:
- Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
How long should I keep Driver Verifier enabled for?
It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.
My system BSOD'd, where can I find the crash dumps?
They will be located in %systemroot%\Minidump
Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users
Regards,
Patrick