(Bugcheck 0xa) A page fault happened in DPC level

NTDEV
1

The bugcheck randomly happened during reboot stress test,
I think there are two possible cause for the issue.
1.The DPC level is correct for the thread but there was something corrupted the memory space that current thread was trying to reference.
2.The DPC level is incorrect for the thread, there is something wrong to raise the IRQL to DPC level in the thread.

anyone can give me suggestion?
thanks in advanced.

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffda5a7fd8da5a, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff803eeb65b69, address which referenced memory

Debugging Details:

BUGCHECK_P1: ffffda5a7fd8da5a

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: fffff803eeb65b69

READ_ADDRESS: ffffda5a7fd8da5a

CURRENT_IRQL: 2

FAULTING_IP:
nt!MiCaptureProtectionFromLockedProto+25
fffff803`eeb65b69 498b1e mov rbx,qword ptr [r14]

CPU_COUNT: 4

CPU_MHZ: 6a0

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 45

CPU_STEPPING: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: conhost.exe

ANALYSIS_VERSION: 10.0.10075.9 amd64fre

TRAP_FRAME: ffffd001744ff520 -- (.trap 0xffffd001744ff520)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffe00086597080 rbx=0000000000000000 rcx=ffffda5a7fd8da5a
rdx=fffff68022416340 rsi=0000000000000000 rdi=0000000000000000
rip=fffff803eeb65b69 rsp=ffffd001744ff6b0 rbp=ffffda5a7fd8da5a
r8=0000000000000000 r9=0000000000000001 r10=0000000000000000
r11=7fffffffffffffff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!MiCaptureProtectionFromLockedProto+0x25:
fffff803eeb65b69 498b1e mov rbx,qword ptr [r14] ds:0000000000000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff803eebda6a9 to fffff803eebcfd00

STACK_TEXT:
ffffd001744ff3d8 fffff803eebda6a9 : 000000000000000a ffffda5a7fd8da5a 0000000000000002 0000000000000000 : nt!KeBugCheckEx
ffffd001744ff3e0 fffff803eebd8ec8 : fffff6fb00000000 0000000000000000 3fffffffffffffff fffffa8000f62ca0 : nt!KiBugCheckDispatch+0x69
ffffd001744ff520 fffff803eeb65b69 : 0000000000000011 fffff803eee8a108 fffff6fb7dbedf68 fffff6fb7dbed000 : nt!KiPageFault+0x248
ffffd001744ff6b0 fffff803eeaa84d0 : da5a7fd8da5a7fd8 ffffda5a7fd8da5a 0000000000000000 fffff68022416870 : nt!MiCaptureProtectionFromLockedProto+0x25
ffffd001744ff6f0 fffff803eeaad451 : 0000000000000080 0000000000000080 0000004482c68000 0000000000000000 : nt!MiGetPageProtection+0x1d0
ffffd001744ff740 fffff803eee890b9 : 0000000000000000 ffffd001744ff8c0 0000000000000000 0000000000000000 : nt!MiCommitExistingVad+0x701
ffffd001744ff850 fffff803eee88d70 : 0000000000000000 ffffe00086597080 0000000000000000 0000000000000080 : nt!MiAllocateVirtualMemory+0x339
ffffd001744ffa30 fffff803eebda363 : fffff6fb401120a0 fffff68022414f20 ffffbc92463408c3 fffff960004e8071 : nt!NtAllocateVirtualMemory+0x40
ffffd001744ffa90 00007ffd27cd367a : 00007ffd27c71d6b 0000004480a20000 0000000000000000 0000004480a28200 : nt!KiSystemServiceCopyEnd+0x13
0000004480d0efe8 00007ffd27c71d6b : 0000004480a20000 0000000000000000 0000004480a28200 0000004480a20000 : ntdll!NtAllocateVirtualMemory+0xa
0000004480d0eff0 00007ffd27c6eed2 : 0000004480a20000 0000000000340002 0000000000107b38 0000000000107b78 : ntdll!RtlpAllocateHeap+0x128b
0000004480d0f2e0 00007ffd12ee32cf : 0000004482590868 0000000000000000 0000000000000019 0000000000000003 : ntdll!RtlpAllocateHeapInternal+0x292
0000004480d0f360 00007ffd12ee3058 : 0000000023290078 000000000007b0f8 0000000000000008 0000004400000003 : ConhostV2!DBCS_SCREEN_BUFFER::CreateInstance+0x133
0000004480d0f390 00007ffd12ee2cb5 : 00000044002a00a8 0000004423290078 0000004400070020 0000000000000008 : ConhostV2!TEXT_BUFFER_INFO::CreateInstance+0x1b8
0000004480d0f420 00007ffd12ee2b1d : ffffffff001e0078 00007ffd00000000 ffffffff23290078 0000000000070020 : ConhostV2!SCREEN_INFORMATION::CreateInstance+0x185
0000004480d0f490 00007ffd12ee2896 : 0000000000f50020 00007ffd00070020 0000000000000072 0000000000000000 : ConhostV2!DoCreateScreenBuffer+0x129
0000004480d0f4f0 00007ffd12ee3a9f : 0000000000000000 0000004480d0f7c4 0000000000000000 0000004480d0f680 : ConhostV2!AllocateConsole+0x152
0000004480d0f560 00007ffd12ee20c6 : 00007ffd12f23cc0 0000004400000072 0000004480a2ad70 0000000000000000 : ConhostV2!SetUpConsole+0x103
0000004480d0f5b0 00007ffd12eeb28d : 0000004480a2ad70 0000004480d0fdf0 0000000000000000 0000004480a20150 : ConhostV2!ConsoleAllocateConsole+0x42
0000004480d0f620 00007ffd12ee84bd : 0000000000000000 0000000000000000 0000000000000000 0000004480d0fe40 : ConhostV2!ConsoleHandleConnectionRequest+0x28d
0000004480d0fd40 00007ffd272a2d92 : 0000000000000000 00007ffd12ee7fd0 0000000000000004 0000000000000004 : ConhostV2!ConsoleIoThread+0x4ed
0000004480d0ff30 00007ffd27c49f64 : 00007ffd272a2d70 0000000000000000 0000000000000000 0000000000000000 : KERNEL32!BaseThreadInitThunk+0x22
0000004480d0ff60 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x34

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiCaptureProtectionFromLockedProto+25
fffff803`eeb65b69 498b1e mov rbx,qword ptr [r14]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: nt!MiCaptureProtectionFromLockedProto+25

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 55c5a3b2

IMAGE_NAME: memory_corruption

BUCKET_ID_FUNC_OFFSET: 25

FAILURE_BUCKET_ID: AV_nt!MiCaptureProtectionFromLockedProto

BUCKET_ID: AV_nt!MiCaptureProtectionFromLockedProto

PRIMARY_PROBLEM_CLASS: AV_nt!MiCaptureProtectionFromLockedProto

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_nt!micaptureprotectionfromlockedproto

FAILURE_ID_HASH: {a27305a9-6bcf-6500-5f96-c9c00e452411}

Followup: MachineOwner

3: kd> .trap 0xffffd001744ff520
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffe00086597080 rbx=0000000000000000 rcx=ffffda5a7fd8da5a
rdx=fffff68022416340 rsi=0000000000000000 rdi=0000000000000000
rip=fffff803eeb65b69 rsp=ffffd001744ff6b0 rbp=ffffda5a7fd8da5a
r8=0000000000000000 r9=0000000000000001 r10=0000000000000000
r11=7fffffffffffffff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!MiCaptureProtectionFromLockedProto+0x25:
fffff803eeb65b69 498b1e mov rbx,qword ptr [r14] ds:0000000000000000=????????????????

2

xxxxx@hotmail.com wrote:

The bugcheck randomly happened during reboot stress test,
I think there are two possible cause for the issue.
1.The DPC level is correct for the thread but there was something corrupted the memory space that current thread was trying to reference.
2.The DPC level is incorrect for the thread, there is something wrong to raise the IRQL to DPC level in the thread.

It is almost certainly #1. The address being referenced is suspicious:
ffffda5a7fd8da5a. Also notice the stack dump for that call:

ffffd001744ff6b0 fffff803eeaa84d0 : da5a7fd8da5a7fd8 ffffda5a7fd8da5a 0000000000000000 fffff68022416870 : nt!MiCaptureProtectionFromLockedProto+0x25

This is odd –> da5a 7fd8 da5a 7fd8 ffff da5a 7fd8 da5a

Looks like a buffer overrun to me. Do you have a driver in this horse race?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

Perhaps I’m missing something, but your dump shows the IRQL as 2, which is dispatch level, not DPC level.

Jeff

4

Agh!! Ignore what I just said. I was thinking APC level, not DPC level (the latter of course being the same as dispatch level).

Jeff

5

[quote]
This is odd –> da5a 7fd8 da5a 7fd8 ffff da5a 7fd8 da5a

Looks like a buffer overrun to me. Do you have a driver in this horse race?

[quote]

Hi Tim,

I don’t have my own driver on the system, so I wonder which driver verifier option should be enabled for the issue.
Do you have any suggestion?

6

DISPATCH_LEVEL is DPC level

wrote in message news:xxxxx@ntdev…
> Perhaps I’m missing something, but your dump shows the IRQL as 2, which is dispatch level, not DPC level.
>
> Jeff
>
>

7

xxxxx@hotmail.com wrote:

[quote]
This is odd –> da5a 7fd8 da5a 7fd8 ffff da5a 7fd8 da5a

Looks like a buffer overrun to me. Do you have a driver in this horse race?

[quote]

I don’t have my own driver on the system, so I wonder which driver verifier option should be enabled for the issue.
Do you have any suggestion?

Just use the standard options.

If you don’t have a driver, then what are you testing here? And if you
do get a Driver Verifier hit, what are you going to do next?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

I’m suspecting this is caused by 3rd party’s software(an anti-virus product from intel), I’m testing our platform’s reliability with all the 3rd party components,so if the verifier can catch some failures when monitoring those 3rd party’s components, I will report them the issue.

Subject: Re: [ntdev] (Bugcheck 0xa) A page fault happened in DPC level
To: xxxxx@lists.osr.com
From: xxxxx@probo.com
Date: Wed, 14 Oct 2015 11:15:35 -0700

xxxxx@hotmail.com wrote:
> [quote]
> This is odd –> da5a 7fd8 da5a 7fd8 ffff da5a 7fd8 da5a
>
> Looks like a buffer overrun to me. Do you have a driver in this horse race?
> [quote]
>
> I don’t have my own driver on the system, so I wonder which driver verifier option should be enabled for the issue.
> Do you have any suggestion?

Just use the standard options.

If you don’t have a driver, then what are you testing here? And if you
do get a Driver Verifier hit, what are you going to do next?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer