Random BSOD showing "Caused By Driver : ntoskrnl.exe"

Hi,

All of the attached DMP files are of the KMODE_EXCEPTION_NOT_HANDLED (1e) bug check.

This indicates that a kernel-mode program generated an exception which the error handler did not catch.

BugCheck 1E, {ffffffffc0000005, fffff80002d8acda, 1, 18}

Every single one of them was caused by an access violation. What caused this access violation was the function - ObpCreateHandle.

Windows' security model requires that a thread specifies up front, at the time that it opens an object, what type of actions it wants to perform on the object. The object manager calls the SRM (Windows File System Agent) to perform access checks based on a thread's desired access, and if the access is granted, a handle is assigned to the thread's process with which the thread (or other threads in the process) can perform further operations on the object. The object manager records the access permissions granted for a handle in the process's handle table.

One event that causes the object manager to perform security access validation is when a process opens an existing object using a name. When an object is opened by name, the object manager performs a lookup of the specified object in the object manager namespace. If the object isn't located in a secondary namespace, such as the configuration manager's registry namespace or a file system driver's file system, namespace, the object manager calls the internal function ObpCreateHandle once it locates the object. As its name implies, ObpCreateHandle creates an entry in the process's handle table that becomes associated with the object. ObpCreateHandle first calls ObpIncrementHandleCount to see if the thread has permission to access the object, and if the thread does, ObpCreateHandle calls the executive function ExCreateHandle to create the entry in the process handle table. ObpIncrementHandleCount calls ObCheckObjectAccess to carry out the security access check.

If we take a look at the call stack (which is the same throughout each dump):

STACK_TEXT: 
fffff880`02748658 fffff800`02ad97e8 : 00000000`0000001e ffffffff`c0000005 fffff800`02d8acda 00000000`00000001 : nt!KeBugCheckEx
fffff880`02748660 fffff800`02a8e2c2 : fffff880`02748e38 00000000`00000000 fffff880`02748ee0 fffffa80`0633c930 : nt! ?? ::FNODOBFM::`string'+0x487ed
fffff880`02748d00 fffff800`02a8ce3a : 00000000`00000001 00000000`00000018 fffffa80`03d30b00 00000000`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`02748ee0 fffff800`02d8acda : 00000000`00000000 fffff880`027490c0 fffffa80`07969730 fffff8a0`08f6ed80 : nt!KiPageFault+0x23a
fffff880`02749070 fffff800`02d7c46e : fffffa80`00000000 fffff8a0`08f6ed80 fffff8a0`000f001f 00000000`00000000 : nt!ObpCreateHandle+0x29a
fffff880`02749180 fffff800`02d6cb8b : fffffa80`0497f070 fffff880`02749540 fffffa80`08638260 00000000`08000000 : nt!ObInsertObjectEx+0xde
fffff880`027493d0 fffff800`02a8ded3 : fffffa80`0633c930 fffff880`02749678 fffff880`02749468 fffffa80`060c7350 : nt!NtCreateSection+0x1fe
fffff880`02749450 fffff800`02a8a490 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
fffff880`02749658 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiServiceLinkage

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

We can see an NtCreateSection call which creates a section object which is an object that represents a section of memory that can be shared. We then see a ObInsertObjectEx call which is reserved for system use. We then after see a ObpCreateHandle as I explained above. From this, we can see that there was no ObpIncrementHandleCount call to see if the thread had permission to access the object. With this said, ExCreateHandle was never called to create the entry in the process handle table, and ultimately the security access check was never carried out.

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

What does all of this mean overall? Well, it can mean few things, but from a quick first glance and analysis, it appears that you are still possibly infected with some sort of malware. To be sure we aren't however dealing with any other device driver corruption and or conflicts, let's go ahead and 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 - http://www.eightforums.com/tutorials/4690-restore-point-create-windows-8-a.html

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 [B]NOT[/B] 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:
http://support.microsoft.com/kb/244617

Regards,

Patrick