I renamed a backup definition file from within Reflect (via the context menu in the 'Backup Definition Files' tab). Now the renamed backup definition file runs successfully as expected, but I also get a log error and email notification that the original file can't be found:

Imaging Summary
Backup Definition File:     c:\.....\my backup.xml     <- file was renamed so doesn't exist
XML validation:             Error - 'c:\.....\my backup.xml' not found

Email Notifications
Recipients:                      yours_[email protected]
Email notification sent
X Backup aborted! - XML validation error

I don't know why it's still trying to find the original backup file when the renamed version is being picked up successfully. I rebooted the laptop after the rename, and I can't find the old file name anywhere in Reflect - except in the log errors.

Any ideas how to stop it looking for the old name?

My guess is that there's a scheduled task that wasn't updated to specify the new definition file name as its parameter.  I think that's supposed to be updated automatically if you rename the file within Reflect, but maybe something went wrong there. Check the Scheduled Backups tab in Reflect to see if there are any tasks still underneath an item pointing to the old file name.  If so, remove them there and then make sure you have any desired schedules still set up with the new definition file.  If everything looks good there, then you might have to go look at Windows Task Scheduler directly.  All Reflect tasks start with "Macrium", so they're easy to find.  Then check the Action tab for each one and check the path to the definition file that they call.

+x

 

jphughan - 24 February 2020 3:45 PM

My guess is that there's a scheduled task that wasn't updated to specify the new definition file name as its parameter.  I think that's supposed to be updated automatically if you rename the file within Reflect, but maybe something went wrong there. Check the Scheduled Backups tab in Reflect to see if there are any tasks still underneath an item pointing to the old file name.  If so, remove them there and then make sure you have any desired schedules still set up with the new definition file.  If everything looks good there, then you might have to go look at Windows Task Scheduler directly.  All Reflect tasks start with "Macrium", so they're easy to find.  Then check the Action tab for each one and check the path to the definition file that they call.

Thanks for the response - like I said, there's no trace of the old file name in the Reflect UI - all tasks, etc., correctly reflect the new name. I hadn't thought of the Windows Task Scheduler - and you're right, all the old tasks were still in there and still enabled! The new name has its own set of tasks, so the old ones shouldn't still be there. I've deleted them, so that should fix the problem.

Strange - I'd have expected Reflect to delete them automatically if it creates replacements.

Thanks for the help

Glad you’re all set, and happy to help! Reflect generally does delete/update old tasks, so I’m not sure what may have happened there. Any third-party anti-malware or other startup/background/scheduled task monitoring applications installed on your system that might have interfered with Reflect trying to do that?

I use a popular antivirus/security package, it shouldn't interfere like that. I'll have a play and see whether it was a one-off. 

These forums have lots of examples of popular antivirus/security packages interfering with things they shouldn't have been, including backups and Rescue Media creation.  I just recently helped someone who turned out to have an anti-malware solution that prevented shadow copies from being deleted, which filled up their storage allocation to the point that Reflect could no longer create new shadow copies in order to perform backups.  This type of nonsense is probably what led Macrium to create this KB article -- although there are many other instances of third-party AV interfering with legitimate activity performed by other applications.  For example, Norton/Symantec has been in the news twice recently for causing Chrome crashes when Google tried to enable a security feature in Chrome.  Google reverted the update the first time to give Symantec time to get their house in order, and then tried again later with the same result.  Before that, after Microsoft switched over to using a more secure digital signature algorithm to verify the authenticity of Windows updates, Norton/Symantec products started blocking Windows Updates from installing at all, a process they never should have been involved with at all given that Microsoft has its own authenticity checks built into that process anyway.

And of course the offending products practically never give any clear indication that they took any action that caused these negative outcomes, leading their users to ignore those products as possible causes of the behavior and instead blame the application that isn't performing as expected.

I dumped third-party AV pretty much when Microsoft Security Essentials arrived, and since moving to Windows 8 I've dumped it altogether.  Windows Defender holds up quite well compared to the competition in independent tests nowadays, it's free forever, and every Windows developer designs with it in mind because it's there by default.  Meanwhile, third-party AV seems to cause more harm than good these days, especially now that major Windows releases are arriving every 6 months, because the fact that they need to hook into Windows in ways that Microsoft does not recommend or support means that when Microsoft changes something that they shouldn't have been using, those hooks can bring the whole system down.  Of course users tend to blame a bad Windows update when that happens because, "My PC worked before the update and now it blue screens during boot!", but it then comes out that AV was the true culprit.  And then there are the times when AV creates security vulnerabilities.  Turns out that when you insert yourself practically everywhere in the system, a bug in your code can be exploited from practically anywhere.  I remember a case again involving Norton/Symantec where its network scanning code had a flaw that meant a remote attacker could take over a victim's PC by simply sending it a few specially crafted network packets.

And some AV solutions expect you to PAY for this privilege!?

+x

 

jphughan - 24 February 2020 11:44 PM

These forums have lots of examples of popular antivirus/security packages interfering with things they shouldn't have been, including backups and Rescue Media creation.  I just recently helped someone who turned out to have an anti-malware solution that prevented shadow copies from being deleted, which filled up their storage allocation to the point that Reflect could no longer create new shadow copies in order to perform backups.  This type of nonsense is probably what led Macrium to create this KB article -- although there are many other instances of third-party AV interfering with legitimate activity performed by other applications.  For example, Norton/Symantec has been in the news twice recently for causing Chrome crashes when Google tried to enable a security feature in Chrome.  They pulled it back the first time, waited for Symantec to get their house in order, and tried again with the same result.  Before that, after Microsoft switched over to using a more secure digital signature algorithm to verify the authenticity of Windows updates, Norton/Symantec products started blocking Windows Updates from installing at all, a process they never should have been involved with at all given that Microsoft has its own authenticity checks built into that process anyway.

And of course the offending products practically never give any clear indication that they took any action that caused these negative outcomes, leading their users to ignore those products as possible causes of the behavior and instead blame the application that isn't performing as expected.

I dumped third-party AV pretty much when Microsoft Security Essentials arrived, and since moving to Windows 8 I've dumped it altogether.  Windows Defender holds up quite well compared to the competition in independent tests nowadays, it's free forever, and every Windows developer designs with it in mind because it's there by default.  Meanwhile, third-party AV seems to cause more harm than good these days, especially now that major Windows releases are arriving every 6 months, because the fact that they need to hook into Windows in ways that Microsoft does not recommend or support means that when Microsoft changes something that they shouldn't have been using, those hooks can bring the whole system down.  Of course users tend to blame a bad Windows update when that happens because, "My PC worked before the update and now it blue screens during boot!", but it then comes out that AV was the true culprit.  And some AV solutions expect you to PAY for this privilege!?

OK, thanks for the heads-up. I'll include turning off the AV when I test the Reflect definition file renaming - it will be interesting to see if I can pin down the problem

Unfortunately with some AV solutions, even turning them off doesn't completely turn them off -- as if lack of notification when they're taking action weren't enough -- so even that doesn't guarantee that they won't interfere.  But I suppose you can always try it.