BSOD - page_fault_in_nonpaged_area - memory at fault?

jamjamjones · 15 Jun 2018

For about the past month or two my PC has been freezing. At first it was irregular but in time it has gotten more and more common. My suspicion is that the RAM or HDD are at fault. I've tested and checked the HDD for problems as much as I can and nothing has ever come back negative (various HDD health checking programs, extensive chkdsk, etc). Recently, I've run a memory diagnostic and it came back positive and reported no issues. However, not long after, my system crashed and rebooted with the BSOD error mentioned in the title, and this has reignited my worries all over again. With all the problems I've been having, and all the troubleshooting and researching I've done, it always seems to come back to it probably being the RAM at fault. This is the first BSOD I've had in a long time, as well.

So, that said, I got the .dmp log from the crash for anyone who can make sense of it:

Code:

Crash Dump Analysis provided by OSR Open Systems Resources, Inc. (OSR  Unique Expertise, Guaranteed Results)
Online Crash Dump Analysis Service
See http://www.osronline.com for more information
Windows 8 Kernel Version 17134 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0xfffff801`fc802000 PsLoadedModuleList = 0xfffff801`fcbbc1f0
Debug session time: Fri Jun 15 15:30:23.770 2018 (UTC - 4:00)
System Uptime: 0 days 0:11:34.502
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
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: ffff8001be666018, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff80580099631, If non-zero, the instruction address which referenced the bad memory
    address.
Arg4: 000000000000000c, (reserved)

Debugging Details:
------------------


Could not read faulting driver name
TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
 ffff8001be666018 

FAULTING_IP: 
portcls!GetMaxMapRegisters+5
fffff805`80099631 8b4150          mov     eax,dword ptr [rcx+50h]

MM_INTERNAL_CODE:  c

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  AV

PROCESS_NAME:  audiodg.exe

CURRENT_IRQL:  0

BAD_PAGES_DETECTED: ef17

TRAP_FRAME:  fffff505278c2df0 -- (.trap 0xfffff505278c2df0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffff548134e02a0e rbx=0000000000000000 rcx=ffff8001be665fc8
rdx=fffff805800b4980 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80580099631 rsp=fffff505278c2f88 rbp=ffff8001be9f2490
 r8=fffff805800b49a0  r9=0000000000000000 r10=0000000000000001
r11=000000000000bb80 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
portcls!GetMaxMapRegisters+0x5:
fffff805`80099631 8b4150          mov     eax,dword ptr [rcx+50h] ds:ffff8001`be666018=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff801fc9ec21d to fffff801fc99a330

STACK_TEXT:  
fffff505`278c2b38 fffff801`fc9ec21d : 00000000`00000050 ffff8001`be666018 00000000`00000000 fffff505`278c2df0 : nt!KeBugCheckEx
fffff505`278c2b40 fffff801`fc8af3e8 : fffff505`278c2caa 00000000`00000000 00000000`00000000 ffffbb5d`aed76bb0 : nt!MiSystemFault+0x14135d
fffff505`278c2c80 fffff801`fc9a79da : 00000000`00000000 fffff805`800b4980 00000000`00000000 ffff8001`c32672a8 : nt!MmAccessFault+0x1f8
fffff505`278c2df0 fffff805`80099631 : fffff805`800e2254 ffff8001`c32672c0 ffff8001`be9f24d8 00000000`00000000 : nt!KiPageFault+0x31a
fffff505`278c2f88 fffff805`800e2254 : ffff8001`c32672c0 ffff8001`be9f24d8 00000000`00000000 ffff8001`00000009 : portcls!GetMaxMapRegisters+0x5
fffff505`278c2f90 fffff805`800e1135 : 00000000`00000000 ffff8001`bef9b3c0 00000000`00000000 ffff8001`bef9b3c0 : portcls!CPortPinWavePci::Init+0x3b4
fffff505`278c3030 fffff805`800c5ae7 : ffff8001`c32671e0 00000000`00000000 ffff8001`be502010 ffff8001`c0d091b0 : portcls!CPortFilterWavePci::NewIrpTarget+0x195
fffff505`278c30b0 fffff805`800c4c6e : 00000000`00000000 ffff8001`00000001 ffff8001`c0d09e80 00000000`00000002 : portcls!xDispatchCreate+0x2c7
fffff505`278c3160 fffff805`801571a9 : ffff8001`be502010 ffff8001`be502202 fffff505`278c3558 ffff8001`c0d09060 : portcls!KsoDispatchCreateWithGenericFactory+0x2e
fffff505`278c3190 fffff805`800c5bd9 : ffff8001`c0d09060 00000000`00000000 ffff8001`c0d091b0 00000000`00000000 : ks!KsDispatchIrp+0x289
fffff505`278c3250 fffff805`7e9838c2 : fffff505`278c3380 ffff8001`be502290 ffff8001`c29ecf88 ffff8001`00000020 : portcls!PcDispatchIrp+0xd9
fffff505`278c32c0 fffff505`278c3380 : ffff8001`be502290 ffff8001`c29ecf88 ffff8001`00000020 00000000`00000000 : vrtaucbl+0x38c2
fffff505`278c32c8 ffff8001`be502290 : ffff8001`c29ecf88 ffff8001`00000020 00000000`00000000 fffff801`fc886189 : 0xfffff505`278c3380
fffff505`278c32d0 ffff8001`c29ecf88 : ffff8001`00000020 00000000`00000000 fffff801`fc886189 ffff8001`c06a8230 : 0xffff8001`be502290
fffff505`278c32d8 ffff8001`00000020 : 00000000`00000000 fffff801`fc886189 ffff8001`c06a8230 ffff8001`c29ecf88 : 0xffff8001`c29ecf88
fffff505`278c32e0 00000000`00000000 : fffff801`fc886189 ffff8001`c06a8230 ffff8001`c29ecf88 ffff8001`be502010 : 0xffff8001`00000020


STACK_COMMAND:  kb

SYMBOL_NAME:  PAGE_NOT_ZERO

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

BUCKET_ID:  PAGE_NOT_ZERO

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

 *** Memory manager detected 61207 instance(s) of page corruption, target is likely to have memory corruption.

And a download for the file itself for those who need it: Dropbox - 061518-99140-01.dmp

The only things I could understand from it is there's something relating to audiodg.exe and a ton of corruption going on with the memory. This stuff has got me really worried since I need the PC to work, so any help is greatly appreciated! I've been considering just going ahead and replacing the RAM but I need more perspective on this issue.

Would also love to know if it's possibly anything else like drivers, but I've been updating any that I could for a while now and there seems to be no difference.

cwsink · 15 Jun 2018

Are you using an older version of Ventrilo? There is a driver in the callstack named vrtaucbl.sys which is a component of Ventrilo according to this page. The timestamp on the driver you have installed is Mon Feb 15 09:07:10 2010 which is pretty old for Windows 10.

jamjamjones · 15 Jun 2018

cwsink said:

Are you using an older version of Ventrilo? There is a driver in the callstack named vrtaucbl.sys which is a component of Ventrilo according to this page. The timestamp on the driver you have installed is Mon Feb 15 09:07:10 2010 which is pretty old for Windows 10.

Nope, never used it in my life. Can't even find a trace of it on the PC.

jamjamjones · 15 Jun 2018

Nevermind, I see that it's actually part of Virtual Audio Cable, which I do happen to use. I'll see if I can update it and, if not, uninstalling it.

cwsink · 15 Jun 2018

That driver is loading for some reason. Does someone else use the computer and perhaps installed it? Perhaps it's a component of something else and happens to have the same name for the driver. I'd suggest searching the system drive to see if you can find the source.

jamjamjones · 15 Jun 2018

I've uninstalled VAC (Virtual Audio Cable) for the time being and will see if it changes anything, but I'm not expecting much.

Were there any other odd things or anything of note from the log?

cwsink · 15 Jun 2018

As you said it was executing a thread in the audiodg.exe process and it tried to read an invalid memory location. The location isn't obviously invalid to look at which typically means code was trying to access memory that had been freed. That is, in fact, what it did:

Code:

1: kd> !pte ffff8001`be666018
                                           VA ffff8001be666018
PXE at FFFFBB5DAED76800    PPE at FFFFBB5DAED00030    PDE at FFFFBB5DA0006F98    PTE at FFFFBB4000DF3330
contains 0A000000056C6863  contains 0A000000056C7863  contains 0A00000447151863  contains 00008B7E00000000
pfn 56c6      ---DA--KWEV  pfn 56c7      ---DA--KWEV  pfn 447151    ---DA--KWEV  not valid
                                                                                  Page has been freed

That would suggest a driver bug to me and it's quite possible vrtaucbl.sys was the culprit. It's often helpful to have multiple dumps to see if there's a consistent pattern so if the you have any and/or the problem continues please make the dumps available.

jamjamjones · 15 Jun 2018

I guess I shouldn't be surprised, it always got messed up with each new windows update and I would have to reinstall it every time. Better to just do away with the whole thing I suppose.

I'll report back to the thread if problems arise again and it ends up not being the solution.

jamjamjones · 15 Jun 2018

Well, sure enough, the problem remains. Haven’t gotten a BSOD this time but rather the typical “PC freezes, audio loops” freeze I’ve been having over and over. I can only see it being my RAM or, god forbid, my motherboard. I’ve done many tests on the HDD and CPU, and my GPU has never shown signs of being faulty, and temps are never an issue.

I guess it’s worth mentioning I’ve only done the Windows memory diagnostic and not something like memtest86. I’m wondering if I should just replace both my sticks, but I’m worried it’s possible they’re not at fault.

cwsink · 16 Jun 2018

For DDR3 memory and earlier the most reliable diagnostic seems to be memtest86. The usual recommendation is 8 full passes without any errors to be confident the memory is likely okay. It can take a while so probably best left to run overnight unless errors show up immediately.