Driver Programming Fundamentals/Philosophy, was: Re: Calling NdisRequest() from ProtoclBindAdapter()

[OSR_Community_User]

Bob Kjelgaard schrieb:

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.

Excellent view!

May I please add a few comments? Thanks:

Assumption 1:

• Very few people in this world solely earn their living writing
  operating systems / OS drivers. (Or training others how to do so.)

Assumption 2:

• You have a relatively simple device
• You need a driver relatively quickly
• You need to be compatible to a lot of OS versions of MS WIndows™
• You can not spend 3-12 months for thoroughly learning and trying
  out how to write OS drivers from scratch for all OS versions you have to
  support.

Then what do you do?

• In other domains, e.g. hardware design, it is usually a good start to
  use an “application note” or an approved “reference design”.

• For OS drivers a “code sample” from the WDK as a starting point is the
  logical choice.

• With something that works at hand now you have time to understand some
  of the finer details and intrinsics, and thus can gradually modify or
  re-write the sample so it eventually becomes “your” driver.

• But even then it might be desirable to keep the general structure of
  the driver close to the sample you used as a starting point. Why?
  – With the next incarnation of the OS and its DDK/WDK the sample will
  have been adapted to reflect the necessities of the new platform.
  – Corrections will have been implemented from the feedback of other
  people who used the sample before.

• If the structure remains close, you or your “code mainenance
  successor” has a chance to factor in these changes (where necessary)
  into “your” driver.

IMO this is not necessarily the “good way” of driver programming.
But it is IMO efficient and acceptable,

• as long as you are careful which samples you use,
• where you get them from (e.g. only WDK/DDK samples),
• and if you document your changes and your rationale somewhere.

(Of course there are enough “oh nice, I can just copy this, twiddle a
bit and it runs somehow”-mentality people in this world. The ‘duct-tape’
types. We are not talking about them.)

Another facet of the problem is of course the question:

“Do I need to become a ‘Ph.D. in Driver Programming’ if what I want to
do is just to send a few bytes to my device and get a few bytes back?”

Yes, I understand that WDM, KMDF and WUDF are a big step towards “make
simple things relatively easily” paradigm.

But until we are completely there, people will_have_to use
templates/samples and modify code. Out of necessity.

Driver programming is a complex issue in a modern world of SMP and
multi-tasking OSs.

Remember Assuption 1? Most people also need to do something else for
their living except driver writing, and don’t have time to learn how to
write PnP, Power Management, WMI, OS-version-abstraction, topics of your choice> code that does not directly contribute to their
device-specific operations.

They actually develop a device. Main focus is NOT a driver - it is an
important prerequisite, but not the main star of the show. There is
hardware, and firmware, possibly an application, and possibly customer
hardware you have to interface to.
And MS Windows™ might not even be the only platform you have to
develop a driver for.
Heresy, I know, but it is known to have happened before!

And this is exactly where frameworks come into the picture - so that you
don’t need to cater for “standard” things that should be handled in a
“standard” way anyway.

Hah! We do_have frameworks, don’t we? What do you say now?

Q: I need to support everything from Win98SE up to Vista64. Can I use WUDF?
A: No, it’s just available for Vista and XP. (For XP and USB only with a
co-installer / update that is ~2.7 MB.)

Q: Can I use KMDF, then?
A: No, it is only available for Vista, XP, Server 2003 and Win2000.

Q: So is there a framework I can use if I need to support WinME and
Win98SE as well?
A: No, you have to use at least WDM.

Q: Will this work on Win98SE as well?
A: Can do, actually quite well, if you buy Walter Oneys WDM programming
book and get WDMSTUB.SYS and USBD98.LIB.

Q: Can I at least use a decent code sample and get something that works
without having to understand every detail of PnP/WMI/PWR from Win98SE
up to Vista64?
A: Yes, you can use the sample code from the WDK. But you should not.
Bob and Martin say you should learn everything about how to write all
finer intrinsics of any OS version you need to support, and write your
own code, using the WDK sample only as a reference/demo.

Q: Well… sounds good, but I am neither a Trainer nor Microsoft Windows
OS Programmer - what do I do if my boss does not want me to?
A: What???

Kindest Regards to you two… SCNR.
-H

[OSR_Community_User]

Hagen-

You expressed your points well- my apologies if some of this reply seems a bit inflammatory- there’s just some bitter experience tied up in this issue for me. I certainly mean no disrespect.

The core of my response to your post is this:

>
Assumption 1:

• Very few people in this world solely earn their living writing
  operating systems / OS drivers. (Or training others how to do so.)
  <<

Having spent a [for the most part intensely depressing] part of my life trying to do exactly that, I’ll add this. I love the fact that people who wouldn’t hire a plumber to wire their house or ask the guy who mows their lawn to fix their TV set feel perfectly comfortable having an inexperienced (in that field) programmer who did a good job on the last UI they needed write a program that sits at the very heart and soul of their mission critical systems. Then tell me that I charge too much, and I’m overestimating the work needed to do the task [especially when I know my tendency is underestimating- ALWAYS has been], and basically that my services won’t be needed as a result.

Sometimes I would get to clean up afterwards (but I never referred to the initial decision- it never struck me as good business to tell your customer he or she is or was a fool). But I was still charging too much and…

My short opinion: there are always plenty of reasons available to justify whatever course of action one wishes to take- wise or not. So I’m expressing opinions and beliefs, not guidelines or rules or laws or facts or… I’m not saying it’s the “best way”. I’m not even convinced there actually is a single “best way”.

Moreover, in my case, I do (and always have) done more than just drivers, and I take the same approach to user mode code. If I have to read a code sample to write a shell extension, then (IMO) the documentation sucks [I didn’t have to, so IMO, it didn’t then, and it’s probably even better now]. When I wrote the [initial, anyway] ICM extensions for 98/Win2K [which I once thought was the only visual impact I’d ever have on Windows], the first thing I did was groan when I saw the existing one [of course I was given a sample, how else could one possibly want to learn how to do something?]. It was straight from the original SDK sample- variable names (which in this instance were utterly non-mnemonic), comments, and all. Even the parts that weren’t being used. Whoever did it probably met the schedule date, though- that’s a plus. And of course, I have no idea what they thought of it, or under what circumstances they made those choices. My point being that I have certainly since realized that I might have done the same as they did under the circumstances.

At least now I’m mature enough to usually keep the groaning to myself, perhaps.

I’ve seen even sadder things than that over my lifetime in this business, particularly in printer drivers (using the NT 3.x/4 Postscript driver BitBlt code in a banding driver with a GDI-managed surface, for instance).

I know- I stubbornly try to learn things my own way, and it is usually the hard way. I’ve heard all the arguments before, and I choose not to agree and usually (this is an exception) not to even argue- some discussions bear little fruit.

Off topic, of course, but the flip side of my initial rant is also quite fun. When things get tight in the job market, these same people will not even talk to you if they want a left-handed monkey wrench, and all you have ever built are right-handed ones. Had to say that for some reason…

Bottom line- I do not expect my views to influence anyone in the subject. Ever. Which is why it’s nice to see someone else state similar views occasionally- even us lunatic fringe loners occasionally like confirmation… Hurray for the internet!

[anton_bassov]

Hagen,

I am afraid you took my statement about writing your own drivers a bit too literally…

I don’t see any problem with modelling your driver upon some existing WDK sample whatsoever. Actually, if your driver is meant to expose add-on functionality to some WDK sample, there is a good chance that your code will be more or less similar to that in WDK anyway, even if you haven’t seen the sample code - after all, both you and sample writer have followed the same design guidelines…

What I do see a problem with is just blindly reusing the existing sample, without even trying to understand how it works, and this is what I was speaking about. More on this below…

Assumption 1:

• Very few people in this world solely earn their living writing
  operating systems / OS drivers.

Remember Assuption 1? Most people also need to do something else for
their living except driver writing, and don’t have time to learn how to
write PnP, Power Management, WMI, OS-version-abstraction, > topics of your choice> code that does not directly contribute to their
> device-specific operations.

Unfortunately, this argument is just a logical fallacy…

Introducing some additional feature to a sample may come into conflict with the existing implementation, so that the code has to be adjusted in more than in one place. For example, if you want to send your own packets from the original passthu, you have to modify PtSendComplete() handler in order to make a discinction between your own sends and the ones originated by bound protocols. Someone who does not understand how NDIS works would hardly know it. Does he has any option, other than learning NDIS fundamentals???

> Q: Well… sounds good, but I am neither a Trainer nor Microsoft Windows
> OS Programmer - what do I do if my boss does not want me to?

Well, the answer seems to be obvious - either learn or just give it up. A chance of writing a workable driver without understanding how it actually works is critically close to zero…

Anton Bassov

[Calvin_Guan]

> They actually develop a device. Main focus is NOT a driver - it is an

important prerequisite, but not the main star of the show. There is
hardware, and firmware, possibly an application, and possibly customer
hardware you have to interface to.
And MS Windows™ might not even be the only platform you have to
develop a driver for.

I figured this is one of the nicest comments. I think driver writers for
silicon vendors who produce complex chips definitely hear you. A driver
engineer in such firm would spend most of their time dealing with h/w
platform issues of either their own or 3rd party’s. Of course getting a
stable driver needs some level of expertise in the OS/driver programming
but that’s NOT the star of the show. Fortunately, I can afford to spend
huge amount time learning WDM and other MSFT stuff in my early career
stage by writing every single line of code and poking around the os by
windbg/sice simply because my labor was cheap and the H/W works wasn’t
that pushy at that time. This learning approach in a fast paced
Californian chip company is nearly impossible.

Q: Well… sounds good, but I am neither a Trainer nor Microsoft
Windows
OS Programmer - what do I do if my boss does not want me to?
A: What???

Just hire someone who knows what he’s doing for the initial work and
fire him if he has no more value after the project flew. That sucks but
it’s the way the business goes.

Calvin Guan (expiring DDK MVP)
NetXtreme NTX Miniport
Broadcom Corporation
Connecting Everything(r)

[Tim_Roberts]

Calvin (Hao) Guan wrote:

Just hire someone who knows what he’s doing for the initial work and
fire him if he has no more value after the project flew. That sucks but
it’s the way the business goes.

As a consulting driver writer, that’s how a lot of my projects go. I am
perfectly willing to take the blame for you, as long as your checks cash.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[anton_bassov]

> This learning approach in a fast paced Californian chip company is nearly impossible.

Yes, but why should a fast-paced company appoint someone who has no clue about driver programming for the job? Is not it better for them just to hire someone with in-depth knowledge of the subject (hiring does not necessarily mean long-term employment), rather than trusting this job to someone who has very little (if any) knowledge of kernel-mode programming? Actually, your statement below explains how things normally happen (and, IMHO, should be happenning - I don’t see anything wrong with it whatsoever, so that I just don’t know why you believe it sucks) in business

Just hire someone who knows what he’s doing for the initial work and
fire him if he has no more value after the project flew. That sucks but
it’s the way the business goes.

Exactly…

This is the most reasonable approach for the company, and such solution suits everyone…

Anton Bassov

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Bob Kjelgaard[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, March 15, 2007 2:38 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] Calling NdisRequest() from ProtoclBindAdapter() - Possible?

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.

Mine too. I read whole thread and although I understand the opposite view, my experience says modifying samples for any project which should persist more than a year is really bad idea. I did it once and it was the worst engineering decision I ever made. Several years before we needed USB driver with selective suspend support quickly for some demonstration purposes so I modified BulkUsb DDK sample. Customers were happy with demonstration and wanted the signed driver quickly. So we did. Since then I discovered many bugs, rewrote almost half of crappy code and all the time I regret I didn’t write it from scratch, instead. Half of the bugs could be avoided by careful reading of the docs which I’d do. The second part was caused by flawed design apparently coming from w9x world. The rest were usually race conditions of different kind. I’d make my own bugs for sure but it’d be much easier to find them than trying to understand every detail of code written by somebody else. The conclusion was I saved some time at the beginning and lost much more within next few years. Unfortunately, I had no chance to throw it away and write it again and better.

Never more DDK/WDK samples. As a reference, maybe. Personally, I prefer WinCE model when OS sources are available (well, mostly) and there are no driver samples to start with. Just OS ones.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[OSR_Community_User]

On Mar 19, 2007, at 7:57 PM, Michal Vodicka wrote:

> 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.
>
Mine too. I read whole thread and although I understand the
opposite view, my experience says modifying samples for any project
which should persist more than a year is really bad idea. I did it
once and it was the worst engineering decision I ever made. Several
years before we needed USB driver with selective suspend support
quickly for some demonstration purposes so I modified BulkUsb DDK
sample. Customers were happy with demonstration and wanted the
signed driver quickly. So we did. Since then I discovered many
bugs, rewrote almost half of crappy code and all the time I regret
I didn’t write it from scratch, instead. Half of the bugs could be
avoided by careful reading of the docs which I’d do. The second
part was caused by flawed design apparently coming from w9x world.
The rest were usually race conditions of different kind. I’d make
my own bugs for sure but it’d be much easier to find them than
trying to understand every detail of code written by somebody else.
The conclusion was I saved some time at the beginning and lost much
more within next few years. Unfortunately, I had no chance to throw
it away and write it again and better.

I wish this were true more often, and it’s a fantastic idea in
principle, but reality rears its ugly head from time to time.

Take the NDIS IM sample driver (Passthru). IM drivers, and especially
those that use control device objects (as demonstrated in Passthru)
are very hard to get right. There are lots of subtle synchronization
issues, and it’s obviously a perf-critical stack, so not over-doing
synchronization is almost as important as not under-doing it. With
all of the variations on packet handling - legacy indications, multi-
packet indications, stacking, etc. - and OS variations - it’s very
hard to do a correct IM from scratch. I only know of a few that are
successful.

Sometimes, for the sake of the whole community, it’s better for
people to lean on samples. (BOCTAOE, as Scott Adams says.)

-sd

[Michal_Vodicka-2]

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Steve Dispensa[SMTP:xxxxx@positivenetworks.net]
Reply To: Windows System Software Devs Interest List
Sent: Tuesday, March 20, 2007 3:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Calling NdisRequest() from ProtoclBindAdapter() - Possible?

Take the NDIS IM sample driver (Passthru). IM drivers, and especially
those that use control device objects (as demonstrated in Passthru)
are very hard to get right. There are lots of subtle synchronization
issues, and it’s obviously a perf-critical stack, so not over-doing
synchronization is almost as important as not under-doing it. With
all of the variations on packet handling - legacy indications, multi-
packet indications, stacking, etc. - and OS variations - it’s very
hard to do a correct IM from scratch. I only know of a few that are
successful.

Good example. I had to write IM driver from scratch for NT 3.51 and then for NT4 because there was no example then. Then updated it using undocumented info from the first sample (IMSamp?). This was it worked well for both NT4 SP3+ and w2k and even with NdisWan. Then our company changed and we stopped support for this kind of software.

It wasn’t an easy task but I learnt a lot and I understood how things worked. Then I read many questions from hopeless people here who modified Passthru sample and weren’t able to make it working. Or worse, make it working correctly. Because the didn’t understand how things work. Without the sample they’d be completely lost and it’d be better because their miserable drivers wouldn’t be available.

Sometimes, for the sake of the whole community, it’s better for
people to lean on samples. (BOCTAOE, as Scott Adams says.)

I don’t think so. It allows incompetent people to write drivers without real understanding. We can see an example here every week or two. And even if they understand, the result depend on the quality of the samples. Which isn’t good enough in some cases. I’m affraid in the most cases, except, maybe, real OS drivers which are included in WDK as samples.

KMDF is a way to go. Well debugged and tested generic code which makes driver development easier. Still there are bugs as we can see here and it’ll take time until it is really stable. Way to go if lawyers don’t make the stupid decision and sources are available :-/ And if static linking is possible; I read the explanation why it isn’t and I still disagree. Two reasons why I won’t use it and prefer writing code from scratch.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

[anton_bassov]

Steve,

IM drivers, and especially those that use control device objects (as demonstrated in Passthru)
are very hard to get right. There are lots of subtle synchronization issues, and it’s
obviously a > perf-critical stack, so not over-doing synchronization is almost as important as not > under-doing it. With all of the variations on packet handling - legacy indications, multi-
packet indications, stacking, etc. - and OS variations - it’s very
hard to do a correct IM from scratch .I only know of a few that are successful.

Indeed, NDIS IM is not the easiest thing to write properly, so to say - you say that you know only a few who were successfull here. However, do you know a *SINGLE* success story of someone who had just modified the existing PASSTHRU sample without even understanding how it actually works… and, surprizingly enough, got a fully functional driver that works flawlessly on various OS flavours and network adapters, without developing interops with third-party drivers???
I think you don’t - after all, such “success story” seems to be just infeasible…

Therefore, I believe Hagen’s argument of using the existing samples in order to avoid learning
is totally wrong…

Sometimes, for the sake of the whole community, it’s better for people to lean on samples.

Well, as long as they use these samples for the purpose of education, I fully agree with you.
However, if they use these samples as a production code without even understanding how they work… well, to be honest, I would not like to come across such “masterpiece”, especially if it happens to be a miniport driver

Anton Bassov

[OSR_Community_User]

xxxxx@hotmail.com wrote:

Therefore, I believe Hagen’s argument of using the existing samples in order to avoid learning
is totally wrong…

NB: I am definitely not against learning how to write proper driver code.

But still it beats me why it should be necessary to learn every single
line of standard “framework grade” housekeeping code, that solely
needs to be present to placify the OS mechanisms, but does not
contribute to the actual main task.

MS has IMHO realised this and therefore does try to alleviate a lot of
standard work (by offering KMDF and WUDF).

Or do you suggest to “just reinvent the wheel, so you fully understand
how nicely shaped that round outer surface has to be”? I believe not.

> Sometimes, for the sake of the whole community, it’s better for people to lean on samples.

Well, as long as they use these samples for the purpose of education, I fully agree with you.
However, if they use these samples as a production code without even understanding how they work…
well, to be honest, I would not like to come across such “masterpiece”, especially if it
happens to be a miniport driver

Of course. On the other hand the “samples” should actually be
production-grade (if not excplicitly documented otherwise).
And even if most samples are just “code snippets”, then there should
definitely come some production-grade ones so you can see how such a
thing looks. (And if they only serve as a “checklist” to see if you
forgot something, then that’s a good reason to have them.)

BTW, do I understand correctly from your comment that either
(a) the NDIS miniport samples are so bad that nobody can reasonably use
them, or
(b) the whole NDIS miniport concept is so difficult and flexible that so
much would have to be modified for any given device that everything has
to be written from scratch anyway?
Or (c) both?
In either case, I’d agree with you. Better write the stuff from scratch.

But for a standard device (e.g. yet another USB keyboard flavour with a
single additional button and another green backlight) I wonder whether
it is really necessary to write everything from scratch.

Don’t get me wrong, it is certainly desirable (and I feel privileged
that I actually get a lot of time for this) to learn about driver
programming.

But in many cases it should actually not be necessary to do so, and
that was the core of my argument. Samples are useful. Or should at least
be.

[anton_bassov]

Hagen,

On the other hand the “samples” should actually be production-grade

The biggest problem that even a slight modification can turn a perfectly workable and bug-free production-grade sample driver into a piece of crap if someone who applied this modification does not understand how the sample actually works…

BTW, do I understand correctly from your comment that either
(a) the NDIS miniport samples are so bad that nobody can reasonably use them, or
(b) the whole NDIS miniport concept is so difficult and flexible that so
much would have to be modified for any given device that everything has
to be written from scratch anyway?
Or (c) both?

Actually, the answer is (d)|: None of the above.

The problem is that even well-written NDIS IM may get into a trouble with poorly written miniport driver. As I have already said, someone who has no clue about NDIS may apply his “modifications”
to a workable miniport sample, effectively turning it into a piece of crap. Therefore, if your well-written NDIS IM has a misfortune to be bound to such miniport, it may take you quite a while to figure out what is going on - after all, your IM works fine with all adapters apart from this particular one…

Anton Bassov

[bank_kus]

I mean this in a good way but, in depth knowledge of *WHAT*?? What exactly
is the definition of *kernel mode* programming.

How difficult is it for a guy with a solid CS background and a good
understanding of OS / comp architecture to pickup an API? I fail to see
what is so rocket science about it. More often than not driver writers bang
registers from 1000 page manuals written by RTL programmers and designed by
a bunch of architects ( which I believe is the difficult part and includes
understanding of good *science* )

banks

wrote in message news:xxxxx@ntdev…
>> This learning approach in a fast paced Californian chip company is nearly
>> impossible.
>
> Yes, but why should a fast-paced company appoint someone who has no clue
> about driver programming for the job? Is not it better for them just to
> hire someone with in-depth knowledge of the subject (hiring does not
> necessarily mean long-term employment), rather than trusting this job to
> someone who has very little (if any) knowledge of kernel-mode programming?
> Actually, your statement below explains how things normally happen (and,
> IMHO, should be happenning - I don’t see anything wrong with it
> whatsoever, so that I just don’t know why you believe it sucks) in
> business
>
>> Just hire someone who knows what he’s doing for the initial work and
>> fire him if he has no more value after the project flew. That sucks but
>> it’s the way the business goes.
>
>
> Exactly…
>
> This is the most reasonable approach for the company, and such solution
> suits everyone…
>
> Anton Bassov
>
>

[Don_Burn_1]

“bank kus” wrote in message news:xxxxx@ntdev…
>I mean this in a good way but, in depth knowledge of WHAT?? What exactly
>is the definition of kernel mode programming.
>
> How difficult is it for a guy with a solid CS background and a good
> understanding of OS / comp architecture to pickup an API? I fail to see
> what is so rocket science about it. More often than not driver writers
> bang registers from 1000 page manuals written by RTL programmers and
> designed by a bunch of architects ( which I believe is the difficult part
> and includes understanding of good science )
>

I will add you to my list of people who I ask to please tell me the
products that you work on, so I can be sure to avoid them and tell my
customers to. Sorry, but there is a lot more to good driver writing that
banging registers. Some of the biggies are:

1. A strong consideration of reliability/security

Most CS grads do not have this. When an application crashes or
hangs it is annoying, but unfortunately all to common. But the same
attitude in a driver causes a system crash with significantly more impact.
Microsoft contents that most system crashes are 3rd party drivers, and all
evidence is this is true.

2. A strong comfort factor with concurrency

Even good multi-threaded application programmers can be terrible
driver writers. In the kernel concurrency is dictated to you, where as in
most application space you control concurrency. This can even be true as a
driver writer coming from another OS, right now I am dealing with a firm
that mainly works with ***X derived systems, they were surprised that they
had to support PnP and not just say “I don’t want it for that device”

3. A strong understanding of the whole API set

A goal of a driver writer should be to write as little code as
possible. While this may be true in other programming disciplines, it is
critical in driver writing. First, this typically improves reliability
since the OS is likely to have more testing than your drivers code. Second
is to reduce the footprint of the driver, which even with the large amount
of memory in systems today, should be treated as a scarce resource.

I’ve been writing drivers for 36 years, and in that time coding and
debugging for “banging registers” has been too tiny to measure.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

[Maxim_S_Shatskih]

Surely. Most protocol drivers do a lot of NdisRequest calls in the bind
path, to query the local MAC address, for instance.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Omer B” wrote in message news:xxxxx@ntdev…
> 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.
>