BSOD with thread created using PsCreateSystemThread - need help

NTDEV
1

Hi,

I am running into a problem of follwoing BSOD, when I tries to use thread created using PsCreateSystemThread. It seems to work, but eventually gets a BSOD, I am not able to get any clue what's wrong here. I see this is called at very high IRQL d at the time of BSOD, for normal operation it is called at LOW_LEVEL 0. I expetcs system to call my thread at passive level all the time. I have no clue why it is happening.

Information about the threads:
I am creating one thread per core of the system processor by assiging the affinity to a specific core. The thread is initialized using the SynchronizationEvent. I can provide more information if needed to debug this issue.

The BSOD is:
5: 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: ffffcb0015c72260, memory referenced
Arg2: 000000000000000d, 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: fffff8000166acc2, address which referenced memory

Debugging Details:

READ_ADDRESS: ffffcb0015c72260

CURRENT_IRQL: d

FAULTING_IP:
nt!KdPollBreakIn+d1
fffff800`0166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi*8]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffffa60028a4890 -- (.trap 0xfffffa60028a4890)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=fffffa80077f9018 rcx=ffffffffffd0d000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000100000000
rip=fffff8000166acc2 rsp=fffffa60028a4a20 rbp=fffff800018051e0
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=000000000000000c r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
nt!KdPollBreakIn+0xd1:
fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi*8] ss:0018:fffff808018051e0=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001713c72 to fffff8000165b860

STACK_TEXT:
fffffa60028a4038 fffff80001713c72 : fffffa8007c3ebb0 0000000000000065 ffffcb0015c72260 fffff80001626c38 : nt!RtlpBreakWithStatusInstruction
fffffa60028a4040 fffff80001714a2b : ffffcb0000000003 0000000000000000 fffff800016a1d90 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffffa60028a40a0 fffff80001661494 : 0000000000000000 fffffa60034b18e2 fffffa8008daa106 fffff8000024ffff : nt!KeBugCheck2+0x6eb
fffffa60028a4710 fffff8000166112e : 000000000000000a ffffcb0015c72260 000000000000000d 0000000000000000 : nt!KeBugCheckEx+0x104
fffffa60028a4750 fffff8000166000b : 0000000000000000 fffffa8007790048 0000000100000000 0000000000000001 : nt!KiBugCheckDispatch+0x6e
fffffa60028a4890 fffff8000166acc2 : 0000000000000001 fffff800018051e0 0000000000026100 0000000000000000 : nt!KiPageFault+0x20b
fffffa60028a4a20 fffff80001669e3a : fffffa60018af180 fffffa60028a4aa0 0000000000026160 fffffa8007c3ebb0 : nt!KdPollBreakIn+0xd1
fffffa60028a4a60 fffff8000165afef : 0000000000000000 fffffa60028a4b20 fffffa8007b42158 fffffa8007c3eca8 : nt!KeUpdateRunTime+0x14a
fffffa60028a4aa0 fffff800016681dd : 0000000000000000 0000000000000100 0000000000000005 fffffa8000000009 : nt!KiSecondaryClockInterrupt+0x11f
fffffa60028a4c30 fffffa600346f3b3 : fffffa8000000000 fffffa8000000000 fffffa80077f9700 fffffa8003989c00 : nt!KeWaitForSingleObject+0x12d
fffffa60028a4cc0 fffff80001884de3 : fffffa80077f9720 0000000000000000 0000000000000000 0000000000000001 : ifM60x64!VmpSCQThread+0x1b3 [c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]
fffffa60028a4d50 fffff8000169b536 : fffffa600198d180 fffffa8007c3ebb0 fffffa6001996d40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60028a4d80 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
ifM60x64!VmpSCQThread+1b3 [c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]
fffffa60`0346f3b3 8944244c mov dword ptr [rsp+4Ch],eax

FAULTING_SOURCE_CODE:
5786: Status = KeWaitForSingleObject(((PVOID)((volatile void *)&(((PQ_THREAD)Context)->Event))),
5787: Executive, KernelMode, FALSE, NULL);
5788: if (Status != STATUS_SUCCESS)
5789: {
5792: break;//ERROR
5793: }
5794:

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: ifM60x64!VmpSCQThread+1b3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ifM60x64

IMAGE_NAME: ifM60x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 491f371f

FAILURE_BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

Followup: MachineOwner

-Tarun

2

It almost obvious that memory pointed to by: (((PVOID)((volatile void
*)&(((PQ_THREAD)Context)->Event))) is invalid. Look at that more carefully.
How do you initialize that and how do you use it later.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Saturday, November 15, 2008 11:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD with thread created using PsCreateSystemThread - need
help

Hi,

I am running into a problem of follwoing BSOD, when I tries to use thread
created using PsCreateSystemThread. It seems to work, but eventually gets a
BSOD, I am not able to get any clue what's wrong here. I see this is called
at very high IRQL d at the time of BSOD, for normal operation it is called
at LOW_LEVEL 0. I expetcs system to call my thread at passive level all the
time. I have no clue why it is happening.

Information about the threads:
I am creating one thread per core of the system processor by assiging the
affinity to a specific core. The thread is initialized using the
SynchronizationEvent. I can provide more information if needed to debug this
issue.

The BSOD is:
5: 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: ffffcb0015c72260, memory referenced
Arg2: 000000000000000d, 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: fffff8000166acc2, address which referenced memory

Debugging Details:

READ_ADDRESS: ffffcb0015c72260

CURRENT_IRQL: d

FAULTING_IP:
nt!KdPollBreakIn+d1
fffff800`0166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi*8]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffffa60028a4890 -- (.trap 0xfffffa60028a4890)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=fffffa80077f9018 rcx=ffffffffffd0d000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000100000000
rip=fffff8000166acc2 rsp=fffffa60028a4a20 rbp=fffff800018051e0
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=000000000000000c r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
nt!KdPollBreakIn+0xd1:
fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi\*8] ss:0018:fffff808018051e0=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80001713c72 to fffff8000165b860

STACK_TEXT:
fffffa60028a4038 fffff80001713c72 : fffffa8007c3ebb0 0000000000000065
ffffcb0015c72260 fffff80001626c38 : nt!RtlpBreakWithStatusInstruction
fffffa60028a4040 fffff80001714a2b : ffffcb0000000003 0000000000000000
fffff800016a1d90 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffffa60028a40a0 fffff80001661494 : 0000000000000000 fffffa60034b18e2
fffffa8008daa106 fffff8000024ffff : nt!KeBugCheck2+0x6eb
fffffa60028a4710 fffff8000166112e : 000000000000000a ffffcb0015c72260
000000000000000d 0000000000000000 : nt!KeBugCheckEx+0x104
fffffa60028a4750 fffff8000166000b : 0000000000000000 fffffa8007790048
0000000100000000 0000000000000001 : nt!KiBugCheckDispatch+0x6e
fffffa60028a4890 fffff8000166acc2 : 0000000000000001 fffff800018051e0
0000000000026100 0000000000000000 : nt!KiPageFault+0x20b
fffffa60028a4a20 fffff80001669e3a : fffffa60018af180 fffffa60028a4aa0
0000000000026160 fffffa8007c3ebb0 : nt!KdPollBreakIn+0xd1
fffffa60028a4a60 fffff8000165afef : 0000000000000000 fffffa60028a4b20
fffffa8007b42158 fffffa8007c3eca8 : nt!KeUpdateRunTime+0x14a
fffffa60028a4aa0 fffff800016681dd : 0000000000000000 0000000000000100
0000000000000005 fffffa8000000009 : nt!KiSecondaryClockInterrupt+0x11f
fffffa60028a4c30 fffffa600346f3b3 : fffffa8000000000 fffffa8000000000
fffffa80077f9700 fffffa8003989c00 : nt!KeWaitForSingleObject+0x12d
fffffa60028a4cc0 fffff80001884de3 : fffffa80077f9720 0000000000000000
0000000000000000 0000000000000001 : ifM60x64!VmpSCQThread+0x1b3
[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]
fffffa60028a4d50 fffff8000169b536 : fffffa600198d180 fffffa8007c3ebb0
fffffa6001996d40 0000000000000001 : nt!PspSystemThreadStartup+0x57
fffffa60028a4d80 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
ifM60x64!VmpSCQThread+1b3
[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]
fffffa60`0346f3b3 8944244c mov dword ptr [rsp+4Ch],eax

FAULTING_SOURCE_CODE:
5786: Status = KeWaitForSingleObject(((PVOID)((volatile void
*)&(((PQ_THREAD)Context)->Event))),
5787: Executive, KernelMode, FALSE, NULL);
5788: if (Status != STATUS_SUCCESS)
5789: {
5792: break;//ERROR
5793: }
5794:

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: ifM60x64!VmpSCQThread+1b3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ifM60x64

IMAGE_NAME: ifM60x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 491f371f

FAILURE_BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

Followup: MachineOwner

-Tarun

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at

3

Is I? The crash happened while handling a clock interrupt. Stuff below the ISR callout on the stack is usually mostly irrelevant in such casis.

I would enable driver verifier (especially special pool) and see what it catches. My guess is pool corruption somewhere causing a secondary failure.

  • S

-----Original Message-----
From: Bercea Gabriel
Sent: Saturday, November 15, 2008 17:24
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] BSOD with thread created using PsCreateSystemThread - need help

It almost obvious that memory pointed to by: (((PVOID)((volatile void
*)&(((PQ_THREAD)Context)->Event))) is invalid. Look at that more carefully.
How do you initialize that and how do you use it later.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Saturday, November 15, 2008 11:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD with thread created using PsCreateSystemThread - need
help

Hi,

I am running into a problem of follwoing BSOD, when I tries to use thread
created using PsCreateSystemThread. It seems to work, but eventually gets a
BSOD, I am not able to get any clue what’s wrong here. I see this is called
at very high IRQL d at the time of BSOD, for normal operation it is called
at LOW_LEVEL 0. I expetcs system to call my thread at passive level all the
time. I have no clue why it is happening.

Information about the threads:
I am creating one thread per core of the system processor by assiging the
affinity to a specific core. The thread is initialized using the
SynchronizationEvent. I can provide more information if needed to debug this
issue.

The BSOD is:
5: 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: ffffcb0015c72260, memory referenced
Arg2: 000000000000000d, 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: fffff8000166acc2, address which referenced memory

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

READ_ADDRESS: ffffcb0015c72260

CURRENT_IRQL: d

FAULTING_IP:
nt!KdPollBreakIn+d1
fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi*8]<br><br>DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br><br>BUGCHECK_STR: 0xA<br><br>PROCESS_NAME: System<br><br>TRAP_FRAME: fffffa60028a4890 -- (.trap 0xfffffa60028a4890)<br>NOTE: The trap frame does not contain all registers.<br>Some register values may be zeroed or incorrect.<br>rax=0000000000000001 rbx=fffffa80077f9018 rcx=ffffffffffd0d000<br>rdx=0000000000000000 rsi=0000000000000000 rdi=0000000100000000<br>rip=fffff8000166acc2 rsp=fffffa60028a4a20 rbp=fffff800018051e0<br> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000<br>r11=000000000000000c r12=0000000000000000 r13=0000000000000000<br>r14=0000000000000000 r15=0000000000000000<br>iopl=0 nv up di pl zr na po nc<br>nt!KdPollBreakIn+0xd1:<br>fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi8]
ss:0018:fffff808018051e0=????????????????<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff80001713c72 to fffff8000165b860<br><br>STACK_TEXT:<br>fffffa60028a4038 fffff80001713c72 : fffffa8007c3ebb0 0000000000000065<br>ffffcb0015c72260 fffff80001626c38 : nt!RtlpBreakWithStatusInstruction<br>fffffa60028a4040 fffff80001714a2b : ffffcb0000000003 0000000000000000<br>fffff800016a1d90 000000000000000a : nt!KiBugCheckDebugBreak+0x12<br>fffffa60028a40a0 fffff80001661494 : 0000000000000000 fffffa60034b18e2<br>fffffa8008daa106 fffff8000024ffff : nt!KeBugCheck2+0x6eb<br>fffffa60028a4710 fffff8000166112e : 000000000000000a ffffcb0015c72260<br>000000000000000d 0000000000000000 : nt!KeBugCheckEx+0x104<br>fffffa60028a4750 fffff8000166000b : 0000000000000000 fffffa8007790048<br>0000000100000000 0000000000000001 : nt!KiBugCheckDispatch+0x6e<br>fffffa60028a4890 fffff8000166acc2 : 0000000000000001 fffff800018051e0<br>0000000000026100 0000000000000000 : nt!KiPageFault+0x20b<br>fffffa60028a4a20 fffff80001669e3a : fffffa60018af180 fffffa60028a4aa0<br>0000000000026160 fffffa8007c3ebb0 : nt!KdPollBreakIn+0xd1<br>fffffa60028a4a60 fffff8000165afef : 0000000000000000 fffffa60028a4b20<br>fffffa8007b42158 fffffa8007c3eca8 : nt!KeUpdateRunTime+0x14a<br>fffffa60028a4aa0 fffff800016681dd : 0000000000000000 0000000000000100<br>0000000000000005 fffffa8000000009 : nt!KiSecondaryClockInterrupt+0x11f<br>fffffa60028a4c30 fffffa600346f3b3 : fffffa8000000000 fffffa8000000000<br>fffffa80077f9700 fffffa8003989c00 : nt!KeWaitForSingleObject+0x12d<br>fffffa60028a4cc0 fffff80001884de3 : fffffa80077f9720 0000000000000000<br>0000000000000000 0000000000000001 : ifM60x64!VmpSCQThread+0x1b3<br>[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]<br>fffffa60028a4d50 fffff8000169b536 : fffffa600198d180 fffffa8007c3ebb0<br>fffffa6001996d40 0000000000000001 : nt!PspSystemThreadStartup+0x57<br>fffffa60028a4d80 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>ifM60x64!VmpSCQThread+1b3<br>[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]<br>fffffa600346f3b3 8944244c mov dword ptr [rsp+4Ch],eax

FAULTING_SOURCE_CODE:
5786: Status = KeWaitForSingleObject(((PVOID)((volatile void
)&(((PQ_THREAD)Context)->Event))),
5787: Executive, KernelMode, FALSE, NULL);
5788: if (Status != STATUS_SUCCESS)
5789: {
5792: break;//ERROR
5793: }
5794:

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: ifM60x64!VmpSCQThread+1b3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ifM60x64

IMAGE_NAME: ifM60x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 491f371f

FAILURE_BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

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

-Tarun

—
NTDEV is sponsored by OSR

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

—
NTDEV is sponsored by OSR

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

4

Are you calling KeWaitForSingleObject at IRQL 2 ?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Sunday, November 16, 2008 2:30 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] BSOD with thread created using PsCreateSystemThread -
need help

Is I? The crash happened while handling a clock interrupt. Stuff below the
ISR callout on the stack is usually mostly irrelevant in such casis.

I would enable driver verifier (especially special pool) and see what it
catches. My guess is pool corruption somewhere causing a secondary failure.

  • S

-----Original Message-----
From: Bercea Gabriel
Sent: Saturday, November 15, 2008 17:24
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] BSOD with thread created using PsCreateSystemThread -
need help

It almost obvious that memory pointed to by: (((PVOID)((volatile void
*)&(((PQ_THREAD)Context)->Event))) is invalid. Look at that more carefully.
How do you initialize that and how do you use it later.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Saturday, November 15, 2008 11:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] BSOD with thread created using PsCreateSystemThread - need
help

Hi,

I am running into a problem of follwoing BSOD, when I tries to use thread
created using PsCreateSystemThread. It seems to work, but eventually gets a
BSOD, I am not able to get any clue what’s wrong here. I see this is called
at very high IRQL d at the time of BSOD, for normal operation it is called
at LOW_LEVEL 0. I expetcs system to call my thread at passive level all the
time. I have no clue why it is happening.

Information about the threads:
I am creating one thread per core of the system processor by assiging the
affinity to a specific core. The thread is initialized using the
SynchronizationEvent. I can provide more information if needed to debug this
issue.

The BSOD is:
5: 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: ffffcb0015c72260, memory referenced
Arg2: 000000000000000d, 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: fffff8000166acc2, address which referenced memory

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

READ_ADDRESS: ffffcb0015c72260

CURRENT_IRQL: d

FAULTING_IP:
nt!KdPollBreakIn+d1
fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi*8]<br><br>DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br><br>BUGCHECK_STR: 0xA<br><br>PROCESS_NAME: System<br><br>TRAP_FRAME: fffffa60028a4890 -- (.trap 0xfffffa60028a4890)<br>NOTE: The trap frame does not contain all registers.<br>Some register values may be zeroed or incorrect.<br>rax=0000000000000001 rbx=fffffa80077f9018 rcx=ffffffffffd0d000<br>rdx=0000000000000000 rsi=0000000000000000 rdi=0000000100000000<br>rip=fffff8000166acc2 rsp=fffffa60028a4a20 rbp=fffff800018051e0<br> r8=0000000000000000 r9=0000000000000000 r10=0000000000000000<br>r11=000000000000000c r12=0000000000000000 r13=0000000000000000<br>r14=0000000000000000 r15=0000000000000000<br>iopl=0 nv up di pl zr na po nc<br>nt!KdPollBreakIn+0xd1:<br>fffff8000166acc2 4c8b44fd00 mov r8,qword ptr [rbp+rdi8]
ss:0018:fffff808018051e0=????????????????<br>Resetting default scope<br><br>LAST_CONTROL_TRANSFER: from fffff80001713c72 to fffff8000165b860<br><br>STACK_TEXT:<br>fffffa60028a4038 fffff80001713c72 : fffffa8007c3ebb0 0000000000000065<br>ffffcb0015c72260 fffff80001626c38 : nt!RtlpBreakWithStatusInstruction<br>fffffa60028a4040 fffff80001714a2b : ffffcb0000000003 0000000000000000<br>fffff800016a1d90 000000000000000a : nt!KiBugCheckDebugBreak+0x12<br>fffffa60028a40a0 fffff80001661494 : 0000000000000000 fffffa60034b18e2<br>fffffa8008daa106 fffff8000024ffff : nt!KeBugCheck2+0x6eb<br>fffffa60028a4710 fffff8000166112e : 000000000000000a ffffcb0015c72260<br>000000000000000d 0000000000000000 : nt!KeBugCheckEx+0x104<br>fffffa60028a4750 fffff8000166000b : 0000000000000000 fffffa8007790048<br>0000000100000000 0000000000000001 : nt!KiBugCheckDispatch+0x6e<br>fffffa60028a4890 fffff8000166acc2 : 0000000000000001 fffff800018051e0<br>0000000000026100 0000000000000000 : nt!KiPageFault+0x20b<br>fffffa60028a4a20 fffff80001669e3a : fffffa60018af180 fffffa60028a4aa0<br>0000000000026160 fffffa8007c3ebb0 : nt!KdPollBreakIn+0xd1<br>fffffa60028a4a60 fffff8000165afef : 0000000000000000 fffffa60028a4b20<br>fffffa8007b42158 fffffa8007c3eca8 : nt!KeUpdateRunTime+0x14a<br>fffffa60028a4aa0 fffff800016681dd : 0000000000000000 0000000000000100<br>0000000000000005 fffffa8000000009 : nt!KiSecondaryClockInterrupt+0x11f<br>fffffa60028a4c30 fffffa600346f3b3 : fffffa8000000000 fffffa8000000000<br>fffffa80077f9700 fffffa8003989c00 : nt!KeWaitForSingleObject+0x12d<br>fffffa60028a4cc0 fffff80001884de3 : fffffa80077f9720 0000000000000000<br>0000000000000000 0000000000000001 : ifM60x64!VmpSCQThread+0x1b3<br>[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]<br>fffffa60028a4d50 fffff8000169b536 : fffffa600198d180 fffffa8007c3ebb0<br>fffffa6001996d40 0000000000000001 : nt!PspSystemThreadStartup+0x57<br>fffffa60028a4d80 0000000000000000 : 0000000000000000 0000000000000000<br>0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16<br><br>STACK_COMMAND: kb<br><br>FOLLOWUP_IP:<br>ifM60x64!VmpSCQThread+1b3<br>[c:\cvs-directory\fcoe\fcoe_windows_driver\vmp\mp_io.c @ 5791]<br>fffffa600346f3b3 8944244c mov dword ptr [rsp+4Ch],eax

FAULTING_SOURCE_CODE:
5786: Status = KeWaitForSingleObject(((PVOID)((volatile void
)&(((PQ_THREAD)Context)->Event))),
5787: Executive, KernelMode, FALSE, NULL);
5788: if (Status != STATUS_SUCCESS)
5789: {
5792: break;//ERROR
5793: }
5794:

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: ifM60x64!VmpSCQThread+1b3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ifM60x64

IMAGE_NAME: ifM60x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 491f371f

FAILURE_BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

BUCKET_ID: X64_0xA_ifM60x64!VmpSCQThread+1b3

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

-Tarun

—
NTDEV is sponsored by OSR

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

—
NTDEV is sponsored by OSR

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

—
NTDEV is sponsored by OSR

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,

  1. The memory is part of the driver device extention, which is resident all the time.
  2. KeWaitForSingleObject is called in the thread created using PsCreateSystemThread, which I believe is called at passive level, so it must be passive level. The thread goes to the sleep mode if there is nothing left in the queue used to process items until woke up by through the event.
  3. I’ll run the Device Verifier and post the result here again if it can help analyse it further.

-Tarun

6

Hi,

With the DV on, I am seeing the following error, too wiered to debug:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff80001684d25

Debugging Details:

BUGCHECK_STR: 0x7f_8

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

EXCEPTION_RECORD: fffffa6005bf66f8 -- (.exr 0xfffffa6005bf66f8)
ExceptionAddress: fffff800016c020a (nt!RtlVirtualUnwind+0x000000000000017a)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000150
Attempt to read from address 0000000000000150

TRAP_FRAME: fffffa6005bf56d0 -- (.trap 0xfffffa6005bf56d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000150 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800016c020a rsp=fffffa6005bf5860 rbp=000000000000031f
r8=0000000000000006 r9=fffff80001658000 r10=0000000000000000
r11=fffff80001857000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
nt!RtlVirtualUnwind+0x17a:
fffff800016c020a 488b02 mov rax,qword ptr [rdx] ds:0000000000000150=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8000175fc72 to fffff800016a7860

STACK_TEXT:
fffff8000373a618 fffff8000175fc72 : fffffa80058d8040 0000000000000065 0000000000000008 fffff80001672c38 : nt!RtlpBreakWithStatusInstruction
fffff8000373a620 fffff80001760a2b : 0000000000000003 0000000000000000 fffff800016edd90 000000000000007f : nt!KiBugCheckDebugBreak+0x12
fffff8000373a680 fffff800016ad494 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x6eb
fffff8000373acf0 fffff800016ad12e : 000000000000007f 0000000000000008 0000000080050031 00000000000006f8 : nt!KeBugCheckEx+0x104
fffff8000373ad30 fffff800016ab978 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiBugCheckDispatch+0x6e
fffff8000373ae70 fffff80001684d25 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiDoubleFaultAbort+0xb8
fffffa6005bf1c80 fffff800016ad1e9 : fffffa6005bf23b8 0000000000000003 fffffa6005bf2460 fffffa6005bf2830 : nt!KiDispatchException+0x35
fffffa6005bf2280 fffff800016abfe5 : 0000000000000000 0000000000000000 0000000000000000 0000000000000003 : nt!KiExceptionDispatch+0xa9
fffffa6005bf2460 fffff800016c020a : fffffa6005bf3488 fffffa6005bf2e60 fffff800017a37e0 fffff80001658000 : nt!KiPageFault+0x1e5
fffffa6005bf25f0 fffff800016c7bd8 : fffffa6000000001 0000000000000000 0000000000000000 0000000000000000 : nt!RtlVirtualUnwind+0x17a
fffffa6005bf2660 fffff80001684db3 : fffffa6005bf3488 fffffa6005bf2e60 0000000000000000 fffffa6005bf3530 : nt!RtlDispatchException+0x118
fffffa6005bf2d50 fffff800016ad1e9 : fffffa6005bf3488 0000000000000003 fffffa6005bf3530 fffffa6005bf3900 : nt!KiDispatchException+0xc3
fffffa6005bf3350 fffff800016abfe5 : 0000000000000000 0000000000000000 0000000000000000 0000000000000003 : nt!KiExceptionDispatch+0xa9
fffffa6005bf3530 fffff800016c020a : fffffa6005bf4558 fffffa6005bf3f30 fffff800017a37e0 fffff80001658000 : nt!KiPageFault+0x1e5
fffffa6005bf36c0 fffff800016c7bd8 : fffffa6000000001 0000000000000000 0000000000000000 0000000000000000 : nt!RtlVirtualUnwind+0x17a
fffffa6005bf3730 fffff80001684db3 : fffffa6005bf4558 fffffa6005bf3f30 0000000000000000 fffffa6005bf4600 : nt!RtlDispatchException+0x118
fffffa6005bf3e20 fffff800016ad1e9 : fffffa6005bf4558 0000000000000003 fffffa6005bf4600 fffffa6005bf49d0 : nt!KiDispatchException+0xc3
fffffa6005bf4420 fffff800016abfe5 : 0000000000000000 0000000000000000 0000000000000000 0000000000000003 : nt!KiExceptionDispatch+0xa9
fffffa6005bf4600 fffff800016c020a : fffffa6005bf5628 fffffa6005bf5000 fffff800017a37e0 fffff80001658000 : nt!KiPageFault+0x1e5
fffffa6005bf4790 fffff800016c7bd8 : fffffa6000000001 0000000000000000 0000000000000000 0000000000000000 : nt!RtlVirtualUnwind+0x17a
fffffa6005bf4800 fffff80001684db3 : fffffa6005bf5628 fffffa6005bf5000 0000000000000000 fffffa6005bf56d0 : nt!RtlDispatchException+0x118
fffffa6005bf4ef0 fffff800016ad1e9 : fffffa6005bf5628 0000000000000003 fffffa6005bf56d0 fffffa6005bf5aa0 : nt!KiDispatchException+0xc3
fffffa6005bf54f0 fffff800016abfe5 : 0000000000000000 0000000000000000 0000000000000000 0000000000000003 : nt!KiExceptionDispatch+0xa9
fffffa6005bf56d0 fffff800016c020a : fffffa6005bf66f8 fffffa6005bf60d0 fffff800017a37e0 fffff80001658000 : nt!KiPageFault+0x1e5
fffffa6005bf5860 fffff800016c7bd8 : fffffa6000000001 0000000000000000 0000000000000000 0000000000000000 : nt!RtlVirtualUnwind+0x17a
fffffa6005bf58d0 fffff80001684db3 : fffffa6005bf66f8 fffffa6005bf60d0 0000000000000000 fffffa6005bf67a0 : nt!RtlDispatchException+0x118
fffffa6005bf5fc0 fffff800016ad1e9 : fffffa6005bf66f8 0000000000000003 fffffa6005bf67a0 fffffa6005bf6b70 : nt!KiDispatchException+0xc3
fffffa6005bf65c0 fffff800016abfe5 : 0000000000000000 fffff800016a6eba fffff8000163f300 0000000000000003 : nt!KiExceptionDispatch+0xa9
fffffa6005bf67a0 fffff800016c020a : fffffa6005bf6a80 fffff80001aa2ab0 0000000000000000 000000000000004d : nt!KiPageFault+0x1e5
fffffa6005bf6930 fffff800016c7bd8 : fffffa6000000001 0000000000000000 0000000000000000 0000000000000000 : nt!RtlVirtualUnwind+0x17a
fffffa6005bf69a0 fffff80001684db3 : fffffa6005bf77c8 fffffa6005bf71a0 0000000000000000 fffffa6005bf7870 : nt!RtlDispatchException+0x118
fffffa6005bf7090 fffff800016ad1e9 : fffffa6005bf77c8 fffffa80058d8040 fffffa6005bf7870 fffffa8005644b18 : nt!KiDispatchException+0xc3
fffffa6005bf7690 fffff800016abdcd : fffffa8004221600 0000000000000008 fffffa80058d8040 fffff800016f3d73 : nt!KiExceptionDispatch+0xa9
fffffa6005bf7870 fffff800016ae66f : fffff80001ab624d fffffa600603ea10 0000000000000246 fffffa6005bf7a30 : nt!KiGeneralProtectionFault+0xcd
fffffa6005bf7a08 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiInterruptDispatch+0x31f

STACK_COMMAND: kb

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

FOLLOWUP_NAME: MachineOwner

DEBUG_FLR_IMAGE_TIMESTAMP: 479192b7

FOLLOWUP_IP:
nt!KiDoubleFaultAbort+b8
fffff800`016ab978 90 nop

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: nt!KiDoubleFaultAbort+b8

FAILURE_BUCKET_ID: X64_TRAP_FRAME_RECURSION

BUCKET_ID: X64_TRAP_FRAME_RECURSION

Followup: MachineOwner

-Tarun

7

Did you look at trap frame? You can change the current context to one in Trap Frame.

.trap 0xfffffa6005bf56d0 command will do that.

Dhiren.

— On Sun, 16/11/08, xxxxx@yahoo.com wrote:

> From: xxxxx@yahoo.com
> Subject: RE:[ntdev] BSOD with thread created using PsCreateSystemThread - need help
> To: “Windows System Software Devs Interest List”
> Date: Sunday, 16 November, 2008, 10:54 AM
> Hi,
>
> With the DV on, I am seeing the following error, too wiered
> to debug:
> 0: kd> !analyze -v
> ***
> *
>
> * Bugcheck Analysis
>
> *
>
>
>
> UNEXPECTED_KERNEL_MODE_TRAP (7f)
> This means a trap occurred in kernel mode, and it’s a
> trap of a kind
> that the kernel isn’t allowed to have/catch (bound
> trap) or that
> is always instant death (double fault). The first number
> in the
> bugcheck params is the number of the trap (8 = double
> fault, etc)
> Consult an Intel x86 family manual to learn more about what
> these
> traps are. Here is a portion of those codes:
> If kv shows a taskGate
> use .tss on the part before the colon, then kv.
> Else if kv shows a trapframe
> use .trap on that value
> Else
> .trap on the appropriate frame will show where the
> trap was taken
> (on x86, this will be the ebp that goes with the
> procedure KiTrap)
> Endif
> kb will then show the corrected stack.
> Arguments:
> Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
> Arg2: 0000000080050031
> Arg3: 00000000000006f8
> Arg4: fffff80001684d25
>
> Debugging Details:
> ------------------
>
>
> BUGCHECK_STR: 0x7f_8
>
> DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
>
> PROCESS_NAME: System
>
> CURRENT_IRQL: 2
>
> EXCEPTION_RECORD: fffffa6005bf66f8 – (.exr
> 0xfffffa6005bf66f8)
> ExceptionAddress: fffff800016c020a
> (nt!RtlVirtualUnwind+0x000000000000017a)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 0000000000000000
> Parameter[1]: 0000000000000150
> Attempt to read from address 0000000000000150
>
> TRAP_FRAME: fffffa6005bf56d0 – (.trap 0xfffffa6005bf56d0)
> NOTE: The trap frame does not contain all registers.
> Some register values may be zeroed or incorrect.
> rax=0000000000000001 rbx=0000000000000000
> rcx=0000000000000000
> rdx=0000000000000150 rsi=0000000000000000
> rdi=0000000000000000
> rip=fffff800016c020a rsp=fffffa6005bf5860
> rbp=000000000000031f
> r8=0000000000000006 r9=fffff80001658000
> r10=0000000000000000
> r11=fffff80001857000 r12=0000000000000000
> r13=0000000000000000
> r14=0000000000000000 r15=0000000000000000
> iopl=0 nv up di pl zr na po nc
> nt!RtlVirtualUnwind+0x17a:
> fffff800016c020a 488b02 mov rax,qword ptr<br>&gt; [rdx] ds:0000000000000150=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from fffff8000175fc72 to
> fffff800016a7860
>
> STACK_TEXT:
> fffff8000373a618 fffff8000175fc72 : fffffa80058d8040<br>&gt; 0000000000000065 0000000000000008 fffff80001672c38 :
> nt!RtlpBreakWithStatusInstruction
> fffff8000373a620 fffff80001760a2b : 0000000000000003<br>&gt; 0000000000000000 fffff800016edd90 000000000000007f :
> nt!KiBugCheckDebugBreak+0x12
> fffff8000373a680 fffff800016ad494 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!KeBugCheck2+0x6eb
> fffff8000373acf0 fffff800016ad12e : 000000000000007f<br>&gt; 0000000000000008 0000000080050031 00000000000006f8 :
> nt!KeBugCheckEx+0x104
> fffff8000373ad30 fffff800016ab978 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!KiBugCheckDispatch+0x6e
> fffff8000373ae70 fffff80001684d25 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!KiDoubleFaultAbort+0xb8
> fffffa6005bf1c80 fffff800016ad1e9 : fffffa6005bf23b8<br>&gt; 0000000000000003 fffffa6005bf2460 fffffa6005bf2830 :
> nt!KiDispatchException+0x35
> fffffa6005bf2280 fffff800016abfe5 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000003 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf2460 fffff800016c020a : fffffa6005bf3488<br>&gt; fffffa6005bf2e60 fffff800017a37e0 fffff80001658000 :
> nt!KiPageFault+0x1e5
> fffffa6005bf25f0 fffff800016c7bd8 : fffffa6000000001<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!RtlVirtualUnwind+0x17a
> fffffa6005bf2660 fffff80001684db3 : fffffa6005bf3488<br>&gt; fffffa6005bf2e60 0000000000000000 fffffa6005bf3530 :
> nt!RtlDispatchException+0x118
> fffffa6005bf2d50 fffff800016ad1e9 : fffffa6005bf3488<br>&gt; 0000000000000003 fffffa6005bf3530 fffffa6005bf3900 :
> nt!KiDispatchException+0xc3
> fffffa6005bf3350 fffff800016abfe5 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000003 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf3530 fffff800016c020a : fffffa6005bf4558<br>&gt; fffffa6005bf3f30 fffff800017a37e0 fffff80001658000 :
> nt!KiPageFault+0x1e5
> fffffa6005bf36c0 fffff800016c7bd8 : fffffa6000000001<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!RtlVirtualUnwind+0x17a
> fffffa6005bf3730 fffff80001684db3 : fffffa6005bf4558<br>&gt; fffffa6005bf3f30 0000000000000000 fffffa6005bf4600 :
> nt!RtlDispatchException+0x118
> fffffa6005bf3e20 fffff800016ad1e9 : fffffa6005bf4558<br>&gt; 0000000000000003 fffffa6005bf4600 fffffa6005bf49d0 :
> nt!KiDispatchException+0xc3
> fffffa6005bf4420 fffff800016abfe5 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000003 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf4600 fffff800016c020a : fffffa6005bf5628<br>&gt; fffffa6005bf5000 fffff800017a37e0 fffff80001658000 :
> nt!KiPageFault+0x1e5
> fffffa6005bf4790 fffff800016c7bd8 : fffffa6000000001<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!RtlVirtualUnwind+0x17a
> fffffa6005bf4800 fffff80001684db3 : fffffa6005bf5628<br>&gt; fffffa6005bf5000 0000000000000000 fffffa6005bf56d0 :
> nt!RtlDispatchException+0x118
> fffffa6005bf4ef0 fffff800016ad1e9 : fffffa6005bf5628<br>&gt; 0000000000000003 fffffa6005bf56d0 fffffa6005bf5aa0 :
> nt!KiDispatchException+0xc3
> fffffa6005bf54f0 fffff800016abfe5 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000003 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf56d0 fffff800016c020a : fffffa6005bf66f8<br>&gt; fffffa6005bf60d0 fffff800017a37e0 fffff80001658000 :
> nt!KiPageFault+0x1e5
> fffffa6005bf5860 fffff800016c7bd8 : fffffa6000000001<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!RtlVirtualUnwind+0x17a
> fffffa6005bf58d0 fffff80001684db3 : fffffa6005bf66f8<br>&gt; fffffa6005bf60d0 0000000000000000 fffffa6005bf67a0 :
> nt!RtlDispatchException+0x118
> fffffa6005bf5fc0 fffff800016ad1e9 : fffffa6005bf66f8<br>&gt; 0000000000000003 fffffa6005bf67a0 fffffa6005bf6b70 :
> nt!KiDispatchException+0xc3
> fffffa6005bf65c0 fffff800016abfe5 : 0000000000000000<br>&gt; fffff800016a6eba fffff8000163f300 0000000000000003 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf67a0 fffff800016c020a : fffffa6005bf6a80<br>&gt; fffff80001aa2ab0 0000000000000000 000000000000004d :
> nt!KiPageFault+0x1e5
> fffffa6005bf6930 fffff800016c7bd8 : fffffa6000000001<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!RtlVirtualUnwind+0x17a
> fffffa6005bf69a0 fffff80001684db3 : fffffa6005bf77c8<br>&gt; fffffa6005bf71a0 0000000000000000 fffffa6005bf7870 :
> nt!RtlDispatchException+0x118
> fffffa6005bf7090 fffff800016ad1e9 : fffffa6005bf77c8<br>&gt; fffffa80058d8040 fffffa6005bf7870 fffffa8005644b18 :
> nt!KiDispatchException+0xc3
> fffffa6005bf7690 fffff800016abdcd : fffffa8004221600<br>&gt; 0000000000000008 fffffa80058d8040 fffff800016f3d73 :
> nt!KiExceptionDispatch+0xa9
> fffffa6005bf7870 fffff800016ae66f : fffff80001ab624d<br>&gt; fffffa600603ea10 0000000000000246 fffffa6005bf7a30 :
> nt!KiGeneralProtectionFault+0xcd
> fffffa6005bf7a08 0000000000000000 : 0000000000000000<br>&gt; 0000000000000000 0000000000000000 0000000000000000 :
> nt!KiInterruptDispatch+0x31f
>
>
> STACK_COMMAND: kb
>
> MODULE_NAME: nt
>
> IMAGE_NAME: ntkrnlmp.exe
>
> FOLLOWUP_NAME: MachineOwner
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 479192b7
>
> FOLLOWUP_IP:
> nt!KiDoubleFaultAbort+b8
> fffff800`016ab978 90 nop
>
> SYMBOL_STACK_INDEX: 5
>
> SYMBOL_NAME: nt!KiDoubleFaultAbort+b8
>
> FAILURE_BUCKET_ID: X64_TRAP_FRAME_RECURSION
>
> BUCKET_ID: X64_TRAP_FRAME_RECURSION
>
> Followup: MachineOwner
> ---------
>
> -Tarun
>
> —
> NTDEV is sponsored by OSR
>
> 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

Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

8

> The crash happened while handling a clock interrupt.

Hardly…

I think IRQL is so high simply because the crash occurs while dispatcher spinlock is being held. When you call KeWaitxxx, the calling thread acquires dispatcher spinlock which, unlike “normal” spinlocks that are acquired and held at DPC level, is acquired and held at SYNCH_LEVEL, i.e. above DIRQL on MP machine. Apparently, the system acquires dispatcher spinlock and accesses KEVENT that is allocated from the paged memory and/or is not properly initialized. In other words, I believe the problem lies with KEVENT that the OP passes to the thread as context…

Anton Bassov

9

Exactly. . .
That’s why I asked if the KeWait… is invoked above APC_LEVEL, because if
the event is allocated from paged pool it might page fault. If not you must
call KeInitializeEvent before using the event object.
Review your code. . .

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Sunday, November 16, 2008 9:36 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD with thread created using PsCreateSystemThread -
need help

The crash happened while handling a clock interrupt.

Hardly…

I think IRQL is so high simply because the crash occurs while dispatcher
spinlock is being held. When you call KeWaitxxx, the calling thread
acquires dispatcher spinlock which, unlike “normal” spinlocks that are
acquired and held at DPC level, is acquired and held at SYNCH_LEVEL, i.e.
above DIRQL on MP machine. Apparently, the system acquires dispatcher
spinlock and accesses KEVENT that is allocated from the paged memory and/or
is not properly initialized. In other words, I believe the problem lies
with KEVENT that the OP passes to the thread as context…

Anton Bassov

NTDEV is sponsored by OSR

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

10

> That’s why I asked if the KeWait… is invoked above APC_LEVEL, because if the event is

allocated from paged pool it might page fault. If not you must call KeInitializeEvent before
using the event object.

Well, you should always call KeInitializeEvent before using the event object. Furthermore, you should not allocate it from the page pool if you are planning to use it, regardless of IRQL - even if you call KeWaitxx at low IRQL, the system will actually access KEVENT in dispatcher context, i.e. while holding dispatcher spinlock at SYNCH level. Therefore, you will crash if it is paged out at the time of the call , and I believe this is exactly what happens here…

Anton Bassov

11

Hi,

I added the call KeInitializeEvent before KeWaitforSingleObject, I see the same BSOD. Also the memory used to pass the Event is allocated as part of driver’s device extension which should not be paged out at all. If you want I can post the code here for more help on this. But the code is very similar to the one in OSR article (http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=65) except I added the processor’s core affinity to the threads I created.

-Tarun

12

Provide sample code please, where you initialize the thread parameter
(context) and part of the worker thread code.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Monday, November 17, 2008 12:17 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] BSOD with thread created using PsCreateSystemThread -
need help

Hi,

I added the call KeInitializeEvent before KeWaitforSingleObject, I see the
same BSOD. Also the memory used to pass the Event is allocated as part of
driver’s device extension which should not be paged out at all. If you want
I can post the code here for more help on this. But the code is very similar
to the one in OSR article
(http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=65) except I
added the processor’s core affinity to the threads I created.

-Tarun

NTDEV is sponsored by OSR

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

13

Hi,

Here is the code I designed for this:

typedef struct _Q_THREAD
{
KEVENT Event;
HANDLE Handle;
LIST_ENTRY Queue;
ULONG QCount;
KSPIN_LOCK QLock;
ULONG ActiveProc;
ULONG ThreadState;
#define THREAD_STATE_RUNNING (0x01)
#define THREAD_STATE_EXIT (0x02)
PVOID pContext;
}Q_THREAD, *PQ_THREAD;

//Device extention
typedef struct _PDEVICE_EXT
{
#define MAX_THREAD (8)
Q_THREAD QThread[MAX_THREAD];
}DEVICE_EXT, *PPDEVICE_EXT;

//findadapter is in context to the storport(virtual)
FindAdapter(PDEVICE_EXT pDeviceExtension)
{
PQ_THREAD pQThread = NULL;
OBJECT_ATTRIBUTES ObjectAttributes;

//Create per processor thread needed to distribute the send IO
for(Index = 0;
Index < min(MAX_THREAD, pDeviceExtension->ActiveProcessorCount);
Index++)
{
pQThread = (PQ_THREAD)(&pDeviceExtension->QThread[Index]);

//Save the pDevExt
pQThread->pContext = (PVOID)pDeviceExtension;
pQThread->ActiveProc = Index;
pQThread->ThreadState = THREAD_STATE_RUNNING;

ThreadAffinityMask = (DWORD_PTR)(1 << Index);

KeInitializeSpinLock(&pQThread->QLock);
InitializeListHead(&pQThread->Queue);
pQThread->QCount = 0;
KeInitializeEvent(&pQThread->Event, SynchronizationEvent, FALSE);
InitializeObjectAttributes(&ObjectAttributes, NULL,
OBJ_KERNEL_HANDLE, NULL, NULL);
NtStatus = PsCreateSystemThread(&pQThread->Handle, 0, &ObjectAttributes,
NULL, NULL, &MyQThread, (PVOID)(&pDevExt->QThread[Index]));

if (!NT_SUCCESS (NtStatus))
{
//ERROR
}
}
}

//thread which eventually executes and then assigned the core affinity
VOID
MyQThread(
PVOID Context
)
{
PDEVICE_EXT pDeviceExtension = \
((PQ_THREAD)Context)->pContext;
NTSTATUS Status = STATUS_SUCCESS;
ULONG NewCount = 0;
PLIST_ENTRY pSCQE = NULL;
ULONG Affinity;
PSRB_EXTENSION pSRBExt = NULL;

//Assign the processor affinity
Affinity = (1 << (((PQ_THREAD)Context)->ActiveProc));
KeSetSystemAffinityThreadEx(Affinity);

do
{
// Make sure there is no stuff to process
if(((PQ_THREAD)Context)->QCount == 0)
{
KeInitializeEvent(
((PVOID)(&(((PQ_THREAD)Context)->Event))),
SynchronizationEvent, FALSE);

// Wait to be signaled that a pending completion exists
Status = KeWaitForSingleObject(
((PVOID)(&(((PQ_THREAD)Context)->Event))),
Executive, KernelMode, FALSE, 0);
if (Status != STATUS_SUCCESS)
{
//ERROR
break;
}

// Make sure there is stuff to process
if (!(((PQ_THREAD)Context)->QCount))
{
continue;
}
}

do
{
pSRBExt = NULL;

// Pulling the next waiting request
pSCQE = ExInterlockedRemoveHeadList(
&(((PQ_THREAD)Context)->Queue),
&(((PQ_THREAD)Context)->QLock));

//Processing the request de-queued here –> pSRBExt = pSCQE;
StartIoContinue(pSRBExt);

//Also checked that the IRQL is not altered here

//Updating the pending count here which just processed
NewCount = InterlockedDecrement(
(volatile long *)&(((PQ_THREAD)Context)->QCount));

} while (TRUE);

}while (TRUE);
}

StartIo(
PDEVICE_EXT pDeviceExtension,
IN PSCSI_REQUEST_BLOCK pSrb
)
{
//Getting pSRBExt from pSrb here

pSRBExt->IoProcessorCoreNumber = Picking a core number here;

//Get the Send Thread Queue to use
pQThread =(PQ_THREAD)\
(&pDeviceExtension->QThread[pSRBExt->IoProcessorCoreNumber]);

// Updating the pending count here and insert entry here
NewCount = \
(ULONG)InterlockedIncrement((volatile long *)&pQThread->QCount);
pPrevEntry = ExInterlockedInsertTailList(&pQThread->Queue,
&pSRBExt->ListLink, &pQThread->QLock);
//Set event to wake all the time
KeSetEvent (&pQThread->Event, IO_NO_INCREMENT, FALSE);

return TRUE;
}

StartIoContinue()
{
//Called from thread
}

-Tarun

14

Why do you initialize the event from inside the thread if you already done it before creating it???

In any case, I am just curious how you have managed to compile it. Look:

typedef struct _PDEVICE_EXT
{ #define MAX_THREAD (8)
Q_THREAD QThread[MAX_THREAD];
}DEVICE_EXT, *PPDEVICE_EXT;

FindAdapter(PDEVICE_EXT pDeviceExtension)
{ PQ_THREAD pQThread = NULL; OBJECT_ATTRIBUTES
ObjectAttributes; //Create per processor thread needed to distribute the send IO

for(Index = 0; Index < min(MAX_THREAD, pDeviceExtension->ActiveProcessorCount); Index++)

ActiveProcessorCount does not seem to be a member of DEVICE_EXT structure, does it??? Therefore,objectively, you should be unable to compile it. Please provide us with the code as it is written, and show us ALL the code…

Anton Bassov

15

Hi,

Sorry this I just pasted here for references, the correct should be like you said. Also ActiveProcessorCount is part of the device extention.

typedef struct _DEVICE_EXT
{
#define MAX_THREAD (8)
Q_THREAD QThread[MAX_THREAD];
ULONG ActiveProcessorCount;
}DEVICE_EXT, *PDEVICE_EXT;

FindAdapter(PDEVICE_EXT pDeviceExtension)
{
PQ_THREAD pQThread = NULL;
OBJECT_ATTRIBUTES ObjectAttributes; //Create per processor thread needed to distribute the send
}

Here, Did you mean to say that I need to put memory allocation for ObjectAttributes also resident (may be in device extension above). Right now I just put it on the stack. I thought it’s all needed for a call to PsCreateSystemThread. It’s not very clear from the documentation.

I’ll try making it resident and seperate for all the threads and update the result here.

-Tarun

16

Do you understand that ActiveProcessorCount can change? Servers can bring
up or down processors without rebooting. Read the docs about getting the
processor present bitfield.

Initializing an event in a loop that waits on that event will not work.
Someone, somewhere has to set or clear the event from an external function
not part of the wait. You will find the signals will get lost or if the
initialize will not run atomically will cause a BSOD almost randomly.

wrote in message news:xxxxx@ntdev…
> Hi,
>
> Sorry this I just pasted here for references, the correct should be like
> you said. Also ActiveProcessorCount is part of the device extention.
>
> typedef struct _DEVICE_EXT
> {
> #define MAX_THREAD (8)
> Q_THREAD QThread[MAX_THREAD];
> ULONG ActiveProcessorCount;
> }DEVICE_EXT, *PDEVICE_EXT;
>
>
> FindAdapter(PDEVICE_EXT pDeviceExtension)
> {
> PQ_THREAD pQThread = NULL;
> OBJECT_ATTRIBUTES ObjectAttributes; //Create per processor thread
> needed to distribute the send
> }
>
> Here, Did you mean to say that I need to put memory allocation for
> ObjectAttributes also resident (may be in device extension above). Right
> now I just put it on the stack. I thought it’s all needed for a call to
> PsCreateSystemThread. It’s not very clear from the documentation.
>
> I’ll try making it resident and seperate for all the threads and update
> the result here.
>
> -Tarun
>

17

Hi,

I understand about a core being shutdown by the server and there must be a way to wake it up, but I am not running into this problem right now.

about your question on signalling, it’s done in StartIo() function above.

-Tarun

18

Yes but the event must be initialized before the thread is created, and then
not re-initialized ever again.
I am just guessing here that you are implementing some sort of virtual
scsiport thing. What IRQL is your startio routine running at? You cannot
mess with events at IRQL > DISPATCH_LEVEL.

On Mon, Nov 17, 2008 at 4:15 AM, wrote:

> Hi,
>
> I understand about a core being shutdown by the server and there must be a
> way to wake it up, but I am not running into this problem right now.
>
> about your question on signalling, it’s done in StartIo() function above.
>
> -Tarun
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–
Mark Roddy

19

Hi,

Here is the updated code I am trying, still see the problem:

typedef struct _Q_THREAD
{
KEVENT Event;
OBJECT_ATTRIBUTES ObjectAttributes;
HANDLE Handle;
LIST_ENTRY Queue;
ULONG QCount;
KSPIN_LOCK QLock;
ULONG ActiveProc;
ULONG ThreadState;
#define THREAD_STATE_RUNNING (0x01)
#define THREAD_STATE_EXIT (0x02)
PVOID pContext;//for device extension
}Q_THREAD, *PQ_THREAD;

//Device extention
typedef struct _DEVICE_EXT
{
//partial members here for references only
ULONG ActiveProcessorCount;
#define MAX_THREAD (8)
Q_THREAD QThread[MAX_THREAD];
}DEVICE_EXT, *PDEVICE_EXT;

//findadapter is in context to the storport(virtual)
FindAdapter(PDEVICE_EXT pDeviceExtension)
{
PQ_THREAD pQThread = NULL;

pDevExtension->ActiveProcessorCount =\
Calculating the number of cores here,
e.g. for dual quad core, it comes out 8.;

//Create per processor thread needed to distribute the send IO
for(Index = 0;
Index < min(MAX_THREAD, pDeviceExtension->ActiveProcessorCount);
Index++)
{
pQThread = (PQ_THREAD)(&pDeviceExtension->QThread[Index]);

//Save the pDevExt
pQThread->pContext = (PVOID)pDeviceExtension;
pQThread->ActiveProc = Index;
pQThread->ThreadState = THREAD_STATE_RUNNING;

ThreadAffinityMask = (DWORD_PTR)(1 << Index);

KeInitializeSpinLock(&pQThread->QLock);
InitializeListHead(&pQThread->Queue);
pQThread->QCount = 0;
KeInitializeEvent(&pQThread->Event, SynchronizationEvent, FALSE);
InitializeObjectAttributes(&pQThread->ObjectAttributes, NULL,
OBJ_KERNEL_HANDLE, NULL, NULL);
NtStatus = PsCreateSystemThread(&pQThread->Handle, 0, &pQThread->ObjectAttributes,
NULL, NULL, &MyQThread, (PVOID)(&pDevExt->QThread[Index]));

if (!NT_SUCCESS (NtStatus))
{
//ERROR
}
}
}

//thread which eventually executes and then assigned the core affinity
VOID
MyQThread(
PVOID Context
)
{
PDEVICE_EXT pDeviceExtension = \
((PQ_THREAD)Context)->pContext;
NTSTATUS Status = STATUS_SUCCESS;
ULONG NewCount = 0;
PLIST_ENTRY pSCQE = NULL;
ULONG Affinity;
PSRB_EXTENSION pSRBExt = NULL;

//Assign the processor affinity
Affinity = (1 << (((PQ_THREAD)Context)->ActiveProc));
KeSetSystemAffinityThreadEx(Affinity);

do
{
// Make sure there is no stuff to process
if(((PQ_THREAD)Context)->QCount == 0)
{
// Wait to be signaled that a pending completion exists
Status = KeWaitForSingleObject(
((PVOID)(&(((PQ_THREAD)Context)->Event))),
Executive, KernelMode, FALSE, 0);
if (Status != STATUS_SUCCESS)
{
//ERROR
break;
}

// Make sure there is stuff to process
if (!(((PQ_THREAD)Context)->QCount))
{
continue;
}
}

do
{
pSRBExt = NULL;

// Pulling the next waiting request
pSCQE = ExInterlockedRemoveHeadList(
&(((PQ_THREAD)Context)->Queue),
&(((PQ_THREAD)Context)->QLock));

//Processing the request de-queued here –> pSRBExt = pSCQE;
StartIoContinue(pSRBExt);

//Also checked that the IRQL is not altered here

//Updating the pending count here which just processed
NewCount = InterlockedDecrement(
(volatile long *)&(((PQ_THREAD)Context)->QCount));

} while (TRUE);

}while (TRUE);
}

//This one is always called at passive level, and used to wake up the a thread sleeping/waiting at a core
StartIo(
PDEVICE_EXT pDeviceExtension,
IN PSCSI_REQUEST_BLOCK pSrb
)
{
//Getting pSRBExt from pSrb here

pSRBExt->IoProcessorCoreNumber = Picking a core number here;

//Get the Send Thread Queue to use
pQThread =(PQ_THREAD)\
(&pDeviceExtension->QThread[pSRBExt->IoProcessorCoreNumber]);

// Updating the pending count here and insert entry here
NewCount = \
(ULONG)InterlockedIncrement((volatile long *)&pQThread->QCount);
pPrevEntry = ExInterlockedInsertTailList(&pQThread->Queue,
&pSRBExt->ListLink, &pQThread->QLock);
//Set event to wake all the time
KeSetEvent (&pQThread->Event, IO_NO_INCREMENT, FALSE);

return TRUE;
}

StartIoContinue()
{
//Called from thread
}

-Tarun

20

What kind of storage stack driver is this and how are you sure that your
‘StartIo’ routine is called at passive level?

On Mon, Nov 17, 2008 at 2:43 PM, wrote:

> Hi,
>
> Here is the updated code I am trying, still see the problem:
>
> typedef struct _Q_THREAD
> {
> KEVENT Event;
> OBJECT_ATTRIBUTES ObjectAttributes;
> HANDLE Handle;
> LIST_ENTRY Queue;
> ULONG QCount;
> KSPIN_LOCK QLock;
> ULONG ActiveProc;
> ULONG ThreadState;
> #define THREAD_STATE_RUNNING (0x01)
> #define THREAD_STATE_EXIT (0x02)
> PVOID pContext;//for device extension
> }Q_THREAD, *PQ_THREAD;
>
>
> //Device extention
> typedef struct _DEVICE_EXT
> {
> //partial members here for references only
> ULONG ActiveProcessorCount;
> #define MAX_THREAD (8)
> Q_THREAD QThread[MAX_THREAD];
> }DEVICE_EXT, *PDEVICE_EXT;
>
>
> //findadapter is in context to the storport(virtual)
> FindAdapter(PDEVICE_EXT pDeviceExtension)
> {
> PQ_THREAD pQThread = NULL;
>
> pDevExtension->ActiveProcessorCount =<br>> Calculating the number of cores here,
> e.g. for dual quad core, it comes out 8.;
>
> //Create per processor thread needed to distribute the send IO
> for(Index = 0;
> Index < min(MAX_THREAD, pDeviceExtension->ActiveProcessorCount);
> Index++)
> {
> pQThread = (PQ_THREAD)(&pDeviceExtension->QThread[Index]);
>
> //Save the pDevExt
> pQThread->pContext = (PVOID)pDeviceExtension;
> pQThread->ActiveProc = Index;
> pQThread->ThreadState = THREAD_STATE_RUNNING;
>
> ThreadAffinityMask = (DWORD_PTR)(1 << Index);
>
> KeInitializeSpinLock(&pQThread->QLock);
> InitializeListHead(&pQThread->Queue);
> pQThread->QCount = 0;
> KeInitializeEvent(&pQThread->Event, SynchronizationEvent, FALSE);
> InitializeObjectAttributes(&pQThread->ObjectAttributes, NULL,
> OBJ_KERNEL_HANDLE, NULL, NULL);
> NtStatus = PsCreateSystemThread(&pQThread->Handle, 0,
> &pQThread->ObjectAttributes,
> NULL, NULL, &MyQThread, (PVOID)(&pDevExt->QThread[Index]));
>
> if (!NT_SUCCESS (NtStatus))
> {
> //ERROR
> }
> }
> }
>
>
>
> //thread which eventually executes and then assigned the core affinity
> VOID
> MyQThread(
> PVOID Context
> )
> {
> PDEVICE_EXT pDeviceExtension = <br>> ((PQ_THREAD)Context)->pContext;
> NTSTATUS Status = STATUS_SUCCESS;
> ULONG NewCount = 0;
> PLIST_ENTRY pSCQE = NULL;
> ULONG Affinity;
> PSRB_EXTENSION pSRBExt = NULL;
>
> //Assign the processor affinity
> Affinity = (1 << (((PQ_THREAD)Context)->ActiveProc));
> KeSetSystemAffinityThreadEx(Affinity);
>
> do
> {
> // Make sure there is no stuff to process
> if(((PQ_THREAD)Context)->QCount == 0)
> {
> // Wait to be signaled that a pending completion exists
> Status = KeWaitForSingleObject(
> ((PVOID)(&(((PQ_THREAD)Context)->Event))),
> Executive, KernelMode, FALSE, 0);
> if (Status != STATUS_SUCCESS)
> {
> //ERROR
> break;
> }
>
> // Make sure there is stuff to process
> if (!(((PQ_THREAD)Context)->QCount))
> {
> continue;
> }
> }
>
> do
> {
> pSRBExt = NULL;
>
> // Pulling the next waiting request
> pSCQE = ExInterlockedRemoveHeadList(
> &(((PQ_THREAD)Context)->Queue),
> &(((PQ_THREAD)Context)->QLock));
>
> //Processing the request de-queued here –> pSRBExt = pSCQE;
> StartIoContinue(pSRBExt);
>
> //Also checked that the IRQL is not altered here
>
> //Updating the pending count here which just processed
> NewCount = InterlockedDecrement(
> (volatile long *)&(((PQ_THREAD)Context)->QCount));
>
> } while (TRUE);
>
> }while (TRUE);
> }
>
>
> //This one is always called at passive level, and used to wake up the a
> thread sleeping/waiting at a core
> StartIo(
> PDEVICE_EXT pDeviceExtension,
> IN PSCSI_REQUEST_BLOCK pSrb
> )
> {
> //Getting pSRBExt from pSrb here
>
> pSRBExt->IoProcessorCoreNumber = Picking a core number here;
>
> //Get the Send Thread Queue to use
> pQThread =(PQ_THREAD)<br>> (&pDeviceExtension->QThread[pSRBExt->IoProcessorCoreNumber]);
>
> // Updating the pending count here and insert entry here
> NewCount = <br>> (ULONG)InterlockedIncrement((volatile long *)&pQThread->QCount);
> pPrevEntry = ExInterlockedInsertTailList(&pQThread->Queue,
> &pSRBExt->ListLink, &pQThread->QLock);
> //Set event to wake all the time
> KeSetEvent (&pQThread->Event, IO_NO_INCREMENT, FALSE);
>
> return TRUE;
> }
>
>
> StartIoContinue()
> {
> //Called from thread
> }
>
> -Tarun
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>

–
Mark Roddy