Solved

NovaBACKUP 14.1 Server Edition blocked by SA but not flagged as virus or spyware

  • 23 December 2012
  • 4 replies
  • 33 views

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
icon

Best answer by Kit 26 December 2012, 20:36

View original

4 replies

Userlevel 7
Badge +56
Hello exectech and Welcome to the Webroot Community Forums. ;)
 
You can use this Function to Allow and Exclude needed files in the mean time but I would suggest you Submit a Support Ticket
and get that and any associated files Whitelisted. Or it could be something else that is causing this and the Support inbox will be happy to help you.
 
TH
Thank you TH. Will have to move the server to the Unmanaged group but no biggie. I will test your solution later today.
Userlevel 7
Hello exectech, Welcome to the Webroot Community Forum. 😃
Userlevel 7
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.

Reply