Ah. I’ve never worked with miniports, so didn’t know that they had assorted
limitations.
The obvious first thing is to see if the system leaks without your miniport.
It is quite possible that some other dirver may be leaking the entries.
If you do decide your driver is involved (which seems likely, since XP
normally will run more than days without crashing from lack of PTEs), then
obviously something you are doing or not doing is involved.
Since this has been running fine for a long time on other (I assume older)
OS versions, the most likely case is that you have had a subtile bug all
along, but up till this point something in the NT code was managing to
compensate for that. The second most likely case is that they have added
some new requirement to the interface that used to be optional, or maybe
just some new requirement that isn’t backwards compatable.
Now, I say those possibilities not to be mean, but simply because those are
the cases I’ve seen most often when something stops working. NT
documentation is typically less than wonderful about spelling out all of
EVERYTHING that really should be done in every occasion, so it is really
easy to do something wrong in the driver if you can’t walk down the hall to
the author of the subsystem and ask him how it REALLY works.
I would consider turning on pool tagging and set up the debugger to catch
the crash when you run out of ptes. Then hunt around and see what kind of
zillion identical pool tags you have. This will give you at least a good
hint of what kind of memory is leaking. From that, *carefully* perusing the
*latest* documentation (not the version you used to write the driver!) and
asking questions about the pool tags here, there is a good chance you can
nail down what is leaking.
A good bet would be something on the order of some SRB field wasn’t zeroed
when you created it (assuming you create stuff like that) and it is causing
the underlying stuff to allocate something and then expects you to do some
call you aren’t doing to delete it at completion. Alternately, something
changed in the interface, and you are now expected to delete something that
has been allocated on your behalf. Pool tags shoudl help.
Loren
----- Original Message -----
From: “Gurpreet Anand”
To: “Windows System Software Devs Interest List”
Sent: Sunday, September 18, 2005 1:18 AM
Subject: Re: [ntdev] Ref: WinXP SP2 PTEs issue
> Loren,
>
> Do correct me if I am wrong over here.
> SCSI Miniport drivers don’t even know what MDLs are or
> can set any completion routines. SCSI Miniport drivers
> don’t allocate memory during IOs but just build
> SGList. They can only allocate noncached memory once
> during initialization.
> My question is how or in which conditions a miniport
> driver can leak PTEs. That might help me pinpoint the
> cause of this issue.
>
>
> — Loren Wilton wrote:
>
> > Map an MDL into system space to do your IO. Don’t
> > unmap it.
> > Allocate space for a lookaside list entry. Forget
> > about it.
> > Allocate a local buffer for your IO. Don’t
> > unallocate in a completion
> > routine.
> > I could go on and on.
> >
> > In general if you are leaking PTEs, there is no
> > reason at all to believe
> > that they will suddenly recover at some later time,
> > unless you are logging
> > into system PTEs and you will eventually free up the
> > log under some
> > conditions or other.
> >
> > Now, the first thing I would do is take out the
> > miniport driver and see if
> > the system is still leaking PTEs. Or you could try
> > to relate the frequency
> > at which they disappear to your IO rate or some
> > such.
> >
> > Unfortunately this usually boils down to a code
> > inspection issue.
> >
> > Loren
> >
> > ----- Original Message -----
> > From: “Gurpreet Anand”
> > To: “Windows System Software Devs Interest List”
> >
> > Sent: Saturday, September 17, 2005 12:09 PM
> > Subject: RE: [ntdev] Ref: WinXP SP2 PTEs issue
> >
> >
> > > Well, the same driver code works for other OS W2K3
> > and
> > > even WinXP Sp1. It is not a new driver and is been
> > > there in the field for some time now.
> > > I have to verify the other thing if it gives
> > problem
> > > if my miniport driver is not running on the
> > system.
> > > I am just wondering what in miniport
> > > driver can cause PTEs to never recover after the
> > IOs
> > > are stopped.
> > >
> > > — Mark Roddy wrote:
> > >
> > > > So if your miniport driver is not running on
> > this
> > > > system do you still run
> > > > out of PTEs?
> > > >
> > > > In general the rule is that if you install your
> > new,
> > > > and therefore crappy,
> > > > driver, and the system behaves badly, it is your
> > > > new, and therefore crappy,
> > > > driver that is the cause of the problem.
> > > >
> > > > =====================
> > > > Mark Roddy DDK MVP
> > > > Windows 2003/XP/2000 Consulting
> > > > Hollis Technology Solutions 603-321-1032
> > > > www.hollistech.com
> > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com] On
> > > > Behalf Of Gurpreet Anand
> > > > > Sent: Friday, September 16, 2005 8:30 PM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: [ntdev] Ref: WinXP SP2 PTEs issue
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I am experiencing some issues with IOs running
> > on
> > > > Windows XP.
> > > > > I have seen PTEs falling down as the IOs
> > > > progressed and never
> > > > > recovered back even if I stop the IOs.
> > > > > Even so if the IOs keeps on running, system
> > gives
> > > > an error
> > > > > that it ran out of PTEs.
> > > > > I have only my miniport driver running on this
> > > > system and I
> > > > > am not able to understand who is not freeing
> > these
> > > > PTEs.
> > > > > Has any one faced this issue on Windows XP?
> > > > >
> > > > > Any help is appreciated.
> > > > >
> > > > > Thanks,
> > > > > Gurpreet
> > > > > PS: I dont see this issue with Windows XP SP1.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yahoo! Mail - PC Magazine Editors’ Choice 2005
> > > > http://mail.yahoo.com
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ
> > at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > > > > xxxxx@hollistech.com To unsubscribe send a
> > blank
> > > > email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > > xxxxx@yahoo.com
> > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>____________________
> > > Yahoo! for Good
> > > Donate to the Hurricane Katrina relief effort.
> > > http://store.yahoo.com/redcross-donate3/
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > xxxxx@earthlink.net
> > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@yahoo.com
> > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@earthlink.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com