Home AOMEI Products Support

Backupper Pro amwrtdrv.sys causes system crash

12467

Comments

  • Got the BSOD the other day with fresh install of v5.9.  Can you imagine? This was the first time I had a BSOD in all my years with Windows NT, 7 and 10. I was not impressed and immediately removed the program from my computer.

    This product is unstable and as I can see from the posts in this forum, the developers are not equipped to support their product (e.g. no ticket system). 

    Got back to my old Symantec System Recovery 2013 R2 which is far more stable and intuitive (but unfortunately discontinued).

    Good luck to all!
  • edited August 2020
    Just uninstalled Backupper, manually deleted the 3 driver files, rebooted and installed Backupper 5.9. But it again installed the OLD amwrtdrv.sys from 2017. I use Windows 8.1. So what now? Is it possible to use the amwrtdrv.sys from Windows 10 and simply copy it to the system?
  • edited August 2020
    5.9 same BSOD and the Sync side of it messes up also (I made multiple posts on topic) so I either go back to 5.8 and skip the backup side due to same BSOD but use it to Sync to my ext HDD or give up on this software.
  • As for the BSOD problem, please download the fixed version from here: https://drive.google.com/file/d/1Ns3vvcqTBgxnQGBaKdFdTPdnh3Dtdw5p/view?usp=drivesdk
    Please first uninstall AOMEI Backupper you have installed via Control Panel, then delete ambakdrv.sys, ammntdrv.sys, amwrtdrv.sys under C:\Windows\System32, reboot the computer, install the new version we sent.
    The fixed version is based on v5.8. After installation, you can update to v5.9 from the program automatically. It will keep using the new drivers.
    For Win 7 and win 8 environment, there still are some issues with the drivers. After installing the fixed version, please set "Disable driver signature enforcement" on reboot computer. 
  • I have already tried that unless your saying this is another newer fix.

    What about my Files Sync issue, it was fine in 5.8 not 5.9
  • @Jh30uk Did you still get the BSOD problem when you use the fixed version? Or, did you get the BSOD again when you upgrade to v5.9 manually?
  • Both if this is the fix for a week ago, but updating to 5.9 gave me those HDD thrashing Sync File issues.
  • edited August 2020
    After this installation was successful I could verify that the three am*drv.sys files from C:\Windows\System32 were new versions:

    2019-07-04  14:29            51.120 ambakdrv.sys
    2020-03-28  16:16           171.952 ammntdrv.sys
    2020-06-08  06:00            43.376 amwrtdrv.sys

    Then I got prompted to upgrade to version 5.9 and I upgraded to version 5.9.
    After this upgrade finished all three am*drv.sys files were backlevel from 2016 and 2017.

    Is this how this is supposed to work?
    I don't think so.

    What do I have to do to keep the newer versons of the driver files?

    I tried to copy the new versions which I saved to a temp directory back to C:\Windows\System32.
    But I get the error message:

    The process cannot access the file because it is being used by another process.

    What should I do?

  • @Jh30uk, please try to recreate the sync task on v5.9 and check if the sync will continue to work.
  • @Gagome Did you perform automatic upgrade from the version to 5.9? Or, uninstall the old version manually and then install the latest one?
  • I had 5.9 installed and encountered the BSOD with amwrtdrv.sys when the scheduled backup started.
    I found your post above with the fixed version 5.8.

    I did uninstall 5.9 and deleted all three am*drv.sys files from C:\Windows\System32.
    Then I rebooted.
    Then I installed the fixed version 5.8.
    The three am*drv.sys files had now newer dates from 2019 and 2020.

    I started Backupper and it displayed a message that a new version 5.9 exists and asked if I wanted to upgrade. I clicked yes and after the upgrade was done all three am*drv.sys files in C:\Windows\System32 had the old date from 2016 and 2017.

    I had copied all three am*drv.sys files to a temp directory before I upgraded. And I tried to copy them back to C:\Windows\System32 after the upgrade but only the file ambakdrv.sys could be copied. The other two resulted in the error message:

    "The process cannot access the file because it is being used by another process."

    Obviously the upgrade process from 5.8 and 5.9 doesn't work like you said in your post above. You said "It will keep using the new drivers". But it replaced the newer files with the older versions.

    I can boot from a maintenance Win10 partition and then copy the newer files to C:\Windows\System32. But I am not sure if this is the correct way to fix this.
    I wonder why the newer am*drv.sys files are not part of 5.9?

    Do you have a suggestion what I should do?

    Thanks.

  • @ Admin, I have done that already multiple times and I am sick of it messing my PC up, if that ext HDD was an SSD it would be well worn by now.

    Unless you fix the BSOD and the Syncing Issue 5.9 introduced I cannot use this software.
  • @Gagome, Sorry for the inconvenience. It indeed replaces the drivers when reinstall/update the program. We have submitted the problem to our technician.
    In addition, after install v5.9, you can replace the drivers manually.  Please run "CMD" as Administrator to open Command Prompt, then type into "net stop ammntdrv.sys", then copy the new ammntdrv.sys to replace, then type into "net start ammntdrv.sys".
  • I guess you meant "net stop ammntdrv".
    Running "net stop" with the driver names with .sys extension doesn't work. But running "net stop" with just the driver names without .sys works and I could successfully copy the newer am*drv.sys files to C:\Windows\System32 and restarted the drivers ammntdrv and amwrtdrv.

    When I compare all three driver files between 5.9 and your fixed 5.8 version only the file amwrtdrv.sys is different. The other two are identical with the previous version.
    So, only this driver should be replaced.

    Now I have recreated my backup schedules (which all were gone after the BSOD) and I will see if it will work now.
    Thanks for the fixed version.
    But you should include the fixed amwrtdrv.sys file into the next version.
  • @Gagome, Yes, it should be "net stop ammntdrv". We will add the drivers to the new version asap.
  • It seems that the new drivers are still NOT present in version 6.
    Version 6 still causes BSODs in WIndows 10 (latest version 2004, uptodate).
    Had to replace the driver manually (in the way mentioned above) for Backupper to make automated and scheduled backups.
    Problem now existing for almost 4 years.
  • edited September 2020
    6.0 why make a new major build with same old bugs?

    Not tried backup but the Sync Files (Real Time)  still hammers HDD full speed after 100% complete and even on a reboot, 5.8 did not do this so 5.9 changes caused it.
  • In short they are exchanging "6" for "half a dozen".
    I've never seen a program take so long to fix in my life.
  • Tried a Basic Sync (it has more settings than the other more advanced versions), can only run on Schedule (Schedule did not work on 5.8 so I opted for Real Time and it was fine).

    It took ages to get to 100% then simply started over so running a loop even though next run is not till 4am (30mins away).

    Going by above comments I am not even going to bother with a Backup as no more BSOD wanted.
  • @Jh30uk
    "It took ages to get to 100% then simply started over so running a loop even though next run is not till 4am (30mins away)."----Sorry that we don't quite understand. Could you explain it in more detail?
  • As for BSOD problem during backup, 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 BSOD problem.
  • ' ADMIN as soon as the Sync 100% Completed it simply started again from 1%, it ran for 6 hours this time before I stopped it. and HDD never stopped getting trashed.

    If backup drives were SSD's they would be worn out by now after builds 5.9-6.0.

    I am back on 5.8 and Real Time Sync is 100% working as it should.

    I do not want to take over this topic so you can read my previous ones as I gave very detailed information there.

    5.8 has a setting called "Fast or Quick" < I cannot see it now unless I make new Sync, this means it only updates new or changed files if not checked it has to do the whole Sync again even though it is only verifying my files as I already have then on the HDD.

    I am not going to delete a massive amount of file every time to let it Sync.

    I do not see this setting in 5,9 or 6.0 unless I missed it.
  • @Jh30uk, Actually, the "Fast Synchronization" on v5.8= don't check "Vertify the intergrity of files in the destination directory during synchronization" on V5.9/6.0. Could you uncheck the option on v6.0 and then check sync again?
  • edited September 2020
    I tried it all before and I am staying on 5.8 and forgetting backup, I cannot sit and wait hours and hours on HDD thrashing then doing same when it completes or PC restarts.

    Why would I not check that setting as the way it is worded that is what I want, I do not need it to redo Sync, just verify if files are the same and if any hanged and Sync if needed,

    I do not remember seeing that setting in 5.9 or 6.0.

    It even broke System restore like last time I uninstalled it, I had to replace the Reg Key fore the Upperfilters because aomeitech takes over that key.

    I do not mind faultfinding but you cannot even fix the BSODS issue that is years old, now you break the File Syncing from 5. onward.
  • Please fix this BSOD problem ONCE AND FOR ALL!!!
    I have a SERVER license and the app is restarting the server every weekend when the backup is starting from scheduler.
    Please stop asking us to replace driver files in system32, is not a professional way to fix the problem.
    Thanks!
  • @Jh30uk, As fot the file sync feature, could you allow us to offer a remote assistant?
    "It even broke System restore like last time I uninstalled it, I had to replace the Reg Key fore the Upperfilters because aomeitech takes over that key."---Did you mean that it brokes windows system restore points? Could you explain it in more detail? 
  • I have already said no to that, I know what I am doing as it is not rocket science and works in 5.8 so its your changed to 5.0 onward to blame.

    I will try and explain in more detail alter but I feel their is a language barrier.
  • @Jh30uk, can you please open a new thread for your matter?

    BSOD while scheduled backups:
    In my case it looks like with version 6.0 and the old drivers included in the installation package scheduled backups are currently performed without BSOD so fair.

    But if I use version 6.0 with the new drives, which were offered for download a few messages before, the program quit to backup and give  strange error messages, but no BSOD.
  • edited September 2020
    Typo above I meant 5.9 onward

    Already did and same as the BSOD there is no point they do not seem to be able to fix it.
  • @SirRudolphy, What error messages did you get? Could you give us a detailed description?
Sign In or Register to comment.