Can you set driver thread priority as MAX

NTDEV
1

KeSetPriorityThread(KeGetCurrentThread(), MAXIMUM_PRIORITY )
in a driver thread, it gives me this,

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.

other priorities are fine

2

Could you post the !analyze -v output, please?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, August 16, 2010 1:33 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Can you set driver thread priority as MAX

KeSetPriorityThread(KeGetCurrentThread(), MAXIMUM_PRIORITY ) in a driver
thread, it gives me this,

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.

other priorities are fine

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

3

Note, this is my test code, it’s not a WDK sample even though it’s in the same dir.
thanks !

1: 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: 0000000000000008, 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: fffff80002846241, address which referenced memory

Debugging Details:

READ_ADDRESS: 0000000000000008

CURRENT_IRQL: 2

FAULTING_IP:
nt!KiQuantumEnd+d9
fffff800`02846241 488b4808 mov rcx,qword ptr [rax+8]

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

TRAP_FRAME: fffff880025c6820 – (.trap 0xfffff880025c6820)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000020
rdx=fffff88004aa3b4e rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002846241 rsp=fffff880025c69b0 rbp=fffffa800184bb30
r8=000000000001f420 r9=0000000000000006 r10=000000000000003e
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz ac pe nc
nt!KiQuantumEnd+0xd9:
fffff800`02846241 488b4808 mov rcx,qword ptr [rax+8] ds:4900:0008=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002986732 to fffff800028877a0

STACK_TEXT:
fffff880025c5f68 fffff80002986732 : 0000000000000008 fffffa80041d4060 0000000000000065 fffff800028cdc24 : nt!RtlpBreakWithStatusInstruction
fffff880025c5f70 fffff8000298751e : 0000000000000003 0000000000000000 fffff800028ca7f0 000000000000000a : nt!KiBugCheckDebugBreak+0x12
fffff880025c5fd0 fffff8000288f844 : ffffffff00000003 0000000001010100 000000000c000000 fffff8000290e3d2 : nt!KeBugCheck2+0x71e
fffff880025c66a0 fffff8000288eca9 : 000000000000000a 0000000000000008 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
fffff880025c66e0 fffff8000288d920 : 0000000000000000 fffffa80041d4060 0000000200000001 0000000000000009 : nt!KiBugCheckDispatch+0x69
fffff880025c6820 fffff80002846241 : fffffa8002a931a0 fffff880025c6ab0 fffff880009f1ec0 0000000000000000 : nt!KiPageFault+0x260
fffff880025c69b0 fffff80002895692 : fffff8800000003e fffff880009ed180 fffff880025c6ab0 fffff880009ed180 : nt!KiQuantumEnd+0xd9
fffff880025c69f0 fffff800028d9113 : fffff8000289c3ac fffff8000289c418 fffffa80041d4060 fffff880025c6ab0 : nt!KiDispatchInterruptContinue+0x16
fffff880025c6a20 fffff8000289c418 : fffffa80041d4060 fffff880025c6ab0 fffffa800184bb30 0000000000000001 : nt!KiDpcInterruptBypass+0x13
fffff880025c6a30 fffff88004aa3b4e : 000000000022aebe fffffa80041d4060 0000000000000000 fffffa8000000000 : nt!KiSecondaryClockInterrupt+0x1a8
fffff880025c6bc0 fffff80002b33c06 : fffff880150d4760 0000000000000000 0000000000000000 0000000000000000 : ksrtm64!CsampPollingThread+0x20e [c:\winddk\7600.16385.1\src\general\ksrtm\sys\ksrtm64.c @ 480]
fffff880025c6d40 fffff8000286dc26 : fffff880009ed180 fffffa80041d4060 fffffa8003efa8a0 0000000000000246 : nt!PspSystemThreadStartup+0x5a
fffff880025c6d80 0000000000000000 : fffff880025c7000 fffff880025c1000 fffff880025c6d40 0000000000000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
ksrtm64!CsampPollingThread+20e [c:\winddk\7600.16385.1\src\general\ksrtm\sys\ksrtm64.c @ 480]
fffff880`04aa3b4e 4885d2 test rdx,rdx

FAULTING_SOURCE_CODE:
476: for(i=2; i 477: {
478: for(j=2; j 479: {
> 480: if(i%j == 0) cnt++;
481: }
482: }
483: }
484:
485: endPerfCnt = KeQueryPerformanceCounter(NULL);

SYMBOL_STACK_INDEX: a

SYMBOL_NAME: ksrtm64!CsampPollingThread+20e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ksrtm64

IMAGE_NAME: ksrtm64.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c6961b7

FAILURE_BUCKET_ID: X64_0xA_ksrtm64!CsampPollingThread+20e

BUCKET_ID: X64_0xA_ksrtm64!CsampPollingThread+20e

Followup: MachineOwner

4

OP… Does this make any sense to you:

ksrtm64!CsampPollingThread+20e
[c:\winddk\7600.16385.1\src\general\ksrtm\sys\ksrtm64.c @ 480]
fffff880`04aa3b4e 4885d2 test rdx,rdx



Peter
OSR

5

Hi Peter,

can you treat me like a dummy and put more details pls ?
i’m justing changing priorities in the KeSetPriorityThread().
If “test rdx, rdx” is the problem, why other priorities works ?

thx !

6

#define HIGH_PRIORITY 31 // Highest thread priority level
*#define MAXIMUM_PRIORITY 32 // Number of thread priority levels*

**
To answer your first question, no 32 is a bad number.

Mark Roddy

On Mon, Aug 16, 2010 at 1:50 PM, wrote:

> Note, this is my test code, it’s not a WDK sample even though it’s in the
> same dir.
> thanks !
>
>
> 1: 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: 0000000000000008, 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: fffff80002846241, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 0000000000000008
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!KiQuantumEnd+d9
> fffff80002846241 488b4808 mov rcx,qword ptr [rax+8]<br>&gt;<br>&gt; DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT<br>&gt;<br>&gt; BUGCHECK_STR: 0xA<br>&gt;<br>&gt; PROCESS_NAME: System<br>&gt;<br>&gt; TRAP_FRAME: fffff880025c6820 -- (.trap 0xfffff880025c6820)<br>&gt; NOTE: The trap frame does not contain all registers.<br>&gt; Some register values may be zeroed or incorrect.<br>&gt; rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000020<br>&gt; rdx=fffff88004aa3b4e rsi=0000000000000000 rdi=0000000000000000<br>&gt; rip=fffff80002846241 rsp=fffff880025c69b0 rbp=fffffa800184bb30<br>&gt; r8=000000000001f420 r9=0000000000000006 r10=000000000000003e<br>&gt; r11=0000000000000000 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000000000 r15=0000000000000000<br>&gt; iopl=0 nv up ei pl nz ac pe nc<br>&gt; nt!KiQuantumEnd+0xd9:<br>&gt; fffff80002846241 488b4808 mov rcx,qword ptr [rax+8]
> ds:4900:0008=???
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from fffff80002986732 to fffff800028877a0
>
> STACK_TEXT:
> fffff880025c5f68 fffff80002986732 : 0000000000000008 fffffa80041d4060
> 0000000000000065 fffff800028cdc24 : nt!RtlpBreakWithStatusInstruction
> fffff880025c5f70 fffff8000298751e : 0000000000000003 0000000000000000
> fffff800028ca7f0 000000000000000a : nt!KiBugCheckDebugBreak+0x12
> fffff880025c5fd0 fffff8000288f844 : ffffffff00000003 0000000001010100
> 000000000c000000 fffff8000290e3d2 : nt!KeBugCheck2+0x71e
> fffff880025c66a0 fffff8000288eca9 : 000000000000000a 0000000000000008
> 0000000000000002 0000000000000000 : nt!KeBugCheckEx+0x104
> fffff880025c66e0 fffff8000288d920 : 0000000000000000 fffffa80041d4060
> 0000000200000001 0000000000000009 : nt!KiBugCheckDispatch+0x69
> fffff880025c6820 fffff80002846241 : fffffa8002a931a0 fffff880025c6ab0
> fffff880009f1ec0 0000000000000000 : nt!KiPageFault+0x260
> fffff880025c69b0 fffff80002895692 : fffff8800000003e fffff880009ed180
> fffff880025c6ab0 fffff880009ed180 : nt!KiQuantumEnd+0xd9
> fffff880025c69f0 fffff800028d9113 : fffff8000289c3ac fffff8000289c418
> fffffa80041d4060 fffff880025c6ab0 : nt!KiDispatchInterruptContinue+0x16
> fffff880025c6a20 fffff8000289c418 : fffffa80041d4060 fffff880025c6ab0
> fffffa800184bb30 0000000000000001 : nt!KiDpcInterruptBypass+0x13
> fffff880025c6a30 fffff88004aa3b4e : 000000000022aebe fffffa80041d4060
> 0000000000000000 fffffa8000000000 : nt!KiSecondaryClockInterrupt+0x1a8
> fffff880025c6bc0 fffff80002b33c06 : fffff880150d4760 0000000000000000
> 0000000000000000 0000000000000000 : ksrtm64!CsampPollingThread+0x20e
> [c:\winddk\7600.16385.1\src\general\ksrtm\sys\ksrtm64.c @ 480]
> fffff880025c6d40 fffff8000286dc26 : fffff880009ed180 fffffa80041d4060
> fffffa8003efa8a0 0000000000000246 : nt!PspSystemThreadStartup+0x5a
> fffff880025c6d80 0000000000000000 : fffff880025c7000 fffff880025c1000
> fffff880025c6d40 0000000000000000 : nt!KxStartSystemThread+0x16
>
>
> STACK_COMMAND: kb
>
> FOLLOWUP_IP:
> ksrtm64!CsampPollingThread+20e
> [c:\winddk\7600.16385.1\src\general\ksrtm\sys\ksrtm64.c @ 480]
> fffff880`04aa3b4e 4885d2 test rdx,rdx
>
> FAULTING_SOURCE_CODE:
> 476: for(i=2; i> 477: {
> 478: for(j=2; j> 479: {
> > 480: if(i%j == 0) cnt++;
> 481: }
> 482: }
> 483: }
> 484:
> 485: endPerfCnt = KeQueryPerformanceCounter(NULL);
>
>
> SYMBOL_STACK_INDEX: a
>
> SYMBOL_NAME: ksrtm64!CsampPollingThread+20e
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: ksrtm64
>
> IMAGE_NAME: ksrtm64.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 4c6961b7
>
> FAILURE_BUCKET_ID: X64_0xA_ksrtm64!CsampPollingThread+20e
>
> BUCKET_ID: X64_0xA_ksrtm64!CsampPollingThread+20e
>
> Followup: MachineOwner
>
>
> —
> 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
>

7

Hi Mark,
it make sense now, i didn’t read the comment in the wdm.h
thanks !