Hi, welcome to Sysnative. Glad to here you were referred here, so thanks to kemical!
Right, so let's get to work. We have two DMP files, two bug checks:
BAD_POOL_HEADER (19)
This indicates that a pool header is corrupt.
BugCheck 19, {20,
ffffe00005050eb0, ffffe00005051080, 41d0002}
Let's run !poolval on the 2nd parameter of the bug check (the pool entry we were looking for within the page).
Code:
4: kd> !poolval ffffe00005050eb0
Pool page ffffe00005050eb0 region is Unknown
Validating Pool headers for pool page: ffffe00005050eb0
Pool page [ ffffe00005050000 ] is __inVALID.
Analyzing linked list...
[ ffffe00005050eb0 ]: invalid block size [ 0x1d ] should be [ 0xd ]
Scanning for single bit errors...
None found
If we then take a look at the 3rd parameter:
Code:
4: kd> dt nt!_POOL_HEADER ffffe00005051080
+0x000 PreviousSize : 0y00000000 (0)
+0x000 PoolIndex : 0y00000000 (0)
+0x002 BlockSize : 0y00000000 (0)
+0x002 PoolType : 0y00000000 (0)
+0x000 Ulong1 : 0
+0x004 PoolTag : 0
+0x008 ProcessBilled : (null)
+0x008 AllocatorBackTraceIndex : 0
+0x00a PoolTagHash : 0
The POOL_HEADER data structure for the next data entry (3rd parameter) is empty, therefore the structure is corrupt.
REFERENCE_BY_POINTER (18)
This indicates that the reference count of an object is illegal for the current state of the object.
The reference count of an object is illegal for the current state of the object. Each time a driver uses a pointer to an object, the driver calls a kernel routine to increase the reference count of the object by one. When the driver is done with the pointer, the driver calls another kernel routine to decrease the reference count by one. Drivers must match calls to the routines that increase (
reference) and decrease (
dereference) the reference count. This bug check is caused by an inconsistency in the object's reference count.
Typically, the inconsistency is caused by a driver that decreases the reference count of an object too many times, making extra calls that dereference the object. This bug check can occur because an object's reference count goes to zero while there are still open handles to the object. It might also occur when the object's reference count drops below zero, whether or not there are open handles to the object.
Unfortunately, we'd need a Kernel dump to dive into this bug check for more info as most of the extensions we need to use aren't available due to the lack of information retained at the time of the crash in a Minidump.
As of right now, with all of this said, it can either be a device driver causing memory corruption or a hardware issue (usually RAM / HDD in the case of *18 and *19).
------------------
1. Remove and replace avast! with Windows 8's built-in Windows Defender for temporary troubleshooting purposes:
avast! removal - avast! Uninstall Utility | Download aswClear for avast! Removal
Windows Defender (how to turn on after removal) - Windows Defender - Turn On or Off in Windows 8
2. If you're still crashing after #1, please do the following:
A) Let's start generating Kernel dumps as opposed to Minidumps. I don't know how to get to System on Windows 8 (Windows Key + X, I think ????), but in any case you're going to want to navigate to System. Once in System, click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > change from Small Memory Dump > Kernel. Apply and hit OK.
Once that's done, your system will now generate Kernel dumps. Note that they will be too large to attach here, so please instead host them on Skydrive, Mediafire, etc. Any simple 3rd party where we can get to them.
B) Enable Driver Verifier:
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 > 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.
If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:
- 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.
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
