Home AOMEI Products Support

Backupper Pro amwrtdrv.sys causes system crash

24567

Comments

  • FYI, I am getting the same problem on W10 Home 1903 18362.175.

    On Sat 15/06/2019 1:14:03 PM your computer crashed or a problem was reported
    crash dump file: C:\WINDOWS\MEMORY.DMP
    This was probably caused by the following module: amwrtdrv.sys (amwrtdrv+0x1845)
    Bugcheck code: 0x3B (0xC0000005, 0xFFFFF8067C031CB4, 0xFFFFFD0B0BBA9DE0, 0x0)
    Error: SYSTEM_SERVICE_EXCEPTION
    file path: C:\WINDOWS\system32\amwrtdrv.sys

    Will wait until there is a proper fix, rather than the manual workaround(s).
  • Same here on Win10 Pro, 1809, 17763.592
    Attaching MS debugger info:
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    SYSTEM_SERVICE_EXCEPTION (3b)
    An exception happened while executing a system service routine.
    Arguments:
    Arg1: 00000000c0000005, Exception code that caused the bugcheck
    Arg2: fffff8034431aad4, Address of the instruction which caused the bugcheck
    Arg3: ffff9f043319adc0, Address of the context record for the exception that caused the bugcheck
    Arg4: 0000000000000000, zero.
    
    Debugging Details:
    ------------------
    KEY_VALUES_STRING: 1
    
        Key  : Analysis.CPU.Sec
        Value: 1
    
        Key  : Analysis.Elapsed.Sec
        Value: 10
    
        Key  : Analysis.Memory.CommitPeak.Mb
        Value: 63
    
    
    PROCESSES_ANALYSIS: 1
    SERVICE_ANALYSIS: 1
    STACKHASH_ANALYSIS: 1
    TIMELINE_ANALYSIS: 1
    
    DUMP_CLASS: 1
    DUMP_QUALIFIER: 401
    BUILD_VERSION_STRING:  17763.1.amd64fre.rs5_release.180914-1434
    SYSTEM_MANUFACTURER:  MSI
    SYSTEM_PRODUCT_NAME:  MS-7850
    SYSTEM_SKU:  To be filled by O.E.M.
    SYSTEM_VERSION:  1.0
    BIOS_VENDOR:  American Megatrends Inc.
    BIOS_VERSION:  V4.11
    BIOS_DATE:  02/16/2016
    BASEBOARD_MANUFACTURER:  MSI
    BASEBOARD_PRODUCT:  Z97 PC Mate(MS-7850)
    BASEBOARD_VERSION:  1.0
    DUMP_TYPE:  1
    BUGCHECK_P1: c0000005
    BUGCHECK_P2: fffff8034431aad4
    BUGCHECK_P3: ffff9f043319adc0
    BUGCHECK_P4: 0
    
    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.
    
    FAULTING_IP: 
    nt!IofCallDriver+44
    fffff803`4431aad4 488b4908        mov     rcx,qword ptr [rcx+8]
    
    CONTEXT:  ffff9f043319adc0 -- (.cxr 0xffff9f043319adc0)
    rax=ffffd18ee77c76a0 rbx=0000000000000000 rcx=0000000000000000
    rdx=ffffd18ee77c74b0 rsi=0000000000040000 rdi=ffffd18e0b1fc520
    rip=fffff8034431aad4 rsp=ffff9f043319b7b0 rbp=ffffd18e0c556da0
     r8=0000000000000003  r9=0000000000000000 r10=ffff800000000000
    r11=ffffd18ee77c76e8 r12=ffffd18ee77c74b0 r13=ffffd18e0c556c50
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei ng nz ac po cy
    cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010297
    nt!IofCallDriver+0x44:
    fffff803`4431aad4 488b4908        mov     rcx,qword ptr [rcx+8] ds:002b:00000000`00000008=????????????????
    Resetting default scope
    
    BUGCHECK_STR:  0x3B_c0000005
    CPU_COUNT: 8
    CPU_MHZ: fa0
    CPU_VENDOR:  GenuineIntel
    CPU_FAMILY: 6
    CPU_MODEL: 3c
    CPU_STEPPING: 3
    CPU_MICROCODE: 6,3c,3,0 (F,M,S,R)  SIG: 25'00000000 (cache) 25'00000000 (init)
    BLACKBOXBSD: 1 (!blackboxbsd)
    
    BLACKBOXPNP: 1 (!blackboxpnp)
    
    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT
    PROCESS_NAME:  ABCore.exe
    CURRENT_IRQL:  0
    ANALYSIS_SESSION_HOST:  FRIKAZOID
    ANALYSIS_SESSION_TIME:  06-24-2019 17:14:12.0486
    ANALYSIS_VERSION: 10.0.18869.1002 amd64fre
    LAST_CONTROL_TRANSFER:  from fffff803520e1845 to fffff8034431aad4
    
    STACK_TEXT:  
    ffff9f04`3319b7b0 fffff803`520e1845 : 00000000`00000000 ffffc600`00000000 ffffd18e`0c556da0 00000000`00040000 : nt!IofCallDriver+0x44
    ffff9f04`3319b7f0 fffff803`520e1b6a : 00000000`03a00000 ffffd18e`0b1fc520 ffffd18e`e814e590 ffffc600`00028158 : amwrtdrv+0x1845
    ffff9f04`3319b870 fffff803`4431aae9 : ffffd18e`ef951e98 ffffd18e`ef951c60 ffffc600`3198c021 ffffd18e`0c3f3080 : amwrtdrv+0x1b6a
    ffff9f04`3319b8a0 fffff803`44898fa1 : ffff9f04`3319bb80 ffffd18e`0b1fc520 00000000`00000001 ffffd18e`e814e590 : nt!IofCallDriver+0x59
    ffff9f04`3319b8e0 fffff803`44897ce8 : ffffd18e`00000000 ffffd18e`e814e590 ffff9f04`3319bb00 ffff9f04`3319bb80 : nt!IopSynchronousServiceTail+0x1b1
    ffff9f04`3319b990 fffff803`44467188 : 00000000`00000660 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtReadFile+0x688
    ffff9f04`3319ba90 00000000`778b1cbc : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
    00000000`04cbf308 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x778b1cbc
    
    
    THREAD_SHA1_HASH_MOD_FUNC:  e5928a7b24684413227c6623da4d5e557cc28651
    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  6af861c7443c51d8d21fddfc3d40fae4435bc7e6
    THREAD_SHA1_HASH_MOD:  dcf8d025da31974ffb0817dec4f1ac8bf0cbb79f
    
    FOLLOWUP_IP: 
    amwrtdrv+1845
    fffff803`520e1845 3d03010000      cmp     eax,103h
    
    FAULT_INSTR_CODE:  1033d
    SYMBOL_STACK_INDEX:  1
    SYMBOL_NAME:  amwrtdrv+1845
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: amwrtdrv
    IMAGE_NAME:  amwrtdrv.sys
    DEBUG_FLR_IMAGE_TIMESTAMP:  50d967ee
    STACK_COMMAND:  .cxr 0xffff9f043319adc0 ; kb
    BUCKET_ID_FUNC_OFFSET:  1845
    FAILURE_BUCKET_ID:  0x3B_c0000005_amwrtdrv!unknown_function
    BUCKET_ID:  0x3B_c0000005_amwrtdrv!unknown_function
    PRIMARY_PROBLEM_CLASS:  0x3B_c0000005_amwrtdrv!unknown_function
    TARGET_TIME:  2019-06-24T14:01:04.000Z
    OSBUILD:  17763
    OSSERVICEPACK:  0
    SERVICEPACK_NUMBER: 0
    OS_REVISION: 0
    SUITE_MASK:  272
    PRODUCT_TYPE:  1
    OSPLATFORM_TYPE:  x64
    OSNAME:  Windows 10
    OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS
    OS_LOCALE:  
    USER_LCID:  0
    OSBUILD_TIMESTAMP:  2021-11-07 15:58:42
    BUILDDATESTAMP_STR:  180914-1434
    BUILDLAB_STR:  rs5_release
    BUILDOSVER_STR:  10.0.17763.1.amd64fre.rs5_release.180914-1434
    ANALYSIS_SESSION_ELAPSED_TIME:  29bb
    ANALYSIS_SOURCE:  KM
    FAILURE_ID_HASH_STRING:  km:0x3b_c0000005_amwrtdrv!unknown_function
    FAILURE_ID_HASH:  {9aabe578-eb6f-176c-a9e8-abe7a444eadd}
    Followup:     MachineOwner
    ---------
  • This thread is from March, now we have June and still no fix. Wow. No "We are aware of the problem", no "We are working on it", no explanation whatsoever if there will EVER be a fix. My trust in this product is gone now. The worst thing a company can do is to NOT communicate with the customers. Because that sends a message like "We don't give shit about your problems, we just want your money".
  • Hi everyone, sorry for the long delay. We have a patch of the BSOD issue, please test the patch to see if it works.
    https://drive.google.com/file/d/1gBd3bf2vst-Gkv6b5KL5G41_OwpqjIsm
  • Hey all, Did Version 5.0 fix this issue? I need to know for sure. It is not listed in the change log that I found?

    Thank you in advice
  • I'll give it a try. Looks better now, hope it also works better ;) .
  • No, version 5.0 didn't fix this issue, please continue testing the patch.
  • Why don't you release a Beta which has the patch integrated? The method is rather complicated and I don't want to install an unsignatured driver.
  • Thank you guys. I am NOT testing the patch either but am waiting to hear that this is fixed. I am not a tester. I am a end user that wants this software to be fixed before purchasing it again.
  • edited July 2019
    @slf exactly my opinion. Although I know how to do all that command line stuff, I simply don't want to do the work the Aomei team has to do. That's not my job as a customer and end user. If it would be an installable patch... ok, maybe. But not this way.
  • Maybe in the next version it will be fixed also the bug regarding NTFS permissions. No more Q-Dir to browse the image from other users..

  • Lol! Program now live to be beautiful like a peacock!
    We do not want anything beautiful Aomei but a functional program.
  • Well, if it looks beautiful AND works, it's also ok :smiley:
  • I tested the patch @ W10 1809.
    More than 300 backups (schedule backup every 60 minutes). No errors, no BSOD. For me it works.
    Please test the patch, because they will signed the driver when more user say it's ok.

  • We see crashes when doing nightly backups on a particular production server once a week or so. So to be confident that the problem is fixed, we'd need several weeks of no crashes. We really can't disable driver signing on a production server for that long. A test server, where disabling signing would not be too bad, just doesn't crash. I had it do a backup every 10 minutes for 24 hours and it never failed. It's good to know that a fix is in the pipeline, but until it's signed, we can't do any useful testing. We've been holding off on full deployment even on workstations although we haven't seen crashes on the few that are using Backupper.
  • I installed the patch and subsequently I had another crash, which is rather disappointing.  I have the impression that the crashes occur when using Windows Scheduler to run Backupper, but not when using the internal scheduling service.  I will be testing this in the next few days, but in the meantime I'd like to see what other users experience is with respect to this.  I prefer to use Windows Scheduling service so it wakes up the computer from hibernation to run the Backup; also, to have the option to reattempt the operation a few times if it fails for some reason.  I don't think Backupper scheduling service does either one of those.
  • Done.  I used a couple of times and it didn't crash. I will be testing it for a few days and reporting.
  • I have been running scheduled backups for a week now without any BSOD.  It looks like the patch solved the problem.  Now I would like to be able to tell my clients, to whom I have recommended Backupper, that the problem is solved, but I cannot expect them to be able o willing to use Recovery Mode Startup options, so it is essential to get a patch that does not have the requirement of disabling Driver Signature Enforcement.
  • GAR123, Thank you for doing the testing you did. I wish they showed that they are testing this and not just relying on you/us to do their beta testing for them. This problem was around for some time and it took a really long time to fix it.
  • So, is there a schedule for the patch to be released formally?
  • Already solved? We can't stand to wait any longer.
  • Their communication is as bad as their problem management...
  • @Willmore

    To pass this topic again takes another week!
    Unfortunate.
  • The release notes for 5.1 say "Fixed issue: the program crashes because of hundreds of thousands of files in NAS/Share folder."  Is that the problem discussed in this thread or something else?
  • I guess it's something else.
  • I cannot understand why the patch that solves the amwrtdrv.sys BSOD bug was not included in 5.1 -- we have been waiting long enough, it seems very clear that the patch works, we need it in production.  It is ridiculous that a Windows restart (due to an installation that requires it or to a power failure, or to any other reason) would cause Backupper to fail unexpectedly.  I expect the Pro version to include timely support, otherwise why pay for it.
  • Another new version and another week to get an answer. It's for the human being to lose his patience.
Sign In or Register to comment.