I'd like to add a bit to what John has put.
First, your latest bugcheck is a 0xEF where a critical process has been terminated, I will need a Kernel dump file to do any sort of analysis on it.
Go the Start
Right click My Computer
Select Properties
Click Advanced system settings
Click on the Advanced tab
Select Settings under Startup and Recovery
Then under Write debugging information select Kernel memory dump.
Once a dump is created go to:
Copy the file to the desktop, zip it up and upload it to a file sharing site like Onedrive. After the upload is done post the download link in your next reply.
As mentioned by john Intel Rapid Storage Technology is probably causing the problem, it's not surprising as it's very common.
Although an update doesn't normally fix the problem, you need to remove it permanently.
To remove IRST you need to remove it on the Programs and Features, then go to Device Manager, expand IDE ATA/ATAPI controllers, then click uninstall on each one.
Once removed reboot and it should stop reinstalling IRST.
So I'll take a quick look at your other dump files.
Code:
[B]KERNEL_DATA_INPAGE_ERROR (7a)[/B]
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: fffff6fb80000370, lock type that was held (value 1,2,3, or PTE address)
Arg2: [B][COLOR="#FF0000"]ffffffffc00000c0[/COLOR][/B], error status (normally i/o status code)
Arg3: 000000000e6f8880, current process (virtual address for lock type 3, or PTE)
Arg4: fffff7000006e318, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
So we couldn't page in memory from disk, but why?
Well this particular exception code means that the device didn't exist; in other words we tried to access a drive to bring memory in which didn't exist.
I would probably say this is a failing drive so I recommend running SeaTools DOS.
SeaTools for DOS | Seagate
Run everything except Fix All and anything under the Advanced tests.
All your other dump files I've seen are exactly the same.
Code:
[B]PAGE_FAULT_IN_NONPAGED_AREA (50)[/B]
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: [COLOR="#FF0000"]0000000000000000[/COLOR], memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: 00000000[COLOR="#800080"]6d626b47[/COLOR], If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
Invalid system memory was referenced, it states that it's null but I believe the context simply wasn't saved.
The most interesting (and helpful) part about the rest of these files is the consistency in the address which called the pagefault.
It's the exact same address.
Unfortunately without a Complete Memory Dump we cannot see what it was that was referencing invalid memory as User Mode addresses aren't saved without that dump file.
Code:
3: kd> [COLOR="#008000"]!address 6d626b47[/COLOR]
Mapping user range ...
Mapping system range ...
Mapping non addressable range ...
Mapping page tables...
Mapping hyperspace...
Mapping HAL reserved range...
Mapping User Probe Area...
Mapping system shared page...
Mapping system cache working set...
Mapping loader mappings...
Mapping system PTEs...
Mapping system paged pool...
Mapping session space...
Mapping dynamic system space...
Mapping PFN database...
Mapping non paged pool...
Mapping VAD regions...
Mapping module regions...
Mapping process, thread, and stack regions...
Mapping system cache regions...
Usage:
Base Address: 00000000`00000000
End Address: 00000000`7ffe0000
Region Size: 00000000`7ffe0000
VA Type: [COLOR="#800080"]UserRange[/COLOR]
VAD Address: 0x0
Commit Charge: 0x100000003
Protection: 0x7feecd9ff88 []
Memory Usage: [COLOR="#800080"]Private[/COLOR]
No Change: yes
More info: !vad 0x0
So that's where this ends.
The only lead I have is the fact that under the loaded modules I see a lot of Intel Rapid Sotrage Technology driver functions which are loading and unloading a lot.