Hi,

I am testing SCEP 2012 SP1 at this time and noticed some problems with it locking up the computer I am using during the day. I included a screen shot of it writing with 26MB/s to a 4096 KB file MpWppTRacing. Telling from the directory it is a support file. Also after it went away I got a message that the Service had crashed.

Version is: 1.151.459.0

Does anyone know how to fix it?

Hi,

Thank you for the post.

Does MSMPENG consume excessive CPU or memory? What is the exact text of any error messages that you received that are associated with this problem? What system and version are you using when the problem occurs?

Regards,

Hi,

Memory and CPU consumption is minimal. I get no errors, but nearly every application on the system goes into "Not Responding" most of the time. That is most likely because of the inability to read or write from disk.

The System I am testing this on is a Windows 8 Enterprise x64 with all important and Optional patches installed.

Thanks

EDIT: it seems to happen a lot after the software crashes. But only in some cases it goes to the high IO utilization. 

Hi,

Thank you for the post.

Is there any other AV software installed on your client? if you disable SCEP, is it the same behavior?

Regards,

I have witnessed the same thing.  SCCM2012 SP1 w/ Endpoint Protection 2012 running on Win7x64 Enterprise.

As reported via Resource Monitor, MsMpEng.exe consumes 25% on a quad core CPU, and System is attributed to the excessive Writes to that .bin file.

Microsoft, is this a known issue, are there already open tickets about this problem?

Why is the MpWppTracing file being created in the first place? What triggers this situation/process to create the file?

EP2012 version info below:

Antimalware Client Version: 4.1.522.0

Engine Version: 1.1.9506.0

Antivirus definition: 1.151.2012.0

Antispyware definition: 1.151.2012.0

Network Inspection System Engine Version: 2.1.9402.0

Network Inspection System Definition Version: 101.4.0.0

I found the location of the MsMpEng.exe dump files created by these crashes.

Enable view of hidden/system folders to navigate to the path:

C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps

The windbg analysis is likely to be a wall of text in this post, but here it goes:

..........................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(18c.1ac): Access violation - code c0000005 (first/second chance not available)
ntdll!NtWaitForMultipleObjects+0xa:
00000000`76fd18ca c3              ret
0:003> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

FAULTING_IP:
MpSvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+2e7
000007fe`fc3b0157 488b042500000000 mov     rax,qword ptr [0]

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000007fefc3b0157 (MpSvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+0x00000000000002e7)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000

DEFAULT_BUCKET_ID:  NULL_POINTER_READ

PROCESS_NAME:  MsMpEng.exe

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

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

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000000000

READ_ADDRESS:  0000000000000000

FOLLOWUP_IP:
MpSvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+2e7
000007fe`fc3b0157 488b042500000000 mov     rax,qword ptr [0]

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  msmpeng.exe

FAULTING_THREAD:  00000000000001ac

PRIMARY_PROBLEM_CLASS:  NULL_POINTER_READ

BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ

LAST_CONTROL_TRANSFER:  from 000007fefc3afe23 to 000007fefc3b0157

STACK_TEXT: 
00000000`00dcf320 000007fe`fc3afe23 : 000007fe`fc4c4078 00000000`00901930 00000000`00000001 000007fe`fc03044d : MpSvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+0x2e7
00000000`00dcf630 000007fe`fc307af8 : 00000000`00000001 00000000`00340920 00000000`00340910 000007fe`e60abef7 : MpSvc!CRegisterWaitCallbackHealthMonitor::OnNotify+0x77
00000000`00dcf670 000007fe`fc307b8c : 00000000`00000000 00000000`00dcf6f0 00000000`00dcf801 00000000`00340910 : MpClient!CommonUtil::CRegisterWaitHandle::OnTriggerImpl+0x54
00000000`00dcf6a0 00000000`76f9656c : 00000000`001d2dc0 00000000`001d2dc0 00000000`001d2e70 00000000`00dcf878 : MpClient!CommonUtil::CRegisterWaitHandle::OnTrigger+0x30
00000000`00dcf710 00000000`76fa0c26 : 00000000`001c6c90 00000000`770845e8 00000000`00000000 00000000`77084610 : ntdll!TppWaitpExecuteCallback+0x10c
00000000`00dcf770 00000000`769b652d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!TppWorkerThread+0x5ff
00000000`00dcfa70 00000000`76fac521 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00dcfaa0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d

STACK_COMMAND:  ~3s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  mpsvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+2e7

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MpSvc

IMAGE_NAME:  MpSvc.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  50515c8d

FAILURE_BUCKET_ID:  NULL_POINTER_READ_c0000005_MpSvc.dll!CRegisterWaitCallbackHealthMonitor::MonitorContext

BUCKET_ID:  X64_APPLICATION_FAULT_NULL_POINTER_READ_mpsvc!CRegisterWaitCallbackHealthMonitor::MonitorContext+2e7

WATSON_STAGEONE_URL:

{URL DELETED}

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

Well, we have seen a number of these events between 11-June-2013 and 14-June-2013, but have not seen any new events after 14-June-2013...

Perhaps Microsoft fixed the glitch... but it would have been helpful to have the issue acknowledged.