Endpoint Protection

As a software developer, I have an app that consistently crashes when SEP injects the UMEngx86.dll into my application.

It's a terrible user experience for my customers (and for me) to need tell my customers that they need to turn off SEP Active Threat Protection in order to run my app!

I started to try to identify what part of my app is crashing when SEP is injected... but since my last reboot, SEP no longer injects UMEngx86.dll into my application.

To debug this problem to see if it's my fault or a fault in SEP, I need a consistent way to have SEP predictably load UMEngx86.dll into my application.

SEP has a "whitelist" to always allow execution of apps without subjecting them to scanning or DLL injection.

SEP has a "blacklist" to always prevent certain apps from even executing.

What I need is a "graylist" rule or some other debug mechanism that lets me identify an app by a specific file name (optionally on a specific computer or group of computers), such that these apps are always injected with the UMEngx86.dll, to aid in debugging problems triggered by SEP.

Note that the failure was consistently occurring ONLY when these DLLs are injected:
C:\ProgramData\Symantec\Symantec Endpoint Protection\14.0.2415.0200.105\Data\Definitions\BASHDefs\20180306.005\UMEngx86.dll

C:\ProgramData\Symantec\Symantec Endpoint Protection\14.0.3897.1101.105\Data\Definitions\BASHDefs\20180317.001\UMEngx86.dll

It never occurs on a clean VM (no SEP) nor when the DLL is not injected.

The Windows Error Report isn't always the same. Two examples follow:

Sig[3].Name=Fault Module Name
Sig[3].Value=StackHash_af85
Sig[4].Name=Fault Module Version
Sig[4].Value=0.0.0.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=00000000
Sig[6].Name=Exception Code
Sig[6].Value=80000003
Sig[7].Name=Exception Offset
Sig[7].Value=PCH_F3_FROM_ntdll+0x000771AC

Sig[3].Name=Fault Module Name
Sig[3].Value=StackHash_738d
Sig[4].Name=Fault Module Version
Sig[4].Value=0.0.0.0
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=00000000
Sig[6].Name=Exception Code
Sig[6].Value=c000041d
Sig[7].Name=Exception Offset
Sig[7].Value=PCH_A7_FROM_MSCTF+0x0001E91B

Thanks,
--Steve

It may be the SONAR component. Add a SONAR exclusion for your app to see what the result is:

http://www.symantec.com/docs/HOWTO80987

 

Block or log unauthorized software with Application and Device Control
https://support.symantec.com/en_US/article.TECH97618.html

 

Block or log unauthorized software with Application and Device Control
https://support.symantec.com/en_US/article.TECH97618.html

Yes. SONAR is causing the problem with my app.

Adding a SONAR exception doesn't work.

"Disable Proactive Threat Protection features" does stop the SONAR DLL from being injected.

I've since identified exactly what triggers the crash, but I still don't have a fix.

The SONAR DLL overwrites the USER32!_SetWindowsHookEx callback with 0xCC (int 3) breakpoints, but does not provide a breakpoint exception handler.

My app starts up like any other app and forwards several standard Window events using DefWindowProcW().

One of these standard Windows events results in MSCTF.dll calling USER32!_SetWindowsHookEx.

The breakpoint instructions injected by SONAR get executed. Windows detects this as a program fault and creates a Windows Error Report.

It's not clear to me how to modify my app to make DefWindowProcW() not cause MSCTF to call _SetWindowsHookEx. All of the callbacks in the backtrace are undocumented Windows functions (except for the DefWindowProcW() call from my app.)

Have any software developers out there run into a problem like this or figured out how to workaround it?

Thanks,

--Steve