v2.5 causes Backup software (Dantz Retrospect 7.0) to fail

[LuckMan212]

Title says it all. Since upgrading to 2.5 (clean install) I cannot perform a backup anymore using my Dantz Retrospect 7.0 software (http://www.dantz.com/en/products/win...ess/index.dtml). I have everything set up correctly. Backup software gets all the way to the end of the backup process (all files backed up) but the client (my machine with NOD32 on it) CPU usage goes to 100% and the Backup Server gets "stuck" on a stage called "Building Snapshot" which I believe involves the Volume Shadow Copy Service.(?) This 100% CPU will go on forever if left by itself.

In any case, I open AMON and notice that AMON is rapidly scanning over and over again a file called "SETUPAPI.LOG". Why, I have no idea but apparently this is related to the problem. As soon as I turn off AMON, the backup completes successfully.

This was NOT a problem in 2.12, fwiw. HELP!

[LuckMan212]

OK- more information to add. If I go to AMON's setup and select the "default" extension set to scan instead of "all files" (see below) then I am able once again to back up.

But this is NOT ideal since I believe it is the recommended (and default) setting to scan ALL files for best protection.

Any ideas? Is this a bug?
http://www.f2systems.com/files/snap161.gif

[WSFuser]

maybe u could try adding SETUPAPI.LOG to the exclusions list?

[rumpstah]

Hi LuckMan212:

Have you tried to exclude the directory to where the backup file is stored (assuming it is a file and not a device)?

Originally Posted by LuckMan212

Title says it all. Since upgrading to 2.5 (clean install) I cannot perform a backup anymore using my Dantz Retrospect 7.0 software (http://www.dantz.com/en/products/win...ess/index.dtml). I have everything set up correctly. Backup software gets all the way to the end of the backup process (all files backed up) but the client (my machine with NOD32 on it) CPU usage goes to 100% and the Backup Server gets "stuck" on a stage called "Building Snapshot" which I believe involves the Volume Shadow Copy Service.(?) This 100% CPU will go on forever if left by itself.

In any case, I open AMON and notice that AMON is rapidly scanning over and over again a file called "SETUPAPI.LOG". Why, I have no idea but apparently this is related to the problem. As soon as I turn off AMON, the backup completes successfully.

This was NOT a problem in 2.12, fwiw. HELP!

[LuckMan212]

Originally Posted by rumpstah

Hi LuckMan212:

Have you tried to exclude the directory to where the backup file is stored (assuming it is a file and not a device)?

the file is stored on my backup server, which is a completely separate machine.

as for excluding SETUPAPI.LOG I had posted this other thread a couple of days ago where basically I tried that exact thing and, it seems as if exclusions are (still) not working right. So that is not working.

ESET?

[Blackspear]

In the mean time, can you please send an email to support@nod32.com and place a link to this thread.

Let us know how you go...

Cheers

[LuckMan212]

ok I sent them an email, waiting for a response now...

[rumpstah]

Is AMON set to scan the Network?

Originally Posted by LuckMan212

the file is stored on my backup server, which is a completely separate machine.

as for excluding SETUPAPI.LOG I had posted this other thread a couple of days ago where basically I tried that exact thing and, it seems as if exclusions are (still) not working right. So that is not working.

ESET?

[LuckMan212]

Yes, it is. However, it was also set like that in 2.12, and it did not cause a problem.

[rumpstah]

To help narrow down the issue, can you disable the Network scanning to see if the backup completes?

Originally Posted by LuckMan212

Yes, it is. However, it was also set like that in 2.12, and it did not cause a problem.

[LuckMan212]

OK, I had a chance to try disabling the "network" scanning from AMON setup, and I re-tested, the bug still occurs and I am not able to successfully complete the backup. CPU usage still goes to 100% at the end of the process as AMON gets stuck in an endless loop scanning "setupapi.log".

Also, in the process I updated NOD32 to v2.50.19 thinking that perhaps it might be fixed there, but it wasn't. So I have gone back to only scanning certain extensions until ESET can provide a fix.

Again, I want to highlight the point that up to v2.5 (1.x, 2.0.x) this problem did not exist. I have emailed ESET again.

[mercurie]

I am watching this thread please post if you get a response to your email question/problem. I have this same backup software and even tho NOD would not be on the machine that uses this backup software. I still would like to know and also I want to know about Eset support, as I have often considered getting a NOD license. Thanks.

[LuckMan212]

I have used Retrospect since v4.0 on the PC. It is very good backup software. I have invested lots of money in the upgrades over the years all the way up thru 7.0. It works in a client-server arrangement so even though the actual backup program does not run NOD32, the client machines have an "Agent" that runs. I will update the thread if I get any resolution (or not) from ESET.

[Bandicoot]

Hi LuckMan212,

Received your email and I hadn't forgotten your issue; found time yesterday to install Retrospect from Dantz, version 7.0.3.101, and ran a system backup without any problems.

It is a good idea to run an 'In-depth analysis' before backing up, just to check there is no malware active on your machine that might be flagged by AMON during the backup.

Regarding the file setupapi.log: When you exclude it in AMON, have you tried including the short and long path names? ie: C:\Program Files\XYZ\setupapi.log and also C:\Progra~1\XYZ\setupapi.log

Bandicoot.

[LuckMan212]

Hello. Thank you for replying.
Some questions before we go on:

1) Did you arrange Retrospect in a client-server arrangement, as I have above, where the NOD32 machine has the Retrospect client installed and a separate machine is functioning as the server?

2) I am currently using the following versions of Retrospect:
Client: 7.0.107
Server: 7.0.265 with 7.0.4.102 patch installed on top
These are the latest available versions as of this writing.
Are these the versions you used? It does not appear so.

3) Did you install and enable the "Open File Backup" add-on in your backup script? (screenshot below) I have purchased this add-on and it allows Retrospect to back up open files such as Outlook PST files or SQL database tables by working in conjunction with the Windows Volume Shadow Copy service.

Without answering "YES" to the above questions, I'm afraid your conclusion that it might be some malware on my machine preventing the backup might be premature.

http://f2systems.com/files/snap168.gif

[LuckMan212]

Still waiting for a reply, either here or via email..

[Bandicoot]

PM sent.

[Bandicoot]

Hello LuckMan212,

Well after 3 hours of tinkering with Retrospect , I have good news or bad news, depending how you want to take it. I ran a backup using the client-server scenario that you have, with the same, latest, programme versions that you have, and I have NOD32 2.50.19 installed on both the server and client machines and although the backup took about one hour to complete, it was successful with no problems whatsoever.

BUT..... I tried to find a way of downloading the add-on "Open File Backup" without success. It seems only available as a shipped, boxed CD-ROM and although you kindly gave me your activation key to install it, I just couldn't find a way to download it. I notice that the complete software package appears to be between $500 to $600, so I guess they're not going to make it too easy to get your hands on it!

So, I suppose we can't actually draw any conclusions for certain as to whether there is a conflict with this add-on and NOD32 right now.

Have you tried to run a client-server backup without this add-on perhaps, so at least we could pin it down to this specific module?

Bandicoot.....(in need of a cup of tea!)

[LuckMan212]

Bandicoot-
There is nothing extra to install or download. Entering in that license key I sent you should enable the Open File Backup option. It is sort of built in to the program, it just needs to be activated. If you launch the program and go to Window->License Manager, take a look there.
And thanks for taking the time out to test this

[Bandicoot]

Thanks for the guidance there LuckMan212. All sorted out now. So, I've just performed 4 more backups with the 'Open File Backup' feature enabled as you described, and running a server-client backup, again, as you described, and all backups ran and finished correctly. Here's a screen shot so you can see what I mean....

Bandicoot.

[LuckMan212]

Most puzzling indeed... well I have sent you (Bandicoot) further information via email. I will report back here in the public forum if/when I have anything to report.

[LuckMan212]

Well didn't want to let the dust collect on this too much... it's been a few months and unfortunately this problem/conflict still exists and I would like to get an update as to what can be done to resolve it.

[Bandicoot]

Hi LuckMan212,

As I posted on 12th June, I could not replicate the problem you described, having followed your setup exactly. As far as I'm aware, nobody else has reported a problem with Dantz Retrospect to support at Eset, so I don't know what solution we can offer you. Maybe another Eset moderator can offer some thoughts....... guys?

Bandicoot.

Originally Posted by Bandicoot

Maybe another Eset moderator can offer some thoughts....... guys?

Bandicoot.

Hey Thoughts? Yes, sure

If he says that setupapi.log gets scanned again and again we take a deeper look what this file is supposed to log. It will log all Device Driver activities like installing/loading/unloading etc. Based on this fact we know now, that his system is trying to install/load permanently some driver. Probably a block device driver for accessing hard disk and setting security permissions for backup reasons. With this knownledge, we could come to this conclusion that:

His environment is permanently trying to load a device driver file ( you can load device drivers manually - on demand - or you can load them permanent upon system start). In the most cases you can configure this with a service (if the driver works together with a Win32 Service) ---> System ---> Preferences ---> Machine Management ---> Services.

Now it COULD BE possible that his machine tries to load and to activate this driver for every operation - meaning this file also would be scanned all the time. Take a look in this SetupAPI.LOG (It's a textfile) to track down this problem. It will tell ya what it tries to installs. Then find this in the driver/service list and take a closer look to the autostart method.

Best thing is if you send a "fresh" SetupAPI.Log to eset support.
Nigel, here is a link which might help you:
http://www.microsoft.com/windows2000...n/setupapi.asp

Download this word document file - and you can track down what's wrong with his environment setup. If you guys still having problems feel free to contact me, but i'm not support department so i can't spend that much time with such things, but i hope this pointed out another way for a possibly solution.

8^) H.B.