Hi,
I’m developing a NDIS IM driver.
Is it possible to issue NdisRequest() from the end of the my IM protocl’s
ProtoclBindAdapter() function? (and supply the binding handle representing
the real miniport…)
For some reason i get a BSOD when i do that…
Thanks.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Wednesday, March 14, 2007 10:30 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling NdisRequest() from ProtoclBindAdapter() - Possible?
Hi,
I’m developing a NDIS IM driver.
Is it possible to issue NdisRequest() from the end of the my IM protocl’s
ProtoclBindAdapter() function? (and supply the binding handle representing
the real miniport…)
For some reason i get a BSOD when i do that…
[PCAUSA] Yes, that can be done successfully.
You must account for (assume) that the query will be completed
asynchronously. You must also make sure that you differentiate your private
requests from requests that originate from calls to MiniportQueryInformation
or MiniportSetInformation. In particular, in your ProtocolRequestComplete
handler you must make sure that you do not call
NdisMQueryInformationComplete then the request being completed is one of
your private queries.
You should also take care to reference count your ADAPT structure (or
whatever you have called it.). Add a reference before making a private query
and dereference when you’re your private query completes. This insures that
your ADAPT structure does not get deleted between the time you initiate the
query and when it completes.
Hope this gives you some guidance. In any case, it can be done.
It would be helpful if you run under a debugger. In that case you will not
get a BSOD. Instead, you will get helpful information from the debugger. If
you are developing a device driver and say “I got a BSOD” then you are not
doing your job correctly. You are trying to use the newsgroup as s
substitute for a debugger, and that’s not the purpose of the group.
Use a debugger instead of asking about BSOD’s.
Good luck,
Thomas F. Divine
Thanks.
— 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
Thomas,
As usual, thanks for great and informative replay.
Luckily, most of the things you were talking about are implemented in your
extension to the pass through example (by NDIS_REQUEST_EX structure), for
some reason it’s just didn’t work from me while issuing the call from the
PtBindAdapter function.
What i just wanted to ask is if in general this thing is possible (make a
req from PtBindAdapter) and not use the newsgroup as a replacement to
a debugger.
I guess i had to rephrase the question…
Thanks.
On 3/14/07, Thomas F. Divine wrote:
>
>
>
>
> ------------------------------
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Omer B
> Sent: Wednesday, March 14, 2007 10:30 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Calling NdisRequest() from ProtoclBindAdapter() -
> Possible?
>
>
>
> Hi,
>
>
>
> I’m developing a NDIS IM driver.
>
> Is it possible to issue NdisRequest() from the end of the my IM protocl’s
> ProtoclBindAdapter() function? (and supply the binding handle representing
> the real miniport…)
>
> For some reason i get a BSOD when i do that…
>
> [PCAUSA] Yes, that can be done successfully.
>
> * *
>
> You must account for (assume) that the query will be completed
> asynchronously. You must also make sure that you differentiate your private
> requests from requests that originate from calls to MiniportQueryInformation
> or MiniportSetInformation. In particular, in your ProtocolRequestComplete
> handler you must make sure that you do _ not _ call
> NdisMQueryInformationComplete then the request being completed is one of
> your private queries.
>
> * *
>
> You should also take care to reference count your ADAPT structure (or
> whatever you have called it?). Add a reference before making a private query
> and dereference when you’re your private query completes. This insures that
> your ADAPT structure does not get deleted between the time you initiate the
> query and when it completes.
>
> * *
>
> Hope this gives you some guidance. In any case, it can be done.
>
> * *
>
> It would be helpful if you run under a debugger. In that case you will
> not get a BSOD. Instead, you will get helpful information from the debugger.
> If you are developing a device driver and say “I got a BSOD” then you are
> not doing your job correctly. You are trying to use the newsgroup as s
> substitute for a debugger, and that’s not the purpose of the group.
>
> * *
>
> Use a debugger instead of asking about BSOD’s.
>
> * *
>
> Good luck,
>
> * *
>
> Thomas F. Divine
>
>
>
> Thanks.
>
>
>
>
>
> — 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
>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Wednesday, March 14, 2007 12:44 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Calling NdisRequest() from ProtoclBindAdapter() -
Possible?
Thomas,
As usual, thanks for great and informative replay.
Luckily, most of the things you were talking about are implemented in your
extension to the pass through example (by NDIS_REQUEST_EX structure), for
some reason it’s just didn’t work from me while issuing the call from the
PtBindAdapter function.
What i just wanted to ask is if in general this thing is possible (make a
req from PtBindAdapter) and not use the newsgroup as a replacement to a
debugger.
[PCAUSA] Certainly it is possible. Most of my production drivers fetch a
variety of information from the lower-level miniport as soon as
NdisOpenAdapter completes.
In my own code I often start an automatic chain or sequence of NdisRequests
that complete asynchronously. As each completes it stashes information in
the ADAPT structure and starts (if necessary) another request for some other
piece of information. As each completes I check the state of the adapter
binding on the off-chance that state could have gone bad between the that
time that the query was initiated and when it completes. If state is bad,
then I stop the chain of automatic start-up queries.
Information I fetch most often is current physical address, frame sizes,
etc.
I guess i had to rephrase the question…
Thanks.
On 3/14/07, Thomas F. Divine wrote:
_____
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Omer B
Sent: Wednesday, March 14, 2007 10:30 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Calling NdisRequest() from ProtoclBindAdapter() - Possible?
Hi,
I’m developing a NDIS IM driver.
Is it possible to issue NdisRequest() from the end of the my IM protocl’s
ProtoclBindAdapter() function? (and supply the binding handle representing
the real miniport…)
For some reason i get a BSOD when i do that…
[PCAUSA] Yes, that can be done successfully.
You must account for (assume) that the query will be completed
asynchronously. You must also make sure that you differentiate your private
requests from requests that originate from calls to MiniportQueryInformation
or MiniportSetInformation. In particular, in your ProtocolRequestComplete
handler you must make sure that you do _ not _ call
NdisMQueryInformationComplete then the request being completed is one of
your private queries.
You should also take care to reference count your ADAPT structure (or
whatever you have called it.). Add a reference before making a private query
and dereference when you’re your private query completes. This insures that
your ADAPT structure does not get deleted between the time you initiate the
query and when it completes.
Hope this gives you some guidance. In any case, it can be done.
It would be helpful if you run under a debugger. In that case you will not
get a BSOD. Instead, you will get helpful information from the debugger. If
you are developing a device driver and say “I got a BSOD” then you are not
doing your job correctly. You are trying to use the newsgroup as s
substitute for a debugger, and that’s not the purpose of the group.
Use a debugger instead of asking about BSOD’s.
Good luck,
Thomas F. Divine
Thanks.
— 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
Thomas,
You must also make sure that you differentiate your private
requests from requests that originate from calls to MiniportQueryInformation
or MiniportSetInformation. In particular, in your ProtocolRequestComplete
handler you must make sure that you do not call
NdisMQueryInformationComplete then the request being completed is one of
your private queries.
Taking into consideration the fact that the OP just applied his modifications to the existing sample
( in this particular case, the one that you wrote), I am 99.9% sure that the reason for BSOD lies with ProtocolRequestComplete() - apparently, the OP just “forgot” to modify ProtocolRequestComplete(), so that it unconditionally indicates request completion to NDIS, no matter if the request has has been originated by the bound protocols or if by the IM driver itself.
In other words, instead of writing his own code, the OP seems to have thoughtlessly “modified” your sample without being bothered to understand how it actually works, and now wonders why he gets BSOD…
I don’t know about you, but I always write my own code from the scratch and use samples only as a guidance - I always try to understand how things work, so that blindly reusing the existing sample is just not the way I do things. The OP seems to have a different approach to things…
Anton Bassov
Dear Anton,
No douth that the approch you’ve described is the perfered one, even by me.
But in this case, the described pocedure is exactly imlemented in the code,
so after understanding it and tracing it i feel safe enough to use it:
( beginning of PtBindAdapter() )
if( NdisRequest != &(pAdapt->Request) )
{
PNDIS_REQUEST_EX pLocalRequest = (PNDIS_REQUEST_EX)NdisRequest;
NdisSetEvent( &pLocalRequest->RequestEvent );
( *pLocalRequest->RequestCompleteHandler )( pAdapt, pLocalRequest,
Status );
return;
}
the problem is, that i even don’t see my PtCompleteRequest() being called.
This is the request code… did i miss something ?
if ( NDIS_STATUS_SUCCESS == *Status )
{
if ( pAdapt->Medium == NdisMedium802_3)
{
NDIS_STATUS status;
PUCHAR infoBuffer = NULL;
PNDIS_REQUEST_EX pNdisRequestEx = NULL;
NdisAllocateMemoryWithTag( (PVOID*)&pNdisRequestEx, sizeof(NDIS_REQUEST_EX),
NDIS_IM_TAG );
ASSERT( NULL != pNdisRequestEx );
NdisZeroMemory( pNdisRequestEx, sizeof(NDIS_REQUEST_EX));
NdisAllocateMemoryWithTag( (PVOID*)&infoBuffer, 100, NDIS_IM_TAG );
ASSERT( NULL != infoBuffer );
pNdisRequestEx->Request.RequestType = NdisRequestQueryInformation;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.Oid =
OID_802_3_CURRENT_ADDRESS;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.InformationBuffer =
infoBuffer;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.InformationBufferLength =
100;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesNeeded = 0;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesWritten = 0;
pNdisRequestEx->RequestCompleteHandler = ImRequestComplete;
pNdisRequestEx->RequestContext = NULL;
NdisResetEvent( &pNdisRequestEx->RequestEvent );
NdisRequest( &status,
pAdapt->RealMiniportBindingHandle,
(PNDIS_REQUEST)&pNdisRequestEx );
if( status != NDIS_STATUS_PENDING )
{
ImRequestComplete( pAdapt, pNdisRequestEx, status );
}
else
{
NdisWaitEvent( &pNdisRequestEx->RequestEvent, 0 );
status = pNdisRequestEx->RequestStatus;
}
}
}
On 3/15/07, xxxxx@hotmail.com wrote:
>
> Thomas,
>
> > You must also make sure that you differentiate your private
> > requests from requests that originate from calls to
> MiniportQueryInformation
> > or MiniportSetInformation. In particular, in your
> ProtocolRequestComplete
> > handler you must make sure that you do not call
> > NdisMQueryInformationComplete then the request being completed is one of
> > your private queries.
>
> Taking into consideration the fact that the OP just applied his
> modifications to the existing sample
> ( in this particular case, the one that you wrote), I am 99.9% sure that
> the reason for BSOD lies with ProtocolRequestComplete() - apparently, the OP
> just “forgot” to modify ProtocolRequestComplete(), so that it
> unconditionally indicates request completion to NDIS, no matter if the
> request has has been originated by the bound protocols or if by the IM
> driver itself.
> In other words, instead of writing his own code, the OP seems to have
> thoughtlessly “modified” your sample without being bothered to understand
> how it actually works, and now wonders why he gets BSOD…
>
> I don’t know about you, but I always write my own code from the scratch
> and use samples only as a guidance - I always try to understand how things
> work, so that blindly reusing the existing sample is just not the way I do
> things. The OP seems to have a different approach to things…
>
> 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
>
ALL THAT FOLLOWS IS TOTALLY AN OPINION: Perhaps, but you’re committing
aesthetic suicide, and in the process so not doing anyone who has to
maintain your code any favors. For the most part, I’ve spent the ten
years or so since leaving school reverse engineering things, and this
has certainly warped my view on this subject. Fundamentally, I’m in
agreement with Anton on this one - what can be gained in even just
familarity if not understanding by some typing is so worth it. I’m no
longer an independent consultant exactly, but when I was, this sort of
thing was the most reliable sign that I should take the contract only if
they were willing to rewrite, because, whether the code works or not, it
destroys all of the intangibles that one (or at least I) has to use to
make reasonable educated guesses in order to figure out where to start,
or, in particular, whether one wants to start or move on to potentially
greener pastures. Most importantly it destroys essentially all temporal
information latent in coding style, so that it becomes outrageously
difficult to figure out what is the work of the original author and what
has been modified or added by someone else. This, for me, destroys the
latent linguistic information, so to speak, that one can use to some
extent speed read code reliably enough to figure out most of the time
where to start easily an order of magnitude faster than could be by
tracing or thorough analysis, assuming the code base is unfamiliar and
significant in size. It makes comments, which under the best of
practical and profitable circumstances are not terribly useful, a
complete waste of time to the point of appearing to be disinformation.
The biggest problem I have with this style is that when one is familiar
with the source of the original code itself, it is difficult not to
assume that its reproduction is unmodified, which can get one in to all
sorts of trouble. An this source of error just keeps getting propagated
with each generation. For an example (or two) of this, search for
“Undocumented Windows NT” (perhaps the most pathological case, as the
majority of it has major issues to begin with) on this list’s archive
for examples of this.
>> xxxxx@gmail.com 2007-03-15 07:10 >>>
Dear Anton,
No douth that the approch you’ve described is the perfered one, even by
me.
But in this case, the described pocedure is exactly imlemented in the
code,
so after understanding it and tracing it i feel safe enough to use it:
( beginning of PtBindAdapter() )
if( NdisRequest != &(pAdapt->Request) )
{
PNDIS_REQUEST_EX pLocalRequest = (PNDIS_REQUEST_EX)NdisRequest;
NdisSetEvent( &pLocalRequest->RequestEvent );
( *pLocalRequest->RequestCompleteHandler )( pAdapt,
pLocalRequest,
Status );
return;
}
the problem is, that i even don’t see my PtCompleteRequest() being
called.
This is the request code… did i miss something ?
if ( NDIS_STATUS_SUCCESS == *Status )
{
if ( pAdapt->Medium == NdisMedium802_3)
{
NDIS_STATUS status;
PUCHAR infoBuffer = NULL;
PNDIS_REQUEST_EX pNdisRequestEx = NULL;
NdisAllocateMemoryWithTag( (PVOID*)&pNdisRequestEx,
sizeof(NDIS_REQUEST_EX),
NDIS_IM_TAG );
ASSERT( NULL != pNdisRequestEx );
NdisZeroMemory( pNdisRequestEx, sizeof(NDIS_REQUEST_EX));
NdisAllocateMemoryWithTag( (PVOID*)&infoBuffer, 100, NDIS_IM_TAG );
ASSERT( NULL != infoBuffer );
pNdisRequestEx->Request.RequestType = NdisRequestQueryInformation;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.Oid =
OID_802_3_CURRENT_ADDRESS;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.InformationBuffer =
infoBuffer;
100;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesNeeded = 0;
pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesWritten = 0;
pNdisRequestEx->RequestCompleteHandler = ImRequestComplete;
pNdisRequestEx->RequestContext = NULL;
NdisResetEvent( &pNdisRequestEx->RequestEvent );
NdisRequest( &status,
pAdapt->RealMiniportBindingHandle,
(PNDIS_REQUEST)&pNdisRequestEx );
if( status != NDIS_STATUS_PENDING )
{
ImRequestComplete( pAdapt, pNdisRequestEx, status );
}
else
{
NdisWaitEvent( &pNdisRequestEx->RequestEvent, 0 );
status = pNdisRequestEx->RequestStatus;
}
}
}
On 3/15/07, xxxxx@hotmail.com wrote:
>
> Thomas,
>
> > You must also make sure that you differentiate your private
> > requests from requests that originate from calls to
> MiniportQueryInformation
> > or MiniportSetInformation. In particular, in your
> ProtocolRequestComplete
> > handler you must make sure that you do not call
> > NdisMQueryInformationComplete then the request being completed is
one of
> > your private queries.
>
> Taking into consideration the fact that the OP just applied his
> modifications to the existing sample
> ( in this particular case, the one that you wrote), I am 99.9% sure
that
> the reason for BSOD lies with ProtocolRequestComplete() - apparently,
the OP
> just “forgot” to modify ProtocolRequestComplete(), so that it
> unconditionally indicates request completion to NDIS, no matter if
the
> request has has been originated by the bound protocols or if by the
IM
> driver itself.
> In other words, instead of writing his own code, the OP seems to
have
> thoughtlessly “modified” your sample without being bothered to
understand
> how it actually works, and now wonders why he gets BSOD…
>
> I don’t know about you, but I always write my own code from the
scratch
> and use samples only as a guidance - I always try to understand how
things
> work, so that blindly reusing the existing sample is just not the way
I do
> things. The OP seems to have a different approach to things…
>
> 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
>
—
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
As i I’ve said before, in general, i agree with Anton’s opinion in this
matter.
But i think that there are cases where you can really understand how things
work without writing them from scratch.
For this specific example, i took the pass through sample as a base to my
driver and put most it’s code under remark (almost all except drive entry
and the pt and mp function headers i think).
Then, I’ve read the MSDN, and asked several basic questions here, and
rewrote all the code blocks while relaying on the ideas presented in the
pass through example.
"The biggest problem I have with this style is that when one is familiar
with the source of the original code itself, it is difficult not to
assume that its reproduction is unmodified, which can get one in to all
sorts of trouble. "
It’s human to think this way, but as i wrote, this is not the ture in this
case.
By joining this forum i did not look for “easy life” or others to solve my
problems, but just for pure understanding and help in things i can’t figure
out myself.
On 3/15/07, Martin O’Brien wrote:
>
> ALL THAT FOLLOWS IS TOTALLY AN OPINION: Perhaps, but you’re committing
> aesthetic suicide, and in the process so not doing anyone who has to
> maintain your code any favors. For the most part, I’ve spent the ten
> years or so since leaving school reverse engineering things, and this
> has certainly warped my view on this subject. Fundamentally, I’m in
> agreement with Anton on this one - what can be gained in even just
> familarity if not understanding by some typing is so worth it. I’m no
> longer an independent consultant exactly, but when I was, this sort of
> thing was the most reliable sign that I should take the contract only if
> they were willing to rewrite, because, whether the code works or not, it
> destroys all of the intangibles that one (or at least I) has to use to
> make reasonable educated guesses in order to figure out where to start,
> or, in particular, whether one wants to start or move on to potentially
> greener pastures. Most importantly it destroys essentially all temporal
> information latent in coding style, so that it becomes outrageously
> difficult to figure out what is the work of the original author and what
> has been modified or added by someone else. This, for me, destroys the
> latent linguistic information, so to speak, that one can use to some
> extent speed read code reliably enough to figure out most of the time
> where to start easily an order of magnitude faster than could be by
> tracing or thorough analysis, assuming the code base is unfamiliar and
> significant in size. It makes comments, which under the best of
> practical and profitable circumstances are not terribly useful, a
> complete waste of time to the point of appearing to be disinformation.
> The biggest problem I have with this style is that when one is familiar
> with the source of the original code itself, it is difficult not to
> assume that its reproduction is unmodified, which can get one in to all
> sorts of trouble. An this source of error just keeps getting propagated
> with each generation. For an example (or two) of this, search for
> “Undocumented Windows NT” (perhaps the most pathological case, as the
> majority of it has major issues to begin with) on this list’s archive
> for examples of this.
>
> >>> xxxxx@gmail.com 2007-03-15 07:10 >>>
> Dear Anton,
>
> No douth that the approch you’ve described is the perfered one, even by
> me.
> But in this case, the described pocedure is exactly imlemented in the
> code,
> so after understanding it and tracing it i feel safe enough to use it:
>
> ( beginning of PtBindAdapter() )
>
>
> if( NdisRequest != &(pAdapt->Request) )
>
> {
>
> PNDIS_REQUEST_EX pLocalRequest = (PNDIS_REQUEST_EX)NdisRequest;
>
> NdisSetEvent( &pLocalRequest->RequestEvent );
>
> ( pLocalRequest->RequestCompleteHandler )( pAdapt,
> pLocalRequest,
> Status );
>
> return;
>
> }
>
> the problem is, that i even don’t see my PtCompleteRequest() being
> called.
> This is the request code… did i miss something ?
>
>
> if ( NDIS_STATUS_SUCCESS == Status )
>
> {
>
> if ( pAdapt->Medium == NdisMedium802_3)
>
> {
>
> NDIS_STATUS status;
>
> PUCHAR infoBuffer = NULL;
>
> PNDIS_REQUEST_EX pNdisRequestEx = NULL;
>
> NdisAllocateMemoryWithTag( (PVOID)&pNdisRequestEx,
> sizeof(NDIS_REQUEST_EX),
> NDIS_IM_TAG );
>
> ASSERT( NULL != pNdisRequestEx );
>
> NdisZeroMemory( pNdisRequestEx, sizeof(NDIS_REQUEST_EX));
>
> NdisAllocateMemoryWithTag( (PVOID)&infoBuffer, 100, NDIS_IM_TAG );
>
> ASSERT( NULL != infoBuffer );
>
> pNdisRequestEx->Request.RequestType = NdisRequestQueryInformation;
>
> pNdisRequestEx->Request.DATA.QUERY_INFORMATION.Oid =
> OID_802_3_CURRENT_ADDRESS;
>
> pNdisRequestEx->Request.DATA.QUERY_INFORMATION.InformationBuffer =
> infoBuffer;
>
> pNdisRequestEx->Request.DATA.QUERY_INFORMATION.InformationBufferLength
> =
> 100;
>
> pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesNeeded = 0;
>
> pNdisRequestEx->Request.DATA.QUERY_INFORMATION.BytesWritten = 0;
>
> pNdisRequestEx->RequestCompleteHandler = ImRequestComplete;
>
> pNdisRequestEx->RequestContext = NULL;
>
> NdisResetEvent( &pNdisRequestEx->RequestEvent );
>
> NdisRequest( &status,
>
> pAdapt->RealMiniportBindingHandle,
>
> (PNDIS_REQUEST)&pNdisRequestEx );
>
> if( status != NDIS_STATUS_PENDING )
>
> {
>
> ImRequestComplete( pAdapt, pNdisRequestEx, status );
>
> }
>
> else
>
> {
>
> NdisWaitEvent( &pNdisRequestEx->RequestEvent, 0 );
>
> status = pNdisRequestEx->RequestStatus;
>
> }
>
> }
>
> }
>
>
> On 3/15/07, xxxxx@hotmail.com wrote:
> >
> > Thomas,
> >
> > > You must also make sure that you differentiate your private
> > > requests from requests that originate from calls to
> > MiniportQueryInformation
> > > or MiniportSetInformation. In particular, in your
> > ProtocolRequestComplete
> > > handler you must make sure that you do not call
> > > NdisMQueryInformationComplete then the request being completed is
> one of
> > > your private queries.
> >
> > Taking into consideration the fact that the OP just applied his
> > modifications to the existing sample
> > ( in this particular case, the one that you wrote), I am 99.9% sure
> that
> > the reason for BSOD lies with ProtocolRequestComplete() - apparently,
> the OP
> > just “forgot” to modify ProtocolRequestComplete(), so that it
> > unconditionally indicates request completion to NDIS, no matter if
> the
> > request has has been originated by the bound protocols or if by the
> IM
> > driver itself.
> > In other words, instead of writing his own code, the OP seems to
> have
> > thoughtlessly “modified” your sample without being bothered to
> understand
> > how it actually works, and now wonders why he gets BSOD…
> >
> > I don’t know about you, but I always write my own code from the
> scratch
> > and use samples only as a guidance - I always try to understand how
> things
> > work, so that blindly reusing the existing sample is just not the way
> I do
> > things. The OP seems to have a different approach to things…
> >
> > 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
> >
>
> —
> 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 (and subsequent posters as well)-
>
I don’t know about you, but I always write my own code from the scratch and use samples only as a guidance
<<
Now that made my day! Nice to know I’m not the only one who thinks that way (I usually go so far as to say that if I have to refer to a code sample to understand something, then the accompanying documentation is potentially deficient).
Not a majority view though, in my own experience.
>This is the request code…
PNDIS_REQUEST_EX pNdisRequestEx = NULL;
NdisAllocateMemoryWithTag( (PVOID*)&pNdisRequestEx, sizeof(NDIS_REQUEST_EX),
NDIS_IM_TAG );
******
NdisRequest( &status, pAdapt->RealMiniportBindingHandle, (PNDIS_REQUEST)&pNdisRequestEx );
did i miss something ?
Look carefully at your code - you have dynamically allocated a structure, filled it … and now you pass *the address* of a pointer to this structure, rather than a pointer itself, to NdisRequest()…
Have you got any more questions about BSOD???
Anton Bassov