Bugcheck code 1A is a "memory management" bugcheck, usually indicating that Mm code detected an inconsistency in Windows' internal memory management data.
The first parameter, 41790, indicates a "subtype" of the bugcheck code: "A page table page has been corrupted. On a 64 bit version of Windows, parameter 2 contains the address of the PFN for the corrupted page table page."
The PFN entry at FFFFFA8000144810 shows:
0: kd> dt _MMPFN fffffa8000144810
nt!_MMPFN
+0x000 u1 : <unnamed-tag>
+0x008 u2 : <unnamed-tag>
+0x010 PteAddress : 0xfffff6fb`400c76d8 _MMPTE
+0x010 VolatilePteAddress : 0xfffff6fb`400c76d8 Void
+0x010 Lock : 0n1074558680
+0x010 PteLong : 0xfffff6fb`400c76d8
+0x018 u3 : <unnamed-tag>
+0x01c UsedPageTableEntries : 0xffff
+0x01e VaType : 0 ''
+0x01f ViewCount : 0 ''
+0x020 OriginalPte : _MMPTE
+0x020 AweReferenceCount : 0n128
+0x028 u4 : <unnamed-tag>
0: kd>
We want to look at the "page table page" as described in the bugcheck description, so the next step would normally be to examine tThe PTE entry at 0xfffff6fb`400c76d8...
0: kd> dt _MMPTE 0xfffff6fb`400c76d8
!_MMPTE
+0x000 u : <unnamed-tag>
Memory read error fffff6fb400c76d8
0: kd>
but that location is not recorded in the dump; in fact, the top-level page table page (the "PML4 page") is not even in the dump.
"memory management" bugchecks can be caused by bugs in device drivers or by actual memory errors (dropped bits and so on); the latter is more common IME. I'd advise running memcheck or Windows' built-in memory tester for a large number of passes, reseating RAM, removing some of the RAM, etc.... the usual things you do when suspecting a memory problem.
If the blue screens recur, please set your system to produce "kernel memory dumps" instead of "small memory dumps" (which is what you posted here) and, after the next crash, update the question with a link to the kernel memory dump.