Bug Check 0x139 for KeWaitForSingleObject()

NTDEV
1

Hi

I am calling KeWaitForSingleObject in the following code blocks. If the msecs = 0, it works fine. If msecs is changed to none zero e.g. 5, I will get bug check 0x139. How can I solve this issue?

Thanks,

Ying

======================================================

typedef struct _event_t {
KEVENT evt;
KDPC dpc;
} wait_event_t;

void wakeDPC(IN struct _KDPC *Dpc, IN PVOID DeferredContext, IN PVOID Arg1, IN PVOID Arg2)
{
wait_event_t *ev_p = (os_wait_queue_head *)DeferredContext;
if (!ev_p) return;
KeSetEvent(&ev_p->evt, 0, FALSE);
}

void init_waitevent(wait_event_t *ev_p)
{
KeInitializeEvent(&ev_p->evt, NotificationEvent, FALSE);
KeInitializeDpc(&ev_p->dpc, wakeDPC, ev_p);
}

static long event_wait_ex(wait_event_t *ev_p, unsigned int msecs)
{
long rc = 0;
LONG units;
LARGE_INTEGER delay;
NTSTATUS status;

units = msecs * 10000;
delay = RtlConvertLongToLargeInteger(-units);

status = KeWaitForSingleObject(&ev_p->evt, Executive, KernelMode, TRUE, &delay);

rc = (status == STATUS_SUCCESS) ? 1 :
((status == STATUS_TIMEOUT) ? 0 : -ERESTARTSYS);

KeClearEvent(&ev_p->evt);

return rc;
}

void wake_up(wait_event_t *ev_p)
{
if (KeGetCurrentIrql() <= DISPATCH_LEVEL) {
KeSetEvent(&ev_p->evt, 0, FALSE);
} else { // irql is too high and schedule dpc to wakeup the event.
KeInsertQueueDpc(&ev_p->dpc, NULL, NULL);
}
}

long do_ioctl(struct my_dev *dev, unsigned int cmd, void __user *uargp)
{

// submit request to device then
...........
ret_ = event_wait_ex(&wq_, msecs);
...........

}

// in a lower IRQL thread context actived by the ISR

int service_work_left_from_isr()
{

....

wake_up(ev_p);

....
}

=========================================== output from Windbg

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: fffff8800a05a3f0, Address of the trap frame for the exception that caused the bugcheck
Arg3: fffff8800a05a348, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

Debugging Details:

TRAP_FRAME: fffff8800a05a3f0 -- (.trap 0xfffff8800a05a3f0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff8800a05a6e8 rbx=0000000000000000 rcx=0000000000000003
rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000000
rip=fffff803a2722a86 rsp=fffff8800a05a580 rbp=0000000000000000
r8=0000000000000000 r9=fffff780000003b0 r10=fffff78000000008
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt! ?? ::FNODOBFM::string'+0x11e13: fffff803a2722a86 cd29 int 29h
Resetting default scope

EXCEPTION_RECORD: fffff8800a05a348 -- (.exr 0xfffff8800a05a348)
ExceptionAddress: fffff803a2722a86 (nt! ?? ::FNODOBFM::`string'+0x0000000000011e13)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000003

DEFAULT_BUCKET_ID: LIST_ENTRY_CORRUPT

BUGCHECK_STR: 0x139

PROCESS_NAME: myservice.exe

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_PARAMETER1: 0000000000000003

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from fffff803a278caba to fffff803a2663cb0

STACK_TEXT:
fffff8800a059908 fffff803a278caba : fffff6fc01d16cd8 fffff6fb7e00e8b0 fffff6fb7dbf0070 fffff6fb7dbedf80 : nt!DbgBreakPointWithStatus
fffff8800a059910 fffff803a278c44a : fffff80300000004 fffff803a28e2ea0 0000000000000000 0000000000000001 : nt!KiBugCheckDebugBreak+0x12
fffff8800a059970 fffff803a2669544 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheck2+0xadb
fffff8800a05a090 fffff803a2668769 : 0000000000000139 0000000000000003 fffff8800a05a3f0 fffff8800a05a348 : nt!KeBugCheckEx+0x104
fffff8800a05a0d0 fffff803a2668a90 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiBugCheckDispatch+0x69
fffff8800a05a210 fffff803a2667cf4 : 0000000000000000 0000000000000000 fffff8800a05a4f0 0000000000000000 : nt!KiFastFailDispatch+0xd0
fffff8800a05a3f0 fffff803a2722a86 : 0000000000000050 ffff2f652026003e fffff8800a05a4f0 ffff2f652026fc2d : nt!KiRaiseSecurityCheckFailure+0xf4
fffff8800a05a580 fffff880098e8d54 : fffff8800a05a6e0 fffff88000000000 fffffa800b364b00 fffff880098e8300 : nt! ?? ::FNODOBFM::string'+0x11e13 fffff8800a05a610 fffff880098e8bcf : fffff8800a05a6e0 fffff880000000c3 fffff880098edc80 0000000000000246 : mydrv!win_event_wait_ex+0x44 [wn.c @ 1216] fffff8800a05a670 fffff880098d83c4 : fffff8800a05a6e0 0000000000000000 00000000000000c3 0000000000000000 : mydrv!wait_event_interruptible_timeout+0x2f [wn.c @ 1234] fffff8800a05a6b0 fffff880098d7a15 : fffffa800c784000 fffff880000000c3 fffff8800a05a808 00000000025ffcb8 : mydrv!wait_on_donelist+0x74 [cb.c @ 276] fffff8800a05a760 fffff880098d8ae5 : fffffa800c784000 fffff8800a05a830 fffff8800a05a7e4 0000000000000000 : mydrv!cb_read+0x125 [cb.c @ 357] fffff8800a05a7b0 fffff880098d7e6b : fffffa800c784000 00000000025ffca8 fffff88000000000 0000000000000002 : mydrv!ucb_io_read+0xe5 [cb.c @ 582] fffff8800a05a870 fffff880098df84f : fffffa800c784000 fffff8a09c410040 00000000025ffca8 fffffa800b907cd0 : mydrv!cb_ioctl+0xeb [cb.c @ 644] fffff8800a05a8c0 fffff880098e5b82 : fffffa800c784000 000000009c410040 00000000025ffca8 0000000020206f49 : mydrv!do_ioctl+0x17f [main.c @ 2190] fffff8800a05a900 fffff880098e4797 : fffffa800c784000 000000009c410040 00000000025ffca8 0000000000000000 : mydrv!do_ioctl_main+0x62 [main.c @ 3093] fffff8800a05a940 fffff803a2a43457 : fffffa800a842480 fffffa800bf1b9e0 0000000000000001 fffff80300000000 : mydrv!main_dispatch+0x3a7 [main.c @ 3160] fffff8800a05a9d0 fffff803a2a58646 : fffffa800b907c00 fffffa8000000000 0000000000000000 00000000025ffcd0 : nt!IopXxxControlFile+0x7e5 fffff8800a05ab60 fffff803a2668453 : fffff8800a05ac50 0000000000000000 0000000000000000 0000000000000000 : nt!NtDeviceIoControlFile+0x56 fffff8800a05abd0 000007fc11e62bda : 000007fc0f04239d 0000000000000003 0000000000000000 000000000000037f : nt!KiSystemServiceCopyEnd+0x13 00000000025ffb88 000007fc0f04239d : 0000000000000003 0000000000000000 000000000000037f 0000000002216260 : ntdll!NtDeviceIoControlFile+0xa 00000000025ffb90 000007fc0f452480 : 000000009c410040 00000000022102c0 0000000000787660 0000000000000296 : KERNELBASE!DeviceIoControl+0x1d9 00000000025ffc00 00000000004012be : 0000000000651690 0000000002211e30 0000000000000000 0000000000000000 : KERNEL32!DeviceIoControlImplementation+0x74 00000000025ffc50 0000000000651690 : 0000000002211e30 0000000000000000 0000000000000000 0000000000000000 : pedClient+0x12be 00000000025ffc58 0000000002211e30 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : pedClient+0x251690 00000000025ffc60 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`025ffd58 : 0x2211e30

STACK_COMMAND: kb

FOLLOWUP_IP:
mydrv!event_wait_ex+44 [wn.c @ 1216]
fffff880`098e8d54 89442430 mov dword ptr [rsp+30h],eax

FAULTING_SOURCE_LINE: wn.c

FAULTING_SOURCE_FILE: wn.c

FAULTING_SOURCE_LINE_NUMBER: 1216

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: mydrv!event_wait_ex+44

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: mydrv

IMAGE_NAME: mydrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 560aeeab

BUCKET_ID_FUNC_OFFSET: 44

FAILURE_BUCKET_ID: 0x139_3_mydrv!event_wait_ex

BUCKET_ID: 0x139_3_mydrv!event_wait_ex

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x139_3_mydrv!event_wait_ex

FAILURE_ID_HASH: {4a9ae1e5-38da-1cdb-fa75-44896bc24fe0}

Followup: MachineOwner

2

Your crash analysis suggests your were at DISPATCH_LEVEL(2) when you tried to wait. The MSDN docs for KeWaitForSingleObject say:

"Callers of KeWaitForSingleObject must be running at IRQL <= DISPATCH_LEVEL. However, if Timeout = NULL or *Timeout != 0, the caller must be running at IRQL <= APC_LEVEL and in a nonarbitrary thread context. (If Timeout != NULL and *Timeout = 0, the caller must be running at IRQL <= DISPATCH_LEVEL.)”

Perhaps you should put at IRQL assert just before your wait on a not-zero timeout, just to verify the IRQL.

Jan

On 9/29/15, 2:06 PM, “xxxxx@lists.osr.com on behalf of xxxxx@yahoo.ca” wrote:

>Hi
>
>I am calling KeWaitForSingleObject in the following code blocks. If the msecs = 0, it works fine. If msecs is changed to none zero e.g. 5, I will get bug check 0x139. How can I solve this issue?
>
>Thanks,
>
>Ying
>
>======================================================
>
>typedef struct _event_t {
> KEVENT evt;
> KDPC dpc;
>} wait_event_t;
>
>void wakeDPC(IN struct _KDPC *Dpc, IN PVOID DeferredContext, IN PVOID Arg1, IN PVOID Arg2)
>{
> wait_event_t *ev_p = (os_wait_queue_head *)DeferredContext;
> if (!ev_p) return;
> KeSetEvent(&ev_p->evt, 0, FALSE);
>}
>
>
>void init_waitevent(wait_event_t *ev_p)
>{
> KeInitializeEvent(&ev_p->evt, NotificationEvent, FALSE);
> KeInitializeDpc(&ev_p->dpc, wakeDPC, ev_p);
>}
>
>static long event_wait_ex(wait_event_t *ev_p, unsigned int msecs)
>{
> long rc = 0;
> LONG units;
> LARGE_INTEGER delay;
> NTSTATUS status;
>
>
> units = msecs * 10000;
> delay = RtlConvertLongToLargeInteger(-units);
>
> status = KeWaitForSingleObject(&ev_p->evt, Executive, KernelMode, TRUE, &delay);
>
> rc = (status == STATUS_SUCCESS) ? 1 :
> ((status == STATUS_TIMEOUT) ? 0 : -ERESTARTSYS);
>
> KeClearEvent(&ev_p->evt);
>
> return rc;
>}
>
>void wake_up(wait_event_t *ev_p)
>{
> if (KeGetCurrentIrql() <= DISPATCH_LEVEL) {
> KeSetEvent(&ev_p->evt, 0, FALSE);
> } else { // irql is too high and schedule dpc to wakeup the event.
> KeInsertQueueDpc(&ev_p->dpc, NULL, NULL);
> }
>}
>
>
>long do_ioctl(struct my_dev *dev, unsigned int cmd, void user *uargp)
>{
>
>// submit request to device then
>…
>ret = event_wait_ex(&wq, msecs);
>…
>
>}
>
>// in a lower IRQL thread context actived by the ISR
>
>int service_work_left_from_isr()
>{
>
>…
>
>wake_up(ev_p);
>
>…
>}
>
>
>=========================================== output from Windbg
>
>
>KERNEL_SECURITY_CHECK_FAILURE (139)
>A kernel component has corrupted a critical data structure. The corruption
>could potentially allow a malicious user to gain control of this machine.
>Arguments:
>Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
>Arg2: fffff8800a05a3f0, Address of the trap frame for the exception that caused the bugcheck
>Arg3: fffff8800a05a348, Address of the exception record for the exception that caused the bugcheck
>Arg4: 0000000000000000, Reserved
>
>Debugging Details:
>------------------
>
>
>TRAP_FRAME: fffff8800a05a3f0 – (.trap 0xfffff8800a05a3f0)
>NOTE: The trap frame does not contain all registers.
>Some register values may be zeroed or incorrect.
>rax=fffff8800a05a6e8 rbx=0000000000000000 rcx=0000000000000003
>rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000000
>rip=fffff803a2722a86 rsp=fffff8800a05a580 rbp=0000000000000000
> r8=0000000000000000 r9=fffff780000003b0 r10=fffff78000000008
>r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
>r14=0000000000000000 r15=0000000000000000
>iopl=0 nv up ei pl nz na po nc
>nt! ?? ::FNODOBFM::string'+0x11e13:<br>&gt;fffff803a2722a86 cd29 int 29h
>Resetting default scope
>
>EXCEPTION_RECORD: fffff8800a05a348 – (.exr 0xfffff8800a05a348)
>ExceptionAddress: fffff803a2722a86 (nt! ?? ::FNODOBFM::string'+0x0000000000011e13)<br>&gt; ExceptionCode: c0000409 (Security check failure or stack buffer overrun)<br>&gt; ExceptionFlags: 00000001<br>&gt;NumberParameters: 1<br>&gt; Parameter[0]: 0000000000000003<br>&gt;<br>&gt;DEFAULT_BUCKET_ID: LIST_ENTRY_CORRUPT<br>&gt;<br>&gt;BUGCHECK_STR: 0x139<br>&gt;<br>&gt;PROCESS_NAME: myservice.exe<br>&gt;<br>&gt;CURRENT_IRQL: 2<br>&gt;<br>&gt;ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.<br>&gt;<br>&gt;EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.<br>&gt;<br>&gt;EXCEPTION_PARAMETER1: 0000000000000003<br>&gt;<br>&gt;ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre<br>&gt;<br>&gt;LAST_CONTROL_TRANSFER: from fffff803a278caba to fffff803a2663cb0<br>&gt;<br>&gt;STACK_TEXT: <br>&gt;fffff8800a059908 fffff803a278caba : fffff6fc01d16cd8 fffff6fb7e00e8b0 fffff6fb7dbf0070 fffff6fb7dbedf80 : nt!DbgBreakPointWithStatus<br>&gt;fffff8800a059910 fffff803a278c44a : fffff80300000004 fffff803a28e2ea0 0000000000000000 0000000000000001 : nt!KiBugCheckDebugBreak+0x12<br>&gt;fffff8800a059970 fffff803a2669544 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheck2+0xadb<br>&gt;fffff8800a05a090 fffff803a2668769 : 0000000000000139 0000000000000003 fffff8800a05a3f0 fffff8800a05a348 : nt!KeBugCheckEx+0x104<br>&gt;fffff8800a05a0d0 fffff803a2668a90 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiBugCheckDispatch+0x69<br>&gt;fffff8800a05a210 fffff803a2667cf4 : 0000000000000000 0000000000000000 fffff8800a05a4f0 0000000000000000 : nt!KiFastFailDispatch+0xd0<br>&gt;fffff8800a05a3f0 fffff803a2722a86 : 0000000000000050 ffff2f652026003e fffff8800a05a4f0 ffff2f652026fc2d : nt!KiRaiseSecurityCheckFailure+0xf4<br>&gt;fffff8800a05a580 fffff880098e8d54 : fffff8800a05a6e0 fffff88000000000 fffffa800b364b00 fffff880098e8300 : nt! ?? ::FNODOBFM::string’+0x11e13
>fffff8800a05a610 fffff880098e8bcf : fffff8800a05a6e0 fffff880000000c3 fffff880098edc80 0000000000000246 : mydrv!win_event_wait_ex+0x44 [wn.c @ 1216]
>fffff8800a05a670 fffff880098d83c4 : fffff8800a05a6e0 0000000000000000 00000000000000c3 0000000000000000 : mydrv!wait_event_interruptible_timeout+0x2f [wn.c @ 1234]
>fffff8800a05a6b0 fffff880098d7a15 : fffffa800c784000 fffff880000000c3 fffff8800a05a808 00000000025ffcb8 : mydrv!wait_on_donelist+0x74 [cb.c @ 276]
>fffff8800a05a760 fffff880098d8ae5 : fffffa800c784000 fffff8800a05a830 fffff8800a05a7e4 0000000000000000 : mydrv!cb_read+0x125 [cb.c @ 357]
>fffff8800a05a7b0 fffff880098d7e6b : fffffa800c784000 00000000025ffca8 fffff88000000000 0000000000000002 : mydrv!ucb_io_read+0xe5 [cb.c @ 582]
>fffff8800a05a870 fffff880098df84f : fffffa800c784000 fffff8a09c410040 00000000025ffca8 fffffa800b907cd0 : mydrv!cb_ioctl+0xeb [cb.c @ 644]
>fffff8800a05a8c0 fffff880098e5b82 : fffffa800c784000 000000009c410040 00000000025ffca8 0000000020206f49 : mydrv!do_ioctl+0x17f [main.c @ 2190]
>fffff8800a05a900 fffff880098e4797 : fffffa800c784000 000000009c410040 00000000025ffca8 0000000000000000 : mydrv!do_ioctl_main+0x62 [main.c @ 3093]
>fffff8800a05a940 fffff803a2a43457 : fffffa800a842480 fffffa800bf1b9e0 0000000000000001 fffff80300000000 : mydrv!main_dispatch+0x3a7 [main.c @ 3160]
>fffff8800a05a9d0 fffff803a2a58646 : fffffa800b907c00 fffffa8000000000 0000000000000000 00000000025ffcd0 : nt!IopXxxControlFile+0x7e5
>fffff8800a05ab60 fffff803a2668453 : fffff8800a05ac50 0000000000000000 0000000000000000 0000000000000000 : nt!NtDeviceIoControlFile+0x56
>fffff8800a05abd0 000007fc11e62bda : 000007fc0f04239d 0000000000000003 0000000000000000 000000000000037f : nt!KiSystemServiceCopyEnd+0x13
>00000000025ffb88 000007fc0f04239d : 0000000000000003 0000000000000000 000000000000037f 0000000002216260 : ntdll!NtDeviceIoControlFile+0xa
>00000000025ffb90 000007fc0f452480 : 000000009c410040 00000000022102c0 0000000000787660 0000000000000296 : KERNELBASE!DeviceIoControl+0x1d9
>00000000025ffc00 00000000004012be : 0000000000651690 0000000002211e30 0000000000000000 0000000000000000 : KERNEL32!DeviceIoControlImplementation+0x74
>00000000025ffc50 0000000000651690 : 0000000002211e30 0000000000000000 0000000000000000 0000000000000000 : pedClient+0x12be
>00000000025ffc58 0000000002211e30 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : pedClient+0x251690
>00000000025ffc60 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000025ffd58 : 0x2211e30
>
>
>STACK_COMMAND: kb
>
>FOLLOWUP_IP:
>mydrv!event_wait_ex+44 [wn.c @ 1216]
>fffff880`098e8d54 89442430 mov dword ptr [rsp+30h],eax
>
>FAULTING_SOURCE_LINE: wn.c
>
>FAULTING_SOURCE_FILE: wn.c
>
>FAULTING_SOURCE_LINE_NUMBER: 1216
>
>SYMBOL_STACK_INDEX: 8
>
>SYMBOL_NAME: mydrv!event_wait_ex+44
>
>FOLLOWUP_NAME: MachineOwner
>
>MODULE_NAME: mydrv
>
>IMAGE_NAME: mydrv.sys
>
>DEBUG_FLR_IMAGE_TIMESTAMP: 560aeeab
>
>BUCKET_ID_FUNC_OFFSET: 44
>
>FAILURE_BUCKET_ID: 0x139_3_mydrv!event_wait_ex
>
>BUCKET_ID: 0x139_3_mydrv!event_wait_ex
>
>ANALYSIS_SOURCE: KM
>
>FAILURE_ID_HASH_STRING: km:0x139_3_mydrv!event_wait_ex
>
>FAILURE_ID_HASH: {4a9ae1e5-38da-1cdb-fa75-44896bc24fe0}
>
>Followup: MachineOwner
>---------
>
>
>—
>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

3

On Tue, Sep 29, 2015 at 5:06 PM, wrote:

> KeWaitForSingleObject(&ev_p->evt, Executive, KernelMode, TRUE, &delay)
>

Why are you setting Alertable to TRUE?

Mark Roddy

4

My guess is that you’re corrupting something and that
KeWaitForSingleObject just
happens to trigger the fault. I didn’t look closely at your code but based
on the bugcheck it’s probably somewhere else.

On Tue, Sep 29, 2015 at 5:52 PM, Mark Roddy wrote:

>
> On Tue, Sep 29, 2015 at 5:06 PM, wrote:
>
>> KeWaitForSingleObject(&ev_p->evt, Executive, KernelMode, TRUE, &delay)
>>
>
> Why are you setting Alertable to TRUE?
>
> Mark Roddy
> — 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
>

5

Hi Jan,

Thanks for your feedback. Though the crash log show that IRQL level is 2 = DISPATCH_LEVEL, the actual IRQL level is 0 = PASSIVE_LEVEL before calling KeWaitForSingleObject(). I think there is something else causing the bug check code 0x139.

Ying

6

Hi Mark,

The reason I set Alertable to TRUE is for user application to be kill e.g. control-c.

Thanks,

Ying

7

Hi Paul,

You are right that the KEVENT object initialize during device enumeration at very beginning is somehow corrupted as after I replaced it with a new KEVENT just intialized in the same function event_wait_ex() before calling KeWaitForSingleObject(), the bug check 0x139 goes away.

I need to spent more time to see how that KEVENT object is corrupted.

Thanks for your kind help.

Cheers,

Ying

8

It isn’t clear to me at all that you are in a specific application thread
context when you wait on that event. Instead it appears that you are in an
arbitrary thread context and you should not be setting Alertable to TRUE.

Mark Roddy

On Wed, Sep 30, 2015 at 12:31 PM, wrote:

> Hi Mark,
>
> The reason I set Alertable to TRUE is for user application to be kill e.g.
> control-c.
>
> Thanks,
>
> Ying
>
> —
> 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
>

9

Hi All,

The issue is caused by passing a copy of wait_event_t is passed to a function after it is initialized
by KeInitializeEvent() before calling KeWaitForSingleObject(). My believe is that passing by copy does not update some of the KEVENT link list pointers which are required to execute KeWaitForSingleObject() correctly.

Thanks everyone for your suggestions.

Cheers,

Ying

10

@Mark Roddy:

The crash stack is in DeviceIoControl context, which I suppose, is the application that wanted this sync call.