How to get ASSERTs to work?

Yang_Zhang · November 9, 2009, 11:38am

Very newbie question here: how do I get ASSERT()'s to work? I tried
the following:

DRIVER_INITIALIZE DriverEntry;
NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT driverObject,
IN PUNICODE_STRING registryPath
)
{
NTSTATUS status = STATUS_SUCCESS;
ASSERT(FALSE); // XXX
...

I build my driver using the Checked Build Environment, but loading my
driver doesn't cause a crash.

Several questions:

From my readings, it seems that checked vs free builds don't have
anything to do with the ASSERTs in my code, and that they only enable
ASSERTs in the system code. Is this correct?
Tangential: how do I determine whether I'm running a checked build?
According to the docs
(Microsoft Learn: Build skills that open doors in your career), "If debugging
is not enabled (and therefore a debugger is not attached) when an
assert fails, the system will crash." Hence, my system should be
crashing. Is this correct?
How do I get my failed ASSERTs to do crash the system? (I know I can
redefine ASSERT to write to NULL or some such, but I'm still
interested in the answer.)

Thanks!

Yang Zhang

OSR_Community_User · November 9, 2009, 11:46am

What OS are you testing on? Is your driver getting loaded?
Use windbg to debug your driver.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Yang Zhang
Sent: Monday, November 09, 2009 11:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to get ASSERTs to work?

Very newbie question here: how do I get ASSERT()'s to work? I tried the
following:

DRIVER_INITIALIZE DriverEntry;
NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT driverObject,
IN PUNICODE_STRING registryPath
)
{
NTSTATUS status = STATUS_SUCCESS;
ASSERT(FALSE); // XXX
...

I build my driver using the Checked Build Environment, but loading my driver
doesn't cause a crash.

Several questions:

From my readings, it seems that checked vs free builds don't have anything
to do with the ASSERTs in my code, and that they only enable ASSERTs in the
system code. Is this correct?
Tangential: how do I determine whether I'm running a checked build?
According to the docs
(Microsoft Learn: Build skills that open doors in your career), "If debugging is
not enabled (and therefore a debugger is not attached) when an assert fails,
the system will crash." Hence, my system should be crashing. Is this
correct?
How do I get my failed ASSERTs to do crash the system? (I know I can
redefine ASSERT to write to NULL or some such, but I'm still interested in
the answer.)

Thanks!

Yang Zhang

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:

To unsubscribe, visit the List Server section of OSR Online at

Yang_Zhang · November 9, 2009, 12:08pm

On Mon, Nov 9, 2009 at 8:55 AM, Yang Zhang wrote:
> On Mon, Nov 9, 2009 at 8:45 AM, Bill Wandel wrote:
>> What OS are you testing on? Is your driver getting loaded?
>> Use windbg to debug your driver.
>
> Windows 7.
>
> My driver gets loaded fine.
>
> I do use windbg to debug, post-mortem. I have a bug that I can’t
> reproduce in a VM, so I’m running on real hardware (to which I can’t
> hook up a live debugger).
>
> Updates: I tried redefining ASSERT to write to NULL (and removing that
> dummy ASSERT from my DriverEntry), and now the machine crashes, but (I
> think) much too early. And now the resulting memory.dmp has a most
> unhelpful stack trace:
>
> nt!KeBugCheckEx+0x1e
> nt!PsCreateSystemThread+0x1da
> nt!wcsupr+0x13a

I forgot to set the sympath to use the global symbol server; once I do
that, the stack trace becomes:

nt!KeBugCheckEx+0x1e
nt!PspSystemThreadStartup+0xde
nt!KiThreadStartup+0x19

Which is still not helpful.
–
Yang Zhang
http://www.mit.edu/~y_z/

Yang_Zhang · November 9, 2009, 12:19pm

Sorry, disregard everything I said about bad frames. For some reason I
wasn’t running the .sys I thought I was. My original questions still
stand.

On Mon, Nov 9, 2009 at 9:00 AM, Yang Zhang wrote:
> On Mon, Nov 9, 2009 at 8:55 AM, Yang Zhang wrote:
>> On Mon, Nov 9, 2009 at 8:45 AM, Bill Wandel wrote:
>>> What OS are you testing on? Is your driver getting loaded?
>>> Use windbg to debug your driver.
>>
>> Windows 7.
>>
>> My driver gets loaded fine.
>>
>> I do use windbg to debug, post-mortem. I have a bug that I can’t
>> reproduce in a VM, so I’m running on real hardware (to which I can’t
>> hook up a live debugger).
>>
>> Updates: I tried redefining ASSERT to write to NULL (and removing that
>> dummy ASSERT from my DriverEntry), and now the machine crashes, but (I
>> think) much too early. And now the resulting memory.dmp has a most
>> unhelpful stack trace:
>>
>> nt!KeBugCheckEx+0x1e
>> nt!PsCreateSystemThread+0x1da
>> nt!wcsupr+0x13a
>
> I forgot to set the sympath to use the global symbol server; once I do
> that, the stack trace becomes:
>
> nt!KeBugCheckEx+0x1e
> nt!PspSystemThreadStartup+0xde
> nt!KiThreadStartup+0x19
>
> Which is still not helpful.
> –
> Yang Zhang
> http://www.mit.edu/~y_z/
>

–
Yang Zhang
http://www.mit.edu/~y_z/

Prokash_Sinha-1 · November 9, 2009, 12:55pm

Yes ASSERT is noop in free build.

I would check two things —

The build is indeed checked build. That means the binary you are
trying to load is indeed built with checked environment.
How it is being installed and being tried to load. ( So make sure you
are placing or installing the right binary). And make sure it has been
loaded without a crash, in case of a right build been installed.

Finally, as always the silver bullet is to hook a debugger.

-pro

Yang Zhang wrote:

Very newbie question here: how do I get ASSERT()'s to work? I tried
the following:

DRIVER_INITIALIZE DriverEntry;
NTSTATUS
DriverEntry(
IN PDRIVER_OBJECT driverObject,
IN PUNICODE_STRING registryPath
)
{
NTSTATUS status = STATUS_SUCCESS;
ASSERT(FALSE); // XXX
…

I build my driver using the Checked Build Environment, but loading my
driver doesn’t cause a crash.

Several questions:

From my readings, it seems that checked vs free builds don’t have
anything to do with the ASSERTs in my code, and that they only enable
ASSERTs in the system code. Is this correct?

Tangential: how do I determine whether I’m running a checked build?

According to the docs
(http://msdn.microsoft.com/en-us/library/ms792434.aspx), “If debugging
is not enabled (and therefore a debugger is not attached) when an
assert fails, the system will crash.” Hence, my system should be
crashing. Is this correct?

How do I get my failed ASSERTs to do crash the system? (I know I can
redefine ASSERT to write to NULL or some such, but I’m still
interested in the answer.)

Thanks!

Yang Zhang
http://www.mit.edu/~y_z/

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

Yang_Zhang · November 9, 2009, 1:11pm

On Mon, Nov 9, 2009 at 8:54 AM, Prokash Sinha wrote:
> Yes ASSERT is noop in free build.
>
> I would check two things —
>
> 1) The build is indeed checked build. That means the binary you are trying
> to load is indeed built with checked environment.

I’m making checked builds of my driver. I verified that the DBG macro
was being defined and that the ASSERT macros were generating the
appropriate condition-checking code.

>
> 2) How it is being installed and being tried to load. ( So make sure you are
> placing or installing the right binary). And make sure it has been loaded
> without a crash, in case of a right build been installed.

I load it using OSRLoader. It loads without crashing. It works fine up
until the point where my bug causes the program to crash (because I
dereference a null pointer).

>
> Finally, as always the silver bullet is to hook a debugger.

I can only use a debugger with my VM (Virtual PC), where ASSERTs
trigger a break, but the bug never shows up there.
–
Yang Zhang
http://www.mit.edu/~y_z/

Daniel_Terhell · November 9, 2009, 1:14pm

The system will bug check if the assertion fails, your driver is a checked
build and the system is booted without the /DEBUG flag. Just not having a
debugger attached is not enough.

Check out the following thread:
http://www.osronline.com/showThread.cfm?link=153733

To find out if you are running the checked build you can use the DBG
conditional preprocessor constant.

//Daniel

Prokash_Sinha-1 · November 9, 2009, 1:23pm

So when it breaks to the debugger, what do you get there? What are you
expecting?. If you hit F5, type go in command line, what should you
expect?.

The debugger is trapping the exception to give you a chance to look thru
what went wrong. If you let it go, it should bug check, and a dump file
should be created.

For your driver binary, you should also have the corresponding pdb file.
In the windbg help you will find how to set the path to point to the pdb
file, so that you can see where it is breaking (at src level).

-pro
Yang Zhang wrote:

On Mon, Nov 9, 2009 at 8:54 AM, Prokash Sinha wrote:
>
>> Yes ASSERT is noop in free build.
>>
>> I would check two things —
>>
>> 1) The build is indeed checked build. That means the binary you are trying
>> to load is indeed built with checked environment.
>>
>
> I’m making checked builds of my driver. I verified that the DBG macro
> was being defined and that the ASSERT macros were generating the
> appropriate condition-checking code.
>
>
>> 2) How it is being installed and being tried to load. ( So make sure you are
>> placing or installing the right binary). And make sure it has been loaded
>> without a crash, in case of a right build been installed.
>>
>
> I load it using OSRLoader. It loads without crashing. It works fine up
> until the point where my bug causes the program to crash (because I
> dereference a null pointer).
>
>
>> Finally, as always the silver bullet is to hook a debugger.
>>
>
> I can only use a debugger with my VM (Virtual PC), where ASSERTs
> trigger a break, but the bug never shows up there.
>

Yang_Zhang · November 9, 2009, 1:43pm

On Mon, Nov 9, 2009 at 8:45 AM, Bill Wandel wrote:
> What OS are you testing on? Is your driver getting loaded?
> Use windbg to debug your driver.

Windows 7.

My driver gets loaded fine.

I do use windbg to debug, post-mortem. I have a bug that I can’t
reproduce in a VM, so I’m running on real hardware (to which I can’t
hook up a live debugger).

Updates: I tried redefining ASSERT to write to NULL (and removing that
dummy ASSERT from my DriverEntry), and now the machine crashes, but (I
think) much too early. And now the resulting memory.dmp has a most
unhelpful stack trace:

nt!KeBugCheckEx+0x1e
nt!PsCreateSystemThread+0x1da
nt!wcsupr+0x13a

Before, I could at least see a dozen or so frames, my driver included
therein. I never call wcsupr, and I redefined the ASSERT after all my
includes. What’s going on?

(It says “WARNING: Stack unwind information not available.” but it
always says that.)
–
Yang Zhang
http://www.mit.edu/~y_z/

Prokash_Sinha-1 · November 9, 2009, 1:54pm

Before getting to the details ----

Best thing is to set a break point in your code that tries to write
to a null pointer. Once you hit that point ( i.e. breaks in to that
code), you can do few things. You can bring up even disassemled code
window and set break points at the assembly level.
memory.dmp might be only mini dump, so you need to configure for a
full dump. Look at the debug help to find how to configure for full
dump. Search the internet too.
The stack you showed here is coming from the Bugcheck handling by the
Windows 7 kernel. If you have a full dump, you will surely have more
stack frames to see that your driver indeed triggered the Bugcheck process.

-pro

Yang Zhang wrote:

On Mon, Nov 9, 2009 at 8:45 AM, Bill Wandel wrote:
>
>> What OS are you testing on? Is your driver getting loaded?
>> Use windbg to debug your driver.
>>
>
> Windows 7.
>
> My driver gets loaded fine.
>
> I do use windbg to debug, post-mortem. I have a bug that I can’t
> reproduce in a VM, so I’m running on real hardware (to which I can’t
> hook up a live debugger).
>
> Updates: I tried redefining ASSERT to write to NULL (and removing that
> dummy ASSERT from my DriverEntry), and now the machine crashes, but (I
> think) much too early. And now the resulting memory.dmp has a most
> unhelpful stack trace:
>
> nt!KeBugCheckEx+0x1e
> nt!PsCreateSystemThread+0x1da
> nt!wcsupr+0x13a
>
> Before, I could at least see a dozen or so frames, my driver included
> therein. I never call wcsupr, and I redefined the ASSERT after all my
> includes. What’s going on?
>
> (It says “WARNING: Stack unwind information not available.” but it
> always says that.)
>

OSR_Community_User · November 9, 2009, 2:05pm

You’d probably be much better off if you could establish a kd session; if it’s not working in a vm, then you would be well served to acquire a second machine, if at all possible. You can use almost anything for the host; it really doesn’t matter how old it is, so long as it supports one of the kd transports.
If you stay with using a crash dump, you’ll probably need to create something more substantial than a minidump. A minidump might not have enough information in it.
Either way, posting your code wouldn’t hurt.
I understand that you’re trying to figure out what’s going on, but for what it is worth, I think it would be a good idea to stop redefining ASSERT or anything else until you get it working. It should not necessary be necessary redefine ASSERT to get the behavior you seek, and if you want to experiment, just use the API’s directly, or define your own MY_ASSERT() or whatever.
To that end, you might want to take a look in wdm.h:

NTSYSAPI
VOID
NTAPI
RtlAssert(
__in PVOID VoidFailedAssertion,
__in PVOID VoidFileName,
__in ULONG LineNumber,
__in_opt PSTR MutableMessage
);

#define ASSERT( exp ) \
((!(exp)) ? \
(RtlAssert( #exp, FILE, LINE, NULL ),FALSE) : \
TRUE)

#define NT_ASSERT(_exp) \
((!(_exp)) ? \
(__annotation(L"Debug", L"AssertFail", L#_exp), \
DbgRaiseAssertionFailure(), FALSE) : \
TRUE)

If all else fails, you could insert a __debugbreak() in your code, just to see if the trace your getting is what you expect.

Good luck,

mm

Yang_Zhang · November 10, 2009, 11:12pm

On Mon, Nov 9, 2009 at 10:13 AM, Daniel Terhell wrote:
> The system will bug check if the assertion fails, your driver is a checked
> build and the system is booted without the /DEBUG flag. Just not having a
> debugger attached is not enough.

Does this imply that the system will not bug check if booted with
the /DEBUG flag? Because I believe I’ve been booting with /DEBUG.

BTW, I know that you can use bcdedit to set whether the system is
booted with /debug, but is there a way to just show it?
–
Yang Zhang
http://www.mit.edu/~y_z/

Daniel_Terhell · November 11, 2009, 5:18am

“Yang Zhang” wrote in message news:xxxxx@ntdev…
> Does this imply that the system will not bug check if booted with
> the /DEBUG flag? Because I believe I’ve been booting with /DEBUG.
>

Yes.

> BTW, I know that you can use bcdedit to set whether the system is
> booted with /debug, but is there a way to just show it?
> –

Use KD_DEBUGGER_ENABLED to see if the system is booted with the debug flag.
KD_DEBUGGER_NOT_PRESENT to see if a debugger is not attached. Check out the
WDK for more info. These variables in combination with the DBG constant will
allow you to write your own assert macros that do exactly what you want in
any combination of these circumstances.

//Daniel

OSR_Community_User · November 11, 2009, 6:32am

You can look at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control:SystemStartOptions

Good luck,

mm