Whats wrong with this piece of code?

NV_VOID
IoctlCallbackFunc (
PNV_VOID CallbackContext,
PNV_UINT32 RequestCancelInfo,
NV_UINT32 ResultLength
)
{
WDFREQUEST Request = (WDFREQUEST)CallbackContext;

Does anyone see anything wrong with the first line of the above function?

What does an entry: nt!Kei386EoiHelper
in the stack trace imply?

Thanks,
-Praveen

Who calls this callback? Is this from your own code? Is KMDF calling you back (doesn’t look like it, the signature doesn’t match anything in KMDF)? What does the callstack look like? The results of !analyze -v?

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar Amritaluru
Sent: Friday, August 18, 2006 12:15 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Whats wrong with this piece of code?

NV_VOID
IoctlCallbackFunc (
??? PNV_VOID??? CallbackContext,
??? PNV_UINT32? RequestCancelInfo,
??? NV_UINT32?? ResultLength
??? )
{
??? WDFREQUEST Request = (WDFREQUEST)CallbackContext;
?
Does anyone see anything wrong with the first line of the above function?
?
What does an entry:? nt!Kei386EoiHelper
?in the stack trace imply?
?
?
Thanks,
-Praveen


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

You should post the entire stack and the exception information.

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 12:15 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Whats wrong with this piece of code?

NV_VOID
IoctlCallbackFunc (
PNV_VOID CallbackContext,
PNV_UINT32 RequestCancelInfo,
NV_UINT32 ResultLength
)
{
WDFREQUEST Request = (WDFREQUEST)CallbackContext;

Does anyone see anything wrong with the first line of the above
function?

What does an entry: nt!Kei386EoiHelper

in the stack trace imply?

Thanks,

-Praveen


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

The issue seems to be bugcheck 0xD1. I was trying to access a WDFREQEUEST from timer callback
routine, hence at a higher IRQL level.

Following is the definition of bugcheck 0xD1 taken from windgb help section.
Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1. This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.

I am not sure whether KMDF docs in DDK talks about KMDF requests becoming pageable?

Question #1: How do I solve this problem? Do I need to lock this request using: MmProbeAndLockPages?

Question #2: Why do I see this issue only with KMDF and not WDM driver where I use IRP address as the callback context

to my callback function called in timer context?

Question #3: Is WDFREQUEST allocated from pageable pool while IRPs allocated from non-pageable pool?

Or did IoMarkIrpPending() do any magic?

Suggestions would be very much appreciated.

Thanks,

-Praveen

“Praveen Kumar Amritaluru” wrote in message news:xxxxx@ntdev…
NV_VOID
IoctlCallbackFunc (
PNV_VOID CallbackContext,
PNV_UINT32 RequestCancelInfo,
NV_UINT32 ResultLength
)
{
WDFREQUEST Request = (WDFREQUEST)CallbackContext;

Does anyone see anything wrong with the first line of the above function?

What does an entry: nt!Kei386EoiHelper
in the stack trace imply?

Thanks,
-Praveen

  1. this is a bug in your code. The WDFREQUEST is accessible at IRQL <= dispatch so it is ok to use it in a timer
  2. because this is your bug, I have no idea how
    a) you set this timer up in WDM
    b) you set this timer up in KMDF
  3. no, it is from NP pool. IoMarkIrpPending? You don’t do that in KMDF.

You either completed the WDFREQUEST in another context or passed in complete garbage. w/out a callstack, it’s hard to tell.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar Amritaluru
Sent: Friday, August 18, 2006 12:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

The issue seems? to be bugcheck 0xD1. I was trying to access a WDFREQEUEST from timer callback
?routine, hence at a higher IRQL level.?
?
Following is the definition of bugcheck 0xD1 taken from windgb help section.
Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1. This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
I am not sure whether KMDF docs in DDK talks about KMDF requests becoming pageable?
Question #1:??? How do I solve this problem? Do I need to lock this request using: MmProbeAndLockPages?
Question #2:??? Why do I see this issue only with KMDF and not WDM driver where I use IRP address as the callback context
? ??? ??? ??? ??? ??? to my callback function called in timer context?
?
Question #3:??? Is WDFREQUEST allocated from pageable pool while IRPs allocated from non-pageable pool?
??? ??? ??? ??? ??? ??? Or did IoMarkIrpPending() do any magic?
?
Suggestions would be very much appreciated.
Thanks,
-Praveen
?
?
?
“Praveen Kumar Amritaluru” wrote in message news:xxxxx@ntdev…
NV_VOID
IoctlCallbackFunc (
??? PNV_VOID??? CallbackContext,
??? PNV_UINT32? RequestCancelInfo,
??? NV_UINT32?? ResultLength
??? )
{
??? WDFREQUEST Request = (WDFREQUEST)CallbackContext;
?
Does anyone see anything wrong with the first line of the above function?
?
What does an entry:? nt!Kei386EoiHelper
?in the stack trace imply?
?
?
Thanks,
-Praveen


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Here is the information from crash:

kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

FAULTING_MODULE: 81800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1 [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3be0 to 8186e51c

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1 nt!DbgBreakPointWithStatus+0x4
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheckEx+0xc01
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c nt!Kei386EoiHelper+0x28e8
818f1aec 8a079583 818f1b50 818f1b6c 00000000 xyz!NRM_DiagParamCmplCallback+0x24 [c:\p4client\sw\main\net\drivers\common\resman\hmacdioc.c @ 3398]
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533 [c:\p4client\sw\main\net\drivers\common\resman\param_utils.c @ 3888]
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68 [c:\p4client\sw\main\net\drivers\common\resman\diag.c @ 723]
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e [c:\p4client\sw\main\net\drivers\common\resman\diag.c @ 5469]
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca xyz!NRM_OSDeferredRoutine+0x1b [c:\p4client\sw\main\net\drivers\windows\osm\osmwdmx.c @ 1924]
818f1ce8 81895dfc 00000000 00000000 0001615b nt!NtBuildGUID+0x4adc
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!NtBuildGUID+0x4488
818f8740 00000000 818f8748 818f8748 818f8750 nt!KiDispatchInterrupt+0x57e

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1 [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )

1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Variable dump just before the crash:
kd> t
Breakpoint 15 hit
nvnetbus!BusIoctlCallbackFunc:
89ed9dd0 cc int 3
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916272
Request = 0x00000008
kd> g

Variabel dump from the previous function.

kd> dt -r pCallback
Local var @ 0x818f1ae8 Type PARAM_02_CMPL_CALLBACK*
0x818f1b50
+0x000 CmplInfo : PARAM_CALLBACK_INFO
+0x000 pfnCallback : 0x8a0629a0 NVNRM!NRM_DiagParamCmplCallback+0
+0x004 Info1 : 0x89ed9dd0
+0x008 Info2 : 0x7c47cfe8 ----------->>>>> Corresponds to WDF request.
+0x00c Info3 : (null)
+0x010 Status : 0
+0x014 DataSize : 0x2c

Variable dump when this request was passed to EvtDeviceControl function:

kd> p
nvnetbus!HandleIoctlGetSet+0x61:
89ed9bd1 837d1464 cmp dword ptr [ebp+0x14],0x64
kd> dv
Device = 0x7706a590
Request = 0x7c47cfe8
OutputBuff = 0x9353c8b0
OutputBuffLength = 0x1400
pBuf = 0x9353c8b0 “”
pReqCtxt = 0x83b830c8
pIoctlCmd = 0x9353c8b0
pDxf = 0x88f95c30
Status = -1568081196
ResultLen = 0
pIoctlResult = 0x89ed9b75
RetStatus = 8
pIrp = 0x9edd2f20

So the address is not garbage. There is no change to the way the timer is being setup between old code and new code.

Yes, I am not using IoMarkIrpPending. I just asked whether it would do any magic.

I am not saying this is a bug in KMDF. I am seeing this bug with my new kmdf’ised driver.

And, I dont see completing this request within my code. I would do it from within this callback invoked by my code
from within my timer routine.

Regds,
-Praveen

“Doron Holan” wrote in message news:xxxxx@ntdev…
1) this is a bug in your code. The WDFREQUEST is accessible at IRQL <= dispatch so it is ok to use it in a timer
2) because this is your bug, I have no idea how
a) you set this timer up in WDM
b) you set this timer up in KMDF
3) no, it is from NP pool. IoMarkIrpPending? You don’t do that in KMDF.

You either completed the WDFREQUEST in another context or passed in complete garbage. w/out a callstack, it’s hard to tell.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar Amritaluru
Sent: Friday, August 18, 2006 12:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

The issue seems to be bugcheck 0xD1. I was trying to access a WDFREQEUEST from timer callback
routine, hence at a higher IRQL level.

Following is the definition of bugcheck 0xD1 taken from windgb help section.
Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1. This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
I am not sure whether KMDF docs in DDK talks about KMDF requests becoming pageable?
Question #1: How do I solve this problem? Do I need to lock this request using: MmProbeAndLockPages?
Question #2: Why do I see this issue only with KMDF and not WDM driver where I use IRP address as the callback context
to my callback function called in timer context?

Question #3: Is WDFREQUEST allocated from pageable pool while IRPs allocated from non-pageable pool?
Or did IoMarkIrpPending() do any magic?

Suggestions would be very much appreciated.
Thanks,
-Praveen

“Praveen Kumar Amritaluru” wrote in message news:xxxxx@ntdev…
NV_VOID
IoctlCallbackFunc (
PNV_VOID CallbackContext,
PNV_UINT32 RequestCancelInfo,
NV_UINT32 ResultLength
)
{
WDFREQUEST Request = (WDFREQUEST)CallbackContext;

Does anyone see anything wrong with the first line of the above function?

What does an entry: nt!Kei386EoiHelper
in the stack trace imply?

Thanks,
-Praveen


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

C’MON dude… Do you think that MAYBE the message

“***** Kernel symbols are WRONG. Please fix symbols to do analysis.”

and the big box with stars around it is a HINT to you to FIX THE SYMBOLS?

We want to help you, but you’ve GOT to give us useful data. Take the time necessary to fix the symbols, and repost the output of the analyze -v. THEN we can help.

Peter
OSR

Note that the address referenced and the address referencing it in the
bugcheck arguments is the same.

Usually this means that the page containing the function has been
invalidated - probably because it was paged memory.

Is your callback a paged function?

-p

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Here is the information from crash:

kd> !analyze -v
ERROR: FindPlugIns 8007007b
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

Debugging Details:

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

************************************************************************
*
***
***
***
***
*** Your debugger is not using the correct symbols
***
***
***
*** In order for this command to work properly, your symbol path
***
*** must point to .pdb files that have full type information.
***
***
***
*** Certain .pdb files (such as the public OS symbols) do not
***
*** contain the required information. Contact the group that
***
*** provided you with these symbols if you need this command to
***
*** work.
***
***
***
*** Type referenced: nt!_KPRCB
***
***
***
************************************************************************
*

FAULTING_MODULE: 81800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3be0 to 8186e51c

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!DbgBreakPointWithStatus+0x4
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheckEx+0xc01
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c nt!Kei386EoiHelper+0x28e8
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
[c:\p4client\sw\main\net\drivers\common\resman\hmacdioc.c @ 3398]
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
[c:\p4client\sw\main\net\drivers\common\resman\param_utils.c @ 3888]
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
[c:\p4client\sw\main\net\drivers\common\resman\diag.c @ 723]
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
[c:\p4client\sw\main\net\drivers\common\resman\diag.c @ 5469]
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
[c:\p4client\sw\main\net\drivers\windows\osm\osmwdmx.c @ 1924]
818f1ce8 81895dfc 00000000 00000000 0001615b nt!NtBuildGUID+0x4adc
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!NtBuildGUID+0x4488
818f8740 00000000 818f8748 818f8748 818f8750
nt!KiDispatchInterrupt+0x57e

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )

1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Variable dump just before the crash:

kd> t
Breakpoint 15 hit
nvnetbus!BusIoctlCallbackFunc:
89ed9dd0 cc int 3
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916272
Request = 0x00000008
kd> g

Variabel dump from the previous function.

kd> dt -r pCallback
Local var @ 0x818f1ae8 Type PARAM_02_CMPL_CALLBACK*
0x818f1b50
+0x000 CmplInfo : PARAM_CALLBACK_INFO
+0x000 pfnCallback : 0x8a0629a0
NVNRM!NRM_DiagParamCmplCallback+0
+0x004 Info1 : 0x89ed9dd0
+0x008 Info2 : 0x7c47cfe8
----------->>>>> Corresponds to WDF request.
+0x00c Info3 : (null)
+0x010 Status : 0
+0x014 DataSize : 0x2c

Variable dump when this request was passed to EvtDeviceControl
function:



kd> p
nvnetbus!HandleIoctlGetSet+0x61:
89ed9bd1 837d1464 cmp dword ptr [ebp+0x14],0x64
kd> dv
Device = 0x7706a590
Request = 0x7c47cfe8
OutputBuff = 0x9353c8b0
OutputBuffLength = 0x1400
pBuf = 0x9353c8b0 “”
pReqCtxt = 0x83b830c8
pIoctlCmd = 0x9353c8b0
pDxf = 0x88f95c30
Status = -1568081196
ResultLen = 0
pIoctlResult = 0x89ed9b75
RetStatus = 8
pIrp = 0x9edd2f20

So the address is not garbage. There is no change to the way the timer
is being setup between old code and new code.

Yes, I am not using IoMarkIrpPending. I just asked whether it would do
any magic.

I am not saying this is a bug in KMDF. I am seeing this bug with my new
kmdf’ised driver.

And, I dont see completing this request within my code. I would do it
from within this callback invoked by my code

from within my timer routine.

Regds,

-Praveen

“Doron Holan” mailto:xxxxx > wrote in message news:xxxxx@ntdev
news:xxxxx

1) this is a bug in your code. The WDFREQUEST is accessible at IRQL <=
dispatch so it is ok to use it in a timer
2) because this is your bug, I have no idea how
a) you set this timer up in WDM
b) you set this timer up in KMDF
3) no, it is from NP pool. IoMarkIrpPending? You don’t do that in
KMDF.

You either completed the WDFREQUEST in another context or passed in
complete garbage. w/out a callstack, it’s hard to tell.

d

From: xxxxx@lists.osr.com
mailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 12:51 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

The issue seems to be bugcheck 0xD1. I was trying to access a
WDFREQEUEST from timer callback
routine, hence at a higher IRQL level.

Following is the definition of bugcheck 0xD1 taken from windgb help
section.
Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL
The DRIVER_IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x000000D1.
This indicates that a kernel-mode driver attempted to access pageable
memory at a process IRQL that was too high.
I am not sure whether KMDF docs in DDK talks about KMDF requests
becoming pageable?
Question #1: How do I solve this problem? Do I need to lock this request
using: MmProbeAndLockPages?
Question #2: Why do I see this issue only with KMDF and not WDM driver
where I use IRP address as the callback context
to my callback function called in timer context?

Question #3: Is WDFREQUEST allocated from pageable pool while IRPs
allocated from non-pageable pool?
Or did IoMarkIrpPending() do any magic?

Suggestions would be very much appreciated.
Thanks,
-Praveen

“Praveen Kumar Amritaluru” mailto:xxxxx > wrote in message news:xxxxx@ntdev
news:xxxxx
NV_VOID
IoctlCallbackFunc (
PNV_VOID CallbackContext,
PNV_UINT32 RequestCancelInfo,
NV_UINT32 ResultLength
)
{
WDFREQUEST Request = (WDFREQUEST)CallbackContext;

Does anyone see anything wrong with the first line of the above
function?

What does an entry: nt!Kei386EoiHelper
in the stack trace imply?

Thanks,
-Praveen


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
http:

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1 nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )

1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

Followup: MachineOwner

kd> kn

ChildEBP RetAddr

00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> " ***** Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the time
> necessary to fix the symbols, and repost the output of the analyze -v.
> THEN we can help.
>
> Peter
> OSR
>
>

The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

Debugging Details:

*** ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )

1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

Followup: MachineOwner

kd> kn

ChildEBP RetAddr

00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> " ***** Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Hi Doran,

Is the complete code segment in WDM not non-pageable?
Is there any difference w.r.t in KMDF?

Why is this code that is part of my driver paged out? Is this expected?

Thanks,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************



Bugcheck Analysis



***************************************************************


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

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

ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )
> 1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

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

kd> kn
# ChildEBP RetAddr
00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Everything is not pagable until you mark it as such. Look for something
that looks like

#pragma alloc_text (PAGE, BusIoctlCallbackFunc)

In your source files (e.g. *.c, not the file named sources). KMDF does
nothing with respect to how your driver is linked or how your functions
are generated. We are a runtime in your driver, we do not control how
the driver is compiled.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 2:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Hi Doran,

Is the complete code segment in WDM not non-pageable?
Is there any difference w.r.t in KMDF?

Why is this code that is part of my driver paged out? Is this expected?

Thanks,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************



Bugcheck Analysis



***************************************************************


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

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

ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )
> 1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

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

kd> kn
# ChildEBP RetAddr
00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Yes. I have the following code in my source file.

#ifdef ALLOC_PRAGMA
#pragma alloc_text (INIT, DriverEntry)
#pragma alloc_text (PAGE, Bus_EvtDeviceAdd)
#pragma alloc_text (PAGE, PDEvtIoDeviceControl)
#pragma alloc_text (PAGE, BusEvtFileClose)
#pragma alloc_text (PAGE, HandleIoctlGetSet)
#pragma alloc_text (PAGE, HandleIoctlGetSet_SpecialHandling)
#pragma alloc_text (PAGE, BusIoctlCallbackFunc)
#pragma alloc_text (PAGE, HandleIoctlBusCmd)
#endif

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Everything is not pagable until you mark it as such. Look for something
that looks like

#pragma alloc_text (PAGE, BusIoctlCallbackFunc)

In your source files (e.g. *.c, not the file named sources). KMDF does
nothing with respect to how your driver is linked or how your functions
are generated. We are a runtime in your driver, we do not control how
the driver is compiled.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 2:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Hi Doran,

Is the complete code segment in WDM not non-pageable?
Is there any difference w.r.t in KMDF?

Why is this code that is part of my driver paged out? Is this expected?

Thanks,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************



Bugcheck Analysis



***************************************************************


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

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

ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )
> 1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

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

kd> kn
# ChildEBP RetAddr
00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Just curious - why did you add BusIoctlCallbacFunc to your list of paged
functions?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 3:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Yes. I have the following code in my source file.

#ifdef ALLOC_PRAGMA
#pragma alloc_text (INIT, DriverEntry)
#pragma alloc_text (PAGE, Bus_EvtDeviceAdd) #pragma alloc_text (PAGE,
PDEvtIoDeviceControl) #pragma alloc_text (PAGE, BusEvtFileClose) #pragma
alloc_text (PAGE, HandleIoctlGetSet) #pragma alloc_text (PAGE,
HandleIoctlGetSet_SpecialHandling)
#pragma alloc_text (PAGE, BusIoctlCallbackFunc) #pragma alloc_text
(PAGE, HandleIoctlBusCmd) #endif

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Everything is not pagable until you mark it as such. Look for something
that looks like

#pragma alloc_text (PAGE, BusIoctlCallbackFunc)

In your source files (e.g. *.c, not the file named sources). KMDF does
nothing with respect to how your driver is linked or how your functions
are generated. We are a runtime in your driver, we do not control how
the driver is compiled.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 2:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Hi Doran,

Is the complete code segment in WDM not non-pageable?
Is there any difference w.r.t in KMDF?

Why is this code that is part of my driver paged out? Is this expected?

Thanks,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************



Bugcheck Analysis



***************************************************************


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

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

ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )
> 1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

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

kd> kn
# ChildEBP RetAddr
00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b 0a 818f1ce8 81895dfc
nt!KiTimerExpiration+0x438 0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

So you cannot be calling paged code from your dpc timer routine - get rid of
the page directive for BusIoctlCallbackFunc.

Driver verifier and prefast would be helpful as well.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Praveen Kumar Amritaluru
Sent: Friday, August 18, 2006 6:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Yes. I have the following code in my source file.

#ifdef ALLOC_PRAGMA
#pragma alloc_text (INIT, DriverEntry)
#pragma alloc_text (PAGE, Bus_EvtDeviceAdd)
#pragma alloc_text (PAGE, PDEvtIoDeviceControl)
#pragma alloc_text (PAGE, BusEvtFileClose)
#pragma alloc_text (PAGE, HandleIoctlGetSet)
#pragma alloc_text (PAGE, HandleIoctlGetSet_SpecialHandling)
#pragma alloc_text (PAGE, BusIoctlCallbackFunc)
#pragma alloc_text (PAGE, HandleIoctlBusCmd)
#endif

Regds,
-Praveen

“Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Everything is not pagable until you mark it as such. Look
> for something
> that looks like
>
> #pragma alloc_text (PAGE, BusIoctlCallbackFunc)
>
> In your source files (e.g. *.c, not the file named sources).
> KMDF does
> nothing with respect to how your driver is linked or how your
> functions
> are generated. We are a runtime in your driver, we do not control how
> the driver is compiled.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
> Amritaluru
> Sent: Friday, August 18, 2006 2:40 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Whats wrong with this piece of code?
>
> Hi Doran,
>
> Is the complete code segment in WDM not non-pageable?
> Is there any difference w.r.t in KMDF?
>
> Why is this code that is part of my driver paged out? Is
> this expected?
>
> Thanks,
> -Praveen
>
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> The function itself is paged out, look at the offset of the faulting
> address
>
> nvnetbus!BusIoctlCallbackFunc+1
>
> there is no way you can even be running the code which
> assigns a passed
> in parameter to a local.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
> Amritaluru
> Sent: Friday, August 18, 2006 1:58 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Whats wrong with this piece of code?
>
> OK. Here is the output.
>
> Thanks,
> -Praveen
>
> kd> !analyze -v
> ERROR: FindPlugIns 8007007b
> **
>

>
>
>
> * Bugcheck Analysis
>
>
>
>

> *
>

>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
> 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 kernel debugger is available get stack backtrace.
> Arguments:
> Arg1: 89ed9dd1, memory referenced
> Arg2: 00000002, IRQL
> Arg3: 00000008, value 0 = read operation, 1 = write operation
> Arg4: 89ed9dd1, address which referenced memory
>
> Debugging Details:
> ------------------
>
> ERROR: Module load completed but symbols could not be loaded for
> mssmbios.sys
>
> WRITE_ADDRESS: 89ed9dd1
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nvnetbus!BusIoctlCallbackFunc+1
> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
> 89ed9dd1 ff558b call dword ptr [ebp-0x75]
>
> DEFAULT_BUCKET_ID: VISTA_BETA2
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c
>
> STACK_TEXT:
> 818f1644 818d3173 00000003 818fadd4 00000000
> nt!RtlpBreakWithStatusInstruction
> 818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
> nt!KiBugCheckDebugBreak+0x1c
> 818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
> 818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
> 818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
> nvnetbus!BusIoctlCallbackFunc+0x1
> 818f1aec 8a079583 818f1b50 818f1b6c 00000000
> xyz!NRM_DiagParamCmplCallback+0x24
> 818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
> 818f1b94 8a07fb4e 89598634 00000000 804c7350
> xyz!DiagCallParamCmpl+0x68
> 818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8
> xyz!DiagTestTimerFunc+0x67e
> 818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
> xyz!NRM_OSDeferredRoutine+0x1b
> 818f1ce8 81895dfc 00000000 00000000 0001615b
> nt!KiTimerExpiration+0x438
> 818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
> 818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_IP:
> nvnetbus!BusIoctlCallbackFunc+1
> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
> 89ed9dd1 ff558b call dword ptr [ebp-0x75]
>
> FAULTING_SOURCE_CODE:
> 1856: PNV_VOID CallbackContext,
> 1857: PNV_UINT32 RequestCancelInfo,
> 1858: NV_UINT32 ResultLength
> 1859: )
> > 1860: {
> 1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
> 1862: WDFREQUEST Request = CallbackContext;
> 1863: NTSTATUS Status;
> 1864: WdfRequestUnmarkCancelable (Request);
> 1865:
>
>
> SYMBOL_STACK_INDEX: 4
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1
>
> MODULE_NAME: nvnetbus
>
> IMAGE_NAME: nvnetbus.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d
>
> FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1
>
> BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1
>
> Followup: MachineOwner
> ---------
>
> kd> kn
> # ChildEBP RetAddr
> 00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
> 01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
> 02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
> 03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
> 04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
> 05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
> 06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
> 07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
> 08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
> 09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
> 0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
> 0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
> 0c 818f1d54 00000000 nt!KiIdleLoop+0x46
> kd> .frame 4
> 04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
> kd> dv
> CallbackContext = 0x7c47cfe8
> RequestCancelInfo = 0x00000000
> ResultLength = 0x2c
> Status = -1980916271
> Request = 0x00000008
>
>
>
>
> wrote in message news:xxxxx@ntdev…
> > C’MON dude… Do you think that MAYBE the message
> >
> > "
Kernel symbols are WRONG. Please fix symbols to do analysis."
> >
> > and the big box with stars around it is a HINT to you to FIX THE
> SYMBOLS?
> >
> > We want to help you, but you’ve GOT to give us useful data.
> Take the
> time
> > necessary to fix the symbols, and repost the output of the
> analyze -v.
>
> > THEN we can help.
> >
> > Peter
> > OSR
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>

Thanks to everyone…

Did delete the line and things are working fine. Used Driver verifier as
well to test it.

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> So you cannot be calling paged code from your dpc timer routine - get rid
> of
> the page directive for BusIoctlCallbackFunc.
>
> Driver verifier and prefast would be helpful as well.
>
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Praveen Kumar Amritaluru
>> Sent: Friday, August 18, 2006 6:38 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Whats wrong with this piece of code?
>>
>> Yes. I have the following code in my source file.
>>
>> #ifdef ALLOC_PRAGMA
>> #pragma alloc_text (INIT, DriverEntry)
>> #pragma alloc_text (PAGE, Bus_EvtDeviceAdd)
>> #pragma alloc_text (PAGE, PDEvtIoDeviceControl)
>> #pragma alloc_text (PAGE, BusEvtFileClose)
>> #pragma alloc_text (PAGE, HandleIoctlGetSet)
>> #pragma alloc_text (PAGE, HandleIoctlGetSet_SpecialHandling)
>> #pragma alloc_text (PAGE, BusIoctlCallbackFunc)
>> #pragma alloc_text (PAGE, HandleIoctlBusCmd)
>> #endif
>>
>>
>> Regds,
>> -Praveen
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> Everything is not pagable until you mark it as such. Look
>> for something
>> that looks like
>>
>> #pragma alloc_text (PAGE, BusIoctlCallbackFunc)
>>
>> In your source files (e.g. *.c, not the file named sources).
>> KMDF does
>> nothing with respect to how your driver is linked or how your
>> functions
>> are generated. We are a runtime in your driver, we do not control how
>> the driver is compiled.
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
>> Amritaluru
>> Sent: Friday, August 18, 2006 2:40 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Whats wrong with this piece of code?
>>
>> Hi Doran,
>>
>> Is the complete code segment in WDM not non-pageable?
>> Is there any difference w.r.t in KMDF?
>>
>> Why is this code that is part of my driver paged out? Is
>> this expected?
>>
>> Thanks,
>> -Praveen
>>
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> The function itself is paged out, look at the offset of the faulting
>> address
>>
>> nvnetbus!BusIoctlCallbackFunc+1
>>
>> there is no way you can even be running the code which
>> assigns a passed
>> in parameter to a local.
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
>> Amritaluru
>> Sent: Friday, August 18, 2006 1:58 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] Whats wrong with this piece of code?
>>
>> OK. Here is the output.
>>
>> Thanks,
>> -Praveen
>>
>> kd> !analyze -v
>> ERROR: FindPlugIns 8007007b
>> **
>>

>>
>>
>>
>> * Bugcheck Analysis
>>
>>
>>
>>

>> *
>>

>>
>> DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
>> 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 kernel debugger is available get stack backtrace.
>> Arguments:
>> Arg1: 89ed9dd1, memory referenced
>> Arg2: 00000002, IRQL
>> Arg3: 00000008, value 0 = read operation, 1 = write operation
>> Arg4: 89ed9dd1, address which referenced memory
>>
>> Debugging Details:
>> ------------------
>>
>> ERROR: Module load completed but symbols could not be loaded for
>> mssmbios.sys
>>
>> WRITE_ADDRESS: 89ed9dd1
>>
>> CURRENT_IRQL: 2
>>
>> FAULTING_IP:
>> nvnetbus!BusIoctlCallbackFunc+1
>> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
>> 89ed9dd1 ff558b call dword ptr [ebp-0x75]
>>
>> DEFAULT_BUCKET_ID: VISTA_BETA2
>>
>> BUGCHECK_STR: 0xD1
>>
>> LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c
>>
>> STACK_TEXT:
>> 818f1644 818d3173 00000003 818fadd4 00000000
>> nt!RtlpBreakWithStatusInstruction
>> 818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
>> nt!KiBugCheckDebugBreak+0x1c
>> 818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
>> 818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
>> 818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
>> nvnetbus!BusIoctlCallbackFunc+0x1
>> 818f1aec 8a079583 818f1b50 818f1b6c 00000000
>> xyz!NRM_DiagParamCmplCallback+0x24
>> 818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
>> 818f1b94 8a07fb4e 89598634 00000000 804c7350
>> xyz!DiagCallParamCmpl+0x68
>> 818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8
>> xyz!DiagTestTimerFunc+0x67e
>> 818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
>> xyz!NRM_OSDeferredRoutine+0x1b
>> 818f1ce8 81895dfc 00000000 00000000 0001615b
>> nt!KiTimerExpiration+0x438
>> 818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
>> 818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46
>>
>>
>> STACK_COMMAND: .bugcheck ; kb
>>
>> FOLLOWUP_IP:
>> nvnetbus!BusIoctlCallbackFunc+1
>> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
>> 89ed9dd1 ff558b call dword ptr [ebp-0x75]
>>
>> FAULTING_SOURCE_CODE:
>> 1856: PNV_VOID CallbackContext,
>> 1857: PNV_UINT32 RequestCancelInfo,
>> 1858: NV_UINT32 ResultLength
>> 1859: )
>> > 1860: {
>> 1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
>> 1862: WDFREQUEST Request = CallbackContext;
>> 1863: NTSTATUS Status;
>> 1864: WdfRequestUnmarkCancelable (Request);
>> 1865:
>>
>>
>> SYMBOL_STACK_INDEX: 4
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1
>>
>> MODULE_NAME: nvnetbus
>>
>> IMAGE_NAME: nvnetbus.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d
>>
>> FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1
>>
>> BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1
>>
>> Followup: MachineOwner
>> ---------
>>
>> kd> kn
>> # ChildEBP RetAddr
>> 00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
>> 01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
>> 02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
>> 03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
>> 04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
>> 05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
>> 06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
>> 07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
>> 08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
>> 09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b
>> 0a 818f1ce8 81895dfc nt!KiTimerExpiration+0x438
>> 0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
>> 0c 818f1d54 00000000 nt!KiIdleLoop+0x46
>> kd> .frame 4
>> 04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
>> [c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
>> kd> dv
>> CallbackContext = 0x7c47cfe8
>> RequestCancelInfo = 0x00000000
>> ResultLength = 0x2c
>> Status = -1980916271
>> Request = 0x00000008
>>
>>
>>
>>
>> wrote in message news:xxxxx@ntdev…
>> > C’MON dude… Do you think that MAYBE the message
>> >
>> > "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>> >
>> > and the big box with stars around it is a HINT to you to FIX THE
>> SYMBOLS?
>> >
>> > We want to help you, but you’ve GOT to give us useful data.
>> Take the
>> time
>> > necessary to fix the symbols, and repost the output of the
>> analyze -v.
>>
>> > THEN we can help.
>> >
>> > Peter
>> > OSR
>> >
>> >
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online
>> at http://www.osronline.com/page.cfm?name=ListServer
>>
>
>

To be honest, ignorance and oversight :frowning:
A typical cut&paste&rename function-name error.

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
Just curious - why did you add BusIoctlCallbacFunc to your list of paged
functions?

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 3:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Yes. I have the following code in my source file.

#ifdef ALLOC_PRAGMA
#pragma alloc_text (INIT, DriverEntry)
#pragma alloc_text (PAGE, Bus_EvtDeviceAdd) #pragma alloc_text (PAGE,
PDEvtIoDeviceControl) #pragma alloc_text (PAGE, BusEvtFileClose) #pragma
alloc_text (PAGE, HandleIoctlGetSet) #pragma alloc_text (PAGE,
HandleIoctlGetSet_SpecialHandling)
#pragma alloc_text (PAGE, BusIoctlCallbackFunc) #pragma alloc_text
(PAGE, HandleIoctlBusCmd) #endif

Regds,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Everything is not pagable until you mark it as such. Look for something
that looks like

#pragma alloc_text (PAGE, BusIoctlCallbackFunc)

In your source files (e.g. *.c, not the file named sources). KMDF does
nothing with respect to how your driver is linked or how your functions
are generated. We are a runtime in your driver, we do not control how
the driver is compiled.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 2:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

Hi Doran,

Is the complete code segment in WDM not non-pageable?
Is there any difference w.r.t in KMDF?

Why is this code that is part of my driver paged out? Is this expected?

Thanks,
-Praveen

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The function itself is paged out, look at the offset of the faulting
address

nvnetbus!BusIoctlCallbackFunc+1

there is no way you can even be running the code which assigns a passed
in parameter to a local.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Praveen Kumar
Amritaluru
Sent: Friday, August 18, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Whats wrong with this piece of code?

OK. Here is the output.

Thanks,
-Praveen

kd> !analyze -v
ERROR: FindPlugIns 8007007b
***********************************************************



Bugcheck Analysis



***************************************************************


DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 89ed9dd1, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000008, value 0 = read operation, 1 = write operation
Arg4: 89ed9dd1, address which referenced memory

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

ERROR: Module load completed but symbols could not be loaded for
mssmbios.sys

WRITE_ADDRESS: 89ed9dd1

CURRENT_IRQL: 2

FAULTING_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

DEFAULT_BUCKET_ID: VISTA_BETA2

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from 818d3173 to 8186e51c

STACK_TEXT:
818f1644 818d3173 00000003 818fadd4 00000000
nt!RtlpBreakWithStatusInstruction
818f1694 818d3be0 00000003 89ed9dd1 89ed9dd1
nt!KiBugCheckDebugBreak+0x1c
818f1a44 8187c620 0000000a 89ed9dd1 00000002 nt!KeBugCheck2+0x5f4
818f1a44 89ed9dd1 0000000a 89ed9dd1 00000002 nt!KiTrap0E+0x2ac
818f1ad4 8a0629c4 7c47cfe8 00000000 0000002c
nvnetbus!BusIoctlCallbackFunc+0x1
818f1aec 8a079583 818f1b50 818f1b6c 00000000
xyz!NRM_DiagParamCmplCallback+0x24
818f1b6c 8a07b078 818f1b7c 8b2e2948 8a079050 xyz!PARAM_Cmpl+0x533
818f1b94 8a07fb4e 89598634 00000000 804c7350 xyz!DiagCallParamCmpl+0x68
818f1c00 8a094f6b 89598634 8b2e2808 818f1ce8 xyz!DiagTestTimerFunc+0x67e
818f1c10 81896450 8b2e2830 8b2e2808 a9333aca
xyz!NRM_OSDeferredRoutine+0x1b
818f1ce8 81895dfc 00000000 00000000 0001615b nt!KiTimerExpiration+0x438
818f1d50 8187dd1e 00000000 0000000e 00000000 nt!KiRetireDpcList+0xca
818f1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nvnetbus!BusIoctlCallbackFunc+1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
89ed9dd1 ff558b call dword ptr [ebp-0x75]

FAULTING_SOURCE_CODE:
1856: PNV_VOID CallbackContext,
1857: PNV_UINT32 RequestCancelInfo,
1858: NV_UINT32 ResultLength
1859: )
> 1860: {
1861: // WDFREQUEST Request = (WDFREQUEST)CallbackContext;
1862: WDFREQUEST Request = CallbackContext;
1863: NTSTATUS Status;
1864: WdfRequestUnmarkCancelable (Request);
1865:

SYMBOL_STACK_INDEX: 4

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nvnetbus!BusIoctlCallbackFunc+1

MODULE_NAME: nvnetbus

IMAGE_NAME: nvnetbus.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 44e6133d

FAILURE_BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

BUCKET_ID: 0xD1_W_VRF_nvnetbus!BusIoctlCallbackFunc+1

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

kd> kn
# ChildEBP RetAddr
00 818f1644 818d3173 nt!RtlpBreakWithStatusInstruction
01 818f1694 818d3be0 nt!KiBugCheckDebugBreak+0x1c
02 818f1a44 8187c620 nt!KeBugCheck2+0x5f4
03 818f1a44 89ed9dd1 nt!KiTrap0E+0x2ac
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
05 818f1aec 8a079583 xyz!NRM_DiagParamCmplCallback+0x24
06 818f1b6c 8a07b078 xyz!PARAM_Cmpl+0x533
07 818f1b94 8a07fb4e xyz!DiagCallParamCmpl+0x68
08 818f1c00 8a094f6b xyz!DiagTestTimerFunc+0x67e
09 818f1c10 81896450 xyz!NRM_OSDeferredRoutine+0x1b 0a 818f1ce8 81895dfc
nt!KiTimerExpiration+0x438 0b 818f1d50 8187dd1e nt!KiRetireDpcList+0xca
0c 818f1d54 00000000 nt!KiIdleLoop+0x46
kd> .frame 4
04 818f1ad4 8a0629c4 nvnetbus!BusIoctlCallbackFunc+0x1
[c:\p4client\sw\main\net\drivers\windows\kmdf\busenum.c @ 1860]
kd> dv
CallbackContext = 0x7c47cfe8
RequestCancelInfo = 0x00000000
ResultLength = 0x2c
Status = -1980916271
Request = 0x00000008

wrote in message news:xxxxx@ntdev…
> C’MON dude… Do you think that MAYBE the message
>
> "
Kernel symbols are WRONG. Please fix symbols to do analysis."
>
> and the big box with stars around it is a HINT to you to FIX THE
SYMBOLS?
>
> We want to help you, but you’ve GOT to give us useful data. Take the
time
> necessary to fix the symbols, and repost the output of the analyze -v.

> THEN we can help.
>
> Peter
> OSR
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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