Hi Devs,
I am new to the field of writing drivers.
Please provide me some stuff for a good start.
Thanks
Sandygg
Hi Sandygg,
There are several source I would recommend. First and formost, get a copy of the WDK 6000, it is esential. Secondly, you are hear at OSR’s site, read the NT Insider articles and play around with their free tools. Third, whenever you have a question about something, search the NTDEV and NTFSD archives from OSR’s home page (osronline.com). Also, search around on Channel 9, there are several excellent videos you can watch regarding kernel basics along with advanced matters http://channel9.msdn.com/ .
Good luck,
Matt
----- Original Message -----
From: Sandy Kumar
To: Windows System Software Devs Interest List
Sent: Thursday, January 10, 2008 6:01 AM
Subject: [ntdev] New to Drivers
Hi Devs,
I am new to the field of writing drivers.
Please provide me some stuff for a good start.
Thanks
Sandygg
— 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
device driver is a vast feild. on which driver you are actually working. Wdk documentation is first and the last thing in this feild… install WDK 6000 … you can also take help from many sample code provided with it.
Hi sandy,
First welcome to Device Driver world
first u can refer *The Windows 2000 Device Driver Book *by Art Baker
it will give u descent idea about Windows device driver and then get DDK/WDK
from Microsoft’s site using that u can start actual driver writing activity.
On Jan 10, 2008 5:46 PM, Matthew Martin wrote:
> Hi Sandygg,
>
> There are several source I would recommend. First and formost, get a copy
> of the WDK 6000, it is esential. Secondly, you are hear at OSR’s site, read
> the NT Insider articles and play around with their free tools. Third,
> whenever you have a question about something, search the NTDEV and NTFSD
> archives from OSR’s home page (osronline.com). Also, search around on
> Channel 9, there are several excellent videos you can watch regarding kernel
> basics along with advanced matters http://channel9.msdn.com/ .
>
> Good luck,
>
> Matt
>
> ----- Original Message -----
> From: Sandy Kumar
> To: Windows System Software Devs Interest List
> Sent: Thursday, January 10, 2008 6:01 AM
> Subject: [ntdev] New to Drivers
>
> Hi Devs,
>
> I am new to the field of writing drivers.
>
> Please provide me some stuff for a good start.
>
>
>
> Thanks
> Sandygg
>
> — 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
>
Thanks,
Regards,
Pravin G.
Aftek Ltd.
“pravin gawale” wrote in message
news:xxxxx@ntdev…
> Hi sandy,
> First welcome to Device Driver world
> first u can refer *The Windows 2000 Device Driver Book *by Art Baker
> it will give u descent idea about Windows device driver and then get
> DDK/WDK
> from Microsoft’s site using that u can start actual driver writing
> activity.
>
>
Bakers book is still known for its numerous errors. It is a good reference
of the basic concepts but do not follow the details in the book.
On the OP’s original question:
1. Consider taking a class. OSR and others have excellent classes on
device drivers. As a total newbie you are facing thousand of pages of data
to look at if you go it alone, a class provides you a guide to get started.
2. Study WDF. WDF (the Windows Driver Foundation) is designed in part to
make it easier for newbies. Get the book “Developing Driver with the
Windows Driver Foundation” and read it. As I am sure people will comment at
some point you need to understand what is going on below WDF but start
there.
3. While it is getting a little old, I am still biased 
towards the
following paper designed to get you going:
http://www.microsoft.com/whdc/driver/foundation/DrvDev_Intro.mspx
4. If you need WDM. WDM (the Windows Driver Model) is the older approach.
Get “Programming the Windows Driver Model Second Edition” this is a much
harder read than Baker or the WDF book, but it is the standard reference
here.
–
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
Welcome.
You certainly are off to a good start: You found OSR Online and this list, which are two essential resources. Also check out www.microsoft.com/whdc for a wide variety of guidance, papers, and presentations of varying levels of specificity and quality.
As other have said, driver development is a vast and fragmented field. It’s like saying “applications development” – One guy who does “applications development” might spend his life doing SQL, whereas another just does COM… Their disciplines don’t overlap much, and it’s unlikely they’d have anything intelligent to discuss together. It’s the same in the driver world.
So, one of your first challenges are (a) defining what type of driver(s) you need to write and (b) what driver model you’ll need to use. Believe it or not, this is one of the hardest questions facing a noob.
If you’re starting by assuming responsibility for an existing driver, and you have to maintain and enhance it, then you’re pretty much locked-in to that driver’s driver model (at least until you know enough to convince your manager to let you completely rewrite it).
If you’re writing a brand new driver, and if WDF supports the type of device and/or driver you need to write, there is NO DOUBT that you should learn WDF and NOT EVEN CONSIDER using any other driver model.
I was going to direct you to the OSR Driver Development FAQ (at http://www.osronline.com/article.cfm?article=20) but looking at it, I see it’s about 3 years old and hideously and embarassingly out of date. Think I’ll schedule it for an update very soon.
Peter
OSR
>…there is NO DOUBT that you should learn WDF and NOT EVEN CONSIDER
using any other driver model.
Sure. If the OP attends OSR seminar, he is going to learn everything just in 3 days. If not, he will, apparently, learn it in a couple of weeks on his own. At this point he can already consider moving a bit deeper, and try to figure out what happens behind his WDF calls - he will already have an idea how it all generally works, so that he can proceed to discovering what makes it all tick…
Anton Bassov
hi Anton,
why do you always insist that people will learn all about WDF drivers in 3
days. As far as I see it, the seminar is titled “Wdf quick start” which does
not imply in my opinion that you learn all about writing drivers for windows
with WDF in those 3 days.
Did I overlook something?
– Reinhard
wrote in message news:xxxxx@ntdev…
> >…there is NO DOUBT that you should learn WDF and NOT EVEN CONSIDER
>> using any other driver model.
>
> Sure. If the OP attends OSR seminar, he is going to learn everything just
> in 3 days. If not, he will, apparently, learn it in a couple of weeks on
> his own. At this point he can already consider moving a bit deeper, and
> try to figure out what happens behind his WDF calls - he will already have
> an idea how it all generally works, so that he can proceed to discovering
> what makes it all tick…
>
> Anton Bassov
>
Anton,
Sorry you have are really out of it. No one is expecting a production
driver in 3 days, but hopefully the attendee will learn the basics enough to
have a chance of developing a driver.
WDF is a set of API’s that help driver people alot. You support the
use of the various kernel synchronization primatives, in fact I see no one
but Alberto calling for building your own sync calls, so why do you have
problems with these API’s. Most of us in a WDM driver use cancel safe
queues, since they are easier and more reliable than most home grown cancel
models, in many ways I consider a lot of WDF to be Power / PnP / Cancel safe
queues. The original presentation on WDF six years ago, had a model that
wrapped the developer tightly and did not allow the use of lower level
primatives. The community objected with the type of coments you are useing
now, and got Microsoft to fix it. Microsoft did listen, something you seem
incapable of doing.
–
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
wrote in message news:xxxxx@ntdev…
> >…there is NO DOUBT that you should learn WDF and NOT EVEN CONSIDER
>> using any other driver model.
>
> Sure. If the OP attends OSR seminar, he is going to learn everything just
> in 3 days. If not, he will, apparently, learn it in a couple of weeks on
> his own. At this point he can already consider moving a bit deeper, and
> try to figure out what happens behind his WDF calls - he will already have
> an idea how it all generally works, so that he can proceed to discovering
> what makes it all tick…
>
> Anton Bassov
>
Don,
Sorry you have are really out of it.
I am afraid you just got it wrong. Look- I am not arguing with anything. Instead, I do agree with Peter that it is better to start from WDF, even if you plan to go deeper than that at a later stage- you are going to get an overall picture without too many ugly details that are going to confuse a newbie quite a lot. For example, the only thing you need to know about IRP at the very beginning is that you either pass it down the stack or complete it - there is no need to dump all possible completion scenarios on you in one go. Furthermore, I do agree with Peter that,
unless you happen to be some kind of retard, you can learn all this high-level picture in 3 days under Peter’s guidance without a slightest problem…
No one is expecting a production driver in 3 days, but hopefully the attendee
will learn the basics enough to have a chance of developing a driver.
However, I do disagree with the above statement. The basics that the attendee is going to learn in 3 days are sufficient not for actually writing drivers but only for proceeding to the next stage of a learning process, and this process may take years and years - for example, for me this learning process still goes on…
Anton Bassov
> hi Anton, why do you always insist that people will learn all about WDF drivers in 3 days.
In fact, I just dumbly repeat Peter’s words…
As far as I see it, the seminar is titled “Wdf quick start” which does not imply in my
opinion that you learn all about writing drivers for windows with WDF in those 3 days.
Did I overlook something?
Sure- you overlooked Peter’s relatively recent post where he said he teaches complete newbies how to write drivers in KMDF just in 3 days. I do believe it is feasible. The only thing I object to is assigning these new-made “gurus” to the *actual* production of drivers straight away. In my opinion, what they get is just a good starting point – they still have a long, long way to go before they are able to produce a commercial-grade driver with which I would not mind my driver being on the same stack with…
Anton Bassov
Hello,
I am also new to Windows Driver Development.
And one of the best beginer help i have found to date is :
http://www.codeproject.com/KB/system/driverdev.aspx
there is 6 parts.
http:And it really explains
basics. And shows the big picture without going into to much details that
only derail beginner.
Hope this helps
On Jan 10, 2008 10:19 PM, wrote:
> > hi Anton, why do you always insist that people will learn all about WDF
> drivers in 3 days.
>
> In fact, I just dumbly repeat Peter’s words…
>
> > As far as I see it, the seminar is titled “Wdf quick start” which does
> not imply in my
> > opinion that you learn all about writing drivers for windows with WDF in
> those 3 days.
>
> > Did I overlook something?
>
> Sure- you overlooked Peter’s relatively recent post where he said he
> teaches complete newbies how to write drivers in KMDF just in 3 days. I do
> believe it is feasible. The only thing I object to is assigning these
> new-made “gurus” to the actual production of drivers straight away. In my
> opinion, what they get is just a good starting point – they still have a
> long, long way to go before they are able to produce a commercial-grade
> driver with which I would not mind my driver being on the same stack
> with…
>
> 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
></http:>
> And one of the best beginer help i have found to date is :
Toby’s articles are really good - whenever any of his articles appeared on the CodeProject, I
always voted for it as of a best article of the month…
Anton Bassov
Be aware that produces a legacy driver, which is a far cry from what is
needed for most work.
–
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
“Slobodan Ninkov” wrote in message
news:xxxxx@ntdev…
> Hello,
> I am also new to Windows Driver Development.
> And one of the best beginer help i have found to date is :
> http://www.codeproject.com/KB/system/driverdev.aspx
> there is 6 parts.
> http:And it really
> explains
> basics. And shows the big picture without going into to much details that
> only derail beginner.
> Hope this helps
>
>
> On Jan 10, 2008 10:19 PM, wrote:
>
>> > hi Anton, why do you always insist that people will learn all about WDF
>> drivers in 3 days.
>>
>> In fact, I just dumbly repeat Peter’s words…
>>
>> > As far as I see it, the seminar is titled “Wdf quick start” which does
>> not imply in my
>> > opinion that you learn all about writing drivers for windows with WDF
>> > in
>> those 3 days.
>>
>> > Did I overlook something?
>>
>> Sure- you overlooked Peter’s relatively recent post where he said he
>> teaches complete newbies how to write drivers in KMDF just in 3 days. I
>> do
>> believe it is feasible. The only thing I object to is assigning these
>> new-made “gurus” to the actual production of drivers straight away. In
>> my
>> opinion, what they get is just a good starting point – they still have a
>> long, long way to go before they are able to produce a commercial-grade
>> driver with which I would not mind my driver being on the same stack
>> with…
>>
>> 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
>>
></http:>
Gosh, I wish I could find my original statement about training devs in KMDF… anybody remember which thread it was? I can’t find it using either Google or the very helpful and wonderful (cough) full text search here on OSR Online.
I don’t basically disagree with anything that Anton has said… except for the fact that he refers to 3 days, which is our WDF Quick Start lecture seminar… when I was originally referring to our 5 Day KMDF Lab seminar – both seminars cover the same material, but the lab seminar gives folks the chance for hands-on practice which is very valuable.
ANYHow, what I remember saying was we teach people the basics of KMDF in our 5 day lab seminar. By the end of that class, they’re able to do useful driver work on USB or software KMDF drivers, including writing simple drivers and making unique, meaningful changes to existing drivers of these types.
I also remember saying that you don’t dip these folks into this 5 day seminar and have them come out as experts – Rather, a student emerges from this seminar with a solid understanding of WDF basics that’ll set them on the right path to their life-long journey learning to be good kernel developers.
And being a good kernel-mode developer is indeed a life-long learning process.
Once trained in the basics, if folks need to learn more about the OS, they can dip their toes into both more advanced or different KMDF topics, and into WDM… little by little.
I find the fact that folks can be so productive with KMDF in so short a time amazing, and a testament to the excellent job done by the KMDF team in designing the Framework. This was the context of the comment: How effective and well-done KMDF is. [I don’t want anyone to think I’ve been gratuitously advertising OSR seminars here on the list. We never do that.]
Peter
OSR
>
And one of the best beginer help i have found to date is :
http://www.codeproject.com/KB/system/driverdev.asp
I’m sorry, but I think this article is poor. It’s outdated, it’s imprecise in its use of terminology, it contains all manner of dubious information, and it’s the sort of “blowing smoke up your ass” tutorial that makes people think they understand what’s going on when they don’t.
I think such a piece of work does far more harm to the community than it provides help. It’s harder to UNlearn something that’s wrong than to learn it right the first time.
Peter
OSR
Peter,
It’s outdated
What makes it so outdated??? Only the fact that this article is not about KMDF???
The fact that he describes non-PnP driver does not yet mean anything - there are quite a few legacy stacks around, and they don’t seem to be going anywhere anytime soon. After all, a driver in itself is just a kernel module - there no requirement for it to directly correspond to some certain piece of a hardware…
it’s imprecise in its use of terminology, it contains all manner of dubious information,
Indeed, this article has some technical imprecisions. However, these imprecisions do not seem to be significant enough to result in actual bugs, unlike the ones in some more popular source that you don’t seem to criticize that much . More on it below
I think such a piece of work does far more harm to the community than it provides help.
What about MSDN??? Does it do more harm or good??? Let’s face it - unlike harmless imprecisions in Toby’s article, quite a few wild statements that can be found on MSDN may directly result in bugs in your code. MSDN description of DPCs is the very first example that comes to my mind - IIRC, it claims that DPC routine gets invoked when IRQL drops below DISPATCH_LEVEL. The only logical conclusion that can be made by someone who is not really an expert in the kernel mechanics is that DPC routine gets invoked at IRQL below DPC level - after all, he is very unlikely to understand that, in actuality, “when IRQL drops below DISPATCH_LEVEL.” means the following scenario:
Some code that was running at elevated IRQL when hardware interrupt occurred; as a result of elevated IRQL at the time of hardware interrupt DPC that got queued by ISR resulted in requesting a software interrupt at DPC level ( if IRQL is below DPC level at the time of hardware interrupt, DPC that ISR queues gets processed before execution returns to interrupted code, i.e. software interrupt would not get requested if IRQL was below DPC level at the time of hardware interrupt ); DPC level software interrupt may fire only when IRQL goes below DPC level.
Probably, too much for a newbie, don’t you think??? Certainly, he will expect a DPC routine to run at IRQL below DPC level, and may get very surprized when he sees a BSOD with IRQL_NOT_LESS_OR_EQUAL or PAGE_FAULT_IN_NONPAGED_AREA message - after all, he does not know that KiDispatchInterrupt() will raise IRQL to DPC level before it invokes a DPC routine, does he???
Anton Bassov
The 6000 WDK says: “When IRQL falls below DISPATCH_LEVEL on a processor, the
kernel dequeues the DPC object and runs the driver’s DpcForIsr routine on
that processor at IRQL DISPATCH_LEVEL.” If you stop reading a possible
logical conclusion is as you said, but another logical conclusion is that
there is not enough information to know the IRQL. However, the WDK has all
the information regarding IRQL and it is the best source for driver
development. MSDN Library has almost stopped being updated. I heard there
is one for VS 2008, but I have seen an update for VS2005 for over six
months. The last VC6 update was October 2001. Also the comments for the
CustomDpc are also correct about the IRQL.
As I have understood NT, when a processor drops below DISPATCH_LEVEL IRQL, a
check for DPCs in the queue(s) is done. If no DPCs or anything else MS may
have added to this transition processing should run, then the scheduler runs
to decide which thread should be run. It can be the current thread that has
been running at DISPATCH_LEVEL or higher, or some other thread whose time
has come.
As I have watched this thread and attended several of the OSR courses, I can
say that Peter, specifically, is extremely consistant in his use of
terminology during the various classes. It has been several years (about 7)
since I last attended, but I suspect he still takes care so the newbies
won’t get confused by the use of inconsistant terminology. The only
exception being those terms Microsoft has foisted upon us with multiple
meanings. For example, does a standard driver’s dispatch routine run at
DISPATCH_LEVEL? No, not usually, but why confuse the masses expecially the
non-native English speakers? I do remember Peter covering this double
meaning in a class. As I only took one course where Tony taught, I cannot
specifically conclude that he is or is not as careful as Peter - though I
suspect he is. Most of the getting this correct is ensuring consistency in
the material presented. I know I ramble far too much to do it as well
myself. I don’t know if I would even have enough patience to do what either
of them does. I think that after the third time, I would be ready to need a
padded room and a shirt that buttons in the back and has sleeves that are
extra long.
wrote in message news:xxxxx@ntdev…
> Peter,
>
>>It’s outdated
>
> What makes it so outdated??? Only the fact that this article is not about
> KMDF???
> The fact that he describes non-PnP driver does not yet mean anything -
> there are quite a few legacy stacks around, and they don’t seem to be
> going anywhere anytime soon. After all, a driver in itself is just a
> kernel module - there no requirement for it to directly correspond to some
> certain piece of a hardware…
>
>
>> it’s imprecise in its use of terminology, it contains all manner of
>> dubious information,
>
> Indeed, this article has some technical imprecisions. However, these
> imprecisions do not seem to be significant enough to result in actual
> bugs, unlike the ones in some more popular source that you don’t seem to
> criticize that much . More on it below
>
>> I think such a piece of work does far more harm to the community than it
>> provides help.
>
> What about MSDN??? Does it do more harm or good??? Let’s face it - unlike
> harmless imprecisions in Toby’s article, quite a few wild statements that
> can be found on MSDN may directly result in bugs in your code. MSDN
> description of DPCs is the very first example that comes to my mind -
> IIRC, it claims that DPC routine gets invoked when IRQL drops below
> DISPATCH_LEVEL. The only logical conclusion that can be made by someone
> who is not really an expert in the kernel mechanics is that DPC routine
> gets invoked at IRQL below DPC level - after all, he is very unlikely to
> understand that, in actuality, “when IRQL drops below DISPATCH_LEVEL.”
> means the following scenario:
>
> Some code that was running at elevated IRQL when hardware interrupt
> occurred; as a result of elevated IRQL at the time of hardware interrupt
> DPC that got queued by ISR resulted in requesting a software interrupt at
> DPC level ( if IRQL is below DPC level at the time of hardware
> interrupt, DPC that ISR queues gets processed before execution returns to
> interrupted code, i.e. software interrupt would not get requested if IRQL
> was below DPC level at the time of hardware interrupt ); DPC level
> software interrupt may fire only when IRQL goes below DPC level.
>
>
>
> Probably, too much for a newbie, don’t you think??? Certainly, he will
> expect a DPC routine to run at IRQL below DPC level, and may get very
> surprized when he sees a BSOD with IRQL_NOT_LESS_OR_EQUAL or
> PAGE_FAULT_IN_NONPAGED_AREA message - after all, he does not know that
> KiDispatchInterrupt() will raise IRQL to DPC level before it invokes a DPC
> routine, does he???
>
>
> Anton Bassov
>
>
>
You seem to be wrapped a little tight there, Anton. Perhaps you should relax a bit before launching on a long “straw man” argument, including a description of DPC routines and imagined bugs that result from misreading what might be in the WDK documentation – if that’s indeed what you mean by “MSDN”.
WhatEVER,
Peter
OSR
> … imagined bugs that result from misreading what might be in the WDK documentation
– if that’s indeed what you mean by “MSDN”.
By “MSDN” I mean any official documentation that comes from MSFT. Ironically, WDK seems to have finally fixed the particular bug that I had described in my previous post. However, both W2K and XP DDKs had it.
In actuality, the consequences that I have described are far from being imaginary. Furthermore, the term “misread” does not really apply here - it is not about “misunderstanding” the text. Instead, it is all about understanding exactly what the text says. I even remember reading some clarification document, saying that the documentation was a bit imprecise - it said that, in actuality, “DPC routine is invoked when IRQL is *about* to drop below DPC level” (which, ironically, is a bit imprecise as well, but at least it made it clear that DPC routine itself runs at DISPATCH_LEVEL). It is obvious that this clarification document was written in response to, apparently, numerous complaints…
Probably, my argument is, indeed, a bit of a “straw man” one, but still you haven’t answered my question - does the official documentation, in your opinion, do more harm or good??? In case of the latter, why should its “imprecisions” be treated more leniently than the ones in Toby’s articles ???
Anton Bassov