Hi Jedzi ^_^,
Oh yes, the exams went well ^_^.
Thanks for attaching the ZIP file. There are some interesting things in them which I will discuss with you shortly.
Let's talk about your latest crash dump file according to the ZIP file.
Below is the stack for the latest dump file -
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff880`08020358 fffff800`02cbc1e9 nt!KeBugCheckEx
01 fffff880`08020360 fffff800`02cbae60 nt!KiBugCheckDispatch+0x69
02 fffff880`080204a0 fffff800`02c93236 nt!KiPageFault+0x260
03 fffff880`08020638 fffff800`02c91e0e nt!MiTryLockProtoPoolPageAtDpc+0x42
04 fffff880`08020640 fffff800`02ceaf21 nt!MiCopyDataPageToImagePage+0x29e
05 fffff880`08020780 fffff800`02cdb5bc nt!MiResolveMappedFileFault+0x971
06 fffff880`080208e0 fffff800`02cd9e23 nt!MiResolveProtoPteFault+0x47c
07 fffff880`08020970 fffff800`02cc9a89 nt!MiDispatchFault+0x1c3
08 fffff880`08020a80 fffff800`02cbad6e nt!MmAccessFault+0x359
09 fffff880`08020be0 00000000`62171027 nt!KiPageFault+0x16e
0a 00000000`0556f450 00000000`00000000 0x62171027
Do you see the last line? The last line contains the address 0x62171027 . This is weird because the address belongs to User Mode. So, when the page fault occurred in the User Mode, the kernel tried bringing the page back to memory, Windows detected corruption and crashed the system to protect your data. The function MiTryLockProtoPoolPageAtDpc
is not documented sadly and I cannot say what it does.
Now, let's see one of the other dump files. One of the dump files has the error - UNEXPECTED_KERNEL_MODE_TRAP (7f)
Below is an excerpt from the analysis -
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
kb will then show the corrected stack.
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
In your case, the dump file says that there was a double fault. This means that an exception (Problem) occurred when handling another exception. This is not allowed since the system does not know how to handle that. So, the system crashed.
You asked that how come the Memory tests are passing. The answer to this question is that the software checks only parts of the hardware and cannot check the memory modules 100%.
The saying goes like this - "If the Memory test detect an error, RAM is bad. If they don't, that does not mean that the RAM sticks are good."
At this point of time, I would suggest you to take the laptop to the service center and get it checked. There are dump files which are depicting errors while reading and writing to RAM so there is a high chance that RAM is the problem. In case you are replacing the RAM sticks yourself, please make sure that you buy them from a shop which accepts returns (Just in case). You also need to make sure that the RAM sticks would be compatible with the system. That's some work so if you don't want to do all of this, I would suggest you to take it to the service center.
Let me know how it goes ^_^