New
#61
38.0.5 it say's it is up to date
38.0.5 it say's it is up to date
Here is the latest Boozad, seems to be happening when left overnight with sleep mode enabled.
2nd one today mate, I thought it was getting better!
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.
There are quite a few Virtual Memory references in the stack too so a Driver Verifier run is going to be in order again.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
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.
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.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)
Thanks mate, will run Dv again now.
Here is the latest dump file mate
Nothing showing in that one at all mate unfortunately. Keep DV running and post up any new logs as and when they happen.
no worries, here is another one!
Still no driver showing, awkward little bugger this is. Nick, do you have Special Pool enabled in Driver Verifier?