Home AOMEI Products Support

Backupper Pro amwrtdrv.sys causes system crash

12346

Comments

  • I have enough now. It's been 18 months since this thread was opened and it still does not work. I nearly lost all data on my RAID once because of that f*cking bluescreens, the harsh disconnection of all external drives and the resulting errors in file structure. I never have bluescreens on this system, all were only because of AOMEI backupper. Letting the users beta or even alpha test single driver files which they have to download from Google Drive and replace manually... I never saw that before. It's unprofessional. So yeah... f*ck that sh*t. Sorry, but my patience is at the end. I'm searching for a better product to backup my system.
  • I am running Windows 10 Pro 64bit Version 2004 on my Desktop PC and today successfully upgraded to Backupper 6.0.0, replaced the amwrtdrv.sys driver with the version created on September 28 available at the site mentioned by Admin on page 5 above (as well as replacing the two other drivers offered on that site).  A scheduled backup then ran with no system crash.  Curiously, the standard installations of Backupper 6.0.0, without the September 28 version of the amwrtdrv.sys driver, have worked normally on two laptop PCs running Windows 10 Pro Version 2004 that I manage (one 64-bit and one 32-bit).
  • My use of Backupper started about 8 months ago, in January, on my Windows 10 system, with my main M.2 nvme SSD 500GB Samsung 970 EVO drive being backed up to an identical (but USB connected) external drive, using Backupper’s Disk Backup.  When Win 10 2004 came out several months ago, my system was upgraded to that, and continues to be current.

    Things worked pretty good at first (incremental backup with incremental scheme), with daily backups done while I was sleeping … as was my computer) but sometimes backups were skipped.  Occasionally, they would start again days later, sometimes my re-starting would get things started again, but often it was me re-installing Backupper was needed to get things going again.

    I switched to System Backup, but that didn’t help.  I thought things worked better though, if I shut down my browser and email system when I finished each night.  I still got lots of failures with “nothing” running in the background during sleep mode though.

    Later, I found that deleting the (accumulating!) back up scheduling stuff found in windows explorer  (also known as file explorer) … ([Windows]  E key) ->  This PC -> “Manage” option at the top -> System Tools/Task Scheduler/Task Scheduler Library … was part of the necessary cleanup.  Still no success though.

    I never did generate a blue screen backing up (I’ve seen them years ago, for other reasons, in my past), but I did generate some “bluescreen” events in some error logs, that matched with my system crashes that occurred during the backup attempt, and left me with a password required Windows start in the morning.

    Recently I upgraded to version 6.0.0 (the current Backupper version), but again no help.  I then installed the 3 recommended replacement drivers and something new happened … on the next morning’s crash … I couldn’t get past the “frozen” desk top showing a non-progressing backup attempt in progress, with a “busy” spinner spinning.  No response from Esc, Delete, Ctrl-Alt-Delete, or any other rational approach except holding down my computer’s physical power button for 5 to 10 seconds, to shut down everything.  The subsequent boot was successful, but without a backup.

    I then put all the pieces together the best that I could.  It works for some people, and not for others was my best clue so I looked for differences, and the only thing that I came up with was that I was using System backup, and some that were having success said that they were using Disk backup.  It wasn’t much, but it was something, so I switched back to Disk Backup (still using the 3 replacement drivers), and so far things are working fine.

    Nothing for sure yet, because it’s only been 3 successes in a row for an overnight backup, but one more will put me in an “unusually long” win streak (I’ll let you know right away if I have a failure).

    Unfortunately, there is one other thing that happened on the day that I switched to Disk Backup, and that is that my Windows 10 system automatically installed a new replacement driver for my Samsung SSD drives on the same day (Oct 7, 2020).   If I do see success, it might be because of the Samsung Drivers.  If anyone is using Samsung SSD’s is now seeing an improvement in backup completions, let us know.

    If my stuff starts failing again, at least we have another story to build on, to try and pin down where the problem lives.

  • yh2827: FYI, my Desktop PC, on which I got scheduled System Backups with Differential Scheme running again today on Backupper Pro 6.0.0 as I described earlier, is using a Samsung SSD 840 EVO 1TB system drive.  One of the two laptop PCs I mentioned has a Samsung SSD 850 EVO 500GB system drive, and the other has a Samsung 860 EVO 500GB system drive.  Backupper Pro 6.0.0 has been doing System Backups with Differential Scheme on both of those laptop PCs for several weeks after standard upgrades to Backupper 6.0.0 without need to manually update any AOMEI drivers.  The SSDs use Microsoft driver Version 10.0.19041.1 dated 6/21/2006.

    I forgot to mention earlier that I am using Backupper Pro, which does automatically delete older backup images when more than a specified number number of images (in my case 7 for each machine) accumulate on the external hard drive that I use to store the images.  I have never tried the Disk Backup method that you mentioned.

  • UpBear: Interesting, My USB and SSD drivers currently in use (like yours) are the 2006 Microsoft driver.  The update I received must have just replaced the (unused) Samsung driver file with a fresher version, so the early success that I'm seeing is NOT from the driver update.  Were any of your systems crashing on attempting a wake from sleep backup before, and are now apparently fixed?  If so, can you spot a difference that is associated with repair with the 3 AOMEI drivers that your other systems didn't need?

    Also your backup is differential and mine is incremental.  Perhaps we will be able to rule out that this difference is related to the problem too.  For a single physical drive being backed up ... System and Drive backups are supposed to be the same, but with Drive having some extra partition and/or extra drive selection capability that I don't use.  I am still prepared to be surprised if System vs Drive makes a difference in the crash problems seen ... it's just the only difference that I see in my limited testing.
  • yh2827: I have never used the wake from sleep option for starting backups, as all three of my systems remain plugged in and "awake" until the scheduled backup starts and completes.  The desktop PC remains on even after the backup is done, while the laptop PCs are shut down after their backups via a batch file run by a post-command I specified in the backup task (Edit Backup > Options > Command > Post-command).  I use the batch file to check whether the backup run ended after 6:00 AM, in which case I don't want the machine to shut down.

    I have no clue as to why both laptops run scheduled backups normally under Backupper Pro 6.0.0, despite the fact that the standard installation of 6.0.0 puts a version of the amwrtdrv.sys driver last modified on 1 Sep 2017 with a size of 37.4 KB into the Windows/System32 folder of both laptops.  If that version of the driver is left in place on my desktop PC running 6.0.0, I get a blue screen system crash immediately whenever a scheduled backup launches.  The version of amwrtdrv.sys created on 28 Sep 2020 with a size of 30.5 KB (available from https://drive.google.com/drive/folders/1sYFjaeNoaIe2RKFqsDWjdBONvjlftF8z) is clearly what allows my desktop PC to run scheduled backups normally under Backupper Pro 6.0.0.

  • edited October 2020
    But ist seems, that amwrtdrv.sys created on 28 Sep 2020 is an improvement. Done 16 scheduled system backups so far without a BSOD. A miracle 

    Also i set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag properties of network service on full access
  • Hi SirRudolphy
    I get as far  in the Registry Editor as:
    Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag
    but am not clear on how to set full access on at that point.

    Some people have reported the new drivers not working for them.  It is possible (in concept) that "A" works fine, and so does "B", but we get a system crash with both A and B being used. Can you tell us about your setup (your A's and B's).  These could include using a scheme (if so ,,, which scheme, and which options within the scheme.  Which Backupper (the current 6.0?), does backup start during computer sleep mode, and if so, what other background stuff was active when sleep mode started, and anything else that you think we might want to consider.

    As you are seeing a success, your information could be quite helpful.  Thanks.  
  • edited October 2020
    @yh2827  Check the Event Viewer. Aomei Backupper produces one serious VSS error (Id 12 and 8194) after the other. Due to the granted full access in the registry this has changed.

    I create my incrimental backups as follows:
    Windows 10 Pro 2004 latest updates
    Disk backup of multiple partitions
    Event based. The event is set at 00:01. At this time the PC is completely shut down. So the backup will be done at the next system start

    Var A
    Version 6.0.0 with the drivers from the original installation file
    BSOD in about 33 % of all cases

    Var B
    Using instead of original drivers the drivers from 28.09.2020
    Currently 14 executed backups without BSOD

    I used to have problems when the incrimental backup chain was completed and the next full backup was due. This is the case for me the day after tomorrow, because I defined 16 backups as one chain. I am curious and will report.
  • I may have full access granted, but I don't know.  I don't have an ID 22 issue, but I do see ID 8194 that you mention as a historical problem.  Here are the multiple AOMEO related serious error groups that show up in my Event Viewer logs ... 

    [System] ID 7043  (June-23 - Oct 3)  The AOMEI Backupper Scheduler Service service did not shut down properly after receiving a preshutdown control.

    [Application] ID 13  (June 12 - Oct 3)  Volume Shadow Copy Service information: The COM Server with CLSID {4e14fba2-2e22-11d1-9964-00c04fbbb345} and name CEventSystem cannot be started. [0x8007045b, A system shutdown is in progress.

    [Application] ID 33  (Sep 1 - Oct 7) Activation context generation failed for "C:\Program Files (x86)\AOMEI Partition Assistant\MFC80U.DLL". Dependent Assembly Microsoft.VC80.MFCLOC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0" could not be found. Please use sxstrace.exe for detailed diagnosis.

    [Application] ID 8193  (June 20 - Oct 3)  Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance.  hr = 0x8007045b, A system shutdown is in progress.

    [Application] ID 8194  (June 10 - Sep 4)  Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x80070005, Access is denied.  This is often caused by incorrect security settings in either the writer or requestor process.

    None of them have shown up since Oct 7, when I installed the new drivers (and started my most recent backup group fresh.  The new AOMEI drivers do appear to be a necessary part of the solution (although some users that installed them are still reporting problems).

    My 5 cycle daily scheme now holds backups for a full, plus 4 incremental, plus the next full.  Tomorrow puts me over the hump.  With success I will start adding  my Chrome browser to the overnight sleep ... then with success, my Outlook mail will try to get through the night.
     

  • Yh2827

    I got the events 13, 8193, 8194 and 12293 since I am using AOMEI Backupper. Each caused by AOMEI Backupper. It seems, some errors appears even if I only started the program without doing a backup. 

    Unfortunately, I also have some error entries since I have been using the new drivers. But these do not lead to BSOD.

    I am with you, the new drivers are part of the solution. But I hope that the TECHNICIANS OF Aomei will finally find a solution and not abuse us paying customers as beta testers.

    I am still convinced about the program and the positive features outweight. I also use ACRONIS TRUE IMAGE 2021 and EASEUS Todo Backup 12.8 (all paid versions). Easeus is the most stable program, but I don't like the emergency environment that much, so AOMEI Backupper is still my first choice.
  • edited October 2020
    Can't copy .SYS files ... Files are in use  (Stopped AOMEI service)

    C:\Users\xxxxx\Downloads>copy am*.sys c:\windows\system32
    ambakdrv.sys
    Overwrite c:\windows\system32\ambakdrv.sys? (Yes/No/All): y
    ammntdrv.sys
    Overwrite c:\windows\system32\ammntdrv.sys? (Yes/No/All): y
    The process cannot access the file because it is being used by another process.
    amwrtdrv.sys
    Overwrite c:\windows\system32\amwrtdrv.sys? (Yes/No/All): y
    The process cannot access the file because it is being used by another process.
            1 file(s) copied.
  • edited October 2020
    Entilza5  there was a procedure posted in this thread a while ago, that included stopping some files being in use (and how to do it).  I fought with it a bit to get it to work, but ultimately succeeded.  I then edited it somewhat, to clear up a few things that had confused me, and saved it for possible future use if I needed to do it again.  It's below.

    Before using it though ... there was an earlier version of the "new" files, that got updated a couple of weeks or so ago.  If you got the 3 drivers that you have more than a week or two ago,  I would recommend that you download the three drivers again.  They are at the same linked location that you would have used previously, and have the same names.  That link is in the text below too.

    Here are the instructions that got me through:

    =-=-=-=-=-=-=-=-=-=-=-=

    As for BSOD problem during backup, please download the new drivers: ambakdrv.sys, ammntdrv.sys, amwrtdrv.sys from the link.   https://drive.google.com/drive/folders/1sYFjaeNoaIe2RKFqsDWjdBONvjlftF8z

    We will be replacing the 3 drivers (same names) that were installed in C:\Windows\System32 when Backupper was last updated, with the new ones … here is how:

    Generally, the ambakdrv.sys file can be replaced directly, so go ahead with this.

    For the other two drivers, we must first stop them running, then re-start them after being replaced.  In Windows, do this by searching for CMD (in the search area beside the “start button”), then select Run as Administrator from the presented Command Prompt app,

    At the App's bottom line ( its "prompt")


    type and then enter:   net stop ammntdrv

    then type and then enter:   net stop amwrtdrv

    Assuming replies indicating success:

    then copy the ammntdrv.sys and amwrtdrv.sys to replace those two installed drivers,  This is done back in your normal windows world (not in the Administrator Command Prompt screen)

    then back at the command prompt again:

    type and then enter:  net start ammntdrv

    then type and then enter:  net start amwrtdrv

    After that, shut everything down, and reboot the computer before the next Backupper run to see if the BSOD (system crash) problem is resolved.
    =-=-=-=-=-=-=-=-=-=-=-=
  • Speaking of "here was a procedure posted in this thread a while ago":
    I tried this to update to Backupper Pro 5.9 a while ago and ended up with a BSOD and afterwards with a dead machine. I couldn't even restore from by AOMEI backup because I had the recovery on a stick instead on CD which for whatever reason wasn't recognized by my machine while booting (the BIOS  was set up correctly to do this). Whatever, by pure coincidence I had a single restore point which rescued me.
    I tried several things afterwards and at least now I am using version 5.8 with the "test" drivers.

    Which brings me to my message:
    a) Things can go wrong. Be careful.
    b) I will be on v5.8 forever and ever as long as I don't read the official announcement "This new version now includes the updated system drivers that led to nasty crashes in the previous versions." I don't need 5.9, 6.0, 6.1 and so on as long as they produce more problems as they solve. If the release is delayed because of compatibility issues with older Windows versions, just release two different versions, one of them having the updated drivers.


  • Well folks, Backupper Pro 6.1.0 became available this week, and I had hopes that it would include the recent drivers that avoid the blue screen crash during scheduled backups.  On October 11, after those newer drivers fixed the problem in Backupper 6.0.0 on my desktop PC running Windows 10 Version 2004, I had asked the AOMEI Support Team: "My continuing concern is that future Backupper upgrades may include the same problem version of the amwrtdrv.sys driver.  Will future upgrades include the version of that driver that does work with Windows 10 Version 2004 or will I have to again manually apply the September 28 version of that driver after future upgrades?"  A day later I got the seemingly clear reply: "We will update the drivers in after version. So, you don't need to replace manually."

    But, after upgrading to Backupper Pro 6.1.0, I noticed that the same older version of amwrtdrv.sys, as well as ambakdrv.sys and ammntdrv.sys, had been re-installed into the Windows/System32 folder.  As with previous versions of Backupper Pro, scheduled backups on the laptop PC that use for testing run normally, even with the older drivers in place.  But on my desktop PC the blue screen crash again appeared about a minute after Backupper Pro 6.1.0 launched a  scheduled backup.  After I manually re-installed the driver versions available at https://drive.google.com/drive/folders/1sYFjaeNoaIe2RKFqsDWjdBONvjlftF8z, including especially the 30.5 KB version of amwrtdrv.sys from September 28, scheduled backups on the desktop PC again ran normally.

    By the way, Yh2827, thanks for your excellent documentation of the process for replacing the three drivers.  That's the process I've been using, but I had not bothered to write it down and had to think hard about it whenever it was needed.  Looks like it will be needed for some further period.
  • @admin

    This is just embarrassing! I think AOMEI is more likely to provide compatible drivers for Windows XP than for Windows 10 2004, and I'm so disappointed that version 6.1.0 still contains these damn old, incompatible drivers! Give me my money back!!!
  • @SirRudolphy Sorry, currently the new drivers only support Windows 10 systems.
  • @admin

    You missanderstood me! Why does the new release 6.1.0 still does not contains the new drivers for Win 10? Thats nonsense!
  • @admin

    What we have ALL been expecting is that new releases of backupper would incorporate the new Win10 drivers. 

    If AOMEI still wants to support legacy versions of Windows (something even Microsoft has stopped doing!), then why could the installation program not detect what version of Windows is running and install the appropriate drivers?
    So for the majority that run on Win10, we would get the newer, and compatible drivers.

    Can you represent this to your technical staff please? I would not have thought that it is that complicated.....

  • So sorry for the inconvenience. We will add the new drivers in the next version 6.1.1. It will be released asap.
  • @admin

    Thanks....  We will wait for your next release.

    Regards
  • When 6.1.1 is released, please let us know if the drivers are compatible with various editions of Windows server.  (At work, we have a tech pro license.) Thanks.
  • @Wssddc, which server system are you using? It is compatible with the various editions of Windows server.
  • @admin

    Can't wait to get the new release 6.1.1 including the new drivers in the installation package :-)

    Until today no BSOD with the new drivers appeared. They actually seem to work fine for Win 10 Pro 2004. 

    There is one thing I am still curious about: In 5 days there will be an automatic cleanup of the image versions. Hopefully this will work without errors. I will report. 

    Many thanks for the support.
  • @admin Server versions are 2012R2 and 2019, workstations are now all Win/10. Most of the discussion about drivers has been Win/7 vs Win/10.  You were at version 4.6 when we purchased our license.  Workstations, then Win/7, were not a problem but the one server we put it on would crash every week or two.  The frequency of crashing gradually dropped, I assume because of Windows updates.  We've been waiting for the driver problem to be resolved before updating workstations or deploying to any other servers.
  • @Wssddc, Please try to update the latest version of AOMEI Backupper and replace the drivers. And then, please check if you will get the computer crash again. 
    Please download the new drivers: ambakdrv.sys, ammntdrv.sys, amwrtdrv.sys from the link.
    And then, please put the three drivers to C:\Windows\System32 to replace. 
    Generally, ambakdrv.sys can be replaced directly. For another two drivers, for replace them successfully, please first stop run "CMD" as Administrator to open Command Prompt, 
    then type into "net stop ammntdrv", "net stop amwrtdrv"
    then copy the ammntdrv.sys and amwrtdrv.sys to replace, 
    then type into "net start ammntdrv", "net start amwrtdrv".
    After that, please reboot the computer, then check if you will get the crash problem again.
  • Amazingly, I found this puppy in the dumpster! https://www.asrock.com/mb/Intel/D1800B-ITX/

    Original Windows 10 working like charm!

    Looking forward to testing backupper with the new drives on this cpu.



  • @admin Even after stopping the service, I was not able to overwrite amwrtdrv.sys.  But I was able to rename it and copy in the replacement.  After rebooting, I was able to delete the renamed file.

    We're 100% work from home these days due to covid-19, so the install was done on the Win/10 machine I use to make remote connections from home.  As far as testing on a server, the frequency of failures has dropped so much that I can't really remember when we had the last crash.  Workstation crashes have been rare enough to not be noticed among all the other things that can go wrong with them.  That's why we haven't been complaining as loudly as others on this forum.

    Two 2012R2 servers had Backupper 4.6, but one of those was retired this week and I need to consult with at least one other person before updating on the other server, so testing will be delayed.

    I think we can automate workstations upgrades using Ivanti Security Controls (the /verysilent switch seems to work for an unattended install), but it would be a lot easier if we didn't have to do the replacement of 3 .sys files.
  • @Wssddc, We will send you the new version with including the new drivers asap.
  • Wir warten alle auf die neue Version 6.1.1 mit den hoffentlich signierten Installationsdateien und gültigen Zertifikaten und den neuen Treibern.

Sign In or Register to comment.