Code:
0: kd> .bugcheck
Bugcheck code 000000C4
Arguments 00000000`000000f6 00000000`000006f8 ffffe000`de434080 fffff801`7d79db8cThe reason for the bug check was verifier caught a driver referencing a user handle as kernel-mode, which is bad programming practice. There's a lot of reasons it's considered bad practice, with one being security.
With a small dump, we can't check about half of what we'd really need to debug this bug check, but we can try anyway.
Code:
0: kd> !process ffffe000de434080
GetPointerFromAddress: unable to read from fffff801285f1000
PROCESS ffffe000de434080
SessionId: none Cid: 1bd8 Peb: 7fa56000 ParentCid: 0c44
DirBase: 18cccc000 ObjectTable: ffffc00126f60040 HandleCount: <Data Not Accessible>
Image: PGPtray.exeSo first of all, checking the address of the current process, we can see the process is regarding Symantec's encryption software.
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 ffffd000`27c07968 fffff801`289136b0 nt!KeBugCheckEx
01 ffffd000`27c07970 fffff801`28918fa0 nt!VerifierBugCheckIfAppropriate+0x3c
02 ffffd000`27c079b0 fffff801`287c02df nt!VfCheckUserHandle+0x1b8
03 ffffd000`27c07a90 fffff801`288a17c2 nt! ?? ::NNGAKEGL::`string'+0x742f
04 ffffd000`27c07b30 fffff801`283ea4b3 nt!NtQueryInformationProcess+0xefe
05 ffffd000`27c08040 fffff801`283e2900 nt!KiSystemServiceCopyEnd+0x13
06 ffffd000`27c08248 fffff801`7d79db8c nt!KiServiceLinkage
07 ffffd000`27c08250 ffffcf80`2c15cc00 PGPwded+0x12b8c
08 ffffd000`27c08258 00000000`00000400 0xffffcf80`2c15cc00
09 ffffd000`27c08260 ffffe000`d8bad000 0x400
0a ffffd000`27c08268 fffff801`2890909a 0xffffe000`d8bad000
0b ffffd000`27c08270 fffff801`7d79e0e7 nt!VerifierExAllocatePoolEx+0x2a
0c ffffd000`27c082b0 ffffe000`d8bab7f0 PGPwded+0x130e7
0d ffffd000`27c082b8 fffff801`7cd264fe 0xffffe000`d8bab7f0
0e ffffd000`27c082c0 ffffd000`27c08350 VerifierExt!XdvQueryThreadContext+0x46
0f ffffd000`27c082f0 ffffe000`de109010 0xffffd000`27c08350
10 ffffd000`27c082f8 ffffe000`d8bab750 0xffffe000`de109010
11 ffffd000`27c08300 ffffe000`de109010 0xffffe000`d8bab750
12 ffffd000`27c08308 ffffe000`00000000 0xffffe000`de109010
13 ffffd000`27c08310 fffff801`7d7a08b0 0xffffe000`00000000
14 ffffd000`27c08318 fffff801`7cd1faf7 PGPwded+0x158b0
15 ffffd000`27c08320 fffff801`7dc03984 VerifierExt!xdv_IRP_MJ_CREATE_wrapper+0xfb
16 ffffd000`27c08380 ffffe000`d8bab750 fltsrv+0x3984
17 ffffd000`27c08388 ffffe000`dd19d170 0xffffe000`d8bab750
18 ffffd000`27c08390 ffffe000`de22e4f0 0xffffe000`dd19d170
19 ffffd000`27c08398 ffffd000`27c0840d 0xffffe000`de22e4f0
1a ffffd000`27c083a0 ffffe000`d6707b00 0xffffd000`27c0840d
1b ffffd000`27c083a8 fffff801`286bbda8 0xffffe000`d6707b00
1c ffffd000`27c083b0 fffff801`7dc0b86d nt!ObpAllocateObject+0x128
1d ffffd000`27c08430 00000000`00000000 fltsrv+0xb86dFrom the start of the stack regarding the thread that caused the crash, we can see Acronis was most likely opening a pre-existing file/folder (calls IRP_MJ_CREATE), and Symantec's encryption driver got involved directly afterwards. As to which driver out of the two of them had the bad programming practice, it's most likely Acronis. I'd remove Acronis and see if the crashes stop.
