bmp999 0 Posted August 24, 2020 Share Posted August 24, 2020 In Windows 10 Pro, using Windows 7 backup on Windows 10 to make daily backups - has worked for 6 months, we get the same error as outlined in KB6121 https://support.eset.com/en/kb6121-windows-backup-failing-error-message However adding these exclusions do not work. I have added all the EFI files in that same folder with no luck. The EFI partition has a lot of files in it, so hoping to get a way to see which file exactly is locked. To prove it is ESET causing the issue not another program, We have disabled ESET for 4 hours every day for a week 1 hr before backup and backup works every time, but it fails almost every time (1 or 2 rare exceptions) in the past 2 weeks if we leave ESET running (not paused) and Daily Backup runs at 11pm. Ideas anyone? Thx, Brian Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 24, 2020 Share Posted August 24, 2020 (edited) Do you have multiple hard drives installed on your PC? Depending on cable connections, the Win boot drive might not be actually Disk 0 as per my below screen shot. Appears the Eset KB article assumes a single drive system as far as exclusions go. Also, the KB article is date April, 2020. This is prior to the Win 10 2004 release. This release might have added additionally EFI files and the like that need exclusion. Edited August 24, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 24, 2020 Author Share Posted August 24, 2020 Yes there is a C drive and an additional internal Drive (not bootable - No OS). Will ask client to send me a SNIP of the Disk Management. Its a new Lenovo (6 months old), C should be a Port 0, but not sure. Will post when I get it. PS: Its Eset version 13.2.15.0 Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 24, 2020 Share Posted August 24, 2020 This article shows how to determine which volume the OS actually resides on: https://superuser.com/questions/1058217/list-every-device-harddiskvolume . It is this volume that must be specified in Eset exclusions. Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 24, 2020 Share Posted August 24, 2020 (edited) It also appears that diskpart via command prompt is the easiest to use to determine correct volume number. As shown below, my Win OS is actually on volume 4. Edited August 24, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 25, 2020 Author Share Posted August 25, 2020 Here is more information... had to visit client to get this. EFI is on HarddiskVolume3 as we have added to the exception list for the BCD, BDC.log and many other files, including the one in the windows folder on C that was suggested. Thx, Brian Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 26, 2020 Share Posted August 26, 2020 (edited) @foneil , this Eset KB: https://support.eset.com/en/kb6121-windows-backup-failing-error-message?ref=esf , needs to be revised. It should state that diskpart via command line prompt needs to be run to determine which volume the backup drive actually resides on. Then the drive letter associated with that volume number used in creating Eset exclusions for Win7 Backup utility. Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 26, 2020 Author Share Posted August 26, 2020 OK, any more suggestions why using HarddiskVolume3 is not working in our case? We have been making backup work by stopping ESET for 4 hrs ever day at 10pm so that backup will run at 11pm. We will STOP this so it fails again. Also we found the location of more detailed backup logs in C:\windows\Logs\WindowsBackup, will post the next failure. It only keeps 5 copies of the logs, so we don't have a failure log until it happens again. Thx, Brian Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 26, 2020 Share Posted August 26, 2020 (edited) On 8/26/2020 at 9:18 AM, bmp999 said: OK, any more suggestions why using HarddiskVolume3 is not working in our case? We have been making backup work by stopping ESET for 4 hrs ever day at 10pm so that backup will run at 11pm. We will STOP this so it fails again. Also we found the location of more detailed backup logs in C:\windows\Logs\WindowsBackup, will post the next failure. It only keeps 5 copies of the logs, so we don't have a failure log until it happens again. Thx, Brian In regards to this from the KB article: Quote In step 5, create exclusions for: \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD.LOG \Device\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi %WINDIR%\system32\winload.efi Now go to the end of the KB article and note this: Quote Volume of exclusion paths can vary In the above exclusion paths, the volume can vary. The correct volume can be found in the registry at “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist”. In this example, the USB drive is drive letter I. The exclusion would be created for I:\EFI\Microsoft\Boot\BCD It really appears that that the exclusions must be set up using the drive specification. What you really have do is determine the drive letter for the drive being used for the Win 7 backup file. Then use that drive letter in the above file exclusions. You also might want to contact Eset technical support for a confirmation to my above statement. -EDIT- This confirms the above assumption. The Eset exclusion must contain the drive letter associated with the backup drive: Quote ESET Antivirus If you’re using ESET antivirus, create exclusions for these two files: \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD.LOG Assuming that the drive-letter is I:\ these are the exclusions you need to create in ESET settings: I:\EFI\Microsoft\Boot\BCD I:\EFI\Microsoft\Boot\BCD.LOG https://www.winhelponline.com/blog/windows-backup-failed-exclusive-lock-efi-partition-avast/ Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 27, 2020 Author Share Posted August 27, 2020 And this is the only system that has this problem at the moment. I have Eset Smart Security on my office w10 system with an internal secondary drive and it does not fail on the EFI partition. Runs exactly same time 11pm. Also it never fails when we run a manual backup on the customer system. Its only the at night for the SCHEDULED backup. We really need the source of the issue addressed, not a work around with scripts and the like. Since this is a customer system, I could be dragged back every time there is a hiccup. We have established that REGISTRY Hivelist points to HarddiskVolume3 and that is what we have used for every exception. But there are a lot more files in there than just these 3 (listed above). Adding them all one by one is arduous. Need wild card to perhaps SKIP them all and then work our way down. Only way to see EFI files I have found that works (and only accessible via Powershell not File Explorer) for W10 is to: Powershell (ADMIN) mountvol P: /s dir P: -s or switch to P: then CD down the paths. mountvol P: /D Attached a full W10 EFI Directory listing. SO back to the first question, what other files can be locked and how do we see which files ESET has its fingers on when backup runs that cause it to fail? Full W10 Directory EFI Partition.txt Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 27, 2020 Share Posted August 27, 2020 (edited) On 8/26/2020 at 8:20 PM, bmp999 said: I have Eset Smart Security on my office w10 system with an internal secondary drive and it does not fail on the EFI partition. Check and see if a drive letter has been assigned to the UEFI partition/volume for some reason on that device. The Eset KB specifically states the issue occurs when an external backup drive is being used. On 8/26/2020 at 8:20 PM, bmp999 said: We really need the source of the issue addressed, not a work around with scripts and the like. Since this is a customer system, I could be dragged back every time there is a hiccup. Contact Eset North America customer support and see if they can assist. Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 27, 2020 Author Share Posted August 27, 2020 You can see by the list vol above that there is no drive letter assigned. Thanks for your help. Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 28, 2020 Share Posted August 28, 2020 (edited) Well it appears I "totally blew this one." First a reference to the above posted Eset KB article; in fact the very first sentence of the article: Quote While attempting to run a backup scan on an external drive after installing ESET, the backup fails and you receive the following error message: The sentence is poorly worded. What is meant is the Win 7 backup fails because Eset real-time scanning is locking a file being created/overwritten on the backup drive in order to scan it. This in turn prevents the Win 7 backup from creating the file on the backup media and to terminate the backup processing. It appears your backup drive letter is E: and assumed this is the drive used in Win 7 backup processing. In regards to the following KB article noted files that require Eset real-time scanning file exclusions: \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD \Device\HarddiskVolume1\EFI\Microsoft\Boot\BCD.LOG \Device\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi %WINDIR%\system32\winload.efi You need to enter the below Eset real-time file scanning exclusions; E:\EFI\Microsoft\Boot\BCD E:\EFI\Microsoft\Boot\BCD.LOG E:\EFI\Microsoft\Boot\bootmgfw.efi E:\%WINDIR%\system32\winload.efi Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 28, 2020 Author Share Posted August 28, 2020 I am away today and the weekend, so will try this next week. However I’m skeptical because there is no actual path E:\EFI... on the E drive. windows 7 backup creates a special folder where files are stored. Opening the folder spawns a program. Also the disk image (which is where the EFI would be backed up, is what’s failing. System image goes into a different file on E:\. something to ponder and try for sure. Thx, Brian Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 28, 2020 Share Posted August 28, 2020 (edited) 1 hour ago, bmp999 said: windows 7 backup creates a special folder where files are stored. Opening the folder spawns a program. Also the disk image (which is where the EFI would be backed up, is what’s failing. System image goes into a different file on E:\. I believe that the Eset KB article assumes that Win 7 backup is running in directory/file backup mode; not image creation mode. As far as what is created in system image mode: It creates the above highlighted directory on my PC. Of note is I don't have access to this directory on my PC running as limited Admin unless I actually allowed Win permissions to be changed. Of note is even read permissions don't exist: I do know Eset has no issues scanning this directory but again I don't have an UEFI and as such, the files with issues would not be included. In any case, try the following Eset file exclusions instead and see if that resolves the issue: E:\WindowsImageBackup\EFI\Microsoft\Boot\BCD E:\WindowsImageBackup\EFI\Microsoft\Boot\BCD.LOG E:\WindowsImageBackup\EFI\Microsoft\Boot\bootmgfw.efi E:\WindowsImageBackup\%WINDIR%\system32\winload.efi Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 28, 2020 Share Posted August 28, 2020 (edited) One additional comment in regards to the Win 7 backup utility you may or may not be aware of. You can run an image backup while Win 10 is fully operational which is pretty neat. This means you could actually test these Eset exclusions when the device is active during the day. No need to wait till your scheduled task runs at night. Also if there are no issues with the image backup running when Win 10 is active during the day but this same issue occurs when only your scheduled task runs, then something else is going one here. Then there is this "tidbit" about Win 7 backup utility that makes it really unacceptable for commercial production environments that appears to be your case. The backup utility requires that Win System Protection; i.e. System Restore, be enabled. System Restore is famous for "flaking off" by mysteriously disabling itself or plain just not working. Also as I recollect, a Win 10 Feature Upgrade will disable it since that is its default setting on a clean Win 10 install. However, the main problem with the Win 7 backup utility is this. You can't backup the UEFI partition unless a system image backup is created. If the UEFI partition gets corrupted or infected by malware, you are forced to restore using a prior created system image backup. I additionally use Paragon's Professional Drive Manager to create image backups via a Win PE boot disk they provide. I have used it for years w/o a restore ever failing. It also is a full feature backup utility that allows for incremental backups; scheduling for backup activity, and the like. With Paragon you can back up anything; boot sector, partition, or the entire disk. Also Paragon creates it backups as archive files with full compression options. Finally, the boot sector, individual partitions(assuming a drive backup was performed), directories,or files can be restored from any image backup if need be. Edited August 28, 2020 by itman Link to comment Share on other sites More sharing options...
nikkinemo95 0 Posted August 29, 2020 Share Posted August 29, 2020 Hi, i read your post and found out it happend due to load. retry Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 31, 2020 Author Share Posted August 31, 2020 On 8/28/2020 at 12:09 PM, itman said: In any case, try the following Eset file exclusions instead and see if that resolves the issue: E:\WindowsImageBackup\EFI\Microsoft\Boot\BCD E:\WindowsImageBackup\EFI\Microsoft\Boot\BCD.LOG E:\WindowsImageBackup\EFI\Microsoft\Boot\bootmgfw.efi E:\WindowsImageBackup\%WINDIR%\system32\winload.efi There is no such files on E drive. Backup is stored in a special folder where there are huge .vhd files and small .xml files. If you right click WindowsImageBackup, you can enter the folder with the OPEN option. Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 31, 2020 Author Share Posted August 31, 2020 We have tested during the day using a manual run and it NEVER fails. Only fails at night. Link to comment Share on other sites More sharing options...
bmp999 0 Posted August 31, 2020 Author Share Posted August 31, 2020 We might have to consider another backup software. Thx for the suggestion. I will try and change the time the backup is done. I'm wondering if its when the computer comes out of sleep that the problem occurs (remember its not every day, but most days at 11pm). Maybe Eset starts a scan when its wakes from sleep. Link to comment Share on other sites More sharing options...
itman 1,739 Posted August 31, 2020 Share Posted August 31, 2020 (edited) 3 hours ago, bmp999 said: Backup is stored in a special folder where there are huge .vhd files These are virtual hard drive files: https://en.wikipedia.org/wiki/VHD_(file_format) . Also makes sense that the Win 7 Backup in image mode would store files as such. It is probably creating a virtual drive to process these files in restore mode. 3 hours ago, bmp999 said: If you right click WindowsImageBackup, you can enter the folder with the OPEN option. Not on my device. Like I posted, I don't even have read permissions on that directory. 3 hours ago, bmp999 said: Maybe Eset starts a scan when its wakes from sleep. Eset does not run a startup scan upon resume from sleep mode. But it does perform a startup scan at user logon time which I believe is what is happening when this scheduled backup task runs at night. Assumed is user logs off PC at end of work hours. Then PC later goes in sleep mode. When the scheduled task runs, Win actually is waking up the PC and also logging on to the user account to run the scheduled task. What account is being logged on to depends how you set up the scheduled scan. It also makes sense that Eset is probably scanning parts of the UEFI when the startup scan is running. Hence the lock issue with Win 7 backup processing. One possible solution here is to create a scheduled task that runs 5 - 10 mins. prior to the Win 7 backup scheduled task. How to do this including running a "dummy" task is described in this article: https://www.ubackup.com/windows-10/windows-10-schedule-sleep-and-wake.html . This will wake up the PC, complete the logon processing, put the device in an active state, and allow Eset startup scan processing to complete. On my PC, Eset startup scanning runs in less than a minute. Edited August 31, 2020 by itman Link to comment Share on other sites More sharing options...
itman 1,739 Posted September 1, 2020 Share Posted September 1, 2020 (edited) For those who haven't read the ubackup.com link I posted above, the developer notes that their backup solution will wake up the device two minutes prior to when the backup is scheduled to run; Quote All you need to is set a schedule backup task with wake the computer to run schedule tasks. Then, it will wake up your computer 2 minutes early. This is a clear indication they are aware of potential conflicts with AV startup scans and other potential system startup processing issues. Edited September 1, 2020 by itman Link to comment Share on other sites More sharing options...
Recommended Posts