Problem with DbgPrint for W2K

NTDEV
1

Hi All,

I have a NDIS driver for Windows 2000. It works fine unless any DbgPrint is
present. If I put any DbgPrint, it crashes with Bug check code 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).
Also if I build my driver with checked environment, I experience the same. I
am using the W2K Beta version of the Debug build. Can it be the cause? Can
anyone please clarify?
The configuration is :-
Windows 2000 Professional
Checked/Debug build, Beta 3
Release Candidate 1 (x86), Build 2000

Regards,
Abhijit

2

Hi abhijit,
I faced the similar problem.It’s surprising that the DbgPrints can cause the crash…
and It took me a One full day to determine that.
Ajitabh

-----Original Message-----
From: Abhijit Mirajkar [SMTP:xxxxx@controlnet.co.in]
Sent: Thursday, May 11, 2000 10:09 AM
To: NT Developers Interest List
Subject: [ntdev] Problem with DbgPrint for W2K

Hi All,

I have a NDIS driver for Windows 2000. It works fine unless any DbgPrint is
present. If I put any DbgPrint, it crashes with Bug check code 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).
Also if I build my driver with checked environment, I experience the same. I
am using the W2K Beta version of the Debug build. Can it be the cause? Can
anyone please clarify?
The configuration is :-
Windows 2000 Professional
Checked/Debug build, Beta 3
Release Candidate 1 (x86), Build 2000

Regards,
Abhijit

You are currently subscribed to ntdev as: xxxxx@future.futsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

First question: Is there a reason you’re using RC1?

What you may have is a stack overflow issue.

We’ve seen problems in the 9x world where we had a stack overflow issue that
occurred more frequently in the checked build of the driver. The reason for
this was the DbgPrint’s in the checked build.

Daniel

-----Original Message-----
From: Ajitabh Prakash [mailto:xxxxx@future.futsoft.com]
Sent: Wednesday, May 10, 2000 9:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

Hi abhijit,
I faced the similar problem.It’s surprising that the DbgPrints can
cause the crash…
and It took me a One full day to determine that.
Ajitabh

-----Original Message-----
From: Abhijit Mirajkar [SMTP:xxxxx@controlnet.co.in]
Sent: Thursday, May 11, 2000 10:09 AM
To: NT Developers Interest List
Subject: [ntdev] Problem with DbgPrint for W2K

Hi All,

I have a NDIS driver for Windows 2000. It works fine unless any DbgPrint is
present. If I put any DbgPrint, it crashes with Bug check code 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).
Also if I build my driver with checked environment, I experience the same. I
am using the W2K Beta version of the Debug build. Can it be the cause? Can
anyone please clarify?
The configuration is :-
Windows 2000 Professional
Checked/Debug build, Beta 3
Release Candidate 1 (x86), Build 2000

Regards,
Abhijit

You are currently subscribed to ntdev as: xxxxx@future.futsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

4

The problem, as I understand it, is that the UNICODE<->ANSI traslation
tables are in pageable memory. So if you are doing a DbgPrint that
needs access the tables and you are running at an elevated IRQL, then
you will bugcheck if the translation tables you need are paged out.

-----Original Message-----
From: Ajitabh Prakash [mailto:xxxxx@future.futsoft.com]
Sent: Wednesday, May 10, 2000 9:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

Hi abhijit,
I faced the similar problem.It’s surprising that the DbgPrints
can cause the crash…
and It took me a One full day to determine that.
Ajitabh

-----Original Message-----
From: Abhijit Mirajkar [SMTP:xxxxx@controlnet.co.in]
Sent: Thursday, May 11, 2000 10:09 AM
To: NT Developers Interest List
Subject: [ntdev] Problem with DbgPrint for W2K

Hi All,

I have a NDIS driver for Windows 2000. It works fine unless any DbgPrint
is
present. If I put any DbgPrint, it crashes with Bug check code 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).
Also if I build my driver with checked environment, I experience the
same. I
am using the W2K Beta version of the Debug build. Can it be the cause?
Can
anyone please clarify?
The configuration is :-
Windows 2000 Professional
Checked/Debug build, Beta 3
Release Candidate 1 (x86), Build 2000

Regards,
Abhijit

You are currently subscribed to ntdev as: xxxxx@future.futsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

5

RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an unwritten rule
that DbgPrint() must be running at < DISPATCH_LEVEL? Is this something that
you only have to worry about when you have a WCHAR in the DbgPrint()
statement?

Alan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nathan Nesbit
Sent: Thursday, May 11, 2000 11:47 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

The problem, as I understand it, is that the UNICODE<->ANSI traslation
tables are in pageable memory. So if you are doing a DbgPrint that needs
access the tables and you are running at an elevated IRQL, then you will
bugcheck if the translation tables you need are paged out.

-----Original Message-----
From: Ajitabh Prakash [mailto:xxxxx@future.futsoft.com]
Sent: Wednesday, May 10, 2000 9:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

Hi abhijit,
I faced the similar problem.It’s surprising that the DbgPrints can
cause the crash…
and It took me a One full day to determine that.
Ajitabh

-----Original Message-----
From: Abhijit Mirajkar [SMTP:xxxxx@controlnet.co.in]
Sent: Thursday, May 11, 2000 10:09 AM
To: NT Developers Interest List
Subject: [ntdev] Problem with DbgPrint for W2K

Hi All,

I have a NDIS driver for Windows 2000. It works fine unless any DbgPrint
is
present. If I put any DbgPrint, it crashes with Bug check code 0x50
(PAGE_FAULT_IN_NONPAGED_AREA).
Also if I build my driver with checked environment, I experience the same.
I
am using the W2K Beta version of the Debug build. Can it be the cause? Can
anyone please clarify?
The configuration is :-
Windows 2000 Professional
Checked/Debug build, Beta 3
Release Candidate 1 (x86), Build 2000

Regards,
Abhijit

You are currently subscribed to ntdev as: xxxxx@future.futsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

6

DpgPrint() as any other function cannot touch pageable memory when running
on DISPATCH_LEVEL and above. Unfortunately, wide character formating (i.e.
%ws, %wZ…) has a side effect which Nathan described. I think it isn’t
documented but checked build informs you about it (via assert) immediatelly.
Free build crashes only when translation tables are paged out which can
occur randomly.

Best regards,

Michal Vodicka
RKK Informationssysteme s.r.o.
:We support your Future
[WWW: http://www.rkk.cz , http://www.skytale.com]

From: Alan L. Taylor[SMTP:xxxxx@clariion.com]
Reply To: NT Developers Interest List
Sent: Thursday, May 11, 2000 7:35 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

So is there an unwritten rule that DbgPrint() must be running at <
DISPATCH_LEVEL?? Is this something that you only have to worry about when
you have a WCHAR in the DbgPrint() statement??
?
Alan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nathan Nesbit
Sent: Thursday, May 11, 2000 11:47 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

The problem, as I understand it, is that the UNICODE<->ANSI
traslation tables are in pageable memory.? So if you are doing a DbgPrint
that needs access the tables and you are running at an elevated IRQL, then
you will bugcheck if the translation tables you need are paged out.

7

From: “Alan L. Taylor”
Sent: Thursday, May 11, 2000 1:35 PM

> RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an unwritten rule
> that DbgPrint() must be running at < DISPATCH_LEVEL?

Not entirely “unwritten”. The DDK documentation for KdPrint() says:

“The Format string supports the printf-style formatting codes. However,
the unicode format codes (%wc and %ws) can only be used at IRQL
PASSIVE_LEVEL.”

Anyone familiar with DDK programming of course knows that KdPrint() is
simply a pre-processor alias for DbgPrint().

So, while the DDK docs for DbgPrint() for some reason do not have the same
PASSIVE_LEVEL comment as those for KdPrint(), we must assume that the
comment “really” applies to DbgPrint().

> Is this something that
> you only have to worry about when you have a WCHAR in the DbgPrint()
> statement?

AFAIK, basically yes.

- Matt

8

While I suppose it is in fact semi-documented, this has got to be considered
a rather colossal bug. How much nonpaged pool is being saved here? 1 page?
2?

From: “Alan L. Taylor”
> Sent: Thursday, May 11, 2000 1:35 PM
>
>
> > RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an
> unwritten rule
> > that DbgPrint() must be running at < DISPATCH_LEVEL?
>
> Not entirely “unwritten”. The DDK documentation for KdPrint() says:
>
> “The Format string supports the printf-style formatting
> codes. However,
> the unicode format codes (%wc and %ws) can only be used at IRQL
> PASSIVE_LEVEL.”
>
> Anyone familiar with DDK programming of course knows that KdPrint() is
> simply a pre-processor alias for DbgPrint().
>
> So, while the DDK docs for DbgPrint() for some reason do not
> have the same
> PASSIVE_LEVEL comment as those for KdPrint(), we must assume that the
> comment “really” applies to DbgPrint().
>
> > Is this something that
> > you only have to worry about when you have a WCHAR in the DbgPrint()
> > statement?
>
> AFAIK, basically yes.
>

9

Good point Mark. This is probably left over from the days of a 64MB memory
being defined in the kernel as a “large memory system”. ha !

Or it could be just an oversight made by an overly frugal kernel engineer.

Either way, it sucks…

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 11, 2000 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

While I suppose it is in fact semi-documented, this has got to be considered
a rather colossal bug. How much nonpaged pool is being saved here? 1 page?
2?

From: “Alan L. Taylor”
> Sent: Thursday, May 11, 2000 1:35 PM
>
>
> > RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an
> unwritten rule
> > that DbgPrint() must be running at < DISPATCH_LEVEL?
>
> Not entirely “unwritten”. The DDK documentation for KdPrint() says:

10

This disadvantage is because of this:

OSLOADER (part of NTLDR) loads proper nls files (l_intl.nls + c_xxxx.nls)
to loader block. Then passes pointer to loader block to the NTOSKRNL’s
main function. Kernel first initializes NlsXxxx variables to point to the
loader block - which is nonpageable. After memory manager initialization
the unnamed section is created, intialized from loader block and some views
are mapped into system cache memory space. These views are in turn
pageable and can be swapped out (and some are). Some NlsXxxx variables
are reinitialized at this time to new values. All drivers are initialized
after this so it is possible for some critical nls pages to be outswapped.
If such a page is touched by some Rtl conversion routine at raised IRQL
all of you can imagine what will be the result.

Paul

-----P?vodn? zpr?va-----
Od: Paul Bunn [SMTP:xxxxx@ultrabac.com]
Odesl?no: 11. kv?tna 2000 22:28
Komu: NT Developers Interest List
P?edm?t: [ntdev] RE: Problem with DbgPrint for W2K

Good point Mark. This is probably left over from the days of a 64MB
memory
being defined in the kernel as a “large memory system”. ha !

Or it could be just an oversight made by an overly frugal kernel engineer.

Either way, it sucks…

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 11, 2000 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

While I suppose it is in fact semi-documented, this has got to be
considered
a rather colossal bug. How much nonpaged pool is being saved here? 1 page?
2?

>
> From: “Alan L. Taylor”
> > Sent: Thursday, May 11, 2000 1:35 PM
> >
> >
> > > RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an
> > unwritten rule
> > > that DbgPrint() must be running at < DISPATCH_LEVEL?
> >
> > Not entirely “unwritten”. The DDK documentation for KdPrint() says:
>
> —
> You are currently subscribed to ntdev as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

11

RE: [ntdev] RE: Problem with DbgPrint for W2K>So is there an unwritten rule
that DbgPrint() must be running at <

DISPATCH_LEVEL? Is this something that you only have to worry about
when you have a WCHAR in the DbgPrint() statement?

AFAIK only if you have a Unicode format specifier (%wZ or %zW - I’ve
forgotten) in DbgPrint.
Without it, DbgPrint works fine even in ISRs.

Max

12

> While I suppose it is in fact semi-documented, this has got to be
considered

a rather colossal bug. How much nonpaged pool is being saved here? 1 page?
2?

More :slight_smile: UNICODE.NLS on my machine (NT4/SP6) is about 87KB in size.
And this is not the only NLS table.

Max

13

This disadvantage is because of this:

OSLOADER (part of NTLDR) loads proper nls files (l_intl.nls + c_xxxx.nls)
to loader block. Then passes pointer to loader block to the NTOSKRNL’s
main function. Kernel first initializes NlsXxxx variables to point to the
loader block - which is nonpageable. After memory manager initialization
the unnamed section is created, intialized from loader block and some views
are mapped into system cache memory space. These views are in turn
pageable and can be swapped out (and some are). Some NlsXxxx variables
are reinitialized at this time to new values. All drivers are initialized
after this so it is possible for some critical nls pages to be outswapped.
If such a page is touched by some Rtl conversion routine at raised IRQL
all of you can imagine what will be the result.

Paul

-----P?vodn? zpr?va-----
Od: Paul Bunn [SMTP:xxxxx@ultrabac.com]
Odesl?no: 11. kv?tna 2000 22:28
Komu: NT Developers Interest List
P?edm?t: [ntdev] RE: Problem with DbgPrint for W2K

Good point Mark. This is probably left over from the days of a 64MB
memory
being defined in the kernel as a “large memory system”. ha !

Or it could be just an oversight made by an overly frugal kernel engineer.

Either way, it sucks…

Regards,

Paul Bunn, UltraBac.com, 425-644-6000
Microsoft MVP - WindowsNT/2000
http://www.ultrabac.com

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, May 11, 2000 1:20 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with DbgPrint for W2K

While I suppose it is in fact semi-documented, this has got to be
considered
a rather colossal bug. How much nonpaged pool is being saved here? 1 page?
2?

>
> From: “Alan L. Taylor”
> > Sent: Thursday, May 11, 2000 1:35 PM
> >
> >
> > > RE: [ntdev] RE: Problem with DbgPrint for W2KSo is there an
> > unwritten rule
> > > that DbgPrint() must be running at < DISPATCH_LEVEL?
> >
> > Not entirely “unwritten”. The DDK documentation for KdPrint() says:
>
> —
> You are currently subscribed to ntdev as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)