Intermittent "Service abend" BSOD

Please upload V2 into the thread.

Have you reinstalled the AOMEI Backupper program? If not, do it.
BTW: Incidentally, the latest version of Partition Assistant is version 8.4

zbook said:

Please upload V2 into the thread.

V2 logging Attached

MrPepka said:

Have you reinstalled the AOMEI Backupper program? If not, do it.
BTW: Incidentally, the latest version of Partition Assistant is version 8.4

Yes - 8.4 is what I installed. However as far as wiping Aomei backupper, NO. This is a license version and I cannot just install a copy of it. During a normal upgrade, The Aomei uninstaller will retain the Licenses information at my request but remove everything else then it proceeds to install the new version and then updates the License information. I made the mistake once of wiping the old version out first, took me a week to get the replacement version licensed again.

When were each of the RAM modules installed?

Check to see if the RAM is or is not on the Qualified Vendor List (QVL)

Code:

Location     : Bottom-Slot 1(top)
BankLabel    : CHANNEL A
Manufacturer : Micron Technology
MemoryType   : DDR3
FormFactor   : SODIMM
Capacity     : 2GB
Speed        : 1600
Serial       : E969A416
PartNumber   : 8KTF25664HZ-1G6M1 
ECC          : False
TypeDetail   : {Synchronous, Unbuffered (Unregistered)}

Location     : Bottom-Slot 2(under)
BankLabel    : CHANNEL B
Manufacturer : Hynix
MemoryType   : DDR3
FormFactor   : SODIMM
Capacity     : 4GB
Speed        : 1600
Serial       : 0A8C1429
PartNumber   : HMT351S6CFR8C-PB  
ECC          : False
TypeDetail   : {Synchronous, Unbuffered (Unregistered)}

zbook said:

When were each of the RAM modules installed?

Check to see if the RAM is or is not on the Qualified Vendor List (QVL)

Code:

Location     : Bottom-Slot 1(top)
BankLabel    : CHANNEL A
Manufacturer : Micron Technology
MemoryType   : DDR3
FormFactor   : SODIMM
Capacity     : 2GB
Speed        : 1600
Serial       : E969A416
PartNumber   : 8KTF25664HZ-1G6M1 
ECC          : False
TypeDetail   : {Synchronous, Unbuffered (Unregistered)}

Location     : Bottom-Slot 2(under)
BankLabel    : CHANNEL B
Manufacturer : Hynix
MemoryType   : DDR3
FormFactor   : SODIMM
Capacity     : 4GB
Speed        : 1600
Serial       : 0A8C1429
PartNumber   : HMT351S6CFR8C-PB  
ECC          : False
TypeDetail   : {Synchronous, Unbuffered (Unregistered)}

Can't be sure. I purchased this system from a seller/acquaintance back in early 2015. Came with Windows 8, he upgraded it to 8.1. Used it for a contract job he was working on. Job ended he sold it to me for $350. Had that 6gb of memory when I picked it up. He refreshed it back to factory (Win 8.0), I upgraded it to 8.1 and then Windows 10 1507 (Initial Release). With the exception of updating of the physical drives, the machine has remained the same.

Documents for memory QVL list do not exist on the HP Web site. Note this machine is over 6 years old.

There can be unexpected computer behavior when there is mismatched RAM.

And there can be unexpected computer behavior when RAM is used that is not on the QVL.

If the RAM modules are used for substantial time without problems then no action is usually taken other than testing the RAM.

If there are no more unexpected shutdowns / restarts then the troubleshooting is completed.
If there are more unexpected shutdowns / restarts after troubleshooting Aoemi software then test the RAM with Memtest86+ version 5.01

Run memtest86+ version 5.01 for at least 8 passes.
Memtest86+ - Advanced Memory Diagnostic Tool

This may take hours so plan to run it overnight.

a) Please make sure you use the Memtest86+ version 5.01 with the link below.
Memtest86+ - Advanced Memory Diagnostic Tool

The testing is done not by time but by passes.
The more passes the better the testing conditions.

There are a significant number of false negatives if fewer than 8 passes are made.
A false negative is a test pass when there is malfunctioning RAM.

There is 6 GB of RAM on the computer.
Memtest86+ version 5.01 testing takes approximately 1 - 2 hours /GB RAM

Just 1 error is a fail and you can abort testing.
Then test 1 RAM module at a time in the same DIMM each for 8 or more passes.

b) When Memtest86+ version 5.01 has completed 8 or more passes use a camera or smart phone camera to take a picture and post an image into the thread.

https://answers.microsoft.com/en-us/...f-ecc7b7ff6461

MemTest86+ - Test RAM

@zbook - Thanks for your analysis, I will run the Memtest since this system is a Backup system and most of the the time its powered off. I could probably run a couple hundred passes if I want. I'm going to continue to monitor this problem and will keep you posted.

Have a good day

Memtest ran for 10 passes and zero errors, I assume the memory is not the problem.

From the crash dump that was generated on August 2nd, the problem definitely seems to be related to your AOMEI backup software.

Let's start by looking at what the crash dump shows us (highlights are my own):

The interrupt request level (IRQL) that kernel was at when the panic occurred was 2.

Code:

Debugger saved IRQL for processor 0x1 -- 2 (DISPATCH_LEVEL)

The call stack that led up to the panic/bugcheck (highlights are my own):

Code:

 0xffffea8a46819d98 : 0xfffff803763d1ae9 : nt!KiBugCheckDispatch+0x69
0xffffea8a46819dc0 : 0xfffff8037632f7ea : nt!IoGetLowerDeviceObjectWithTag+0x1e
0xffffea8a46819dd0 : 0x7472617473657220 :  !da "" restart..""
0xffffea8a46819e98 : 0xfffff80376841bf1 : nt!IoGetDeviceObjectPointer+0xe1
0xffffea8a46819ed8 : 0xfffff803763cde2b : nt!KiPageFault+0x46b
0xffffea8a46819ee0 : 0x0000000000000b32 :  Trap @ ffffea8a46819ee0
0xffffea8a46819f28 : 0xffff8809b51de190 :  !du "TQTTUUTUULPU"
0xffffea8a46819fb8 : 0xfffff803768ca917 : nt!ExpAllocateStringRoutine+0x17
0xffffea8a46819fd0 : 0x7472617473657220 :  !da "" restart..""
0xffffea8a4681a028 : 0xfffff8037656d0a9 : nt!ExFreePool+0x9
0xffffea8a4681a048 : 0xfffff8037632f7ea : nt!IoGetLowerDeviceObjectWithTag+0x1e
0xffffea8a4681a080 : 0xfffff8037632f7b0 : nt!IoGetLowerDeviceObject
0xffffea8a4681a088 : 0xfffff803768da07d : nt!MmGetSystemRoutineAddress+0x5d
0xffffea8a4681a098 : 0xfffff8037632f7be : nt!IoGetLowerDeviceObject+0xe
0xffffea8a4681a0a8 : 0xfffff8037632f7b0 : nt!IoGetLowerDeviceObject
*** WARNING: Unable to verify timestamp for amwrtdrv.sys
0xffffea8a4681a0f0 : 0xfffff80376772508 : nt!IoDriverObjectType
0xffffea8a4681a138 : 0xfffff80380f42ea0 :  !du "\Driver\Disk"
0xffffea8a4681a158 : 0xfffff80380f42ef0 :  !du "IoGetLowerDeviceObject"
0xffffea8a4681a1b0 : 0x004b005300490044 :  !du "DISK1"
0xffffea8a4681a1f0 : 0xfffff80376200000 : "nt!SeConvertSecurityDescriptorToStringSecurityDescriptor <PERF> (nt+0x0)"
0xffffea8a4681a1f8 : 0xfffff80376233206 : nt!RtlpHpLfhSlotAllocate+0x126
0xffffea8a4681a2a8 : 0xfffff8037681ba9d : nt!SeCodeIntegrityQueryPolicyInformation+0x2d
0xffffea8a4681a2e8 : 0xffff8809b93de030 :  !da "UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUEUUUTQUUUUUU"
0xffffea8a4681a358 : 0xfffff80376232b34 : nt!ExAllocateHeapPool+0xb94
0xffffea8a4681a398 : 0xfffff803767e74f0 : nt!ObpAllocateObject+0x1a0
0xffffea8a4681a440 : 0xfffff803767e3705 : nt!IopCheckBackupRestorePrivilege+0xe5
0xffffea8a4681a458 : 0xfffff80376231819 : nt!IofCallDriver+0x59
0xffffea8a4681a498 : 0xfffff803762308c4 : nt!IoCallDriverWithTracing+0x34
0xffffea8a4681a4b8 : 0xfffff80376231083 : nt!RtlCopyUnicodeString+0x43
0xffffea8a4681a4e8 : 0xfffff803767e3e1b : nt!IopParseDevice+0x62b
0xffffea8a4681a4f8 : 0xfffff803767e3705 : nt!IopCheckBackupRestorePrivilege+0xe5
0xffffea8a4681a578 : 0xfffff80376270634 : nt!SeAccessCheckWithHint+0x134
0xffffea8a4681a618 : 0xfffff8037623967d : nt!ExAcquirePushLockSharedEx+0xed
0xffffea8a4681a650 : 0xfffff803767e37f0 : nt!IopParseDevice
0xffffea8a4681a658 : 0xfffff803767eac5f : nt!ObpLookupObjectName+0x78f
0xffffea8a4681a6d8 : 0xffff8809bc558030 :  !du "\DR1\DISK1"
0xffffea8a4681a718 : 0xffff8809bc558020 :  !du "amwrtdrv\DR1\DISK1"
0xffffea8a4681a818 : 0xfffff803767e90c1 : nt!ObOpenObjectByNameEx+0x201
0xffffea8a4681a888 : 0xfffff803762394bd : nt!ExAcquirePushLockExclusiveEx+0xed
0xffffea8a4681a8a0 : 0xfffff80376200000 : "nt!SeConvertSecurityDescriptorToStringSecurityDescriptor <PERF> (nt+0x0)"
0xffffea8a4681a8b0 : 0xffff8809bc558010 :  !du "\Device\amwrtdrv\DR1\DISK1"
0xffffea8a4681a958 : 0xfffff8037682dbc0 : nt!IopCreateFile+0x820
0xffffea8a4681a9f8 : 0xfffff8037682d389 : nt!NtCreateFile+0x79
0xffffea8a4681aa80 : 0xfffff8037682d310 : nt!NtCreateFile
0xffffea8a4681aa88 : 0xfffff803763d1518 : nt!KiSystemServiceCopyEnd+0x28
0xffffea8a4681aaf8 : 0xfffff803763d1518 : nt!KiSystemServiceCopyEnd+0x28
0xffffea8a4681ab00 : 0xffffc5061be1c080 :  Trap @ ffffea8a4681ab00

So putting this together we see that some function in amwrtdrv.sys (the kernel driver for AOMEI software) was called. Subsequently there was a call to allocate kernel memory for a string (nt!ExpAllocateStringRoutine), which in turn appears to have caused a pagefault (nt!KiPageFault). That pagefault then led to a blue screen of death (nt!KiBugCheckDispatch)

The problem is that the pagefault handler runs at IRQL 2, and how interrupt request levels works is that only something of higher IRQL can interrupt what is currently running on the CPU. Hence, because the routine to allocate kernel memory was running at IRQL 2, the pagefault handler itself cannot run to service the pagefault, hence any pagefault at IRQL 2 (or higher) is an immediate bluescreen of death (nt!KiBugCheckDispatch).

This is why Windows reported a bugcheck code of 0xA - IRQL_NOT_LESS_OR_EQUAL.