ASSERT is not causing a BSOD but NT_ASSERT is

Rafal_Zwierz · February 16, 2010, 10:30am

Hi,

I have lived with with assumption that failed asserts in the kernel
mode cause BSODs when a checked version of a driver is running on a
system which is NOT running in DEBUG mode. Threads
http://www.osronline.com/showThread.cfm?link=169579 and
http://www.osronline.com/showThread.cfm?link=153733 made my assumption
even stronger.

However a recent bug has shaken this assumption. It seemed that failed
ASSERTs were NOT causing BSODs on my test Win 7 RTM (x86) machine.

I have checked WDK docs and have googled a fair bit but didn’t find
any strong statement that ASSERTs should cause BSODs, so I have
resorted to a debugger. As you probably know ASSERT calls RtlAssert()
when the condition is false, so I disassembled the latter. To my
surprise it seems that after printing assertion message (using
DbgPrint) RtlAssert checks fixed place in memory (FFDF02D4h) to see
whether it contains 3, and quits if it doesn’t:

82b0bb42 a0d402dfff mov al,byte ptr ds:[FFDF02D4h]
82b0bb47 2403 and al,3
82b0bb49 83c41c add esp,1Ch
82b0bb4c 3c03 cmp al,3
82b0bb4e 0f858d000000 jne nt!RtlAssert+0xf9 (82b0bbe1)

…

nt!RtlAssert+0xf9:
156 82b0bbe1 8b4dfc mov ecx,dword ptr [ebp-4]
156 82b0bbe4 5f pop edi
156 82b0bbe5 5e pop esi
156 82b0bbe6 33cd xor ecx,ebp
156 82b0bbe8 5b pop ebx
156 82b0bbe9 e8da28f7ff call nt!__security_check_cookie (82a7e4c8)
156 82b0bbee c9 leave
156 82b0bbef c21000 ret 10h

So if FFDF02D4h contains something else than 3 no ‘BSOD making’ call
is made. With some experimenting it seems that FFDF02D4 is set to 1
when the system is running in DEBUG mode and to 3 if it is running in
DEBUG mode and a debugger is attached to it.

When I replace a failing ASSERT with a failing NT_ASSERT then I get a
nice BSOD exactly as I would expect.

I was wondering whether one of you might know an answer to some/all of
the following questions:

What am I missing?
Has implementation of RtlAssert been changed between XP and Vista
(RtlAssert on Vista looks very like the RtlAssert on Win7 shown
above)?
Is there any way to tell the OS that I want ASSERTs to result in
BSODs? I.e. how can I influence FFDF02D4h without a debugger. I would
like to have our system test run with version of drivers which BSOD
when a false assertion is hit. (I know I can write my own assert
macros, but I wonder whether there is any out-of-the-box way).
NT_ASSERT is not documented. Is that an omission or does MS wants
people to use only ASSERTs?

Thanks a lot for your help.
Take care,
Rafal

Don_Burn_1 · February 16, 2010, 10:38am

Well a lot of your questions are answered in
http://www.osronline.com/article.cfm?article=474

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Rafal Zwierz” wrote in message
news:xxxxx@ntdev:

> Hi,
>
> I have lived with with assumption that failed asserts in the kernel
> mode cause BSODs when a checked version of a driver is running on a
> system which is NOT running in DEBUG mode. Threads
> http://www.osronline.com/showThread.cfm?link=169579 and
> http://www.osronline.com/showThread.cfm?link=153733 made my assumption
> even stronger.
>
> However a recent bug has shaken this assumption. It seemed that failed
> ASSERTs were NOT causing BSODs on my test Win 7 RTM (x86) machine.
>
> I have checked WDK docs and have googled a fair bit but didn’t find
> any strong statement that ASSERTs should cause BSODs, so I have
> resorted to a debugger. As you probably know ASSERT calls RtlAssert()
> when the condition is false, so I disassembled the latter. To my
> surprise it seems that after printing assertion message (using
> DbgPrint) RtlAssert checks fixed place in memory (FFDF02D4h) to see
> whether it contains 3, and quits if it doesn’t:
>
> 82b0bb42 a0d402dfff mov al,byte ptr ds:[FFDF02D4h]
> 82b0bb47 2403 and al,3
> 82b0bb49 83c41c add esp,1Ch
> 82b0bb4c 3c03 cmp al,3
> 82b0bb4e 0f858d000000 jne nt!RtlAssert+0xf9 (82b0bbe1)
>
> …
>
> nt!RtlAssert+0xf9:
> 156 82b0bbe1 8b4dfc mov ecx,dword ptr [ebp-4]
> 156 82b0bbe4 5f pop edi
> 156 82b0bbe5 5e pop esi
> 156 82b0bbe6 33cd xor ecx,ebp
> 156 82b0bbe8 5b pop ebx
> 156 82b0bbe9 e8da28f7ff call nt!security_check_cookie (82a7e4c8)
> 156 82b0bbee c9 leave
> 156 82b0bbef c21000 ret 10h
>
> So if FFDF02D4h contains something else than 3 no ‘BSOD making’ call
> is made. With some experimenting it seems that FFDF02D4 is set to 1
> when the system is running in DEBUG mode and to 3 if it is running in
> DEBUG mode and a debugger is attached to it.
>
> When I replace a failing ASSERT with a failing NT_ASSERT then I get a
> nice BSOD exactly as I would expect.
>
> I was wondering whether one of you might know an answer to some/all of
> the following questions:
> 1. What am I missing?
> 2. Has implementation of RtlAssert been changed between XP and Vista
> (RtlAssert on Vista looks very like the RtlAssert on Win7 shown
> above)?
> 3. Is there any way to tell the OS that I want ASSERTs to result in
> BSODs? I.e. how can I influence FFDF02D4h without a debugger. I would
> like to have our system test run with version of drivers which BSOD
> when a false assertion is hit. (I know I can write my own assert
> macros, but I wonder whether there is any out-of-the-box way).
> 4. NT_ASSERT is not documented. Is that an omission or does MS wants
> people to use only ASSERTs?
>
> Thanks a lot for your help.
> Take care,
> Rafal

________ Information from ESET Smart Security, version of virus
signature database 4871 (20100216) __________

The message was checked by ESET Smart Security.

http://www.eset.com

Rafal_Zwierz · February 16, 2010, 11:02am

Thanks for the reply Don.

I had read the article that you pointed me to before posting and
please forgive me if I am being thick, but I hadn’t found anything
about why ASSERT is not causing a BSOD.

With the help of the article I know that NT_ASSERT is quite different
from ASSERT in how it works, how it is supported by the debugger and
all that. Also I understand that the difference in the implementation
of NT_ASSERT makes it behave as expected (i.e. BSOD).

However, I am still not clear why ASSERT has been changed not to cause
BSODs on Win7 and Vista (one of the posts by Daniel Terhell in thread
http://www.osronline.com/showThread.cfm?link=153733 suggests that on
XP ASSERT would cause a BSOD on system NOT running in DEBUG mode).

In other words I know that I could write my own asserts or use
undocumented NT_ASSERTs, but I wanted to know why documented ASSERTs
are not working as they used to and how I would feel that they should.

So, I guess that my question remains open.

Thanks again,
Rafal

On 16 February 2010 15:38, Don Burn wrote:
> Well a lot of your questions are answered in
> http://www.osronline.com/article.cfm?article=474
>
>
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
> “Rafal Zwierz” wrote in message
> news:xxxxx@ntdev:
>
>> Hi,
>>
>> I have lived with with assumption that failed asserts in the kernel
>> mode cause BSODs when a checked version of a driver is running on a
>> system which is NOT running in DEBUG mode. Threads
>> http://www.osronline.com/showThread.cfm?link=169579 and
>> http://www.osronline.com/showThread.cfm?link=153733 made my assumption
>> even stronger.
>>
>> However a recent bug has shaken this assumption. It seemed that failed
>> ASSERTs were NOT causing BSODs on my test Win 7 RTM (x86) machine.
>>
>> I have checked WDK docs and have googled a fair bit but didn’t find
>> any strong statement that ASSERTs should cause BSODs, so I have
>> resorted to a debugger. As you probably know ASSERT calls RtlAssert()
>> when the condition is false, so I disassembled the latter. To my
>> surprise it seems that after printing assertion message (using
>> DbgPrint) RtlAssert checks fixed place in memory (FFDF02D4h) to see
>> whether it contains 3, and quits if it doesn’t:
>>
>> ?82b0bb42 a0d402dfff ? ? ?mov ? ? al,byte ptr ds:[FFDF02D4h]
>> ?82b0bb47 2403 ? ? ? ? ? ?and ? ? al,3
>> ?82b0bb49 83c41c ? ? ? ? ?add ? ? esp,1Ch
>> ?82b0bb4c 3c03 ? ? ? ? ? ?cmp ? ? al,3
>> ?82b0bb4e 0f858d000000 ? ?jne ? ? nt!RtlAssert+0xf9 (82b0bbe1)
>>
>> …
>>
>> nt!RtlAssert+0xf9:
>> ?156 82b0bbe1 8b4dfc ? ? ? ? ?mov ? ? ecx,dword ptr [ebp-4]
>> ?156 82b0bbe4 5f ? ? ? ? ? ? ?pop ? ? edi
>> ?156 82b0bbe5 5e ? ? ? ? ? ? ?pop ? ? esi
>> ?156 82b0bbe6 33cd ? ? ? ? ? ?xor ? ? ecx,ebp
>> ?156 82b0bbe8 5b ? ? ? ? ? ? ?pop ? ? ebx
>> ?156 82b0bbe9 e8da28f7ff ? ? ?call ? ?nt!security_check_cookie
>> (82a7e4c8)
>> ?156 82b0bbee c9 ? ? ? ? ? ? ?leave
>> ?156 82b0bbef c21000 ? ? ? ? ?ret ? ? 10h
>>
>> So if FFDF02D4h contains something else than 3 no ‘BSOD making’ call
>> is made. With some experimenting it seems that FFDF02D4 is set to 1
>> when the system is running in DEBUG mode and to 3 if it is running in
>> DEBUG mode and a debugger is attached to it.
>>
>> When I replace a failing ASSERT with a failing NT_ASSERT then I get a
>> nice BSOD exactly as I would expect.
>>
>> I was wondering whether one of you might know an answer to some/all of
>> the following questions:
>> 1. What am I missing?
>> 2. Has implementation of RtlAssert been changed between XP and Vista
>> (RtlAssert on Vista looks very like the RtlAssert on Win7 shown
>> above)?
>> 3. Is there any way to tell the OS that I want ASSERTs to result in
>> BSODs? I.e. how can I influence FFDF02D4h without a debugger. I would
>> like to have our system test run with version of drivers which BSOD
>> when a false assertion is hit. (I know I can write my own assert
>> macros, but I wonder whether there is any out-of-the-box way).
>> 4. NT_ASSERT is not documented. Is that an omission or does MS wants
>> people to use only ASSERTs?
>>
>> Thanks a lot for your help.
>> Take care,
>> Rafal
>
>
>________ Information from ESET Smart Security, version of virus signature
> database 4871 (20100216) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
> —
> 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
>

Michal_Vodicka-2 · February 16, 2010, 6:05pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
Sent: Tuesday, February 16, 2010 5:02 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

In other words I know that I could write my own asserts or use
undocumented NT_ASSERTs, but I wanted to know why documented ASSERTs
are not working as they used to and how I would feel that they should.

It is because MS devs who changed it feel different. They probably can’t
imagine somebody is running checked build of driver without KD or WinDbg
connected. Not very smart, IMO. Yet another example how things look
differently inside and outside of MS.

Well, for you drivers the cure is simple. Just define own assert macro
which behaves reasonably. For checked version of OS drivers it is
worse…

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Rafal_Zwierz · February 17, 2010, 3:15am

I guess writing our own ASSERTs is what we will have to do :-(.

Why do you think that for checked version of OS drivers things are
worse? Aren’t they all using NT_ASSERT?

Thanks,
Rafal

On 16 February 2010 23:04, Michal Vodicka wrote:
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
>> Sent: Tuesday, February 16, 2010 5:02 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>>
>> In other words I know that I could write my own asserts or use
>> undocumented NT_ASSERTs, but I wanted to know why documented ASSERTs
>> are not working as they used to and how I would feel that they should.
>
> It is because MS devs who changed it feel different. They probably can’t
> imagine somebody is running checked build of driver without KD or WinDbg
> connected. Not very smart, IMO. Yet another example how things look
> differently inside and outside of MS.
>
> Well, for you drivers the cure is simple. Just define own assert macro
> which behaves reasonably. For checked version of OS drivers it is
> worse…
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · February 17, 2010, 3:10pm

He’s saying, if you’re running a CHK build without a debugger, and an
NT_ASSERT happens, it blue screens. In your own code, you can define
your own ASSERT’s. But you can’t stop checked OS drivers from blue
screening if they’re using NT_ASSERT.

I personally think NT_ASSERT is better for what it was designed to do.
But aside from that, if you’re using any kind of ASSERT’s correctly, if
an ASSERT happens, something Really Bad is going on, and if execution
continues after the assertion failure, all bets are off.

Granted, not everyone uses ASSERT’s correctly, and that’s why we have
people expecting to continue nonchalantly after an assertion failure.

Thanks,
Daniel

On 2/17/2010 12:14 AM, Rafal Zwierz wrote:

I guess writing our own ASSERTs is what we will have to do :-(.

Why do you think that for checked version of OS drivers things are
worse? Aren’t they all using NT_ASSERT?

Thanks,
Rafal

On 16 February 2010 23:04, Michal Vodicka wrote:
>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
>>> Sent: Tuesday, February 16, 2010 5:02 PM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>>>
>>> In other words I know that I could write my own asserts or use
>>> undocumented NT_ASSERTs, but I wanted to know why documented ASSERTs
>>> are not working as they used to and how I would feel that they should.
>>>
>> It is because MS devs who changed it feel different. They probably can’t
>> imagine somebody is running checked build of driver without KD or WinDbg
>> connected. Not very smart, IMO. Yet another example how things look
>> differently inside and outside of MS.
>>
>> Well, for you drivers the cure is simple. Just define own assert macro
>> which behaves reasonably. For checked version of OS drivers it is
>> worse…
>>
>> Best regards,
>>
>> Michal Vodicka
>> UPEK, Inc.
>> [xxxxx@upek.com, http://www.upek.com]
>>
> —
> 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
>

Michal_Vodicka-2 · February 17, 2010, 8:06pm

No, they aren’t. Look for example to the latest WDK and FastFat sources.
It is full of ASSERTs.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
Sent: Wednesday, February 17, 2010 9:15 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

I guess writing our own ASSERTs is what we will have to do :-(.

Why do you think that for checked version of OS drivers things are
worse? Aren’t they all using NT_ASSERT?

Thanks,
Rafal

On 16 February 2010 23:04, Michal Vodicka
wrote:
> >> -----Original Message-----
> >> From: xxxxx@lists.osr.com
> >> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Rafal Zwierz
> >> Sent: Tuesday, February 16, 2010 5:02 PM
> >> To: Windows System Software Devs Interest List
> >> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
> >>
> >> In other words I know that I could write my own asserts or use
> >> undocumented NT_ASSERTs, but I wanted to know why
> documented ASSERTs
> >> are not working as they used to and how I would feel that
> they should.
> >
> > It is because MS devs who changed it feel different. They
> probably can’t
> > imagine somebody is running checked build of driver without
> KD or WinDbg
> > connected. Not very smart, IMO. Yet another example how things look
> > differently inside and outside of MS.
> >
> > Well, for you drivers the cure is simple. Just define own
> assert macro
> > which behaves reasonably. For checked version of OS drivers it is
> > worse…
> >
> > Best regards,
> >
> > Michal Vodicka
> > UPEK, Inc.
> > [xxxxx@upek.com, http://www.upek.com]
>
> —
> 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
>

Michal_Vodicka-2 · February 17, 2010, 8:16pm

Actually, I wanted to say that some OS drivers still use ASSERTs and not
NT_ASSERTs. In turn they won’t bugcheck on assertion failure without a
debugger attached which is Really Bad Thing.

NT_ASSERT is different story. IMO it is plain evil. Instead of RtlAssert
you have no chance to see assertion message so you have to disassemble
the code and try to guess what is wrong. Sometimes it was also necessary
with classic asserts but at least there was some hint. Yet another
“improvement” made without consideration of checked build users outside
of MS.

Continuing after assertion failure isn’t an unreasonable requirement.
Assertion failure may not mean fatal problem. My code is usually able to
fail gracefully after assertions failure and in debug version assert
just informs me something unexpected happened. I use asserts like this:

if (VERIFY(Pointer != NULL)) {
// do something useful
}
else {
// return failure
}

VERIFY(x) expands to x in release version and to something as
ASSERT(x),x in debug version (not exactly, just want to show principle).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Daniel Strommen
Sent: Wednesday, February 17, 2010 9:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

He’s saying, if you’re running a CHK build without a debugger, and an
NT_ASSERT happens, it blue screens. In your own code, you can define
your own ASSERT’s. But you can’t stop checked OS drivers from blue
screening if they’re using NT_ASSERT.

I personally think NT_ASSERT is better for what it was
designed to do.
But aside from that, if you’re using any kind of ASSERT’s
correctly, if
an ASSERT happens, something Really Bad is going on, and if execution
continues after the assertion failure, all bets are off.

Granted, not everyone uses ASSERT’s correctly, and that’s why we have
people expecting to continue nonchalantly after an assertion failure.

Thanks,
Daniel

On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
> I guess writing our own ASSERTs is what we will have to do :-(.
>
> Why do you think that for checked version of OS drivers things are
> worse? Aren’t they all using NT_ASSERT?
>
> Thanks,
> Rafal
>
> On 16 February 2010 23:04, Michal
Vodicka wrote:
> >
> >>> -----Original Message-----
> >>> From: xxxxx@lists.osr.com
> >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Rafal Zwierz
> >>> Sent: Tuesday, February 16, 2010 5:02 PM
> >>> To: Windows System Software Devs Interest List
> >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
> >>>
> >>> In other words I know that I could write my own asserts or use
> >>> undocumented NT_ASSERTs, but I wanted to know why
> documented ASSERTs
> >>> are not working as they used to and how I would feel that
> they should.
> >>>
> >> It is because MS devs who changed it feel different. They
> probably can’t
> >> imagine somebody is running checked build of driver
> without KD or WinDbg
> >> connected. Not very smart, IMO. Yet another example how things look
> >> differently inside and outside of MS.
> >>
> >> Well, for you drivers the cure is simple. Just define own
> assert macro
> >> which behaves reasonably. For checked version of OS drivers it is
> >> worse…
> >>
> >> Best regards,
> >>
> >> Michal Vodicka
> >> UPEK, Inc.
> >> [xxxxx@upek.com, http://www.upek.com]
> >>
> > —
> > 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
>

Peter_Wieland · February 17, 2010, 8:20pm

NT_ASSERT messages should be visible in the debugger with Windows 7 (you need the latest version of the debuggers too). No help for Vista though.

-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 17, 2010 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Actually, I wanted to say that some OS drivers still use ASSERTs and not NT_ASSERTs. In turn they won’t bugcheck on assertion failure without a debugger attached which is Really Bad Thing.

NT_ASSERT is different story. IMO it is plain evil. Instead of RtlAssert you have no chance to see assertion message so you have to disassemble the code and try to guess what is wrong. Sometimes it was also necessary with classic asserts but at least there was some hint. Yet another “improvement” made without consideration of checked build users outside of MS.

Continuing after assertion failure isn’t an unreasonable requirement.
Assertion failure may not mean fatal problem. My code is usually able to fail gracefully after assertions failure and in debug version assert just informs me something unexpected happened. I use asserts like this:

if (VERIFY(Pointer != NULL)) {
// do something useful
}
else {
// return failure
}

VERIFY(x) expands to x in release version and to something as ASSERT(x),x in debug version (not exactly, just want to show principle).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Daniel
Strommen
Sent: Wednesday, February 17, 2010 9:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

He’s saying, if you’re running a CHK build without a debugger, and an
NT_ASSERT happens, it blue screens. In your own code, you can define
your own ASSERT’s. But you can’t stop checked OS drivers from blue
screening if they’re using NT_ASSERT.

I personally think NT_ASSERT is better for what it was designed to do.
But aside from that, if you’re using any kind of ASSERT’s correctly,
if an ASSERT happens, something Really Bad is going on, and if
execution continues after the assertion failure, all bets are off.

Granted, not everyone uses ASSERT’s correctly, and that’s why we have
people expecting to continue nonchalantly after an assertion failure.

Thanks,
Daniel

On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
> I guess writing our own ASSERTs is what we will have to do :-(.
>
> Why do you think that for checked version of OS drivers things are
> worse? Aren’t they all using NT_ASSERT?
>
> Thanks,
> Rafal
>
> On 16 February 2010 23:04, Michal
Vodicka wrote:
> >
> >>> -----Original Message-----
> >>> From: xxxxx@lists.osr.com
> >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Rafal Zwierz
> >>> Sent: Tuesday, February 16, 2010 5:02 PM
> >>> To: Windows System Software Devs Interest List
> >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
> >>>
> >>> In other words I know that I could write my own asserts or use
> >>> undocumented NT_ASSERTs, but I wanted to know why
> documented ASSERTs
> >>> are not working as they used to and how I would feel that
> they should.
> >>>
> >> It is because MS devs who changed it feel different. They
> probably can’t
> >> imagine somebody is running checked build of driver
> without KD or WinDbg
> >> connected. Not very smart, IMO. Yet another example how things look
> >> differently inside and outside of MS.
> >>
> >> Well, for you drivers the cure is simple. Just define own
> assert macro
> >> which behaves reasonably. For checked version of OS drivers it is
> >> worse…
> >>
> >> Best regards,
> >>
> >> Michal Vodicka
> >> UPEK, Inc.
> >> [xxxxx@upek.com, http://www.upek.com]
> >>
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

Michal_Vodicka-2 · February 17, 2010, 8:26pm

Does it mean messages are in public symbols? If so and if it works also
for crashdumps, I’d take it back (who cares about Vista ;-)).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, February 18, 2010 2:20 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

NT_ASSERT messages should be visible in the debugger with
Windows 7 (you need the latest version of the debuggers too).
No help for Vista though.

-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 17, 2010 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Actually, I wanted to say that some OS drivers still use
ASSERTs and not NT_ASSERTs. In turn they won’t bugcheck on
assertion failure without a debugger attached which is Really
Bad Thing.

NT_ASSERT is different story. IMO it is plain evil. Instead
of RtlAssert you have no chance to see assertion message so
you have to disassemble the code and try to guess what is
wrong. Sometimes it was also necessary with classic asserts
but at least there was some hint. Yet another “improvement”
made without consideration of checked build users outside of MS.

Continuing after assertion failure isn’t an unreasonable requirement.
Assertion failure may not mean fatal problem. My code is
usually able to fail gracefully after assertions failure and
in debug version assert just informs me something unexpected
happened. I use asserts like this:

if (VERIFY(Pointer != NULL)) {
// do something useful
}
else {
// return failure
}

VERIFY(x) expands to x in release version and to something as
ASSERT(x),x in debug version (not exactly, just want to show
principle).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel
> Strommen
> Sent: Wednesday, February 17, 2010 9:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>
> He’s saying, if you’re running a CHK build without a
debugger, and an
> NT_ASSERT happens, it blue screens. In your own code, you
can define
> your own ASSERT’s. But you can’t stop checked OS drivers from blue
> screening if they’re using NT_ASSERT.
>
> I personally think NT_ASSERT is better for what it was
designed to do.
> But aside from that, if you’re using any kind of ASSERT’s
correctly,
> if an ASSERT happens, something Really Bad is going on, and if
> execution continues after the assertion failure, all bets are off.
>
> Granted, not everyone uses ASSERT’s correctly, and that’s
why we have
> people expecting to continue nonchalantly after an
assertion failure.
>
> Thanks,
> Daniel
>
> On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
> > I guess writing our own ASSERTs is what we will have to do :-(.
> >
> > Why do you think that for checked version of OS drivers
things are
> > worse? Aren’t they all using NT_ASSERT?
> >
> > Thanks,
> > Rafal
> >
> > On 16 February 2010 23:04, Michal
> Vodicka wrote:
> > >
> > >>> -----Original Message-----
> > >>> From: xxxxx@lists.osr.com
> > >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
> > Rafal Zwierz
> > >>> Sent: Tuesday, February 16, 2010 5:02 PM
> > >>> To: Windows System Software Devs Interest List
> > >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but
> NT_ASSERT is
> > >>>
> > >>> In other words I know that I could write my own asserts or use
> > >>> undocumented NT_ASSERTs, but I wanted to know why
> > documented ASSERTs
> > >>> are not working as they used to and how I would feel that
> > they should.
> > >>>
> > >> It is because MS devs who changed it feel different. They
> > probably can’t
> > >> imagine somebody is running checked build of driver
> > without KD or WinDbg
> > >> connected. Not very smart, IMO. Yet another example how
> things look
> > >> differently inside and outside of MS.
> > >>
> > >> Well, for you drivers the cure is simple. Just define own
> > assert macro
> > >> which behaves reasonably. For checked version of OS
> drivers it is
> > >> worse…
> > >>
> > >> Best regards,
> > >>
> > >> Michal Vodicka
> > >> UPEK, Inc.
> > >> [xxxxx@upek.com, http://www.upek.com]
> > >>
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online
> > at http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> 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
>

Peter_Wieland · February 17, 2010, 8:31pm

Yes the messages are left in the public symbols now.

I don’t know how you extract the message once you’re at the assertion so I don’t know (offhand) about crashdumps. If there’s a command line option to dump it I would expect it to show up.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 17, 2010 5:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Does it mean messages are in public symbols? If so and if it works also for crashdumps, I’d take it back (who cares about Vista ;-)).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, February 18, 2010 2:20 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

NT_ASSERT messages should be visible in the debugger with Windows 7
(you need the latest version of the debuggers too).
No help for Vista though.

-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 17, 2010 5:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Actually, I wanted to say that some OS drivers still use ASSERTs and
not NT_ASSERTs. In turn they won’t bugcheck on assertion failure
without a debugger attached which is Really Bad Thing.

NT_ASSERT is different story. IMO it is plain evil. Instead of
RtlAssert you have no chance to see assertion message so you have to
disassemble the code and try to guess what is wrong. Sometimes it was
also necessary with classic asserts but at least there was some hint.
Yet another “improvement”
made without consideration of checked build users outside of MS.

Continuing after assertion failure isn’t an unreasonable requirement.
Assertion failure may not mean fatal problem. My code is usually able
to fail gracefully after assertions failure and in debug version
assert just informs me something unexpected happened. I use asserts
like this:

if (VERIFY(Pointer != NULL)) {
// do something useful
}
else {
// return failure
}

VERIFY(x) expands to x in release version and to something as
ASSERT(x),x in debug version (not exactly, just want to show
principle).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel
> Strommen
> Sent: Wednesday, February 17, 2010 9:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>
> He’s saying, if you’re running a CHK build without a
debugger, and an
> NT_ASSERT happens, it blue screens. In your own code, you
can define
> your own ASSERT’s. But you can’t stop checked OS drivers from blue
> screening if they’re using NT_ASSERT.
>
> I personally think NT_ASSERT is better for what it was
designed to do.
> But aside from that, if you’re using any kind of ASSERT’s
correctly,
> if an ASSERT happens, something Really Bad is going on, and if
> execution continues after the assertion failure, all bets are off.
>
> Granted, not everyone uses ASSERT’s correctly, and that’s
why we have
> people expecting to continue nonchalantly after an
assertion failure.
>
> Thanks,
> Daniel
>
> On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
> > I guess writing our own ASSERTs is what we will have to do :-(.
> >
> > Why do you think that for checked version of OS drivers
things are
> > worse? Aren’t they all using NT_ASSERT?
> >
> > Thanks,
> > Rafal
> >
> > On 16 February 2010 23:04, Michal
> Vodicka wrote:
> > >
> > >>> -----Original Message-----
> > >>> From: xxxxx@lists.osr.com
> > >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
> > Rafal Zwierz
> > >>> Sent: Tuesday, February 16, 2010 5:02 PM
> > >>> To: Windows System Software Devs Interest List
> > >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but
> NT_ASSERT is
> > >>>
> > >>> In other words I know that I could write my own asserts or use
> > >>> undocumented NT_ASSERTs, but I wanted to know why
> > documented ASSERTs
> > >>> are not working as they used to and how I would feel that
> > they should.
> > >>>
> > >> It is because MS devs who changed it feel different. They
> > probably can’t
> > >> imagine somebody is running checked build of driver
> > without KD or WinDbg
> > >> connected. Not very smart, IMO. Yet another example how
> things look
> > >> differently inside and outside of MS.
> > >>
> > >> Well, for you drivers the cure is simple. Just define own
> > assert macro
> > >> which behaves reasonably. For checked version of OS
> drivers it is
> > >> worse…
> > >>
> > >> Best regards,
> > >>
> > >> Michal Vodicka
> > >> UPEK, Inc.
> > >> [xxxxx@upek.com, http://www.upek.com]
> > >>
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online
> > at http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> 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

Michal_Vodicka-2 · February 17, 2010, 8:34pm

Good news, thanks.

I’d expect !analyze -v is able to extract the message, at least it is
the most reasonable way. I guess I’ll try it sometimes.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Thursday, February 18, 2010 2:31 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Yes the messages are left in the public symbols now.

I don’t know how you extract the message once you’re at the
assertion so I don’t know (offhand) about crashdumps. If
there’s a command line option to dump it I would expect it to show up.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, February 17, 2010 5:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Does it mean messages are in public symbols? If so and if it
works also for crashdumps, I’d take it back (who cares about
Vista ;-)).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
Peter Wieland
> Sent: Thursday, February 18, 2010 2:20 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>
> NT_ASSERT messages should be visible in the debugger with Windows 7
> (you need the latest version of the debuggers too).
> No help for Vista though.
>
> -p
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
Michal Vodicka
> Sent: Wednesday, February 17, 2010 5:16 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>
> Actually, I wanted to say that some OS drivers still use
ASSERTs and
> not NT_ASSERTs. In turn they won’t bugcheck on assertion failure
> without a debugger attached which is Really Bad Thing.
>
> NT_ASSERT is different story. IMO it is plain evil. Instead of
> RtlAssert you have no chance to see assertion message so
you have to
> disassemble the code and try to guess what is wrong.
Sometimes it was
> also necessary with classic asserts but at least there was
some hint.
> Yet another “improvement”
> made without consideration of checked build users outside of MS.
>
> Continuing after assertion failure isn’t an unreasonable
requirement.
> Assertion failure may not mean fatal problem. My code is
usually able
> to fail gracefully after assertions failure and in debug version
> assert just informs me something unexpected happened. I use asserts
> like this:
>
> if (VERIFY(Pointer != NULL)) {
> // do something useful
> }
> else {
> // return failure
> }
>
> VERIFY(x) expands to x in release version and to something as
> ASSERT(x),x in debug version (not exactly, just want to show
> principle).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Daniel
> > Strommen
> > Sent: Wednesday, February 17, 2010 9:10 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
> >
> > He’s saying, if you’re running a CHK build without a
> debugger, and an
> > NT_ASSERT happens, it blue screens. In your own code, you
> can define
> > your own ASSERT’s. But you can’t stop checked OS drivers
from blue
> > screening if they’re using NT_ASSERT.
> >
> > I personally think NT_ASSERT is better for what it was
> designed to do.
> > But aside from that, if you’re using any kind of ASSERT’s
> correctly,
> > if an ASSERT happens, something Really Bad is going on, and if
> > execution continues after the assertion failure, all bets are off.
> >
> > Granted, not everyone uses ASSERT’s correctly, and that’s
> why we have
> > people expecting to continue nonchalantly after an
> assertion failure.
> >
> > Thanks,
> > Daniel
> >
> > On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
> > > I guess writing our own ASSERTs is what we will have to do :-(.
> > >
> > > Why do you think that for checked version of OS drivers
> things are
> > > worse? Aren’t they all using NT_ASSERT?
> > >
> > > Thanks,
> > > Rafal
> > >
> > > On 16 February 2010 23:04, Michal
> > Vodicka wrote:
> > > >
> > > >>> -----Original Message-----
> > > >>> From: xxxxx@lists.osr.com
> > > >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
> > > Rafal Zwierz
> > > >>> Sent: Tuesday, February 16, 2010 5:02 PM
> > > >>> To: Windows System Software Devs Interest List
> > > >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but
> > NT_ASSERT is
> > > >>>
> > > >>> In other words I know that I could write my own
> asserts or use
> > > >>> undocumented NT_ASSERTs, but I wanted to know why
> > > documented ASSERTs
> > > >>> are not working as they used to and how I would feel that
> > > they should.
> > > >>>
> > > >> It is because MS devs who changed it feel different. They
> > > probably can’t
> > > >> imagine somebody is running checked build of driver
> > > without KD or WinDbg
> > > >> connected. Not very smart, IMO. Yet another example how
> > things look
> > > >> differently inside and outside of MS.
> > > >>
> > > >> Well, for you drivers the cure is simple. Just define own
> > > assert macro
> > > >> which behaves reasonably. For checked version of OS
> > drivers it is
> > > >> worse…
> > > >>
> > > >> Best regards,
> > > >>
> > > >> Michal Vodicka
> > > >> UPEK, Inc.
> > > >> [xxxxx@upek.com, http://www.upek.com]
> > > >>
> > > > —
> > > > NTDEV is sponsored by OSR
> > > >
> > > > For our schedule of WDF, WDM, debugging and other
> seminars visit:
> > > > http://www.osr.com/seminars
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online
> > > at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > >
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>

Pavel_Lebedinsky · February 17, 2010, 10:53pm

> I’d expect !analyze -v is able to extract the message, at least it is

the most reasonable way. I guess I’ll try it sometimes.

.exr -1 should also print the message. Let us know if this doesn’t work
for you on win7.

By the way, the reason why NT_ASSERT is used in many parts of
the kernel (as opposed to RtlAssert) is because it doesn’t perturb
registers and other system state as much, so analyzing failures is easier.

NT_ASSERTs are also easier to suppress from debugger (using
either ‘ahi’ or ‘ew . 9090’).

–
Pavel Lebedinsky/Windows Fundamentals Test
This posting is provided “AS IS” with no warranties, and confers no rights.

Rafal_Zwierz · February 18, 2010, 1:33pm

Michal,

Thanks for clarifying.

I couldn’t agree with you more on the most of the things apart from
that NT_ASSERTs are not plain evil, but that was already pointed out
by Peter Wieland.

I am still curious why the decision was made at MS to stop ASSERTs
from bluescreening.

Anyway, we probably end up writing our own ASSERTs, and maybe even
ones that are controllable from the registry, so that our test team
can easily run tests with asserts causing BSODs.

Best wishes,
Rafal

On 18 February 2010 01:15, Michal Vodicka wrote:
> Actually, I wanted to say that some OS drivers still use ASSERTs and not
> NT_ASSERTs. In turn they won’t bugcheck on assertion failure without a
> debugger attached which is Really Bad Thing.
>
> NT_ASSERT is different story. IMO it is plain evil. Instead of RtlAssert
> you have no chance to see assertion message so you have to disassemble
> the code and try to guess what is wrong. Sometimes it was also necessary
> with classic asserts but at least there was some hint. Yet another
> “improvement” made without consideration of checked build users outside
> of MS.
>
> Continuing after assertion failure isn’t an unreasonable requirement.
> Assertion failure may not mean fatal problem. My code is usually able to
> fail gracefully after assertions failure and in debug version assert
> just informs me something unexpected happened. I use asserts like this:
>
> if (VERIFY(Pointer != NULL)) {
> // do something useful
> }
> else {
> // return failure
> }
>
> VERIFY(x) expands to x in release version and to something as
> ASSERT(x),x in debug version (not exactly, just want to show principle).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Daniel Strommen
>> Sent: Wednesday, February 17, 2010 9:10 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>>
>> He’s saying, if you’re running a CHK build without a debugger, and an
>> NT_ASSERT happens, it blue screens. ?In your own code, you can define
>> your own ASSERT’s. ?But you can’t stop checked OS drivers from blue
>> screening if they’re using NT_ASSERT.
>>
>> I personally think NT_ASSERT is better for what it was
>> designed to do.
>> But aside from that, if you’re using any kind of ASSERT’s
>> correctly, if
>> an ASSERT happens, something Really Bad is going on, and if execution
>> continues after the assertion failure, all bets are off.
>>
>> Granted, not everyone uses ASSERT’s correctly, and that’s why we have
>> people expecting to continue nonchalantly after an assertion failure.
>>
>> Thanks,
>> Daniel
>>
>> On 2/17/2010 12:14 AM, Rafal Zwierz wrote:
>> > I guess writing our own ASSERTs is what we will have to do :-(.
>> >
>> > Why do you think that for checked version of OS drivers things are
>> > worse? Aren’t they all using NT_ASSERT?
>> >
>> > Thanks,
>> > Rafal
>> >
>> > On 16 February 2010 23:04, Michal
>> Vodicka ?wrote:
>> >
>> >>> -----Original Message-----
>> >>> From: xxxxx@lists.osr.com
>> >>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>> Rafal Zwierz
>> >>> Sent: Tuesday, February 16, 2010 5:02 PM
>> >>> To: Windows System Software Devs Interest List
>> >>> Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is
>> >>>
>> >>> In other words I know that I could write my own asserts or use
>> >>> undocumented NT_ASSERTs, but I wanted to know why
>> documented ASSERTs
>> >>> are not working as they used to and how I would feel that
>> they should.
>> >>>
>> >> It is because MS devs who changed it feel different. They
>> probably can’t
>> >> imagine somebody is running checked build of driver
>> without KD or WinDbg
>> >> connected. Not very smart, IMO. Yet another example how things look
>> >> differently inside and outside of MS.
>> >>
>> >> Well, for you drivers the cure is simple. Just define own
>> assert macro
>> >> which behaves reasonably. For checked version of OS drivers it is
>> >> worse…
>> >>
>> >> Best regards,
>> >>
>> >> Michal Vodicka
>> >> UPEK, Inc.
>> >> [xxxxx@upek.com, http://www.upek.com]
>> >>
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online
>> at http://www.osronline.com/page.cfm?name=ListServer
>> >
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online
>> at http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Michal_Vodicka-2 · February 18, 2010, 4:03pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel
Lebedinsky
Sent: Thursday, February 18, 2010 4:53 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

.exr -1 should also print the message. Let us know if this
doesn’t work
for you on win7.

Thanks, I’ll try it once I get NT_ASSERT.

By the way, the reason why NT_ASSERT is used in many parts of
the kernel (as opposed to RtlAssert) is because it doesn’t perturb
registers and other system state as much, so analyzing
failures is easier.

OK, it seems as a good reason. But why you haven’t changed all ASSERTs
to NT_ASSERTs at Win7? One massive search and replace would make the
job. Current mixed state is messy.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · February 18, 2010, 4:08pm

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rafal Zwierz
Sent: Thursday, February 18, 2010 7:33 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

I am still curious why the decision was made at MS to stop ASSERTs
from bluescreening.

I meant the reason I wrote before seriously

Anyway, we probably end up writing our own ASSERTs, and maybe even
ones that are controllable from the registry, so that our test team
can easily run tests with asserts causing BSODs.

This is what we do. Reading from the registry once when driver is
loaded.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

OSR_Community_User · February 18, 2010, 10:24pm

Devs seem to have a propensity for wrapping asserts. And redefining
them in strange places. Combine that with the fact that Windows is a
huge code base… and even massive sed changes need to be manually
reviewed and tested.

But I think you should start seeing NT_ASSERT much more often and
consistently in the future. I don’t think they would have introduced it
if they didn’t plan to use it more.

Thanks,
Daniel

On 2/18/2010 1:03 PM, Michal Vodicka wrote:

…
OK, it seems as a good reason. But why you haven’t changed all ASSERTs
to NT_ASSERTs at Win7? One massive search and replace would make the
job. Current mixed state is messy.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

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

Michal_Vodicka-2 · February 19, 2010, 3:18pm

Wrapping asserts is 1) silly 2) no problem because everything necessary
is to change the wrapper macro.

I understand huge code base problem but NT_ASSERT has the same syntax
and use as ASSERT so it should be no problem. Personally I don’t quite
understand why they just haven’t changed the definition of ASSERT macro.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Daniel Strommen
Sent: Friday, February 19, 2010 4:24 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ASSERT is not causing a BSOD but NT_ASSERT is

Devs seem to have a propensity for wrapping asserts. And redefining
them in strange places. Combine that with the fact that Windows is a
huge code base… and even massive sed changes need to be manually
reviewed and tested.

But I think you should start seeing NT_ASSERT much more often and
consistently in the future. I don’t think they would have
introduced it
if they didn’t plan to use it more.

Thanks,
Daniel

On 2/18/2010 1:03 PM, Michal Vodicka wrote:
> …
> OK, it seems as a good reason. But why you haven’t changed
all ASSERTs
> to NT_ASSERTs at Win7? One massive search and replace would make the
> job. Current mixed state is messy.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> 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