Intermitted BSOD with ESMX on SBS2008

I have an intermittent crash issue that I think is ESMX related. This only happens on SBS2008 systems. I updated to the latest version of ESMX and it does not resolve the issue. Disabling the filtering platform driver does not help. As you can see below, RAX is invalid on the trap frame. This is typical of the issue.

I can avoid the issue by turning off real time file protection and antistealth, but I would rather not do this. I currently have ESMX 4.3.10016.0, but this happens with other versions as well. As far as I can tell, this does not happen with 2.7 installed and does not happen on other operating systems including server 2003 and server 2008 r2. I tried contacting support but they were completely useless. This happens very infrequently (every few months), but I have a lot of servers so it is concerning.



3: kd> !analyze -v
*******************************************************************************
* *
* 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: fffff80002541e8e, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

Debugging 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`02541e8e 488b28 mov rbp,qword ptr [rax]

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002485080
0000000000000000

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR: 0x1E

PROCESS_NAME: BlackBerryAgent

CURRENT_IRQL: 1

TRAP_FRAME: fffffa600a3eec80 -- (.trap 0xfffffa600a3eec80)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002541e8e rsp=fffffa600a3eee10 rbp=0000000000000000
r8=0000000000000000 r9=000000000000000c r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!PspGetSetContextInternal+0x396:
fffff800`02541e8e 488b28 mov rbp,qword ptr [rax] ds:1010:00000000`00000000=?
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000229aac7 to fffff800022b8490

STACK_TEXT:
fffffa60`0a3ee498 fffff800`0229aac7 : 00000000`0000001e ffffffff`c0000005 fffff800`02541e8e 00000000`00000000 : nt!KeBugCheckEx
fffffa60`0a3ee4a0 fffff800`022b82e9 : fffffa60`0a3eebd8 fffffa60`0ab77570 fffffa60`0a3eec80 fffffa60`0ab77ac8 : nt! ?? ::FNODOBFM::`string'+0x29117
fffffa60`0a3eeaa0 fffff800`022b70e5 : 00000000`00000000 fffffa80`0c6b1734 00000000`00001f00 fffffa60`0ab77570 : nt!KiExceptionDispatch+0xa9
fffffa60`0a3eec80 fffff800`02541e8e : 00000000`00000000 fffffa60`0ab77570 fffffa60`00000000 fffffa60`0ab77ac8 : nt!KiPageFault+0x1e5
fffffa60`0a3eee10 fffff800`022e593d : 00000000`7ef49f80 fffffa80`0c764bb0 fffffa60`0ab77570 00000000`00000000 : nt!PspGetSetContextInternal+0x396
fffffa60`0a3ef360 fffff800`022d9bbe : fffffa80`0c764bb0 00000000`00000000 fffffa60`0a3ef670 fffffa60`0a3ef878 : nt!PspGetSetContextSpecialApc+0x9d
fffffa60`0a3ef470 fffff800`022dd613 : fffffa60`0a3ef590 00000000`00000000 00000000`00000000 fffffa80`0c764bb0 : nt!KiDeliverApc+0x19e
fffffa60`0a3ef510 fffffa60`03314b86 : fffffa60`0a3ef801 fffff880`0d417a90 00000000`000000ba 00000000`00000000 : nt!KiApcInterrupt+0x103
fffffa60`0a3ef6a0 fffffa60`0a3ef801 : fffff880`0d417a90 00000000`000000ba 00000000`00000000 fffff880`0cd08708 : ehdrv+0x17b86
fffffa60`0a3ef6a8 fffff880`0d417a90 : 00000000`000000ba 00000000`00000000 fffff880`0cd08708 fffff800`024def00 : 0xfffffa60`0a3ef801
fffffa60`0a3ef6b0 00000000`000000ba : 00000000`00000000 fffff880`0cd08708 fffff800`024def00 fffffa60`0a3ef768 : 0xfffff880`0d417a90
fffffa60`0a3ef6b8 00000000`00000000 : fffff880`0cd08708 fffff800`024def00 fffffa60`0a3ef768 fffffa80`0c9a7010 : 0xba


STACK_COMMAND: kb

FOLLOWUP_IP:
ehdrv+17b86
fffffa60`03314b86 ??

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: ehdrv+17b86

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ehdrv

IMAGE_NAME: ehdrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d006956

FAILURE_BUCKET_ID: X64_0x1E_ehdrv+17b86

BUCKET_ID: X64_0x1E_ehdrv+17b86

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

 

I see that ehdrv is referenced in your Bugcheck Analysis. Try testing it with the ESET Self-Defense module disabled. Ehdrv.sys mainly responsible for that module.

Additionally, ensure that you are configuring the client in accordance with ESET’s and Microsoft’s best practices for a server.

 

I will give that I try. I wouldn't be surprised if some peculiarity in the Vista kernel combined with AV self defense drivers is causing a problem with thread contexts being set properly on asynchronous procedure calls. This doesn't happen on Server 2008 R2 at all. Also, from reviewing some other forums, people have been having this issue with Kaspersky deployed in a similar environment.

 

Since EMSX 4.3 already has protocol content filtering disabled by default to prevent a bug in MS Windows Filtering Platform from manifesting on Win2008 servers and recommended exclusions are applied automatically, my additional suggestions would be disabling Self-defense along with Anti-Stealth on critical servers (unless there's a high chance that somebody could run malware on the servers).

 

Thank you for the information. I have not had a recurrence on any server with self-defense and anti-stealth disabled. I just wish support was more responsive to this issue since I do not have access to symbols or source code for the driver. I spoke with Microsoft PSS and they were unable to determine the reason for the invalid thread context and suggested removing the AV software which I did not want to do. I find the workaround acceptable.

Thanks,

Chris