Hi all.
I have a couple settings that the user can change with some custom OIDs, and
such settings should be saved in the registry. Unfortunately, in order to
call NdisOpenConfiguration you need the “ConfigurationHandle” which is
passed as a parameter of the MiniportInitialize handler.
Is it safe to store such handle in the adapter extension and use it later
(e.g. in the MiniportHalt routine)? The documentation doesn’t say anything
about it.
Have a nice day
GV
> Is it safe to store such handle in the adapter extension and use it later
(e.g. in the MiniportHalt routine)?
I would say so…
In actuality, this handle is ‘NdisWrapperHandle’ that gets returned by NdisMInitializeWrapper(), which means that it has to be valid until you pass it to NdisTerminateWrapper(). Therefore, I believe that you can use it until you call NdisTerminateWrapper()…
Anton Bassov
> In actuality, this handle is ‘NdisWrapperHandle’ that gets returned by
NdisMInitializeWrapper(), which means that it has to be valid until
you
pass it to NdisTerminateWrapper(). Therefore, I believe that you can
use
it until you call NdisTerminateWrapper()…Anton Bassov
Wrong.
NdisWrapperConfigurationContext(per instance) is NOT
NdisWrapperHandle(per driver).
Why? Say if your have 10 NICs controlled by driverabc.sys, then you have
10 NdisWrapperConfigurationContext but one NdisWrapperHandler.
If what you said is true, which instance’s config is the target for
NdisOpen/ReadConfigXxx?
Calvin Guan (expiring DDK MVP)
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)
> NdisWrapperConfigurationContext(per instance) is NOT NdisWrapperHandle(per driver).
Why? Say if your have 10 NICs controlled by driverabc.sys, then you have
10 NdisWrapperConfigurationContext but one NdisWrapperHandler.
If what you said is true, which instance’s config is the target for NdisOpen/ReadConfigXxx?
Apparently, you will say that I am unable to understand what documentation says…
NdisOpenConfiguration returns a handle for a registry key in which an NDIS NIC driver’s advanced configuration parameters are stored
[end quote]
As you can see, NdisOpenConfiguration() returns a handle to per-driver configuration and not per-instance one.Taking into consideration the fact that this handle may be used for subsequent calls to
NdisOpenConfigurationKeyByName() and NdisOpenConfigurationKeyByIndex() in order to open subkeys you are interested in, you should not have any problem with retrieving per-instance info…
A NIC driver or intermediate driver must call NdisMInitializeWrapper before it calls any other NdisXxx function. Usually, this call is the initial action of any NIC driver’s DriverEntry function, which calls NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the returned NdisWrapperHandle next. NDIS intermediate drivers also must call NdisMIntializeWrapper from the DriverEntry function and, then, call NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the returned NdisWrapperHandle.
Such a driver’s subsequent calls to NdisXxx initialization and configuration functions must pass the NdisWrapperHandle as a parameter. Consequently, it is an input parameter to the MiniportInitialize function.
[end quote]
Please pay a special attention to the last sentence…
Anton Bassov
I think you can only refer to this handle during the lifetime of
MiniportInitialize. I ran this down a while ago and seem to recall it
was allocated on the stack. I have a comment in one of my drivers
that says to only call within MiniportInitialize.
-sd
On Mar 15, 2007, at 7:14 PM, Gianluca Varenni wrote:
Hi all.
I have a couple settings that the user can change with some custom
OIDs, and such settings should be saved in the registry.
Unfortunately, in order to call NdisOpenConfiguration you need the
“ConfigurationHandle” which is passed as a parameter of the
MiniportInitialize handler.Is it safe to store such handle in the adapter extension and use it
later (e.g. in the MiniportHalt routine)? The documentation doesn’t
say anything about it.Have a nice day
GV
Questions? First check the Kernel Driver FAQ at http://
www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
On Mar 16, 2007, at 4:10 AM, xxxxx@hotmail.com wrote:
A NIC driver or intermediate driver must call
NdisMInitializeWrapper before it calls any other NdisXxx function.
Usually, this call is the initial action of any NIC driver’s
DriverEntry function, which calls NdisMRegisterMiniport or
NdisIMRegisterLayeredMiniport with the returned NdisWrapperHandle
next. NDIS intermediate drivers also must call
NdisMIntializeWrapper from the DriverEntry function and, then, call
NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the
returned NdisWrapperHandle.Such a driver’s subsequent calls to NdisXxx initialization and
configuration functions must pass the NdisWrapperHandle as a
parameter. Consequently, it is an input parameter to the
MiniportInitialize function.[end quote]
Please pay a special attention to the last sentence…
Note that NdisWrapperHandle is different from the
WrapperConfigurationContext, which is also different from
MiniportAdapterHandle. This has been known to cause confusion due to
different lifetimes and different uses.
-sd
Steve,
Registry access only available in miniportInitialize context is a
confirmed pre-ndis6 limitation.
Calvin Guan (expiring DDK MVP)
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-280936-
xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Friday, March 16, 2007 10:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
outside MiniportInitialize?I think you can only refer to this handle during the lifetime of
MiniportInitialize. I ran this down a while ago and seem to recall it
was allocated on the stack. I have a comment in one of my drivers
that says to only call within MiniportInitialize.-sd
On Mar 15, 2007, at 7:14 PM, Gianluca Varenni wrote:
> Hi all.
>
> I have a couple settings that the user can change with some custom
> OIDs, and such settings should be saved in the registry.
> Unfortunately, in order to call NdisOpenConfiguration you need the
> “ConfigurationHandle” which is passed as a parameter of the
> MiniportInitialize handler.
>
> Is it safe to store such handle in the adapter extension and use it
> later (e.g. in the MiniportHalt routine)? The documentation doesn’t
> say anything about it.
>
> Have a nice day
> GV
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Argh… that’s too bad. I need to save some parameters that are set through
custom OIDs in the registry, and obviously I cannot do that in the
miniportInitialize.
And if I revert to the standard registry functions (provided that I get to
know the registry hive corresponding to the specific miniport instance), I’m
not sure the driver will be blessed by HCT/DTM.
Any ideas?
GV
----- Original Message -----
From: “Calvin (Hao) Guan”
To: “Windows System Software Devs Interest List”
Sent: Friday, March 16, 2007 10:18 AM
Subject: RE: [ntdev] Is it possible to call NdisOpenConfiguration from
outside MiniportInitialize?
Steve,
Registry access only available in miniportInitialize context is a
confirmed pre-ndis6 limitation.
Calvin Guan (expiring DDK MVP)
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-280936-
> xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
> Sent: Friday, March 16, 2007 10:12 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
> outside MiniportInitialize?
>
> I think you can only refer to this handle during the lifetime of
> MiniportInitialize. I ran this down a while ago and seem to recall it
> was allocated on the stack. I have a comment in one of my drivers
> that says to only call within MiniportInitialize.
>
> -sd
>
> On Mar 15, 2007, at 7:14 PM, Gianluca Varenni wrote:
>
> > Hi all.
> >
> > I have a couple settings that the user can change with some custom
> > OIDs, and such settings should be saved in the registry.
> > Unfortunately, in order to call NdisOpenConfiguration you need the
> > “ConfigurationHandle” which is passed as a parameter of the
> > MiniportInitialize handler.
> >
> > Is it safe to store such handle in the adapter extension and use it
> > later (e.g. in the MiniportHalt routine)? The documentation doesn’t
> > say anything about it.
> >
> > Have a nice day
> > GV
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://
> > www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
wrote in message news:xxxxx@ntdev…
>> NdisWrapperConfigurationContext(per instance) is NOT
>> NdisWrapperHandle(per driver).
>
>> Why? Say if your have 10 NICs controlled by driverabc.sys, then you have
>> 10 NdisWrapperConfigurationContext but one NdisWrapperHandler.
>
>> If what you said is true, which instance’s config is the target for
>> NdisOpen/ReadConfigXxx?
>
> Apparently, you will say that I am unable to understand what documentation
> says…
>
> 1. [begin quote]
>
> NdisOpenConfiguration returns a handle for a registry key in which an NDIS
> NIC driver’s advanced configuration parameters are stored
>
> [end quote]
>
> As you can see, NdisOpenConfiguration() returns a handle to per-driver
> configuration and not per-instance one.Taking into consideration the fact
> that this handle may be used for subsequent calls to
> NdisOpenConfigurationKeyByName() and NdisOpenConfigurationKeyByIndex() in
> order to open subkeys you are interested in, you should not have any
> problem with retrieving per-instance info…
>
Sadly enough, the documentation is wrong. As a matter of fact
NdisOpenConfiguration opens the key
HKLM\S\CCS\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}<number>
where uniquely identifies your network card (it actually uniquely
identifies the miniport instance, so you have entries for virtual miniports
and the miniport halves of IM drivers). So it’s a per device configuration.
> 2. [begin quote]
>
> A NIC driver or intermediate driver must call NdisMInitializeWrapper
> before it calls any other NdisXxx function. Usually, this call is the
> initial action of any NIC driver’s DriverEntry function, which calls
> NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the returned
> NdisWrapperHandle next. NDIS intermediate drivers also must call
> NdisMIntializeWrapper from the DriverEntry function and, then, call
> NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the returned
> NdisWrapperHandle.
>
> Such a driver’s subsequent calls to NdisXxx initialization and
> configuration functions must pass the NdisWrapperHandle as a parameter.
> Consequently, it is an input parameter to the MiniportInitialize function.
>
> [end quote]
>
> Please pay a special attention to the last sentence…
And again I think the documentation is quite misleading.
NdisOpenConfiguration opens the per device configuration registry hives.
Have a nice day
GV
>
>
> Anton Bassov
>
Why can’t you have the app or service that generates the custom OIDs do the
additional work of stashing necessary information in the registry?
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-280944-
xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
Sent: Friday, March 16, 2007 2:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
outside MiniportInitialize?Argh… that’s too bad. I need to save some parameters that are set
through
custom OIDs in the registry, and obviously I cannot do that in the
miniportInitialize.
And if I revert to the standard registry functions (provided that I get to
know the registry hive corresponding to the specific miniport instance),
I’m
not sure the driver will be blessed by HCT/DTM.Any ideas?
GV
----- Original Message -----
From: “Calvin (Hao) Guan”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, March 16, 2007 10:18 AM
> Subject: RE: [ntdev] Is it possible to call NdisOpenConfiguration from
> outside MiniportInitialize?
>
>
> Steve,
>
> Registry access only available in miniportInitialize context is a
> confirmed pre-ndis6 limitation.
>
> Calvin Guan (expiring DDK MVP)
> NetXtreme NTX Miniport
> Broadcom Corporation
> Connecting Everything(r)
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-280936-
> > xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
> > Sent: Friday, March 16, 2007 10:12 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
> > outside MiniportInitialize?
> >
> > I think you can only refer to this handle during the lifetime of
> > MiniportInitialize. I ran this down a while ago and seem to recall it
> > was allocated on the stack. I have a comment in one of my drivers
> > that says to only call within MiniportInitialize.
> >
> > -sd
> >
> > On Mar 15, 2007, at 7:14 PM, Gianluca Varenni wrote:
> >
> > > Hi all.
> > >
> > > I have a couple settings that the user can change with some custom
> > > OIDs, and such settings should be saved in the registry.
> > > Unfortunately, in order to call NdisOpenConfiguration you need the
> > > “ConfigurationHandle” which is passed as a parameter of the
> > > MiniportInitialize handler.
> > >
> > > Is it safe to store such handle in the adapter extension and use it
> > > later (e.g. in the MiniportHalt routine)? The documentation doesn’t
> > > say anything about it.
> > >
> > > Have a nice day
> > > GV
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://
> > > www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
----- Original Message -----
From: “Thomas F. Divine”
To: “Windows System Software Devs Interest List”
Sent: Friday, March 16, 2007 1:17 PM
Subject: RE: [ntdev] Is it possible to call NdisOpenConfiguration from
outside MiniportInitialize?
> Why can’t you have the app or service that generates the custom OIDs do
> the
> additional work of stashing necessary information in the registry?
>
I will probably do something like that. Doing that using the
NdisReadConfiguration/NdisWriteConfiguration functions would have just been
way easier to implement (since the driver already uses such key for a bunch
of other configuration parameters). I just need to look for a way to obtain
the registry name
HKLM\S\CCS\Control\Class{4D36E972-E325-11CE-BFC1-08002bE10318}<number>
if I want to store all my parameters in the same registry hive.
gv
> Thomas F. Divine
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-280944-
>> xxxxx@lists.osr.com] On Behalf Of Gianluca Varenni
>> Sent: Friday, March 16, 2007 2:29 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
>> outside MiniportInitialize?
>>
>> Argh… that’s too bad. I need to save some parameters that are set
>> through
>> custom OIDs in the registry, and obviously I cannot do that in the
>> miniportInitialize.
>> And if I revert to the standard registry functions (provided that I get
>> to
>> know the registry hive corresponding to the specific miniport instance),
>> I’m
>> not sure the driver will be blessed by HCT/DTM.
>>
>> Any ideas?
>>
>> GV
>>
>>
>>
>> ----- Original Message -----
>> From: “Calvin (Hao) Guan”
>> To: “Windows System Software Devs Interest List”
>> Sent: Friday, March 16, 2007 10:18 AM
>> Subject: RE: [ntdev] Is it possible to call NdisOpenConfiguration from
>> outside MiniportInitialize?
>>
>>
>> Steve,
>>
>> Registry access only available in miniportInitialize context is a
>> confirmed pre-ndis6 limitation.
>>
>> Calvin Guan (expiring DDK MVP)
>> NetXtreme NTX Miniport
>> Broadcom Corporation
>> Connecting Everything(r)
>>
>>
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com [mailto:bounce-280936-
>> > xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
>> > Sent: Friday, March 16, 2007 10:12 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: Re: [ntdev] Is it possible to call NdisOpenConfiguration from
>> > outside MiniportInitialize?
>> >
>> > I think you can only refer to this handle during the lifetime of
>> > MiniportInitialize. I ran this down a while ago and seem to recall it
>> > was allocated on the stack. I have a comment in one of my drivers
>> > that says to only call within MiniportInitialize.
>> >
>> > -sd
>> >
>> > On Mar 15, 2007, at 7:14 PM, Gianluca Varenni wrote:
>> >
>> > > Hi all.
>> > >
>> > > I have a couple settings that the user can change with some custom
>> > > OIDs, and such settings should be saved in the registry.
>> > > Unfortunately, in order to call NdisOpenConfiguration you need the
>> > > “ConfigurationHandle” which is passed as a parameter of the
>> > > MiniportInitialize handler.
>> > >
>> > > Is it safe to store such handle in the adapter extension and use it
>> > > later (e.g. in the MiniportHalt routine)? The documentation doesn’t
>> > > say anything about it.
>> > >
>> > > Have a nice day
>> > > GV
>> > >
>> > >
>> > > —
>> > > Questions? First check the Kernel Driver FAQ at http://
>> > > www.osronline.com/article.cfm?id=256
>> > >
>> > > To unsubscribe, visit the List Server section of OSR Online at
>> > > http://www.osronline.com/page.cfm?name=ListServer
>> >
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Anton B,
All my computers and servers are down today. I got nothing to do and was
in good mood. So I decided to reply to your post.
Anton, I’ve been telling you in other NGs that the DDK doc is not always
accurate. Sometimes it’s just incorrect. Don’t quote them blindly to
confuse yourself as well as less experienced. NTDEV is a dedicated
mailing list maintained by OSR which IMHO, has the highest S/N ratio
compared to other usernet/NGs. I personally benefit a lot from Peter’s
mailing lists from time to time. It’s been a nice experience to read
those high quality answers from participants. ***PLEASE DON’T BREAK
IT***.
RTFM is essential. Being able to be aware of what the documentation
SHOULD HAVE said is equally important. Of course the latter is way more
difficult to achieve. I guess whoever has written at least one
no-so-trivial driver would agree with me.
I know you love to argue. I have no problem with that. In fact, I learn
the most when I was getting flamed badly. At BRCM, driver, f/w, chip
guys do argue in most design meetings. Sometimes the argument is quite
entertaining. My job also requires me to politely and professionally
challenge “big guys” at MSFT and third party h/w vendors when necessary.
I believe I have been quite successfully doing my job. We argue with
solid points backed by concrete evidence and rigorous analysis. In the
end, all parties benefit from the argument and finally reach a point
where most are happy. Because we assume that the person we are arguing
to is experienced and knows what they are doing very well. So before I
argue, I will do necessary homework to make sure I don’t sound like a
jackass to those industry veterans.
Finally, mind you dude, there are some extremely skilled and high
caliber consultants and developers and managers watching the posts. They
might be your future clients and/or employers. Making obviously wrong
comments hurts credibility.
Calvin Guan (expiring DDK MVP)
Sr. Staff Engineer
NetXtreme NTX Miniport
Broadcom Corp. - Top 2 America’s Most Admired Semiconductor Company
Connecting Everything(r)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-280913-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, March 16, 2007 2:11 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Is it possible to call NdisOpenConfiguration from
outside MiniportInitialize?> NdisWrapperConfigurationContext(per instance) is NOT
NdisWrapperHandle(per driver).> Why? Say if your have 10 NICs controlled by driverabc.sys, then you
have
> 10 NdisWrapperConfigurationContext but one NdisWrapperHandler.> If what you said is true, which instance’s config is the target for
NdisOpen/ReadConfigXxx?Apparently, you will say that I am unable to understand what
documentation
says…
- [begin quote]
NdisOpenConfiguration returns a handle for a registry key in which an
NDIS
NIC driver’s advanced configuration parameters are stored[end quote]
As you can see, NdisOpenConfiguration() returns a handle to per-driver
configuration and not per-instance one.Taking into consideration the
fact
that this handle may be used for subsequent calls to
NdisOpenConfigurationKeyByName() and NdisOpenConfigurationKeyByIndex()
in
order to open subkeys you are interested in, you should not have any
problem with retrieving per-instance info…
- [begin quote]
A NIC driver or intermediate driver must call NdisMInitializeWrapper
before it calls any other NdisXxx function. Usually, this call is the
initial action of any NIC driver’s DriverEntry function, which calls
NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the
returned
NdisWrapperHandle next. NDIS intermediate drivers also must call
NdisMIntializeWrapper from the DriverEntry function and, then, call
NdisMRegisterMiniport or NdisIMRegisterLayeredMiniport with the
returned
NdisWrapperHandle.Such a driver’s subsequent calls to NdisXxx initialization and
configuration functions must pass the NdisWrapperHandle as a
parameter.
Consequently, it is an input parameter to the MiniportInitialize
function.[end quote]
Please pay a special attention to the last sentence…
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Calvin,
Anton, I’ve been telling you in other NGs that the DDK doc is not always accurate.
This is true - this is the third time just in one week (!!!) that I discuss some this or that MSDN inconsistency in the NG. The first one was about PsCreateSystemThread() - MSDN says that, under W2K, callers of this routine have to run in context of a system process (which is not true) . On that particular occasion, I knew the answer, to that I pointed out this inconsistency to the OP.
On the remainng two ocassions it was you who pointed MSDN inconsistencies to me.
The one about IoMarkIrpPending() is just a harmless “discrepancy” between MSDN and the existion
implementation of IoCompleteRequest(). However, the one that we have discovered on this particular thread is already a serious bug that may lead you to making mistakes in your code…
Being able to be aware of what the documentation SHOULD HAVE said is equally important.
Actually, when you discover some MSDN inconsistency, sometimes just don’t believe your own eyes -according MSFT, MSDN may be still correct, despite the fact that all the evidence strongly suggests otherwise…
Here is the example.
According to MSDN, VirtualLock() locks pages in memory. However, if you disassemble it, you will see that it locks pages only in the working set of the target process - this is why you can successfully call it without SeLockMemory privilege. I had 2 discussions with Mr. Pavel Lebedinsky from MSFT about this issue, and on both occasions he assured me that MSDN is, actually, correct - according to him, Memory Manager does not make any distinction between LOCK_IN_RAM and LOCK_IN_WS flags that are specified to ZwLockVirtualMemory() call, so that, by specifying LOCK_IN_WS flag, VirtualLock() actually locks pages in RAM…
In other words, sometimes you just cannot say anything without seeing the OS source code…
I know you love to argue. I have no problem with that. In fact, I learn the most
when I was getting flamed badly.
Actually, this is the only reason why I try to defend my point - even if in the end of the day it turns out that I was wrong, still I learn quite a lot from a discussion…
At BRCM, driver, f/w, chip guys do argue in most design meetings
Well, this is already a bit different type of argument - the one that we have in the NG is just for education and training (at least the way I see it), but the one that we have with clients is already the actual job. Therefore, you should try to avoid mistakes at any cost when arguing with clients, although you can afford to make some wrong statements when you are just educating yourself.
In other words, making mistakes in the NG discussions helps you to avoid making them when dealing
with clients…
Finally, mind you dude, there are some extremely skilled and high
caliber consultants and developers and managers watching the posts. They
might be your future clients and/or employers. Making obviously wrong
comments hurts credibility.
Well, this may be an issue to be considered…
Anton Bassov
> implementation of IoCompleteRequest(). However, the one that we have
discovered on this particular thread is already a serious bug that may
lead you to making mistakes in your code…
[CG] It’s not “we”. It’s you-Anton. You obviously still don’t understand
Eliyas’s (Mr. Toaster) correction to your post. I’m not going to repeat
the education. The code snippet is taken from some field proven mass
production drivers. It survived days of MSFT internal stress test matrix
which you have never heard of. Don’t think I’m that stupid.
Calvin Guan (expiring DDK MVP)
Sr. Staff Engineer
NetXtreme NTX Miniport
Broadcom Corp. - Top 2 America’s Most Admired Semiconductor Company
Connecting Everything(r)
> >implementation of IoCompleteRequest(). However, the one that we have
> discovered on this particular thread is already a serious bug that may
> lead you to making mistakes in your code…
[CG] It’s not “we”. It’s you-Anton. You obviously still don’t understand
Eliyas’s (Mr. Toaster) correction to your post. I’m not going to repeat
the education. The code snippet is taken from some field proven mass
production drivers. It survived days of MSFT internal stress test matrix
which you have never heard of.
Please read my previous post carefully - I said that " a serious bug that may lead you to making mistakes in your code" is the one that we discuss on this thread, and the one that we discussed in another NG is just harmless discrepancy. If you follow MSDN there and make unnecessary call to IoMarlIrpPending() in your completion routine, nothing is going to happen, apart from few wasted CPU cycles. However, if follow MSDN here and mistake a handle that gets passed to your MiniportInitialize() for the one returned by NdisMInitializeWrapper(), it will hardly do you any good…
BTW, the code snippet your speak about is taken from IoCompteleRequest() implementation, so that it is taken from ntoskrnl.exe, rather than from any driver…
Don’t think I’m that stupid
Actually, I never thought anything like that - I really don’t know what the above suspicion is based upon…
Anton Bassov
Anton,
Watch carefully. These are the 2 examples I pasted from the thread in other NG. They are not from ntoskrnl.exe
//
// Example A:
//
NTSTATUS CompRoutineA(irp)
{
//do whatever with the IRP
return STATUS_CONTINUE_COMPLETION;
}
NTSTATUS
Xyz_call_drv_and_potentially_alter_the_return_status (
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{
IoMarkIrpPending(Irp);
IoSetCompletionRoutine(Irp,CompRoutineA,…);
IoCallDriver(DeviceObject,Irp);
return STATUS_PENDING;
}
Your first reply:
“As you will see below, the above code (CompletionRoutineA) has quite insidious bug in it…”
After Eliyas told you why the code is correct and presented the snippet of IoCompleteRequest. you then replied:
" Indeed, as it turns out,
IoMarkIrpPending()
call by the driver is unnecessary, simply because, unless the completion
routine returns STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest() calls
IoMarkIrpPending() anyway if Irp->PendingReturned is set. In other words,
IoCompleteRequest() does something that, according to the doc I quoted,
should be done by the completion routine, so that doing the same thing in the
completion routine is simply unnecessary. However, officially all the above is undocumented behaviour, so that MSFT
can change it at whenever it wants - after all, if some problem arises, they
can always say that you just haven’t followed their guidelines…"
Quiz 1:
Anton, are you aware of the MULTIPLE errors in your statement? I suggest you do your homework before you attempt to defend yourself.
//
// Example B:
//
VOID func_a()
{
IoGetDeviceObjectPointer(…,&pDevObject);
irp = IoAllocateIrp(); // with no extra stack;
/// setup IRP stack.
IoSetCompetionRoutineB(irp,CompRoutineB,…);
IoCallDriver();
return;
}
NTSTATUS
CompRoutineB(irp)
{
if (Irp->PendingReturned)
{
/// do NOT mark pending regardless what code you return,
}
ObDereferenceObject(devobj);
IoFreeIrp(Irp);
return SMPR;
}
Anton, you seemed to believe marking IRP pending in example is “harmless”. Let me tell ya, marking irp pending in CompRoutineB is wrong and completely unnecessary.
Quiz 2: Why marking IRP pending is a fatal error here?
If you don’t know the answer to the quizs, and ask nicely, someone in the list or I would probably tell you.
Calvin Guan (expiring DDK MVP)
Sr. Staff Engineer
NetXtreme NTX Miniport
Broadcom Corp. - Top 2 America’s Most Admired Semiconductor Company
Connecting Everything(r)
----- Original Message ----
From: “xxxxx@hotmail.com”
To: Windows System Software Devs Interest List
Sent: Sunday, March 18, 2007 12:45:46 PM
Subject: RE:[ntdev] Is it possible to call NdisOpenConfiguration from outside MiniportInitialize?
> >implementation of IoCompleteRequest(). However, the one that we have
>> discovered on this particular thread is already a serious bug that may
> > lead you to making mistakes in your code…
> [CG] It’s not “we”. It’s you-Anton. You obviously still don’t understand
> Eliyas’s (Mr. Toaster) correction to your post. I’m not going to repeat
> the education. The code snippet is taken from some field proven mass
> production drivers. It survived days of MSFT internal stress test matrix
> which you have never heard of.
Please read my previous post carefully - I said that " a serious bug that may lead you to making mistakes in your code" is the one that we discuss on this thread, and the one that we discussed in another NG is just harmless discrepancy. If you follow MSDN there and make unnecessary call to IoMarlIrpPending() in your completion routine, nothing is going to happen, apart from few wasted CPU cycles. However, if follow MSDN here and mistake a handle that gets passed to your MiniportInitialize() for the one returned by NdisMInitializeWrapper(), it will hardly do you any good…
BTW, the code snippet your speak about is taken from IoCompteleRequest() implementation, so that it is taken from ntoskrnl.exe, rather than from any driver…
> Don’t think I’m that stupid
Actually, I never thought anything like that - I really don’t know what the above suspicion is based upon…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Calvin,
> After Eliyas told you why the code is correct and presented the snippet of
> IoCompleteRequest. you then replied:
> " Indeed, as it turns out,
> IoMarkIrpPending()=0Acall by the driver is unnecessary, simply because, unless
> the completion
> routine returns STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest() calls
> IoMarkIrpPending() anyway if Irp->PendingReturned is set. In other words,
> IoCompleteRequest() does something that, according to the doc I quoted,
> should be done by the completion routine, so that doing the same thing in the
> completion routine is simply unnecessary. However, officially all the above is
> undocumented behaviour, so that MSFT
>can change it at whenever it wants - after all, if some problem arises, they
>can always say that you just haven’t followed their guidelines…"
Quiz 1:=0AAnton, are you aware of the MULTIPLE errors in your statement? I
suggest you do your homework before you attempt to defend yourself.
Please look carefully at the code snippet that Elyas has provided - you will see that my statement above is not all that wrong… You will see it shortly.
//
// Example B:
//
VOID func_a()
{
IoGetDeviceObjectPointer(…,&pDevObject);
irp = IoAllocateIrp(); // with no extra stack;=0A /// setup IRP
stack.
IoSetCompetionRoutineB(irp,CompRoutineB,…);
IoCallDriver();
return;
}
NTSTATUS
CompRoutineB(irp)
{
if (Irp->PendingReturned)
{
/// do NOT mark pending regardless what code you return,
}
ObDereferenceObject(devobj);
IoFreeIrp(Irp);
return SMPR;
}=0A
Anton, you seemed to believe marking IRP pending in example is “harmless”. Let
me tell ya, marking irp pending in CompRoutineB is wrong and completely
unnecessary.
Quiz 2: Why marking IRP pending is a fatal error here?
Judging from the code that Elyas has provided, marking irp pending in CompRoutineB strictly under under the condition that Irp->PendingReturned is set is *NOT* a fatal error here - this is nothing more than just a dead piece of code that will never get invoked. Why??? Simply because pending flag is copied from the stack location to the Irp->PendingReturned before your routine gets invoked. Once you have not marked your IRP pending before passing it down the stack, Irp-PendingReturned flag is going to be clear, so that your completion routine will never mark irp pending anyway.
Actually, your code is going to blue-screen anyway, but for the totally different reason…
It is going to happen because of the following line:
ObDereferenceObject(devobj);
Once you haven’t allocated extra stack location in IRP, Irp->CurrentLocation will be equal to (CCHAR) (Irp->StackCount + 1) by the time your completion routine gets invoked, and, according to the snippet that Elyas has provided, devobj that gets passed to your routine will be NULL under these circumstances. Therefore, you dereference NULL pointer. BANG!!!
Anton Bassov
You still don’t get it right on both quizs… I’m going to answer Q2. and leave Q1 for your exercise.
As for the devobj in CompRoutineB, no, I am not using the first arg past so the code won’t BSOD. This is irrelevant to the discussion but a good point. The point (answer to Q2) is you can NOT mark IRP pending in CompRoutineB because there is NO i/o stack location there!
This is my last comment on this thread.
Calvin
----- Original Message ----
From: “xxxxx@hotmail.com”
To: Windows System Software Devs Interest List
Sent: Sunday, March 18, 2007 10:52:18 PM
Subject: RE:[ntdev] Is it possible to call NdisOpenConfiguration from outside MiniportInitialize?
Calvin,
>> After Eliyas told you why the code is correct and presented the snippet of
>> IoCompleteRequest. you then replied:
>> " Indeed, as it turns out,
>> IoMarkIrpPending()=0Acall by the driver is unnecessary, simply because, unless
>> the completion
>> routine returns STATUS_MORE_PROCESSING_REQUIRED, IoCompleteRequest() calls
>> IoMarkIrpPending() anyway if Irp->PendingReturned is set. In other words,
>> IoCompleteRequest() does something that, according to the doc I quoted,
>> should be done by the completion routine, so that doing the same thing in the
>> completion routine is simply unnecessary. However, officially all the above is
>> undocumented behaviour, so that MSFT
>>can change it at whenever it wants - after all, if some problem arises, they
>>can always say that you just haven’t followed their guidelines…"
> Quiz 1:=0AAnton, are you aware of the MULTIPLE errors in your statement? I
> suggest you do your homework before you attempt to defend yourself.
Please look carefully at the code snippet that Elyas has provided - you will see that my statement above is not all that wrong… You will see it shortly.
//
// Example B:
//
VOID func_a()
{
IoGetDeviceObjectPointer(…,&pDevObject);
irp = IoAllocateIrp(); // with no extra stack;=0A /// setup IRP
stack.
IoSetCompetionRoutineB(irp,CompRoutineB,…);
IoCallDriver();
return;
}
NTSTATUS
CompRoutineB(irp)
{
if (Irp->PendingReturned)
{
/// do NOT mark pending regardless what code you return,
}
ObDereferenceObject(devobj);
IoFreeIrp(Irp);
return SMPR;
}=0A
> Anton, you seemed to believe marking IRP pending in example is “harmless”. Let
> me tell ya, marking irp pending in CompRoutineB is wrong and completely
> unnecessary.
> Quiz 2: Why marking IRP pending is a fatal error here?
Judging from the code that Elyas has provided, marking irp pending in CompRoutineB strictly under under the condition that Irp->PendingReturned is set is NOT a fatal error here - this is nothing more than just a dead piece of code that will never get invoked. Why??? Simply because pending flag is copied from the stack location to the Irp->PendingReturned before your routine gets invoked. Once you have not marked your IRP pending before passing it down the stack, Irp-PendingReturned flag is going to be clear, so that your completion routine will never mark irp pending anyway.
Actually, your code is going to blue-screen anyway, but for the totally different reason…
It is going to happen because of the following line:
ObDereferenceObject(devobj);
Once you haven’t allocated extra stack location in IRP, Irp->CurrentLocation will be equal to (CCHAR) (Irp->StackCount + 1) by the time your completion routine gets invoked, and, according to the snippet that Elyas has provided, devobj that gets passed to your routine will be NULL under these circumstances. Therefore, you dereference NULL pointer. BANG!!!
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Calvin,
The point (answer to Q2) is you can NOT mark IRP pending in CompRoutineB because
there is NO i/o stack location there!
I know it - after all, you mentioned it in your post on another NG, so that I just have no chance of not knowing it. However, in context of your example on this thread it just does not matter, simply because your completion routione will have no chance to mark IRP pending anyway. However, if it tried to do something like that… then BANG!!!
This is my last comment on this thread.
Indeed, it looks like we changed the subject of our discussion, so that discussing it on this thread
is, apparently, not the best idea…
Anton Bassov