Hi all,
I need to allocate Non-paged pool in my storport miniport driver - Windows
Server 2003 SP2. As per the MSDN documentation
http://msdn.microsoft.com/en-us/library/ms803218.aspx , I’m trying to use
storport provided APIs instead of OS APIs.
The MSDN doc for StorPortAllocatePool (
http://msdn.microsoft.com/en-us/library/aa907228.aspx) says this API will
give back, *“In Windows Vista, a pointer to the address of the allocated
memory block. In earlier versions of Windows, this parameter is a pointer to
a memory descriptor list (MDL).”*
As per the doc, I cannot use MmGetSystemAddressForMdlSafe API to convert
this MDL to Virtual memory, for my storport miniport driver 
Does it mean that, in Windows Server 2003 SP2 - I cannot allocate Non-paged
pool memory at all? Is there any documented way to allocate (non-paged)
memory in Windows Server 2003 SP2 storport miniport drivers? Why there is a
different behavior of same API across Windows OS versions?
Regards,
T.V.Gokul.
Wow, that is pretty crappy isn’t it? Seeing as how there are several
interfaces defined that provide (!PVOID!) ‘mdl pointers’, the lack of
access to the standard mdl support routines is a bit on the broken
side.
Generally I add a separate compilation unit that provides the missing apis.
So far, WHQL has not clamped down on storport drivers that color
outside the lines.
Mark Roddy
On Tue, Jun 2, 2009 at 8:45 AM, Gokul TV wrote:
> Hi all,
>
> I need to allocate Non-paged pool in my storport miniport driver - Windows
> Server 2003 SP2. As per the MSDN documentation
> http://msdn.microsoft.com/en-us/library/ms803218.aspx , I’m trying to use
> storport provided APIs instead of OS APIs.
>
> The MSDN doc for StorPortAllocatePool
> (http://msdn.microsoft.com/en-us/library/aa907228.aspx) says this API will
> give back, “In Windows?Vista, a pointer to the address of the allocated
> memory block. In earlier versions of Windows, this parameter is a pointer to
> a memory descriptor list (MDL).”
>
> As per the doc, I cannot use MmGetSystemAddressForMdlSafe API to convert
> this MDL to Virtual memory, for my storport miniport driver
>
> Does it mean that, in Windows Server 2003 SP2 - I cannot allocate Non-paged
> pool memory at all? Is there any documented way to allocate (non-paged)
> memory in Windows Server 2003 SP2 storport miniport drivers? Why there is a
> different behavior of same API across Windows OS versions?
>
> Regards,
> T.V.Gokul.
> — 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
Hi Mark,
YES! Absoultely its crappy. I felt I’ve been stopped because of this. Its
nice to hear that WHQL stopping miniport drivers that uses OS provided APIs.
Let me follow the same idea having a separate file/compilation unit
providing missing APIs. If MSFT updates/fixes its APIs or documentation,
then I’ll relook into it.
Thanks for your reply.
Regards,
T.V.Gokul.
Sorry for my typos… I like to say its nice to hear that WHQL is not
stopping storport miniport drivers that uses OS provided APIs
Regards,
T.V.Gokul.
On Wed, Jun 3, 2009 at 9:25 AM, Gokul TV wrote:
> Hi Mark,
>
> YES! Absoultely its crappy. I felt I’ve been stopped because of this. Its
> nice to hear that WHQL stopping miniport drivers that uses OS provided APIs.
>
> Let me follow the same idea having a separate file/compilation unit
> providing missing APIs. If MSFT updates/fixes its APIs or documentation,
> then I’ll relook into it.
>
> Thanks for your reply.
>
> Regards,
> T.V.Gokul.
>
>
T.V.,
I believe that what you’ve encountered is a doc error. We’re looking into it. For now, I believe you should proceed with your development/testing using the assumption that StorPortAllocatePool works the same way on all OSes starting with its introduction on Windows Server 2003 SP2; specifically, that the buffer address is returned, not an MDL. If I’m wrong about it, it’ll be evident as soon as you start testing. 
I’ll follow up to this posting once we’ve gotten to the bottom of the issue.
Thanks.
– Keith
Apart from the document, the StorPortAllocatePool’s function header in
storport.h also confused me! Even it says the StorPortAllocatePool
returns MDL!
typedef
PVOID
(*PStorPortAllocatePool)(
IN ULONG NumberOfBytes,
IN ULONG Tag,
IN PVOID HwDeviceExtension,
IN OUT PVOID *PMdl
);
Thanks Keith for the clarification. I’ll start my dev/testing process
in Windows Server 2003 SP2, by mid of this week. If this assumption
breaks, I’ll let you know. Meanwhile, keep us posted regarding the
storport doc changes.
Regards,
T.V.Gokul.
What header file did you get that out of? If that’s in a WDK, which version?
– Keith
I’m using the WDK 6001.18002 (RTM version). And the header file is
storport.h @ <ddk_dir>\inc\ddk\storport.h (In my case it is,
D:\WinDDK\6001.18002\inc\ddk\storport.h)
Regards,
T.V.Gokul.</ddk_dir>
Hi Keith,
I got a chance to verify StorPortAllocatePool in Windows Server 2003
SP2 (with KB943295) and YES, it returns memory pool address only!
The one other observation is, it is failing with
STOR_STATUS_INVALID_IRQL in HwStorFindAdapter. I hope this is because
it is called at DIRQL level!
Regards,
T.V.Gokul.
T.V.,
First, regarding the header file, now I understand the confusion. That old interface for retrieving the “extended function table” should not be used, and that’s what that old PStorPortAllocatePool function prototype was part of. Historically, the old interface that uses an actual function table was a pre-release implementation of the Storport extended function mechanism, supplanted by the macro/direct-call interface that’s there today. That pre-release mechanism was never intended for use by shipping miniports, and I believe it’s continued existence in storport.h was intended to be temporary, giving early adopters of that old interface a small grace period for switching over to the released version of the interface. It looks like we weren’t thorough enough about resolving the confusion and removing the old interface.
Second, HwStorFindAdapter isn’t called by Storport at DIRQL. So if your miniport is elevating to DIRQL before calling StorPortAllocatePool, then yes, that would explain the problem.
– Keith
T.V,
I just looked at C:\WinDDK\6001.18002\inc\ddk\storport.h. Yes, an API based on *PStorPortAllocatePool appears there. But that’s not what you would be using when you call StorPortAllocatePool. Look for the declaration of StorPortAllocatePool and you’ll see that it’s an inlined function that calls an extended function and, most importantly, that the API returns a PVOID as the fourth parameter and not an MDL pointer.
Maybe all this is clear and obvious now. But I want to make sure nobody is thrown by the presence of *PStorPortAllocatePool; that’s irrelevant. And, of course, the WDK doc needs some rewording.
Thanks Keith and James for clearing this doubt. Now I feel its much more
easy to proceed with my storport miniport design.
One other thing that is not much clear is, using
Message-Signalled-Interruputs-X in storport miniport drivers in Windows
Server 2003 SP2.
For general WDM drivers to use MSI/MSI-X, they need to link with
“iointex.lib” and add appropriate fields in inf file.
How about for storport miniport drivers? Shall we assume that storport for
Windows Server 2003 SP2 supports MSI/MSI-X and adding appropriate fields in
miniport inf (as per
http://msdn.microsoft.com/en-us/library/bb961247.aspx), will enable
Windows to support MSI/MSI-X interrupts of the hardware?
Regards,
T.V.Gokul.
I don’t have details as to what amount of MSI support existed in Windows Server 2003 SP2. I’ll have to defer to WDK support on that one. However, I wouldn’t assume that it’s supported. Just from scanning the WDK documentation, it looks like certain MSI-related Storport functions (e.g. StorPortGetMSIInfo) is available only from Windows Vista and later.
– Keith
Keith is right: MSI(x) requires Vista or later.
Peter
OSR
I think I’ve digressed the thread’s topic. I’ve few more doubts in this, so
I’ll start a new thread regarding MSI(x) support in Storport in Windows
Server 2003-SP2.
Regards,
T.V.Gokul.