I am new to network driver development (Vista & XP) i am using sample winddk
code for NDIS filter driver but, i am unable to trace IRPs(IRP_MJ_CREATE) etc in
Dbgview, i have put debug print messages in other routines and can see them in
the logs but not in the case of IRP dispatch rotines… can anyone throw
some light in which way should i look or i need to do something different
…
wrote in message news:xxxxx@ntdev…
> I am new to network driver development (Vista & XP) i am using sample
> winddk
> code for NDIS filter driver but, i am unable to trace IRPs(IRP_MJ_CREATE)
> etc in
> Dbgview, i have put debug print messages in other routines and can see
> them in
> the logs but not in the case of IRP dispatch rotines… can anyone
> throw
> some light in which way should i look or i need to do something different
So your NDIS driver has a dispatch routine for IRP_MJ_CREATE etc.
where you put a dbgprint, and it doesn’t print, correct?
–PA
The simplest way is to put breakpoint into your dispatch routine and to see
if the IRP comes.
–
V.
This posting is provided “AS IS” with no warranties, and confers no
rights.
wrote in message news:xxxxx@ntdev…
>I am new to network driver development (Vista & XP) i am using sample
>winddk
> code for NDIS filter driver but, i am unable to trace IRPs(IRP_MJ_CREATE)
> etc in
> Dbgview, i have put debug print messages in other routines and can see
> them in
> the logs but not in the case of IRP dispatch rotines… can anyone
> throw
> some light in which way should i look or i need to do something different
> …
>
>
>
> i am using sample winddk code for NDIS filter driver but, i am unable to trace IRPs
(IRP_MJ_CREATE) etc in
Hardly surprising, taking into account that NDIS filters and miniports don’t receive IRP upon their “normal” operations - the only IRPs that they may receive are those that get sent to its control device object that is not a part of network stack, and it happens when some app opens it with CreateFile(). However, as long as we speak about “standard” network operations like sending and receiving data, filters don’t deal with IRPs of any description. If you want your IRP_MJ_CREATE handler to get invoked, you have to call CreateFile()
on its standalone control device from your app…
Anton Bassov
Yes my code has dispatch routine for IRP_MJ_create as:
NTSTATUS
FilterDispatch(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PIO_STACK_LOCATION IrpStack;
NTSTATUS Status = STATUS_SUCCESS;
DbgPrint(“==>FilterDispatch\n”);
UNREFERENCED_PARAMETER(DeviceObject);
IrpStack = IoGetCurrentIrpStackLocation(Irp);
switch (IrpStack->MajorFunction)
{
case IRP_MJ_CREATE:
DbgPrint(“==>FilterDispatch ::
IRP_MJ_CREATE\n”);
break;
case IRP_MJ_READ:
DbgPrint(“==>FilterDispatch :: IRP_MJ_READ\n”);
break;
case IRP_MJ_CLEANUP:
DbgPrint(“==>FilterDispatch ::
IRP_MJ_CLEANUP\n”);
break;
case IRP_MJ_CLOSE:
DbgPrint(“==>FilterDispatch :: IRP_MJ_CLOSE\n”);
break;
default:
break;
}
Irp->IoStatus.Status = Status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
DbgPrint(“<==FilterDispatch\n”);
return Status;
}
But it is not printing…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Friday, May 09, 2008 1:13 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS Network Driver Problem
wrote in message news:xxxxx@ntdev…
> I am new to network driver development (Vista & XP) i am using sample
> winddk
> code for NDIS filter driver but, i am unable to trace
IRPs(IRP_MJ_CREATE)
> etc in
> Dbgview, i have put debug print messages in other routines and can see
> them in
> the logs but not in the case of IRP dispatch rotines… can anyone
> throw
> some light in which way should i look or i need to do something
different
So your NDIS driver has a dispatch routine for IRP_MJ_CREATE etc.
where you put a dbgprint, and it doesn’t print, correct?
–PA
—
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
It is not going into code of dispatch routine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Volodymyr M.
Shcherbyna
Sent: Friday, May 09, 2008 1:15 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS Network Driver Problem
The simplest way is to put breakpoint into your dispatch routine and to
see
if the IRP comes.
–
V.
This posting is provided “AS IS” with no warranties, and confers no
rights.
wrote in message news:xxxxx@ntdev…
>I am new to network driver development (Vista & XP) i am using sample
>winddk
> code for NDIS filter driver but, i am unable to trace
IRPs(IRP_MJ_CREATE)
> etc in
> Dbgview, i have put debug print messages in other routines and can see
> them in
> the logs but not in the case of IRP dispatch rotines… can anyone
> throw
> some light in which way should i look or i need to do something
different
> …
>
>
>
—
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
> It is not going into code of dispatch routine
Please read my post carefully again, so that you will understand under what circumstances your dispatch routine is going to get invoked, and data sends/receives are none of them… Once your routine never gets invoked, it is hardly surprising that you never see debug message that it is supposed to print. All other routines are parts of normal network operations, so that you see their debug messages…
Anton Bassov
The articles “Extending the NDIS IM Driver Samples…” at http://www.wd-3.com may be helpful.
Thomas F. Divine
http://www.pcausa.com
(New samples unifying NDIS 5 and 6 filters and protocols are under development. Will be distributed under license…)
Thomas
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323732-
xxxxx@lists.osr.com] On Behalf Of xxxxx@rsystems.com
Sent: Friday, May 09, 2008 3:05 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS Network Driver ProblemI am new to network driver development (Vista & XP) i am using sample
winddk
code for NDIS filter driver but, i am unable to trace
IRPs(IRP_MJ_CREATE) etc in
Dbgview, i have put debug print messages in other routines and can see
them in
the logs but not in the case of IRP dispatch rotines… can anyone
throw
some light in which way should i look or i need to do something
different
…
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thomas,
The articles “Extending the NDIS IM Driver Samples…” at http://www.wd-3.com may be helpful.
…but only to those who want to understand what the code actually does. Unfortunately, it does not seem to be the case here - judging from the OP’s question, he just has no idea what the purpose of IRP handlers in NDIS filters is and what the sample he uses actually does. Let’s wait until he starts modifying it - I can imagine the questions he is going to ask then…
Anton Bassov
Anton,
Is it really necessary to malign people whom ask questions that are not that atypical of a new-comer to the confusing terminology of the NT driver programming?
The OP is likely struggling through discovering that PnP (WDM) “Filter Drivers” are completely unrelated to NDIS (IM) “Filter Drivers” and when that is understood, the OP will be pointed in the correct direction.
Likewise, when a developer with WDM knowledge finds themselves working in NDIS and has yet to realize that IRPs play almost no role in NDIS, especially not in data transfer, then, they tend to ask questions which reveal this.
Neither of these are reason to make comments like below.
When you were learning this stuff, did you ever ask a question to someone whom knew the answer and they derided you because you did not know the answer? If so, I feel sorry for you. They treated you poorly and you did not deserve that treatment, especially if you had the courage to admit you did not know and sought their help.
Perhaps you could just answer the questions as posed. If the question itself is ‘wrong’ (ie. Demonstrating naivety on the part of the ask-er), point that out along with an explanation of why.
In this case, the OP either
a) knows a lot more about what they are doing than they indicated. Perhaps they have really good reason to be ‘filtering’ IRPs to a NDIS (Miniport) Driver.
b) has not yet figured out that IRP filtering and NDIS packet filtering are totally different.
If you suspect (a), then, ask for clarification. If you suspect (b), then kindly point out the difference and wait for the new question.
But really, suggesting that the OP may not “… want to understand what the code actually does.” is presumptive and likely not true.
Civility and Community please.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, May 09, 2008 12:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS Network Driver Problem
Thomas,
The articles “Extending the NDIS IM Driver Samples…” at http://www.wd-3.com may be helpful.
…but only to those who want to understand what the code actually does. Unfortunately, it does not seem to be the case here - judging from the OP’s question, he just has no idea what the purpose of IRP handlers in NDIS filters is and what the sample he uses actually does. Let’s wait until he starts modifying it - I can imagine the questions he is going to ask then…
Anton Bassov
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
The DDK/WDK samples are highly useful and the documentation is better than in the past.
Nevertheless, the WDK is not well written from the perspective of “teaching”. And, as mentioned in other threads, there is no financial incentive for anyone in their right mind to consider writing books on these very specialized subjects.
The WDK/DDK samples have been successively enhanced to illustrate new techniques added by new versions of the OS. The samples look like a half-dozen developers made modifications over the past 12 years (probably true), and there is no consistency in style, naming conventions or techniques.
The NDIS samples are often functional, but for various reasons they may obscure the very NDIS library functions they should illustrate. Excessive use of MACROs leads to bloat and, in fact, obscures the primitive NDIS library functions that should be illustrated. For example, why should a newbie have to figure out that a NPROT_LOCK is really an alias for a NDIS_SPIN_LOCK. Ok, the MACRO does add some (possible) value - but would be better introduced at a later step when discussing debugging techniques.
When it comes to filter samples in general, and NDIS filter samples in particular, the WDK samples simply do nothing. This is OK, but there is actually a significant amount of work needed to extend the samples just a tiny bit further. For example, to add IRP queuing that is flushes itself properly on cleanup, unbind, pause, etc.
There is certainly no excuse for not reading the documentation and studying the WDK samples. But it is easy to understand why even a conscientious developer new to the Windows driver world would ask some fairly fundamental questions at first. We just need to see how well he or she learns.
Good luck to all!
Thomas F. Divine
http://www.pcausa.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323817-
xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, May 09, 2008 1:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] NDIS Network Driver ProblemAnton,
Is it really necessary to malign people whom ask questions that are not
that atypical of a new-comer to the confusing terminology of the NT
driver programming?The OP is likely struggling through discovering that PnP (WDM) “Filter
Drivers” are completely unrelated to NDIS (IM) “Filter Drivers” and
when that is understood, the OP will be pointed in the correct
direction.Likewise, when a developer with WDM knowledge finds themselves working
in NDIS and has yet to realize that IRPs play almost no role in NDIS,
especially not in data transfer, then, they tend to ask questions which
reveal this.Neither of these are reason to make comments like below.
When you were learning this stuff, did you ever ask a question to
someone whom knew the answer and they derided you because you did not
know the answer? If so, I feel sorry for you. They treated you poorly
and you did not deserve that treatment, especially if you had the
courage to admit you did not know and sought their help.Perhaps you could just answer the questions as posed. If the question
itself is ‘wrong’ (ie. Demonstrating naivety on the part of the ask-
er), point that out along with an explanation of why.In this case, the OP either
a) knows a lot more about what they are doing than they indicated.
Perhaps they have really good reason to be ‘filtering’ IRPs to a NDIS
(Miniport) Driver.b) has not yet figured out that IRP filtering and NDIS packet filtering
are totally different.If you suspect (a), then, ask for clarification. If you suspect (b),
then kindly point out the difference and wait for the new question.But really, suggesting that the OP may not “… want to understand what
the code actually does.” is presumptive and likely not true.Civility and Community please.
-dave-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323812-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, May 09, 2008 12:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS Network Driver ProblemThomas,
> The articles “Extending the NDIS IM Driver Samples…” at
http://www.wd-3.com may be helpful.…but only to those who want to understand what the code actually
does. Unfortunately, it does not seem to be the case here - judging
from the OP’s question, he just has no idea what the purpose of IRP
handlers in NDIS filters is and what the sample he uses actually does.
Let’s wait until he starts modifying it - I can imagine the questions
he is going to ask then…Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
David,
When you were learning this stuff, did you ever ask a question to someone whom knew
the answer and they derided you because you did not know the answer?
Nope…
If I had someone around whom I could ask a technical question and get more-or-less sensible answer to it, I would be really happy, no matter in which form it would have been given. However, somehow it happened that I had to learn everything - from basics of programming in VBA to kernel-level development- on my own. Assuming that you are located in the US West Coast, you should realize that not everyone is as lucky as you are - you, indeed, have a chance to meet the world’s top experts face-to- face wherever you go, so that you can just ask questions and get tested and ready-to-use recipes.
However, it does not work this way in other parts of the world. If you go, say, to Western Europe, you are not going to find that many people who understand what the OS actually does, let alone those who are able to write drivers. The best you can reasonably expect is to meet someone who does UM development in C or C++ and is aware of the concept of system calls (the way transition is made and what happens next is,certainly, already a mystery to them - any expectation of something beyond that is already from the field of unreasonable, because kernel-level developer is really ,really rare beast in this part of the world ). What you are mainly going to see here are .NET and Java “gurus” who do web/database development and don’t know anything above their language’s runtime library, SQL and scripting languages, despite having worked with computers for at least 10 years…
If so, I feel sorry for you. They treated you poorly and you did not deserve that treatment,
especially if you had the courage to admit you did not know and sought their help.
As you can see, the only reason why you may feel sorry for me is because I have to figure out everything myself. Hopefully, it also explains my irritation with those posters who prefer to rely upon the external help.
More on it below
The OP is likely struggling through discovering that PnP (WDM) “Filter Drivers” are completely >unrelated to NDIS (IM) “Filter Drivers” and when that is understood, the OP will be pointed in the correct >direction. Likewise, when a developer with WDM knowledge finds themselves working in NDIS and has >yet to realize that IRPs play almost no role in NDIS, especially not in data transfer, then, they tend to ask >questions which reveal this.
…
But really, suggesting that the OP may not “… want to understand what the code actually does.” is >presumptive and likely not true.
In fact, there is nothing to struggle with here yet. Let’s face it - when you look at some code sample that deals with architecture that you are totally unfamiliar with, it would not be too unreasonable to expect you to at least read MSDN documentation of all API calls that your target sample makes, so that you get at least some idea of what your target sample actually does. If the OP did it he would have understood that all IRPs in his sample are related to standalone device and not to the actual network operations.
When it comes to struggling, I would expect him to struggle with something that is worth it - NDIS, indeed, has quite a few not-so-obvious things that are not mentioned in documentation (for example, why NdisGetReceivedPacket() may return NULL and what has to be done in this case). However, what he asks are just basic questions that he could have easily avoided if he bothered to study his target sample carefully…
Anton Bassov
Humm…
Anton,
If you think that most of us who provide help on this list actually get to meet each other often, then you are mistaken. Possibly some can go to the WinHEC marketing show each year - but certainly not myself.
Do we chat privately off-list and give each other “inside information”? Perhaps once a decade.
If you think that most of us who provide help on this list learned what we are doing without going through the same painful “experimental” learning process that you describe, then that would probably be a rare individual.
Believe me, it is lonely here in my office with a bunch of machines and no one to talk with.
Do I get answers from this list? Rarely, and then most often from an expert who says that what I want to do cannot be achieved.
In this particular development area we are all essentially equally disadvantaged in the area of available information. Of course, I do have more than one PC, which gives me an advantage over some on this list. 
There are a few notable exceptions, of course. Employees of Microsoft and a few other giants may have someone around that helps - but even in those cases the person having a question may be half the world away and not know that there was a question to be asked. It is amazing how badly organized some big companies really are.
The key virtue I think: patience.
Warmest regards,
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323847-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, May 09, 2008 6:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] NDIS Network Driver ProblemDavid,
> When you were learning this stuff, did you ever ask a question to
someone whom knew
> the answer and they derided you because you did not know the answer?Nope…
If I had someone around whom I could ask a technical question and get
more-or-less sensible answer to it, I would be really happy, no matter
in which form it would have been given. However, somehow it happened
that I had to learn everything - from basics of programming in VBA to
kernel-level development- on my own. Assuming that you are located in
the US West Coast, you should realize that not everyone is as lucky as
you are - you, indeed, have a chance to meet the world’s top experts
face-to- face wherever you go, so that you can just ask questions and
get tested and ready-to-use recipes.However, it does not work this way in other parts of the world. If you
go, say, to Western Europe, you are not going to find that many people
who understand what the OS actually does, let alone those who are able
to write drivers. The best you can reasonably expect is to meet someone
who does UM development in C or C++ and is aware of the concept of
system calls (the way transition is made and what happens next
is,certainly, already a mystery to them - any expectation of something
beyond that is already from the field of unreasonable, because kernel-
level developer is really ,really rare beast in this part of the world
). What you are mainly going to see here are .NET and Java “gurus” who
do web/database development and don’t know anything above their
language’s runtime library, SQL and scripting languages, despite having
worked with computers for at least 10 years…> If so, I feel sorry for you. They treated you poorly and you did not
deserve that treatment,
>especially if you had the courage to admit you did not know and sought
their help.As you can see, the only reason why you may feel sorry for me is
because I have to figure out everything myself. Hopefully, it also
explains my irritation with those posters who prefer to rely upon the
external help.
More on it below> The OP is likely struggling through discovering that PnP (WDM)
“Filter Drivers” are completely >unrelated to NDIS (IM) “Filter
Drivers” and when that is understood, the OP will be pointed in the
correct >direction. Likewise, when a developer with WDM knowledge finds
themselves working in NDIS and has >yet to realize that IRPs play
almost no role in NDIS, especially not in data transfer, then, they
tend to ask >questions which reveal this.…
> But really, suggesting that the OP may not “… want to understand
what the code actually does.” is >presumptive and likely not true.In fact, there is nothing to struggle with here yet. Let’s face it -
when you look at some code sample that deals with architecture that you
are totally unfamiliar with, it would not be too unreasonable to expect
you to at least read MSDN documentation of all API calls that your
target sample makes, so that you get at least some idea of what your
target sample actually does. If the OP did it he would have understood
that all IRPs in his sample are related to standalone device and not to
the actual network operations.When it comes to struggling, I would expect him to struggle with
something that is worth it - NDIS, indeed, has quite a few not-so-
obvious things that are not mentioned in documentation (for example,
why NdisGetReceivedPacket() may return NULL and what has to be done in
this case). However, what he asks are just basic questions that he
could have easily avoided if he bothered to study his target sample
carefully…Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I actually like being isolated in my cave. I growl at the other apes that
wander too close.
On Fri, May 9, 2008 at 6:33 PM, Thomas F. Divine wrote:
> Humm…
>
> Anton,
>
> If you think that most of us who provide help on this list actually get to
> meet each other often, then you are mistaken. Possibly some can go to the
> WinHEC marketing show each year - but certainly not myself.
>
> Do we chat privately off-list and give each other “inside information”?
> Perhaps once a decade.
>
> If you think that most of us who provide help on this list learned what we
> are doing without going through the same painful “experimental” learning
> process that you describe, then that would probably be a rare individual.
>
> Believe me, it is lonely here in my office with a bunch of machines and no
> one to talk with.
>
> Do I get answers from this list? Rarely, and then most often from an expert
> who says that what I want to do cannot be achieved.
>
> In this particular development area we are all essentially equally
> disadvantaged in the area of available information. Of course, I do have
> more than one PC, which gives me an advantage over some on this list.
>
> There are a few notable exceptions, of course. Employees of Microsoft and a
> few other giants may have someone around that helps - but even in those
> cases the person having a question may be half the world away and not know
> that there was a question to be asked. It is amazing how badly organized
> some big companies really are.
>
> The key virtue I think: patience.
>
> Warmest regards,
>
> Thomas F. Divine
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-323847-
> > xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
> > Sent: Friday, May 09, 2008 6:15 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE:[ntdev] NDIS Network Driver Problem
> >
> > David,
> >
> > > When you were learning this stuff, did you ever ask a question to
> > someone whom knew
> > > the answer and they derided you because you did not know the answer?
> >
> > Nope…
> >
> > If I had someone around whom I could ask a technical question and get
> > more-or-less sensible answer to it, I would be really happy, no matter
> > in which form it would have been given. However, somehow it happened
> > that I had to learn everything - from basics of programming in VBA to
> > kernel-level development- on my own. Assuming that you are located in
> > the US West Coast, you should realize that not everyone is as lucky as
> > you are - you, indeed, have a chance to meet the world’s top experts
> > face-to- face wherever you go, so that you can just ask questions and
> > get tested and ready-to-use recipes.
> >
> >
> > However, it does not work this way in other parts of the world. If you
> > go, say, to Western Europe, you are not going to find that many people
> > who understand what the OS actually does, let alone those who are able
> > to write drivers. The best you can reasonably expect is to meet someone
> > who does UM development in C or C++ and is aware of the concept of
> > system calls (the way transition is made and what happens next
> > is,certainly, already a mystery to them - any expectation of something
> > beyond that is already from the field of unreasonable, because kernel-
> > level developer is really ,really rare beast in this part of the world
> > ). What you are mainly going to see here are .NET and Java “gurus” who
> > do web/database development and don’t know anything above their
> > language’s runtime library, SQL and scripting languages, despite having
> > worked with computers for at least 10 years…
> >
> >
> > > If so, I feel sorry for you. They treated you poorly and you did not
> > deserve that treatment,
> > >especially if you had the courage to admit you did not know and sought
> > their help.
> >
> > As you can see, the only reason why you may feel sorry for me is
> > because I have to figure out everything myself. Hopefully, it also
> > explains my irritation with those posters who prefer to rely upon the
> > external help.
> > More on it below
> >
> > > The OP is likely struggling through discovering that PnP (WDM)
> > “Filter Drivers” are completely >unrelated to NDIS (IM) “Filter
> > Drivers” and when that is understood, the OP will be pointed in the
> > correct >direction. Likewise, when a developer with WDM knowledge finds
> > themselves working in NDIS and has >yet to realize that IRPs play
> > almost no role in NDIS, especially not in data transfer, then, they
> > tend to ask >questions which reveal this.
> >
> > …
> >
> > > But really, suggesting that the OP may not “… want to understand
> > what the code actually does.” is >presumptive and likely not true.
> >
> > In fact, there is nothing to struggle with here yet. Let’s face it -
> > when you look at some code sample that deals with architecture that you
> > are totally unfamiliar with, it would not be too unreasonable to expect
> > you to at least read MSDN documentation of all API calls that your
> > target sample makes, so that you get at least some idea of what your
> > target sample actually does. If the OP did it he would have understood
> > that all IRPs in his sample are related to standalone device and not to
> > the actual network operations.
> >
> > When it comes to struggling, I would expect him to struggle with
> > something that is worth it - NDIS, indeed, has quite a few not-so-
> > obvious things that are not mentioned in documentation (for example,
> > why NdisGetReceivedPacket() may return NULL and what has to be done in
> > this case). However, what he asks are just basic questions that he
> > could have easily avoided if he bothered to study his target sample
> > carefully…
> >
> >
> > Anton Bassov
> >
> >
> >
> >
> > —
> > 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
>
>
> —
> 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
>
–
Mark Roddy
Thomas,
If you think that most of us who provide help on this list learned what we are doing without going through >the same painful “experimental” learning process that you describe, then that would probably
be a rare individual.
Imagine working for some major chip-maker in Silicon Valley…
Unless your problem happens to be really extra-ordinary, you will hardly look for an answer in a NG, let alone proceed to time-consuming research on your own, simply because you are more than likely to get help from your collegue who sits right next desk to you. At the same time, I do see what you mean - I am not so sure major chip-makers will be bothered to hire a newbie and train him/her if they can just hire an experienced engineer and get the job done quickly, so that, in order to reach this level you still have to learn everything on your own and go through above mentioned painful process …
Believe me, it is lonely here in my office with a bunch of machines and no one to talk with.
The way I understand it, you are located in Georgia, so that you are at least 3000 miles (or maybe even more) away from Silicon Valley, and, hence, apparently, are in exactly the same position as kernel -level developers in Europe…
Anton Bassov