AfxBeginThread and Deep Behavioral Inspection

[ThorstenK 0]

With the newly added feature "Deep Behavioral Inspection" which comes with the new ESET Endpoint Antivirus version 7.2.2055.0, calls to the MFC function AfxBeginThread won't return.

When using a debugger (Visual Studio  2019) everything works.

Without a debugger the program freezes. The call stack after attaching a Debugger is

    ntdll.dll!NtWaitForAlertByThreadId()    Unbekannt
    ntdll.dll!RtlpWaitOnAddressWithTimeout()    Unbekannt
    ntdll.dll!RtlpWaitOnAddress()    Unbekannt
    ntdll.dll!RtlpWaitOnCriticalSection()    Unbekannt
    ntdll.dll!RtlpEnterCriticalSectionContended()    Unbekannt
    ntdll.dll!RtlEnterCriticalSection()    Unbekannt
    ebehmoni.dll!00007ffa47f95db1()    Unbekannt

When the "Deep Behavioral Inspection" feature is disabled everything works like expected.

Is there anything we can do beside disabling this feature?

[Marcos 4,841]

Would it be possible to provide the application for replication and further investigation of the issue?

[ThorstenK 0]

Sorry, our application requires a hardware lock and comes with several protection mechanisms. I could offer you a TeamViewer session for some further Investigation, I can also provide some log files if there any. Please send me a PM for a TeamViewer session.

[itman 1,596]

Is the thread being created in a suspended state or security attributes being changed? Either of these could be a possible trigger of suspicious activity by deep behavior inspection:

Quote

Starting the Thread

There are two overloaded versions of AfxBeginThread: one that can only create worker threads, and one that can create both user-interface threads and worker threads. To begin execution of your worker thread using the first overload, call AfxBeginThread, providing the following information:

The address of the controlling function.

The parameter to be passed to the controlling function.

(Optional) The desired priority of the thread. The default is normal priority. For more information about the available priority levels, see SetThreadPriority in the Windows SDK.

(Optional) The desired stack size for the thread. The default is the same size stack as the creating thread.

(Optional) CREATE_SUSPENDED if you want the thread to be created in a suspended state. The default is 0, or start the thread normally.

(Optional) The desired security attributes. The default is the same access as the parent thread. For more information about the format of this security information, see SECURITY_ATTRIBUTES in the Windows SDK.

https://docs.microsoft.com/en-us/cpp/parallel/multithreading-creating-worker-threads?view=vs-2019

Also is any Eset log activity or the like being generated indicating detection activity by deep behavior inspection?

Also is only a worker thread being created or additionally, a user-interface thread?

Edited January 15, 2020 by itman

[itman 1,596]

Also the simple solution to this is to exclude your program/s from Deep Behavior Analysis scanning rather totally disabling Deep Behavior Analysis.

Edited January 15, 2020 by itman

[ThorstenK 0]

It's worker thread, created like 

AfxBeginThread(InputGamepad::threadPolling, nullptr);

first time creation of the thread is successful, but after the thread ended during program execution a new call to only this AfxBeginThread freezes. Further debugging brings me to the function _AfxThreadEntry()

// wait for thread to be resumed
VERIFY(::WaitForSingleObject(hEvent2, INFINITE) == WAIT_OBJECT_0);

in the module 

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.24.28314\atlmfc\src\mfc\thrdcore.cpp

. Within this function the thread is created via _beginthreadex with CREATE_SUSPENDED flag. But obviously the thread is not being resumed.

While our application is beeing executed there several thread running. No messages or notification are provided from the deep behavior inspection 

[itman 1,596]

Did you try to exclude the app from Eset Deep Behavior Inspection?

[Marcos 4,841]

Would it be possible to provide a complete memory dump from time when the issue occurs by manually initiating a crash as per  https://support.eset.com/en/how-do-i-generate-a-memory-dump-manually ? Has the issue manifested just recently and it used to work with Endpoint 7.0, 7.1 or 7.2 alright before?

[ThorstenK 0]

When the application is excluded from Eset Deep Behavior Inspection everything works like expected. The Issue comes ONLY with the actual ESET Endpoint Antivirus Version 7.2.2055.0. Versions Prior to this works fine. I will provide a Memory Dump tomorrow, do you have an E-Mail Address for sending the dump?

[Marcos 4,841]

If possible, try to reproduce it with a freshly installed EP 7.2 without updating modules (e.g. you could disconnect the pc from LAN right after activation).

As for the memory dump, compress it and upload it to a safe location (e.g. OneDrive) and drop me a private message with a download link.

[ThorstenK 0]

In our company there some computers with an update issue on EP 7.2. This computers are not having the AfxBeginThread Problem. The EP 7.2 modules on these computers have the following versions.

Advanced Heuristik: 1195 (20191025)
Anti-Stealth-Unterstützung: 1154 (20190614)
Archivunterstützung: 1293 (20191004)
Datenbank: 1110 (20190827)
Erkennungsroutine: 20272 (20191031)
Erweitertes Machine Learning-Modul: 1039 (20191025)
ESET SysInspector: 1275 (20181220)
Firewall-Modul: 1395 (20191023)
HIPS-Unterstützung: 1373 (20190916)
Internet-Schutz: 1380 (20190920)
Konfigurationsmodul (33): 1811.5 (20191017)
LiveGrid-Kommunikationsmodul: 1053 (20190321)
Lokalisierungsunterstützung: 1772 (20191031)
Netzwerk-Schutzmodul: 1682 (20190801)
Rootkit-Erkennungs- und Bereinigungsmodul: 1019 (20170825)
Schutz vor skriptbasierten Angriffen: 1058 (20191016)
Sicheres Heimnetzwerk Modul: 1030.2 (20190424)
Soforteinsatz-Modul: 15163 (20191031)
Spezielles Säuberungsprogramm: 1013 (20190627)
Support-Modul für das Kryptografieprotokoll: 1040 (20190913)
Support-Modul für tiefe Verhaltensinspektion: 1085 (20191001)
Säuberungstechnologie: 1200 (20190916)
Updates: 1018.1 (20190709)
Viren- und Spyware-Schutz: 1556.2 (20191025)

Computers WITH the AfxBeginThread problem have these version numbers

Advanced Heuristik: 1196 (20191108)
Anti-Stealth-Unterstützung: 1156.1 (20191216)
Archivunterstützung: 1296 (20191212)
Datenbank: 1110 (20190827)
Erkennungsroutine: 20686 (20200117)
Erweitertes Machine Learning-Modul: 1047 (20200115)
ESET SysInspector: 1275 (20181220)
Firewall-Modul: 1396.1 (20191223)
HIPS-Unterstützung: 1379.3 (20200113)
Internet-Schutz: 1383 (20191205)
Konfigurationsmodul (33): 1811.5 (20191017)
LiveGrid-Kommunikationsmodul: 1055 (20191107)
Lokalisierungsunterstützung: 1780 (20191217)
Netzwerk-Schutzmodul: 1682 (20190801)
Rootkit-Erkennungs- und Bereinigungsmodul: 1019 (20170825)
Schutz vor skriptbasierten Angriffen: 1063 (20200113)
Sicheres Heimnetzwerk Modul: 1035 (20191112)
Soforteinsatz-Modul: 15583 (20200117)
Spezielles Säuberungsprogramm: 1013 (20190627)
Support-Modul für das Kryptografieprotokoll: 1040 (20190913)
Support-Modul für tiefe Verhaltensinspektion: 1087.1 (20200107)
Säuberungstechnologie: 1205 (20191209)
Updates: 1018.1 (20190709)
Viren- und Spyware-Schutz: 1558.2 (20191218)

 

i have send you a private message with the link to the requeseted Memory Dump

 

[Marcos 4,841]

I wonder if you could check and confirm that the issue is gone after switching to the pre-release update channel in the advanced update setup and downloading the Deep behavioral inspection module 1090.

[ThorstenK 0]

I can confirm that this issue is fixed with the actual Deep behavioral inspection module 1090. Thanks

[ThorstenK 0]

When will the new deep behavioral inspection module 1090 be released?

[Marcos 4,841]

It had been released for a big portion of users, now it's released for everyone.