I accidentally called ZwReadFile at APC_LEVEL IRQL (holding a fast mutex
actually) in a driver running on Vista RTM and got a weird result.
ZwReadFile just wouldn't return. No crash, no bad status return, the thread
just hung. Then of course the application was stuck with an open handle and
neither the app or the driver could die properly.
I turned on DriverVerifier for my driver with all options selected except
low resource simulation and it never complained.

It seems 1) ZwReadFile should be checking the current IRQL and returning a
bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier should have
caught this no?

Just FYI to any MSFT folks that might care.

I caught it pretty fast on my own, but this could cause someone no end of
pain if they didn't know what to look for.

Btw, this driver ran fine on XP SP2...don't know if that was (bad) luck or
just a change in under arching operation.

Haven't tried SDV on it yet.

Bill M.

Re: Verifier doesn't catch IRQL violation by Don

Don
Thu Oct 11 14:18:15 PDT 2007


"Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
news:uc76VrEDIHA.3548@TK2MSFTNGP06.phx.gbl...
> It seems 1) ZwReadFile should be checking the current IRQL and returning a
> bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier should have
> caught this no?
>

Well traditionally the checks for IRQL are ASSERT's in the checked build,
there wasn't an error in the for this. Verifier has never done IRQL
checking.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply



Re: Verifier doesn't catch IRQL violation by Bill

Bill
Thu Oct 11 14:30:48 PDT 2007

Fair enough on Verifier...I haven't had that many IRQL violations to notice.

Why is that on the checked build? I guess I guess I never have understood
using an ASSERT for something that can render the system inoperable. Too
costly in terms of time to check IRQL or something?

Bill M.

"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:e2ET2wEDIHA.2004@TK2MSFTNGP06.phx.gbl...
>
> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
> news:uc76VrEDIHA.3548@TK2MSFTNGP06.phx.gbl...
>> It seems 1) ZwReadFile should be checking the current IRQL and returning
>> a bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier should have
>> caught this no?
>>
>
> Well traditionally the checks for IRQL are ASSERT's in the checked build,
> there wasn't an error in the for this. Verifier has never done IRQL
> checking.
>
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>



Re: Verifier doesn't catch IRQL violation by Doron

Doron
Thu Oct 11 15:28:26 PDT 2007

yes, the cost of checking IRQL is high and doing this is in a very sensitive
perf path is not a good idea. i fwd'ed the suggestion off to the verifier
folks

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
news:%23s5023EDIHA.1168@TK2MSFTNGP02.phx.gbl...
> Fair enough on Verifier...I haven't had that many IRQL violations to
> notice.
>
> Why is that on the checked build? I guess I guess I never have understood
> using an ASSERT for something that can render the system inoperable. Too
> costly in terms of time to check IRQL or something?
>
> Bill M.
>
> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
> news:e2ET2wEDIHA.2004@TK2MSFTNGP06.phx.gbl...
>>
>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
>> news:uc76VrEDIHA.3548@TK2MSFTNGP06.phx.gbl...
>>> It seems 1) ZwReadFile should be checking the current IRQL and returning
>>> a bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier should have
>>> caught this no?
>>>
>>
>> Well traditionally the checks for IRQL are ASSERT's in the checked build,
>> there wasn't an error in the for this. Verifier has never done IRQL
>> checking.
>>
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>
>


Re: Verifier doesn't catch IRQL violation by Bill

Bill
Sun Oct 14 18:58:12 PDT 2007

Many thanks Doron!


"Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
news:eaUeLYFDIHA.5976@TK2MSFTNGP02.phx.gbl...
> yes, the cost of checking IRQL is high and doing this is in a very
> sensitive perf path is not a good idea. i fwd'ed the suggestion off to
> the verifier folks
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
> news:%23s5023EDIHA.1168@TK2MSFTNGP02.phx.gbl...
>> Fair enough on Verifier...I haven't had that many IRQL violations to
>> notice.
>>
>> Why is that on the checked build? I guess I guess I never have
>> understood using an ASSERT for something that can render the system
>> inoperable. Too costly in terms of time to check IRQL or something?
>>
>> Bill M.
>>
>> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
>> news:e2ET2wEDIHA.2004@TK2MSFTNGP06.phx.gbl...
>>>
>>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
>>> news:uc76VrEDIHA.3548@TK2MSFTNGP06.phx.gbl...
>>>> It seems 1) ZwReadFile should be checking the current IRQL and
>>>> returning a bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier
>>>> should have caught this no?
>>>>
>>>
>>> Well traditionally the checks for IRQL are ASSERT's in the checked
>>> build, there wasn't an error in the for this. Verifier has never done
>>> IRQL checking.
>>>
>>>
>>>
>>> --
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Website: http://www.windrvr.com
>>> Blog: http://msmvps.com/blogs/WinDrvr
>>> Remove StopSpam to reply
>>>
>>>
>>
>>
>



Re: Verifier doesn't catch IRQL violation by Tim

Tim
Mon Oct 15 21:06:18 PDT 2007

"Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote:
>
>Why is that on the checked build? I guess I guess I never have understood
>using an ASSERT for something that can render the system inoperable. Too
>costly in terms of time to check IRQL or something?

Some people have said that turning off ASSERTs in release mode is like
removing the brakes from a car as it leaves the factory.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Re: Verifier doesn't catch IRQL violation by Don

Don
Tue Oct 16 05:06:13 PDT 2007

Tim,

Having come out of a fault tolerant world that is a claim many people
from FT believe, but there are two types of ASSERT's:

1. Light-weight - this is the type that fault tolerant systems use.
For instance on a linked list operation check that the list head is
consistent in an assert.

2 Heavy-weight - this is common in many systems including Windows.
For the linked list example for every operation on the list walk every
element and check they are consistent.

Sorry the latter does not make sense in a production environment but is
wonderful in a debugging environment. It would be great if Microsoft spent
the effort to fix the ASSERT's and classifying them as the two types above
so the heavy weight are removed in the free build but not the lightweight
ones.

It would be even better if they changed many of these to error
returns but that would be a radical change to the kernel API's. Overall, I
don't expect either since they are a lot of work, and the checked build is
not getting much support in Redmond from what I see.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"Tim Roberts" <timr@probo.com> wrote in message
news:54e8h3tbcnoaoat75ajmseg9bhojuc79el@4ax.com...
> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote:
>>
>>Why is that on the checked build? I guess I guess I never have understood
>>using an ASSERT for something that can render the system inoperable. Too
>>costly in terms of time to check IRQL or something?
>
> Some people have said that turning off ASSERTs in release mode is like
> removing the brakes from a car as it leaves the factory.
> --
> Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc.



Re: Verifier doesn't catch IRQL violation by Bill

Bill
Tue Oct 16 08:14:57 PDT 2007

One problem I keep having is I have a heck of a time getting the checked
version of the OS to install anywhere (XP). I don't know if the CD images
are bad or its just broke, but I have one machine out of 8 that I can run
the checked build on. Anyone else having these kinds of problems?

Bill M.

"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:OzFp1z%23DIHA.536@TK2MSFTNGP06.phx.gbl...
> Tim,
>
> Having come out of a fault tolerant world that is a claim many people
> from FT believe, but there are two types of ASSERT's:
>
> 1. Light-weight - this is the type that fault tolerant systems use.
> For instance on a linked list operation check that the list head is
> consistent in an assert.
>
> 2 Heavy-weight - this is common in many systems including Windows.
> For the linked list example for every operation on the list walk every
> element and check they are consistent.
>
> Sorry the latter does not make sense in a production environment but
> is wonderful in a debugging environment. It would be great if Microsoft
> spent the effort to fix the ASSERT's and classifying them as the two types
> above so the heavy weight are removed in the free build but not the
> lightweight ones.
>
> It would be even better if they changed many of these to error
> returns but that would be a radical change to the kernel API's. Overall,
> I don't expect either since they are a lot of work, and the checked build
> is not getting much support in Redmond from what I see.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
> "Tim Roberts" <timr@probo.com> wrote in message
> news:54e8h3tbcnoaoat75ajmseg9bhojuc79el@4ax.com...
>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote:
>>>
>>>Why is that on the checked build? I guess I guess I never have
>>>understood
>>>using an ASSERT for something that can render the system inoperable. Too
>>>costly in terms of time to check IRQL or something?
>>
>> Some people have said that turning off ASSERTs in release mode is like
>> removing the brakes from a car as it leaves the factory.
>> --
>> Tim Roberts, timr@probo.com
>> Providenza & Boekelheide, Inc.
>
>



Re: Verifier doesn't catch IRQL violation by Don

Don
Tue Oct 16 08:23:56 PDT 2007

Bill,

What is the problem you are having? There are unfortunately asserts
that will trigger on a number of systems where the ACPI is not exactly what
Microsoft expects. Also, a popular NIC card would cause ASSERT's. For
both of these all you can do is modify the install so the debugger is
running. This is too complex to explain here, but is in my article
http://www.osronline.com/article.cfm?article=264


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply


"Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
news:%23QJNJdAEIHA.4332@TK2MSFTNGP06.phx.gbl...
> One problem I keep having is I have a heck of a time getting the checked
> version of the OS to install anywhere (XP). I don't know if the CD images
> are bad or its just broke, but I have one machine out of 8 that I can run
> the checked build on. Anyone else having these kinds of problems?
>
> Bill M.
>
> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
> news:OzFp1z%23DIHA.536@TK2MSFTNGP06.phx.gbl...
>> Tim,
>>
>> Having come out of a fault tolerant world that is a claim many
>> people from FT believe, but there are two types of ASSERT's:
>>
>> 1. Light-weight - this is the type that fault tolerant systems use.
>> For instance on a linked list operation check that the list head is
>> consistent in an assert.
>>
>> 2 Heavy-weight - this is common in many systems including Windows.
>> For the linked list example for every operation on the list walk every
>> element and check they are consistent.
>>
>> Sorry the latter does not make sense in a production environment but
>> is wonderful in a debugging environment. It would be great if Microsoft
>> spent the effort to fix the ASSERT's and classifying them as the two
>> types above so the heavy weight are removed in the free build but not the
>> lightweight ones.
>>
>> It would be even better if they changed many of these to error
>> returns but that would be a radical change to the kernel API's.
>> Overall, I don't expect either since they are a lot of work, and the
>> checked build is not getting much support in Redmond from what I see.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>> "Tim Roberts" <timr@probo.com> wrote in message
>> news:54e8h3tbcnoaoat75ajmseg9bhojuc79el@4ax.com...
>>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote:
>>>>
>>>>Why is that on the checked build? I guess I guess I never have
>>>>understood
>>>>using an ASSERT for something that can render the system inoperable.
>>>>Too
>>>>costly in terms of time to check IRQL or something?
>>>
>>> Some people have said that turning off ASSERTs in release mode is like
>>> removing the brakes from a car as it leaves the factory.
>>> --
>>> Tim Roberts, timr@probo.com
>>> Providenza & Boekelheide, Inc.
>>
>>
>
>



Re: Verifier doesn't catch IRQL violation by Bill

Bill
Tue Oct 16 08:55:51 PDT 2007

Don't remember all the problems, but installs keep backing out because of
But honestly,errors. I will check out your article. if it's this
difficult...I will run the checked HAL and kernel via bcdedit/boot.ini
replacement, but I am not wasting time trying to get a checked build to
install if it is this difficult. It's unfortunate.

Bill M.


"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:eBVGRiAEIHA.4308@TK2MSFTNGP06.phx.gbl...
> Bill,
>
> What is the problem you are having? There are unfortunately asserts
> that will trigger on a number of systems where the ACPI is not exactly
> what Microsoft expects. Also, a popular NIC card would cause ASSERT's.
> For both of these all you can do is modify the install so the debugger is
> running. This is too complex to explain here, but is in my article
> http://www.osronline.com/article.cfm?article=264
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
> news:%23QJNJdAEIHA.4332@TK2MSFTNGP06.phx.gbl...
>> One problem I keep having is I have a heck of a time getting the checked
>> version of the OS to install anywhere (XP). I don't know if the CD
>> images are bad or its just broke, but I have one machine out of 8 that I
>> can run the checked build on. Anyone else having these kinds of
>> problems?
>>
>> Bill M.
>>
>> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
>> news:OzFp1z%23DIHA.536@TK2MSFTNGP06.phx.gbl...
>>> Tim,
>>>
>>> Having come out of a fault tolerant world that is a claim many
>>> people from FT believe, but there are two types of ASSERT's:
>>>
>>> 1. Light-weight - this is the type that fault tolerant systems
>>> use. For instance on a linked list operation check that the list head is
>>> consistent in an assert.
>>>
>>> 2 Heavy-weight - this is common in many systems including
>>> Windows. For the linked list example for every operation on the list
>>> walk every element and check they are consistent.
>>>
>>> Sorry the latter does not make sense in a production environment but
>>> is wonderful in a debugging environment. It would be great if Microsoft
>>> spent the effort to fix the ASSERT's and classifying them as the two
>>> types above so the heavy weight are removed in the free build but not
>>> the lightweight ones.
>>>
>>> It would be even better if they changed many of these to error
>>> returns but that would be a radical change to the kernel API's. Overall,
>>> I don't expect either since they are a lot of work, and the checked
>>> build is not getting much support in Redmond from what I see.
>>>
>>>
>>> --
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Website: http://www.windrvr.com
>>> Blog: http://msmvps.com/blogs/WinDrvr
>>> Remove StopSpam to reply
>>>
>>>
>>> "Tim Roberts" <timr@probo.com> wrote in message
>>> news:54e8h3tbcnoaoat75ajmseg9bhojuc79el@4ax.com...
>>>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote:
>>>>>
>>>>>Why is that on the checked build? I guess I guess I never have
>>>>>understood
>>>>>using an ASSERT for something that can render the system inoperable.
>>>>>Too
>>>>>costly in terms of time to check IRQL or something?
>>>>
>>>> Some people have said that turning off ASSERTs in release mode is like
>>>> removing the brakes from a car as it leaves the factory.
>>>> --
>>>> Tim Roberts, timr@probo.com
>>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>
>>
>
>



Re: Verifier doesn't catch IRQL violation by Alexander

Alexander
Fri Oct 19 19:16:40 PDT 2007

KeGetCurrentIrql in WinXP is about 3 instructions, one of them is reading
from some high memory (per-processor block? or APIC?).

In Win2008 (and probably Vista, too), it's just one byte fetch from FS:
segment, where cached IRQL is kept. This makes a lot of sense, since IRQL
only changes explicitly (at least what one execution stream sees. Any
temporary changes caused by interrupts are not visible to it).


"Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
news:eaUeLYFDIHA.5976@TK2MSFTNGP02.phx.gbl...
> yes, the cost of checking IRQL is high and doing this is in a very
> sensitive perf path is not a good idea. i fwd'ed the suggestion off to
> the verifier folks
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
> news:%23s5023EDIHA.1168@TK2MSFTNGP02.phx.gbl...
>> Fair enough on Verifier...I haven't had that many IRQL violations to
>> notice.
>>
>> Why is that on the checked build? I guess I guess I never have
>> understood using an ASSERT for something that can render the system
>> inoperable. Too costly in terms of time to check IRQL or something?
>>
>> Bill M.
>>
>> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
>> news:e2ET2wEDIHA.2004@TK2MSFTNGP06.phx.gbl...
>>>
>>> "Bill McKenzie" <bkmckenzie@sbcglobal.net> wrote in message
>>> news:uc76VrEDIHA.3548@TK2MSFTNGP06.phx.gbl...
>>>> It seems 1) ZwReadFile should be checking the current IRQL and
>>>> returning a bad status if it isn't PASSIVE_LEVEL and 2) DriverVerifier
>>>> should have caught this no?
>>>>
>>>
>>> Well traditionally the checks for IRQL are ASSERT's in the checked
>>> build, there wasn't an error in the for this. Verifier has never done
>>> IRQL checking.
>>>
>>>
>>>
>>> --
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Website: http://www.windrvr.com
>>> Blog: http://msmvps.com/blogs/WinDrvr
>>> Remove StopSpam to reply
>>>
>>>
>>
>>
>



Re: Verifier doesn't catch IRQL violation by Maxim

Maxim
Sat Oct 20 13:54:47 PDT 2007

> KeGetCurrentIrql in WinXP is about 3 instructions, one of them is reading
> from some high memory (per-processor block? or APIC?).

APIC.
This read can be slow.

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