BSOD on a nearly new computer

Yep 38.0.5 is good, that's the latest one.

Right I'm looking at the latest one first, a 0x1A, these are usually down to bad RAM or a driver. We know the RAM's good as you've tested with MemTest86+ so we're looking at a driver again. None are showing (sod's law) so I think DV is called for again.

I'll outline the dump below just to explain briefly what's going on. The 41790 shows that a page table page has become corrupt.

Code:

MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041790, A page table page has been corrupted. On a 64 bit OS, parameter 2
    contains the address of the PFN for the corrupted page table page.
    On a 32 bit OS, parameter 2 contains a pointer to the number of used
    PTEs, and parameter 3 contains the number of used PTEs.
Arg2: fffffa80047fff40
Arg3: 000000000000ffff
Arg4: 0000000000000000

There are quite a few Virtual Memory references in the stack too so a Driver Verifier run is going to be in order again.

Your earlier dump is a 0x1 which is an APC_INDEX_MISMATCH and usually points to a Checked Build but I'm presuming that's not the case here. A bit of info from the dump is below.

Code:

BugCheck 1, {76dddc2a, 0, ffff, fffff88020546b60}

Probably caused by : ntkrnlmp.exe ( nt!KiSystemServiceExit+245 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

APC_INDEX_MISMATCH (1)
This is a kernel internal error. The most common reason to see this
bugcheck is when a filesystem or a driver has a mismatched number of
calls to disable and re-enable APCs. The key data item is the
Thread->CombinedApcDisable field. This consists of two separate 16-bit
fields, the SpecialApcDisable and the KernelApcDisable. A negative value
of either indicates that a driver has disabled special or normal APCs
(respectively) without re-enabling them; a positive value indicates that
a driver has enabled special or normal APCs (respectively) too many times.
Arguments:
Arg1: 0000000076dddc2a, Address of system call function or worker routine
Arg2: 0000000000000000, Thread->ApcStateIndex
Arg3: 000000000000ffff, (Thread->SpecialApcDisable << 16) | Thread->KernelApcDisable
Arg4: fffff88020546b60, Call type (0 - system call, 1 - worker routine)

Maybe a driver is the issue again, I've not dealt with a 0x1 before personally so I can only presume it's possible. Again I think the best bet in this instance would be to run Driver Verifier again.

Nothing showing in that one at all mate unfortunately. Keep DV running and post up any new logs as and when they happen.

Still no driver showing, awkward little bugger this is. Nick, do you have Special Pool enabled in Driver Verifier?