I need to exclude some programs from real-time protection scanning and I need some direction. The error message is contained below. Right now the only work around to turn off protection scanning which is not acceptable. Any help would be greatly appreciated.
OS: Windows Server 2008 R2 Standard (64-bit)
RAM: 12GB
CPU: Xeon 3.3GHz 4-Core
Here is the error detail:
Problem Event Name: BEX
Application Name: NovaBackX.exe
Application Version: 14.1.10.0
Application Timestamp: 50c3acfa
Fault Module Name: WRusr.dll
Fault Module Version: 8.0.2.96
Fault Module Timestamp: 50d237dd
Exception Offset: 00018560
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033
Additional Information 1: 2608
Additional Information 2: 2608c5700f693da309fa1a40136afc7c
Additional Information 3: 0a97
Additional Information 4: 0a97994f40f74f03e0d128f2b3952d56
Answer
NovaBACKUP 14.1 Server Edition blocked by SA but not flagged as virus or spyware
Best answer by Kit
That is crashing from the DLL injection, not being blocked. That's not a good sign for the stability of the software package that is crashing.
Based on your mention of the "Unmanaged Group", I gather you are using Endpoint Protection, so quick contact with our business support team would be your best bet. Changing the determination on our side to stop checking that process (If it's safe and not compromised) will be a solution from our end. Their implementation of a fix would be most optimal in the long term, since we are not the only security product or other product that performs legitimate DLL injection. We'll also look at it from a code standpoint on our side.
In other news, you may want to seriously consider running Windows Memory Diagnostics or similar functionality on that system, since it's exceptionally rare for anything in our code to fully crash and is quite often indicative of hardware issues.
Based on your mention of the "Unmanaged Group", I gather you are using Endpoint Protection, so quick contact with our business support team would be your best bet. Changing the determination on our side to stop checking that process (If it's safe and not compromised) will be a solution from our end. Their implementation of a fix would be most optimal in the long term, since we are not the only security product or other product that performs legitimate DLL injection. We'll also look at it from a code standpoint on our side.
In other news, you may want to seriously consider running Windows Memory Diagnostics or similar functionality on that system, since it's exceptionally rare for anything in our code to fully crash and is quite often indicative of hardware issues.
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.