BSOD on SBS 2008

At 11:32 today EMSX 4.2.10020.0 auto-installed virus defs v6195. Since then ekrn.exe has been using 25% CPU constantly. At 13:02, SBS crashed with a BSOD. Here's the MEMORY.DMP results:

Code:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80001b3ae8e, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception

Debugging Details:
------------------

PEB is paged out (Peb.Ldr = 00000000`7efdf018).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018).  Type ".hh dbgerr001" for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
nt!PspGetSetContextInternal+396
fffff800`01b3ae8e 488b28          mov     rbp,qword ptr [rax]

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  ffffffffffffffff

READ_ADDRESS:  ffffffffffffffff 

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x1E

PROCESS_NAME:  ekrn.exe

CURRENT_IRQL:  1

LAST_CONTROL_TRANSFER:  from fffff80001893ac7 to fffff800018b1490

STACK_TEXT:  
fffffa60`057d85d8 fffff800`01893ac7 : 00000000`0000001e ffffffff`c0000005 fffff800`01b3ae8e 00000000`00000000 : nt!KeBugCheckEx
fffffa60`057d85e0 fffff800`018b12e9 : fffffa60`057d8d18 fffffa60`0990c570 fffffa60`057d8dc0 fffffa60`0990cac8 : nt! ?? ::FNODOBFM::`string'+0x29117
fffffa60`057d8be0 fffffa60`057d8d18 : fffffa60`0990c570 fffffa60`057d8dc0 fffffa60`0990cac8 fffff880`10d91101 : nt!KiExceptionDispatch+0xa9
fffffa60`057d8be8 fffffa60`0990c570 : fffffa60`057d8dc0 fffffa60`0990cac8 fffff880`10d91101 fffff800`0198baa5 : 0xfffffa60`057d8d18
fffffa60`057d8bf0 fffffa60`057d8dc0 : fffffa60`0990cac8 fffff880`10d91101 fffff800`0198baa5 00640062`00390030 : 0xfffffa60`0990c570
fffffa60`057d8bf8 fffffa60`0990cac8 : fffff880`10d91101 fffff800`0198baa5 00640062`00390030 00790053`005c0035 : 0xfffffa60`057d8dc0
fffffa60`057d8c00 fffff880`10d91101 : fffff800`0198baa5 00640062`00390030 00790053`005c0035 006d0065`00740073 : 0xfffffa60`0990cac8
fffffa60`057d8c08 fffff800`0198baa5 : 00640062`00390030 00790053`005c0035 006d0065`00740073 00720069`0044002e : 0xfffff880`10d91101
fffffa60`057d8c10 00640062`00390030 : 00790053`005c0035 006d0065`00740073 00720069`0044002e 00000000`00000000 : nt!ExFreePoolWithTag+0x2a5
fffffa60`057d8c18 00790053`005c0035 : 006d0065`00740073 00720069`0044002e 00000000`00000000 00000000`00000000 : 0x640062`00390030
fffffa60`057d8c20 006d0065`00740073 : 00720069`0044002e 00000000`00000000 00000000`00000000 00000000`00000000 : 0x790053`005c0035
fffffa60`057d8c28 00720069`0044002e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x6d0065`00740073
fffffa60`057d8c30 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x720069`0044002e


STACK_COMMAND:  .bugcheck ; kb

FOLLOWUP_IP: 
nt!PspGetSetContextInternal+396
fffff800`01b3ae8e 488b28          mov     rbp,qword ptr [rax]

SYMBOL_NAME:  nt!PspGetSetContextInternal+396

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4cb7275f

FAILURE_BUCKET_ID:  X64_0x1E_nt!PspGetSetContextInternal+396

BUCKET_ID:  X64_0x1E_nt!PspGetSetContextInternal+396

Followup: MachineOwner
---------

Has this been caused by dodgy definitions again or is something else to blame?

 

I'd upgrade EMSX to the latest 4.3 build and disable the "Protocol Filtering" completely to see if the issues stil persist.

 

I upgraded to 4.3 at the weekend but it blue screened again in the early hours of the morning.

I'll try disabling Protocol Filtering and see what happens. Thanks man!

 

It does this.

It is caused by either the anti-stealth or the self-defense module. Don't bother contacting their support. They will waste hours of your life and make you want to switch vendors. They are completely useless.

Disable the anti-stealth and self-defense and it will fix it.

 

This is actually a known issue where the Microsoft WFP platform conflicts with the ESET nNetwork driver. Version 4.3 of all server products have an option (that is enabled by default) to NOT load that driver, rendering HTTP and POP3 checking non-functional (Which you wouldn't really need on a server anyway.

 

This is not related to the WFP issue. I already went through all that. It happens even with the WFP driver disabled.

 

Do you have Anti-Stealth disabled?

 

I do now... This definitely is related to the anti-stealth or self defense kernel mode driver. We have had this issue on several servers with this OS (SBS2008 with SP2). AFAIK, the driver causes invalid thread contexts to be returned during APC delivery (APCs run in the security context of the calling thread) and it causes the system to crash. This occurs even with the epfwwfpr.sys driver disabled/renamed per SOLN2567 and the related Microsoft hotfix installed.

There is no trap frame in the debugger output and maybe the symbols are missing, but I am sure a full debug will look exactly the same as what I have been seeing. Anyone who bothers contacting ESET about this will seriously regret wasting their time. Just disable these modules.

 

I was not talking about your issue, i was talking about the topicstarter's issue. If you are experiencing different issue I suggest making a new thread about this.

 

Well, considering you quoted my post, you can see why I would think you are talking to me. Regardless, he can try that WPF fix, but it won't work. My fix will work.

 

I did not quote anyone . I merely stated that there is a known issue with 2008 systems and 4.2 versions of EMSX. But considering there hasn't been a response since the 13th, i'm assuming it works without crashes at the moment.