BSOD SYSTEM_SERVICE_EXCEPTION 00000000`c0000005

milek86

Member
Joined
Aug 28, 2019
Posts
7
I built my pc a month ago and I had a few bluescreens, some caused by AMD drivers (now fixed I think) and now, in a week I had two, both "caused" by ntoskrnl.exe but I can't figure out the real cause :(
The report might show some hamachi stuff but I uninstalled it soon after the bsod
 

Attachments

Last edited:
The latest crash dump (28 Aug 2019) actually shows there could be another explanation for the crash. A Malwarebytes driver could not be loaded. Try uninstalling this and see if it makes a difference or look for an update. The current driver on your system is dated with Timestamp: Mon Apr 8 07:06:03 2019

Code:
10: kd> !dpx ffff9209ab974000 ffff9209ab97a000
Start memory scan : 0xffff9209ab974000
End memory scan : 0xffff9209ab97a000

rsp : 0xffff990095ddeff8 : 0xfffff804075d1ae9 : nt!KiBugCheckDispatch+0x69
0xffff9209ab978858 : 0xfffff80407436dd0 : nt!ExAcquireResourceSharedLite+0x40
0xffff9209ab978898 : 0xfffff804079e7fa1 : nt!ObpCreateHandle+0x601
0xffff9209ab9788f8 : 0xfffff804079ecc90 : nt!CmpParseKey
0xffff9209ab978908 : 0xfffff804079eaeaa : nt!ObpLookupObjectName+0x84a
0xffff9209ab978a48 : 0xfffff804075d53c0 : !du "WIN://NOALLAPPPKG"
[COLOR=rgb(255, 0, 0)]Unable to load image \SystemRoot\System32\Drivers\MbamChameleon.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for MbamChameleon.sys[/COLOR]
0xffff9209ab978b78 : 0xfffff804079f2595 : nt!CmKeyBodyRemapToVirtualForEnum+0x6c5
0xffff9209ab978d38 : 0xfffff80407c41c8e : nt!VrpShouldOperateOnCall+0x22
0xffff9209ab978d98 : 0xfffff804079ec550 : nt!CmpCallCallBacksEx+0x280
0xffff9209ab978da8 : 0xffffaa01484f3b00 : !du "SCSI\DiskNVMe____ADATA_SX6000PNP_1c19"
0xffff9209ab978e28 : 0xfffff80407445777 : nt!ExFreeHeapPool+0x357
0xffff9209ab978f48 : 0xfffff8040776d0a9 : nt!ExFreePool+0x9
0xffff9209ab978f68 : 0xfffff804075d1c16 : nt!KiExceptionDispatch+0x116
0xffff9209ab978f78 : 0xfffff804079f74d7 : nt!ObpFreeObject+0x197
0xffff9209ab979050 : 0xfffff80407400000 : "nt!SeConvertSecurityDescriptorToStringSecurityDescriptor (nt+0x0)"
0xffff9209ab979058 : 0xfffff80407433620 : nt!RtlpHpLfhSlotAllocate+0x540
0xffff9209ab9790b8 : 0xfffff80407444289 : nt!RtlRbRemoveNode+0x3a9
0xffff9209ab979108 : 0xfffff804074f3b8b : nt!ExpInsertPoolTrackerExpansion+0xdf
0xffff9209ab979148 : 0xfffff804075cd9a2 : nt!KiGeneralProtectionFault+0x322
0xffff9209ab979150 : 0x0000000000000000 : Trap @ ffff9209ab979150
0xffff9209ab979158 : 0xfffff80407831e68 : nt!ExpTaggedPoolLock
0xffff9209ab979228 : 0xffff8a904a5e4c07 : win32kbase!EtwTraceAcquiredExclusiveUserCrit+0x227
0xffff9209ab979248 : 0x005c006c0065006e : !du "nel\Desk"
0xffff9209ab979288 : 0xfffff804074394bd : nt!ExAcquirePushLockExclusiveEx+0xed
0xffff9209ab979298 : 0xfffff804074394bd : nt!ExAcquirePushLockExclusiveEx+0xed
0xffff9209ab9792b8 : 0xfffff80407444289 : nt!RtlRbRemoveNode+0x3a9
0xffff9209ab9792f8 : 0xfffff80407442758 : nt!RtlpHpVsChunkSplit+0x48
0xffff9209ab9793c8 : 0xfffff80407442619 : nt!RtlpHpVsContextAllocateInternal+0x3c9
0xffff9209ab979438 : 0xfffff80407432bae : nt!ExAllocateHeapPool+0xc0e
0xffff9209ab9794d8 : 0xffff8a904a23bb76 : win32kfull!UserAtomicCheck::~UserAtomicCheck+0x22
0xffff9209ab979530 : 0xffff8a904a4da488 : win32kfull!WPP_f3f8cf549e503a6a86e4761750732b2d_Traceguids
0xffff9209ab979578 : 0xfffff8040776d06d : nt!ExAllocatePoolWithTag+0x5d
0xffff9209ab9795a8 : 0xfffff8040776d06d : nt!ExAllocatePoolWithTag+0x5d
0xffff9209ab9795c8 : 0xfffff8041559e9be : dxgmms2!VidSchCreateProcess+0x3e
0xffff9209ab9795f8 : 0xfffff80413f61242 : dxgkrnl!DXGPROCESS::DeferredInitialize+0x5e
0xffff9209ab979628 : 0xfffff80413f60e89 : dxgkrnl!DXGPROCESS::Initialize+0x2b9
0xffff9209ab979640 : 0xfffff80413ef2d98 : dxgkrnl!DXGGLOBAL::m_pDxgmmsExport+0x8
0xffff9209ab979658 : 0xffff9209ab979748 : 0xfffff80407509f76 : nt!ExReleaseFastMutexUnsafeAndLeaveCriticalRegion+0x26
0xffff9209ab979668 : 0xfffff80413f6005d : dxgkrnl!DXGPROCESS::CreateDxgProcess+0x141
0xffff9209ab979698 : 0xfffff80413e570fd : dxgkrnl!DXGETWPROFILER_BASE::PushProfilerEntry+0xbd
0xffff9209ab9796a8 : 0xffff8a904a52cd01 : win32kfull!aulCacheCT+0x161
0xffff9209ab9796c8 : 0xfffff80413f5ff01 : dxgkrnl!DxgkProcessCallout+0xc1
0xffff9209ab9796d0 : 0xffff8a904a7bd0e0 : win32kbase!gDxgkWin32kEngInterface
0xffff9209ab979728 : 0xffff8a904a5c05f9 : win32kbase!GdiProcessCallout+0x209
0xffff9209ab979748 : 0xfffff80407509f76 : nt!ExReleaseFastMutexUnsafeAndLeaveCriticalRegion+0x26
0xffff9209ab9797a8 : 0xffff8a904a20c48d : win32kfull!W32pProcessCallout+0x17d
0xffff9209ab9797b8 : 0xffff8a904a2f1d51 : win32kfull!GreIsCurrentProcessSystemCritical+0x61
0xffff9209ab9797e8 : 0xffff8a904a5e1f05 : win32kbase!W32CalloutDispatch+0x385
0xffff9209ab9797f8 : 0xfffff80407836988 : nt!PsWin32CallBack
0xffff9209ab979808 : 0xfffff80407474167 : nt!MiDispatchFault+0x2b7
0xffff9209ab979928 : 0xfffff804074749e6 : nt!MiUnlockWorkingSetShared+0x66
0xffff9209ab979958 : 0xfffff804074729b2 : nt!MmAccessFault+0x322
0xffff9209ab979a08 : 0xffff8a904b061040 : win32k!W32CalloutDispatchThunk+0x10
0xffff9209ab979a10 : 0xfffff80407836988 : nt!PsWin32CallBack
0xffff9209ab979a30 : 0xffff8a904b061030 : win32k!W32CalloutDispatchThunk
0xffff9209ab979a38 : 0xfffff804079c82f1 : nt!ExCallCallBack+0x3d
0xffff9209ab979a68 : 0xfffff80407ac1c41 : nt!PsConvertToGuiThread+0xc1
0xffff9209ab979ac8 : 0xfffff804075c3949 : nt!KiConvertToGuiThread+0x9
0xffff9209ab979af8 : 0xfffff804075d1912 : nt!KiSystemServiceExitPico+0x17d
0xffff9209ab979b00 : 0xffffe503000002de : Trap @ ffff9209ab979b00
 
Okay, I'll reply if anything crashes again :) I uninstalled mbam and driver verifier is running
 
Code:
4: kd> !dpx
Start memory scan : 0xffffe783f85b1078 ($csp)
End memory scan : 0xffffe783f85b2000 (Kernel Stack Base)

rsp : 0xffffe783f85b1078 : 0xfffff802347d1ae9 : nt!KiBugCheckDispatch+0x69
0xffffe783f85b1078 : 0xfffff802347d1ae9 : nt!KiBugCheckDispatch+0x69
0xffffe783f85b10a0 : 0xfffff80234642cb6 : nt!RtlpHpVsChunkSplit+0x5a6
0xffffe783f85b11b8 : 0xfffff802347cde2b : [HI]nt!KiPageFault+0x46b[/HI] << We crash here!
0xffffe783f85b11c0 : 0x0000000000000000 : Trap @ ffffe783f85b11c0
0xffffe783f85b1328 : 0xfffff80234642cb6 : nt!RtlpHpVsChunkSplit+0x5a6
0xffffe783f85b1370 : 0xfffff802350b8180 : hal!HalpApic1WriteIcr
0xffffe783f85b1378 : 0xfffff802350b6c53 : hal!HalpApicRequestInterrupt+0xa3
0xffffe783f85b13b8 : 0xfffff802346e7718 : nt!RtlpHpSegPageRangeAllocate+0x148
0xffffe783f85b1418 : 0xfffff80234642619 : nt!RtlpHpVsContextAllocateInternal+0x3c9
0xffffe783f85b1488 : 0xfffff802346323b8 : nt!ExAllocateHeapPool+0x418
0xffffe783f85b1538 : 0xfffff80234be7f00 : nt!ObpCreateHandle+0x560
0xffffe783f85b15c8 : 0xfffff8023496d06d : [HI]nt!ExAllocatePoolWithTag+0x5d[/HI] << Create a pool allocation
0xffffe783f85b15f8 : 0xfffff80234648355 : nt!KiExitDispatcher+0x105
0xffffe783f85b1618 : 0xfffff80234629570 : nt!ExAllocatePoolWithQuotaTag+0x60
0xffffe783f85b1648 : 0xfffff8023496d06d : nt!ExAllocatePoolWithTag+0x5d
0xffffe783f85b1698 : 0xfffff8023f87d8f9 : Npfs!NpAddDataQueueEntry+0x239
0xffffe783f85b1708 : 0xfffff8023f87de19 : [HI]Npfs!NpCommonWrite+0x219[/HI] << A call related to named pipes
0xffffe783f85b1798 : 0xfffff8023f87db7d : Npfs!NpFsdWrite+0x6d
0xffffe783f85b1808 : 0xfffff80234631819 : nt!IofCallDriver+0x59
0xffffe783f85b1818 : 0xfffff80234600000 : "nt!SeConvertSecurityDescriptorToStringSecurityDescriptor (nt+0x0)"
0xffffe783f85b1848 : 0xfffff802358e3f48 : FLTMGR!FltpDispatch+0xe8
0xffffe783f85b1858 : 0xfffff8023463c082 : nt!KiSwapThread+0xc22
0xffffe783f85b18a8 : 0xfffff80234631819 : nt!IofCallDriver+0x59
0xffffe783f85b18e8 : 0xfffff80234be7215 : nt!IopSynchronousServiceTail+0x1a5
0xffffe783f85b1908 : 0xfffff80234c43861 : nt!ObReferenceFileObjectForWrite+0x91
0xffffe783f85b1988 : 0xfffff80234c435c6 : nt!NtWriteFile+0x676
0xffffe783f85b1a88 : 0xfffff802347d1518 : nt!KiSystemServiceCopyEnd+0x28
0xffffe783f85b1af8 : 0xfffff802347d1518 : nt!KiSystemServiceCopyEnd+0x28
0xffffe783f85b1b00 : 0xffff968bf74e1080 : Trap @ ffffe783f85b1b00

npfs.sys is a file system driver, more specifically it is Named Pipe filesystem driver. However, this is unlikely to be the cause of your issue.

Having that said, since pipes use a block of shared memory as a buffer for inter-process communication, then it is likely that a pool allocation was made to accommodate for this, but since the address belonged to a page which wasn't in memory or was corrupt, an invalid page fault was dispatched which lead to the crash since your IRQL level was too high.

Code:
4: kd> !irql
Debugger saved IRQL for processor 0x4 -- 2 (DISPATCH_LEVEL)

Code:
4: kd> !verifier

Verify Flags Level 0x00000000

STANDARD FLAGS:
[X] (0x00000000) Automatic Checks
[ ] (0x00000001) Special pool
[ ] (0x00000002) Force IRQL checking
[ ] (0x00000008) Pool tracking
[ ] (0x00000010) I/O verification
[ ] (0x00000020) Deadlock detection
[ ] (0x00000080) DMA checking
[ ] (0x00000100) Security checks
[ ] (0x00000800) Miscellaneous checks
[ ] (0x00020000) DDI compliance checking

ADDITIONAL FLAGS:
[ ] (0x00000004) Randomized low resources simulation
[ ] (0x00000200) Force pending I/O requests
[ ] (0x00000400) IRP logging
[ ] (0x00002000) Invariant MDL checking for stack
[ ] (0x00004000) Invariant MDL checking for driver
[ ] (0x00008000) Power framework delay fuzzing
[ ] (0x00010000) Port/miniport interface checking
[ ] (0x00040000) Systematic low resources simulation
[ ] (0x00080000) DDI compliance checking (additional)
[ ] (0x00200000) NDIS/WIFI verification
[ ] (0x00800000) Kernel synchronization delay fuzzing
[ ] (0x01000000) VM switch verification
[ ] (0x02000000) Code integrity checks

[X] Indicates flag is enabled


Summary of All Verifier Statistics

RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0

Pool Allocations Attempted 0x0
Pool Allocations Succeeded 0x0
Pool Allocations Succeeded SpecialPool 0x0
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0

Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x0 for 00000000 bytes

For OP:

Do you have Driver Verifier running at the moment? If so, please disable it and enable it again with the appropriate settings as illustrated in this guide - Driver Verifier - BSOD related - Windows 10, 8.1, 8, 7 + Vista
 
Ok, I got another one right when you replied. I'll do the driver verifier again

edit: it's running :)
 

Attachments

Last edited:
Code:
2: kd> kNL
# Child-SP RetAddr Call Site
00 ffffba8e`8947ad38 fffff802`23bd1ae9 nt!KeBugCheckEx
01 ffffba8e`8947ad40 fffff802`23bcde2b nt!KiBugCheckDispatch+0x69
02 ffffba8e`8947ae80 fffff802`23a42cb6 [HI]nt!KiPageFault+0x46b[/HI]
03 ffffba8e`8947b010 fffff802`23a42619 nt!RtlpHpVsChunkSplit+0x5a6
04 ffffba8e`8947b0e0 fffff802`23a32bae nt!RtlpHpVsContextAllocateInternal+0x3c9
05 ffffba8e`8947b150 fffff802`23d6d06d nt!ExAllocateHeapPool+0xc0e
06 ffffba8e`8947b290 fffff802`367d3a08 nt!ExAllocatePoolWithTag+0x5d
07 ffffba8e`8947b2e0 00000000`36305753 [HI]atikmdag+0xe3a08[/HI]
08 ffffba8e`8947b2e8 ffffba8e`8947b3c0 0x36305753
09 ffffba8e`8947b2f0 00000000`00000003 0xffffba8e`8947b3c0
0a ffffba8e`8947b2f8 00000000`00000000 0x3

Seems very likely to be a driver related issue, very similar call stack to the last crash, but this time there seems be a AMD graphics card driver hanging around, so I would suggest either checking for a driver update or rolling back a few versions to see if that provides any system stability.

Code:
2: kd> lmvm atikmdag
Browse full module list
start end module name
fffff802`366f0000 fffff802`3a0d1000 atikmdag T (no symbols)
Loaded symbol image file: atikmdag.sys
Image path: \SystemRoot\System32\DriverStore\FileRepository\u0345604.inf_amd64_8a71636be473da79\B345674\atikmdag.sys
Image name: atikmdag.sys
Browse all global symbols functions data
Timestamp: [HI]Thu Aug 8 16:20:17 2019[/HI] (5D4CAE31)
CheckSum: 039ACE25
ImageSize: 039E1000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

Have you tried booting into Safe Mode and seeing if the issue still occurs? Just to see if this is related to the driver and not the graphics card itself.
 
Another one, now with driver verifier, again by atikmdag. I'm running an older version of the driver (19.8.1) and the new is 19.9.1 also having the same problems :/
Apparently they don't even test their own drivers
Is there any way to stop this from happening else than waiting for amd?
 

Attachments

Code:
0: kd> lmvm atikmdag
Browse full module list
start end module name
fffff803`97370000 fffff803`9ad51000 atikmdag T (no symbols)
Loaded symbol image file: atikmdag.sys
Image path: \SystemRoot\System32\DriverStore\FileRepository\u0345604.inf_amd64_8a71636be473da79\B345674\atikmdag.sys
Image name: atikmdag.sys
Browse all global symbols functions data
Timestamp: [HI]Thu Aug 8 16:20:17 2019[/HI] (5D4CAE31)
CheckSum: 039ACE25
ImageSize: 039E1000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables:

Have you tried rolling back to an older version of the driver you have now?

Have you tried booting Safe Mode with Networking and seeing if you still experience the same issues?

The crash was a Stop 0x50, and again, the call stack is very similar to the other crashes, which leads me to believe that is more of a driver issue than hardware. Nonetheless, I would suggest running a GPU stress test to ensure that there is no hardware related issues - FurMark Display Card Stress Test

Call Stack:

Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff201`688adbd8 fffff802`1bff1f34 nt!KeBugCheckEx
01 fffff201`688adbe0 fffff802`1be829df nt!MiSystemFault+0x1d5374
02 fffff201`688adce0 fffff802`1bfddd20 nt!MmAccessFault+0x34f
03 fffff201`688ade80 fffff803`9862a85f [HI]nt!KiPageFault+0x360[/HI]
04 fffff201`688ae010 ffffda89`c4ecaae4 [HI]atikmdag+0x12ba85f[/HI]
05 fffff201`688ae018 ffffda89`c3acf601 0xffffda89`c4ecaae4
06 fffff201`688ae020 00000000`00000000 0xffffda89`c3acf601

If we dump the particular call stack frame, we can see all the bugcheck parameters too:

Code:
0: kd> .frame /r 4
04 fffff201`688ae010 ffffda89`c4ecaae4 atikmdag+0x12ba85f
rax=0000000000086770 rbx=ffffda89c4ecaae4 rcx=ffffda89d3600004
rdx=ffffda89c4ecaf54 rsi=0000000000000000 rdi=0000000000086770
rip=fffff8039862a85f rsp=fffff201688ae010 rbp=0000000000000000
r8=ffffda89d3600004 r9=0000000000003460 r10=000000001a000280
r11=0000000000000007 r12=0000000000000001 r13=0000000000000000
r14=ffffda89c38a2f00 r15=ffffda89c4ecac44
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040246
atikmdag+0x12ba85f:
[HI]fffff803`9862a85f[/HI] 41833c0a02 cmp dword ptr [r10+rcx],2 ds:002b:[HI]ffffda89`ed600284[/HI]=????????

Then using the !pte extension to dump the validity of the virtual address being referenced:

Code:
0: kd> !pte ffffda89`ed600284
VA ffffda89ed600284
PXE at FFFFEFF7FBFDFDA8 PPE at FFFFEFF7FBFB5138 PDE at FFFFEFF7F6A27B58 PTE at FFFFEFED44F6B000
contains 0A00000003278863 contains 0A00000004018863 contains 0000000000000000
pfn 3278 ---DA--KWEV pfn 4018 ---DA--KWEV contains 0000000000000000
[HI]not valid[/HI]

The address isn't valid, and therefore the system attempts to use a page fault to create a address translation which then fails due to some exception condition, which based on the instruction being executed the contents of the address, it is likely due to the fact that the address may have been freed.
 
Last edited:

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top