driver verifier test help

NTDEV
1

Does anyone can tell me the cause of the following error?

I call the KeAcquireSpinLock in dispatch read routine.

But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0, f975b9b4}
—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL。

Does this mean I can’t call KeAcquireSpinLock in Dispatch read routine, if my driver want to pass WHQL?

Thanks

2

Is there any chance you acquire a spin lock in the read dispatch routine and
on an error condition fail to release it? I know driver verifier will
complain if the IRQL between when a driver is called and when it returns is
different.

Driver verifier also periodically forces pagable memory to be marked not
present, which can cause this error if you mistakenly touch pagable code or
data after acquiring a spin lock (which raises the IRQL to DISPATCH_LEVEL).
This is a feature of driver verifier. The bug is still there without driver
verifier, it’s just you are lucky and the pagable memory happens to be
present most of the time. I’d suggest looking at the target address of the
fault, and see if it’s perhaps paged code or paged data.

Jan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.
com
Sent: Tuesday, August 21, 2007 11:44 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] driver verifier test help

Does anyone can tell me the cause of the following error?

I call the KeAcquireSpinLock in dispatch read routine.

But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0,
f975b9b4}
—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL$B!#(B

Does this mean I can’t call KeAcquireSpinLock in Dispatch read routine, if
my driver want to pass WHQL?

Thanks

3

> I call the KeAcquireSpinLock in dispatch read routine.

But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0, f975b9b4}
—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL???

Apparently, you access pageable memory in operation that is protected by the spinlock. Once the code protected by a spinlock runs at elevated IRQL, you cannot touch pageable memory. As long as this does not *actually* cause a page fault, you are not going to crash, so that a bug like that is not necessarily going to reveal itself right on the spot. DriverVerifier, apparently, just makes sure that all pageable addresses that your driver accesses are *actually* paged. In other words, DriverVerifier just helped you to detect a bug in your code…

Anton Bassov

4

Your read dispatch routine itself is marked as pageable. You can tell because the first and fourth parameters are the same.

d

Sent using my smartphone, apologies forany typos

-----Original Message-----
From: “xxxxx@gmail.com”
To: “Windows System Software Devs Interest List”
Sent: 08/21/07 11:44 PM
Subject: [ntdev] driver verifier test help

Does anyone can tell me the cause of the following error?

I call the KeAcquireSpinLock in dispatch read routine.

But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0, f975b9b4}
—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL。

Does this mean I can’t call KeAcquireSpinLock in Dispatch read routine, if my driver want to pass WHQL?

Thanks

—
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

You can, but you cannot touch anything pageable from under a spinlock.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
Does anyone can tell me the cause of the following error?

I call the KeAcquireSpinLock in dispatch read routine.

But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0,
f975b9b4}
—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL。

Does this mean I can’t call KeAcquireSpinLock in Dispatch read routine, if my
driver want to pass WHQL?

Thanks

6

Since the address which referenced the memory (4th parameter) and the address referenced (1st parameter) are the same.

-Saravana

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of chiranjeevi marella
Sent: Thursday, August 23, 2007 12:13 PM
To: Windows System Software Devs Interest List
Subject: Re: RE: [ntdev] driver verifier test help

Hi Doron,

How can we tell that Read Dispatch routine is marked as pageable when
first and fourth parameters are same.

Thanks & Regards,
Chiranjeevi.

On Wed, 22 Aug 2007 Doron Holan wrote :

Your read dispatch routine itself is marked as pageable. You can tell because the first and fourth parameters are the same.

d

Sent using my smartphone, apologies forany typos

-----Original Message-----
From: “xxxxx@gmail.com”
>To: “Windows System Software Devs Interest List”
>Sent: 08/21/07 11:44 PM
>Subject: [ntdev] driver verifier test help
>
>Does anyone can tell me the cause of the following error?
>
>I call the KeAcquireSpinLock in dispatch read routine.
>
>But when Driver Verifier is runing , the BugCheck D1, {f975b9b4, 2, 0, f975b9b4}
>—means :DRIVER_IRQL_NOT_LESS_OR_EQUAL。
>
>Does this mean I can’t call KeAcquireSpinLock in Dispatch read routine, if my driver want to pass WHQL?
>
>Thanks
>
>—
>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

Chiranjeev.M
M.Tech

http: sig js

— 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</http:>

7

ok, Thanks veryone!

8

chiranjeevi marella wrote:

How can we tell that Read Dispatch routine is marked as pageable when
first and fourth parameters are same.

The first parameter tells what address triggered the fault. The fourth
parameter tells what instruction was being executed at the time of the
fault. When the two are equal, that means the fault happened when the
CPU tried to fetch the instruction. The only way that can happen is if
the page containing the instruction was paged out. The only way THAT
can happen is if the routine was marked pageable.

Driver verifier triggers this by forcing all of your paged code and data
to page out whenever it gets the opportunity, such as when you call
KeAcquireSpinLock. By the time it returns to you, your code is paged
out, so when the very last return statement tries to go back to your
code, you get a page fault.

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

9

The first parameter is the Virtual Address (not physical) at which the
fault occurred. The address which you are seeing is most probably the
address of your dispatch routine.

Also, driver verifier does not page out pageable memory. It merely bugchecks
the machine if you access any memory which is pageable at DISPATCH LEVEL or
higher (even if the page is resident in physical memory).

-Saravana

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of chiranjeevi marella
Sent: Friday, August 24, 2007 6:22 PM
To: Windows System Software Devs Interest List
Subject: Re: Re: [ntdev] driver verifier test help

Thanks Tim,

What i understood from the DDK help is that, the fourth parameter is the
virtual address of the instruction(in the text/code section of our
driver)that is executed by the processor, and the first parameter is the
physical address of the same instruction if present in main memory.
Now my doubt is that, if we have acquired the spin lock after some set of
instructions in the read dispatch routine(suppose marked as pageable), the
very next instruction should cause this bug check only if driver verifier is
enabled, since it pages out all pageable memory.(And if driver verifier is
not enabled in this case,can we get away accessing the pageable memory till
we release the spinlock, since the page containing our text/code section is
currently in main memory).

There can be a possibility that, routine is in non-paged memory and after
acquiring the spin lock, we accessed the paged memory. In this situation if
driver verifier is enabled, it pages out the memory that we will try to
reference, causing the same bug check. Here the routine is not pageable.
What will be the first and fourth parameters in this case.

Please correct me if any of my assumptions are wrong.

Thanks,
Chiranjeevi.

On Thu, 23 Aug 2007 Tim Roberts wrote :

chiranjeevi marella wrote:
>
>
> How can we tell that Read Dispatch routine is marked as pageable when
> first and fourth parameters are same.
>

The first parameter tells what address triggered the fault. The fourth
parameter tells what instruction was being executed at the time of the
fault. When the two are equal, that means the fault happened when the
CPU tried to fetch the instruction. The only way that can happen is if
the page containing the instruction was paged out. The only way THAT
can happen is if the routine was marked pageable.

Driver verifier triggers this by forcing all of your paged code and data
to page out whenever it gets the opportunity, such as when you call
KeAcquireSpinLock. By the time it returns to you, your code is paged
out, so when the very last return statement tries to go back to your
code, you get a page fault.

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

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

Chiranjeev.M
M.Tech

http:e-home.htm/xxxxx@Middle5/1399600_1393116/1399039/1?PARTNER=3&OAS_QUERY=
null%20target=new%20> rakhi

— 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</http:>

10

chiranjeevi marella wrote:

What i understood from the DDK help is that, the fourth parameter is
the virtual address of the instruction(in the text/code section of our
driver)that is executed by the processor, and the first parameter is
the physical address of the same instruction if present in main memory.
Now my doubt is that, if we have acquired the spin lock after some set
of instructions in the read dispatch routine(suppose marked as
pageable), the very next instruction should cause this bug check only
if driver verifier is enabled, since it pages out all pageable
memory.(And if driver verifier is not enabled in this case,can we get
away accessing the pageable memory till we release the spinlock, since
the page containing our text/code section is currently in main memory).

Yes, exactly. However, since your customers can turn on driver verifier
any time they want to, you can’t rely on being able to break the rules.

It is theoretically possible that the code in your function crosses a
page boundary, and in that case it’s possible for the first page to be
in while the second page is out, but that’s statistically unlikely.

There can be a possibility that, routine is in non-paged memory and
after acquiring the spin lock, we accessed the paged memory. In this
situation if driver verifier is enabled, it pages out the memory that
we will try to reference, causing the same bug check. Here the routine
is not pageable.

Yes. Again, the rule is that you are not allowed to acquire a spinlock
in a pageable routine.

What will be the first and fourth parameters in this case.

You said it above: the 4th parameter will be the address of the
instruction that caused the fault, and the 1st parameter will be the
address of the memory that was paged out.

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

11

Saravana Kumar Rathinam wrote:

The first parameter is the Virtual Address (not /physical/) at which
the fault occurred. The address which you are seeing is most probably
the address of your dispatch routine.

Also, driver verifier does not page out pageable memory. It merely
bugchecks the machine if you access any memory which is pageable at
DISPATCH LEVEL or higher (even if the page is resident in physical
memory).

No, this is not correct. How could it? If the page is resident, there
is no fault for Verifier to catch.

No, Verifier actually trims the working set to force pageable memory out
at every opportunity. That’s the only way it can catch these exceptions.

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

12

Yes, without a fault there would be no way of catching these, but the page
can be resident if it’s on the standby list, in which case there would be a
page fault (soft). Also, in cases where the Paged pool is expanded and there
are new system page tables created for these, page faults would happen if
the process page directory does not point to the new system page table (even
if the page is physically resident).

I did not know that verifier trims the working set too. Are all the pageable
working set entries trimmed?

Thanks,

-Saravana

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, August 24, 2007 10:03 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] driver verifier test help

Saravana Kumar Rathinam wrote:

The first parameter is the Virtual Address (not /physical/) at which
the fault occurred. The address which you are seeing is most probably
the address of your dispatch routine.

Also, driver verifier does not page out pageable memory. It merely
bugchecks the machine if you access any memory which is pageable at
DISPATCH LEVEL or higher (even if the page is resident in physical
memory).

No, this is not correct. How could it? If the page is resident, there
is no fault for Verifier to catch.

No, Verifier actually trims the working set to force pageable memory out
at every opportunity. That’s the only way it can catch these exceptions.

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

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

Saravana Kumar Rathinam wrote:

Yes, without a fault there would be no way of catching these, but the page
can be resident if it’s on the standby list, in which case there would be a
page fault (soft). Also, in cases where the Paged pool is expanded and there
are new system page tables created for these, page faults would happen if
the process page directory does not point to the new system page table (even
if the page is physically resident).

Yes, the “physically resident” state is irrelevant. The key question is
whether the page is present in the page tables. If it is, there will
not be a fault of any kind. What verifier does is eliminate those pages
from the page tables.

I did not know that verifier trims the working set too. Are all the pageable
working set entries trimmed?

Someone like Doron will have to provide the details. My understanding
is that the verifier is rather aggressive with the trimming.

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

14

I don’t think it trims working sets for all applications, rather it just
invalidates the page table entries for all of pageable pool (or as much
as it can). I haven’t looked at the code for this in years, I am sure
it is a lot smarter then it used to be since I looked at it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, August 28, 2007 10:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] driver verifier test help

Saravana Kumar Rathinam wrote:

Yes, without a fault there would be no way of catching these, but the
page
can be resident if it’s on the standby list, in which case there would
be a
page fault (soft). Also, in cases where the Paged pool is expanded and
there
are new system page tables created for these, page faults would happen
if
the process page directory does not point to the new system page table
(even
if the page is physically resident).

Yes, the “physically resident” state is irrelevant. The key question is
whether the page is present in the page tables. If it is, there will
not be a fault of any kind. What verifier does is eliminate those pages
from the page tables.

I did not know that verifier trims the working set too. Are all the
pageable
working set entries trimmed?

Someone like Doron will have to provide the details. My understanding
is that the verifier is rather aggressive with the trimming.

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

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

15

Thanks, I just found that the ‘Windows Internals’ book elaborates on this
further, (Chapter 7, Page 413),

-Saravana

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, August 28, 2007 11:20 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] driver verifier test help

I don’t think it trims working sets for all applications, rather it just
invalidates the page table entries for all of pageable pool (or as much
as it can). I haven’t looked at the code for this in years, I am sure
it is a lot smarter then it used to be since I looked at it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, August 28, 2007 10:43 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] driver verifier test help

Saravana Kumar Rathinam wrote:

Yes, without a fault there would be no way of catching these, but the
page
can be resident if it’s on the standby list, in which case there would
be a
page fault (soft). Also, in cases where the Paged pool is expanded and
there
are new system page tables created for these, page faults would happen
if
the process page directory does not point to the new system page table
(even
if the page is physically resident).

Yes, the “physically resident” state is irrelevant. The key question is
whether the page is present in the page tables. If it is, there will
not be a fault of any kind. What verifier does is eliminate those pages
from the page tables.

I did not know that verifier trims the working set too. Are all the
pageable
working set entries trimmed?

Someone like Doron will have to provide the details. My understanding
is that the verifier is rather aggressive with the trimming.

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

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