Okay, this isn't actuallly as helpful as I thought.
Code:
WARNING: Process directory table base 1972D000 doesn't match CR3 00185000
WARNING: Process directory table base 1972D000 doesn't match CR3 00185000
We'll get back to this error message soon.
Code:
BugCheck 7F, {d, 0, 0, 0}
So all we have is a double fault bugcheck with null parameters except the first parameter which is d, this means an exception was initiated which isn't covered by other exceptions; a protection fault which is related to access violations for applications.
This sort of makes sense and I'll explain why soon.
Code:
80ee6b38 82cab5ae badb0d00 889b3d40 00000000 nt!KiSystemFatalException+0xf
80ee6ba8 82cb8c2b 889b3d40 853689e8 889b3d40 nt!KiSwapProcess+0x7a
80ee6bc4 82cbdc3f 00000010 801c7000 85417a50 nt!KiAttachProcess+0xd1
80ee6bf4 82cbdab9 889b3d40 854178e0 82db7900 nt!KeForceAttachProcess+0x136
80ee6c08 82cbda0c 889b3f30 80ee6c74 82d967e0 nt!MiForceAttachProcess+0xd
80ee6c1c 82cb3e09 889b3f30 00000000 80ee6c74 nt!MiAttachAndLockWorkingSet+0x9f
80ee6c5c 82cb3c03 00000002 00000001 00000000 nt!MiProcessWorkingSets+0x126
80ee6c88 82cb43cb 00000000 854178e0 00000000 nt!MmWorkingSetManager+0xa4
80ee6d50 82e3e53e 00000000 ada1b269 00000000 nt!KeBalanceSetManager+0x1af
80ee6d90 82cdf899 82cb421c 00000000 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
So, looking in the callstack we see the Memory Manager working with pages on the working set, locking them in then attaching processes.
Then we get a KiSwapProcess which is a context switch meaning Windows has saved the state of the current executing thread then performs and interrupt or exception, the fact that an exception occurred during the context switch is never good.
So going back to our first message we see the process directory table base doesn't match the contents stored in the 3rd control register, this allows the process to be saved within the control register for when a context switch occurs so it can resume execution later.
Code:
0: kd> r @cr3
cr3=00185000
However, the control register doesn't match the process directory table base so that usually means the exception occurred during the context switch as it didn't save the current process.
So apart from that there isn't much else that gives us a hint at the cause.
Then there's always the anti virus to consider, although I don't like going down the road of removing as many programs as possible.
Let's try Driver Verifier.
What is Driver Verifier?
Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior.
Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem.
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"
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/8.1)
- DDI compliance checking (Windows 8/8.1)
- 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. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled per my instructions above, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.
- 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 detect it in violation almost straight away, 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.
-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1
How long should I keep Driver Verifier enabled for?
I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.
My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?
- If you have the system set to generate Small Memory Dumps, they will be located in
%systemroot%\Minidump.
- If you have the system set to generate Kernel-Memory Dumps, it will be located in
%systemroot% and labeled MEMORY.DMP.
