Suspicious Files in RSS v3.2.12918.5857-REL14

I need to ask about the 'suspicious files' bit

a) what criteria is used to put them on the list? What constitutes 'suspicious' activity? They are clean files, all of them.

b) When Data Collection Policy is set to 'ask' (so I can have an eye on the queue and the frequency of this and which files are selected) no files seem to be uploaded, the list just grows and grows. I get no feedback about those files and the Internet connection works because updates work. Are your servers not taking 'suspicious' files submissions?. Feedback about actions that impact my time would be greatly appreciated. I can't set it to automatic before I'm satisfied about these oddities.

c) When Data Collection Policy is set to 'do not collect' the list keeps growing by the hour. After having reset the three test machines 12 hours ago it's now at 230 files. Moreover, the upload queue is taking two minutes to show up, pegging the processor at 100% for two minutes. This is very hard to understand; it is not an issue of bringing swapped out pages back into RAM because the second and third time I do the same, it takes the same time. My train of thought should not be interrupted for two minutes just for this. Is this fixable in Returnil or is it due to problems in the bowels of Windows libraries?

Thanks

 

A. This is determined by the Anti-execute settings in virtual Mode > Settings > Additional Protection Options.

B & C. This is a strange report. Are you able to receive Virus Guard updates? For example, the current signature at the time of this post is 3.2-b3.64052 (12/16/2011). Is yours on the same increment?

Mike

 

It's 3.2-b3.64190

 

I noticed the same thing. Even though I'm not getting the pop-up anymore (from the recent thread I started) the suspicious files just stay in the queue all the time and never seem to upload. I get all the updates just fine but it won't upload anything.

 

Also, the dialog keeps popping up with the policy set to 'do not collect' and no matter what I click/don't click nothing seems to happen and there is no feedback on what the program is doing.

 

Hi Luciya,
What the team suspects is a damaged or corrupt database. To try and resolve this, the process is to:

1. Delete the database files to force the client to reconstruct it and,
2. To set the data collection policy to do not collect following the db "reset"

I will send you a PM with more detailed instructions for doing this and then will need your feedback on their efficacy. If this does not clear the issue, we will move this to the support system where we can ask for some specific troubleshooting logs they engineers can review.

Mike

 

Read you PM, and explained there that I believe you should look into what caused the alleged corruption in the first place, not ask me to delete files and start over. Also, why a PM when there's not any private information involved? It's all part of your campaign to hide any problems and ignore or downplay what leaves the program in a bad light. How can we know that it won't happen again? Returnil is definitely not ready for prime time. I have tested this program for just four days and I'm tired of little oddities and problems. I can't use it.

 

Hi Luciya,
Please see my reply in the previous thread and your PM. You are correct that the information is not "private", but until we have gone through the process of re-creating the database and getting the proper information appended to the rvs3 log, there is no reason to clutter the thread with what may or may not be the resolution to the issue you have reported.

This is just the first step to getting to the root cause and the PM system offers a way to explore possibilities while keeping the confusion to a minimum for other users. Also note that the forums have a built in minimum number of posts a new member has to make before they can use the PM system. As a MOD, I can shorten that period by sending you a PM which opens the door for us to communicate sensitive or private information if required going forward.

My only goal here is to get as much accurate information as possible, be able to provide instructions from the engineering team in an efficient manner, and keep a lid on extraneous involvement by other users at the outset of the thread so we can get to a root cause and resolution as efficiently as possible. As this progresses, then more information can be relayed to others in the thread that include specific instructions determined to be useful for others who may encounter the same issue for whatever reason.

As I have posted time and again in these and other forums; we value all feedback and see negative feedback as a challenge to make our products and services better.

Mike

 

Coldmoon, I understand that you might need "breathing space" to get to grips with the problem but I also think that you need "transparency" or your actions might be viewed as clandestine and insulting to your users, a perceived loss of integrity often results in a drop in confidence of the product and developer. A lot of good developers/softwares have lost "status", momentum and credibility and died because of a breakdown in user developer open interaction. Once confidence is lost it is not easily regained. A frank, developer user dialogue (no matter what the problem) is (in my opinion) the best policy.

 

Hi pidbo,
As you know I am not shy about discussing anything reported. The gist at the moment is that this is a database corruption issue with an as yet, undetermined root cause so the only instructions to date have been for a database deletion/re-creation process. The next step following that is to see if the issue is reproducible and then to collect the relevant rvs3 logs and msinfo32 report so the team can investigate this further in the lab.

Mike