WDM - Toaster - Driverentry() is called by NtWriteFile. Why?

NTDEV
1

I am trying to learn WDM toaster driver. The first thing is virtual bus driver, busenum.sys

While debugging it, I came to know its DriverEntry() is called by NtWriteFile(). I am not getting it. Last time I checked the stack of some other driver, it was called by iopLoadDriver(), which I thought OS’s internal function and beleived into one thing.

I am not getting the flow, like who is calling my DriverEntry()? Will the same function always call the DriverEntry(), irrespective of what driver I am writing? Isn’t it a job of some other OS component to load my driver, which I think should be ISR(interrupt service routine)? A good source will be really appreciated. (I am referring Walter Oney, 2nd Ed). Rather than book, one website/blog link is highly appreciated, which should have entire flow, like what happenes inside when I connect the Pendrive, to the device driveer level, not at OS level, I am aware of interrupts and all, but how driver gets the actual control??

2

Don’t waste your time with the wdm version, just use the kmdf version. There is never a reason to use wdm to write a bus driver again. As for NtWriteFile in the stack, I am guessing your symbols are bad (is the offset huge?). IopLoadDriver should be the one loading your driver. You should never take a dependency on that, it is an implementation details.

An isr is only involved if there is a HW interrupt, no such thing in this case

d

Bent by my phone

From: xxxxx@gmail.commailto:xxxxx
Sent: ?10/?7/?2013 7:06 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] WDM - Toaster - Driverentry() is called by NtWriteFile. Why?

I am trying to learn WDM toaster driver. The first thing is virtual bus driver, busenum.sys

While debugging it, I came to know its DriverEntry() is called by NtWriteFile(). I am not getting it. Last time I checked the stack of some other driver, it was called by iopLoadDriver(), which I thought OS’s internal function and beleived into one thing.

I am not getting the flow, like who is calling my DriverEntry()? Will the same function always call the DriverEntry(), irrespective of what driver I am writing? Isn’t it a job of some other OS component to load my driver, which I think should be ISR(interrupt service routine)? A good source will be really appreciated. (I am referring Walter Oney, 2nd Ed). Rather than book, one website/blog link is highly appreciated, which should have entire flow, like what happenes inside when I connect the Pendrive, to the device driveer level, not at OS level, I am aware of interrupts and all, but how driver gets the actual control??

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

3

Yes, I understand that this is a virtual driver, so in this case no ISRs will come into picture, rather IOCTLs will be responsible for it. But I want to know where exactly this PDO is getting created in case of real hardware, like if i connect PenDrive. I have clear OS concepts(I think so, but I may be wrong), and now learning driver thing, but I am not getting the link between ISR getting called and DriverEntry() gaining the control. Though I am learning toaster, I am trying to have a complete view of what happens behind the scene in case of drivers(be it virtual/physical).

I understand that WDM is old, but I am just trying to learn, not going to write bus driver…:smiley:

Regards

4

> Yes, I understand that this is a virtual driver, so in this case no ISRs

will come into picture, rather IOCTLs will be responsible for it. But I
want to know where exactly this PDO is getting created in case of real
hardware, like if i connect PenDrive. I have clear OS concepts(I think so,
but I may be wrong), and now learning driver thing, but I am not getting
the link between ISR getting called and DriverEntry() gaining the control.
Though I am learning toaster, I am trying to have a complete view of what
happens behind the scene in case of drivers(be it virtual/physical).

Show the stack backtrace when DriverEntry is called. As already pointed
out, you must make sure you are using the correct symbol set. It is
impossible to have DriverEntry called from an ISR. Set a breakpoint at
DriverEntry.

I understand that WDM is old, but I am just trying to learn, not going to
write bus driver…:smiley:

But learning a WDM driver is like learning FORTRAN II out of curiosity.
It is an interesting pastime, and you will learn /something/, just not
something useful.
joe

Regards

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

5

xxxxx@gmail.com wrote:

Yes, I understand that this is a virtual driver, so in this case no ISRs will come into picture, rather IOCTLs will be responsible for it. But I want to know where exactly this PDO is getting created in case of real hardware, like if i connect PenDrive.

Somebody, somewhere, has to create a PDO. In the case of a
software-enumerated device, like the Toaster sample, there will be some
installation process somewhere that creates a device node with an ID
that matches your INF. “Devcon install” can do that, or you can do it
with an application.

Once the device node has been created, the system will go look for a
driver. It will find yours and load it. THAT’S where DriverEntry is
called, once and never again, until the next boot.

I have clear OS concepts(I think so, but I may be wrong), and now learning driver thing, but I am not getting the link between ISR getting called and DriverEntry() gaining the control.

There is no link. DriverEntry is called exactly once when the driver is
loaded into memory, in response to a plug-and-play event that shows a
new PDO is present. DriverEntry then registers the callbacks for the
various requests that a driver can receive, like AddDevice, read, write,
ioctl, etc. After that, for a software device, your driver code only
runs when there is a request from user mode. But DriverEntry never runs
again.

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

6

(Quote)
There is never a reason to use WDM to write a bus driver again
(/quote)

“Almost” never a reason (consider PCI.sys the exception).

For any reason that might be contemplated by the OP, I even agree with your absolute statement.

Peter
OSR

7

How about never write a /new wdm/ bus driver again.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, October 8, 2013 11:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDM - Toaster - Driverentry() is called by NtWriteFile. Why?

(Quote)
There is never a reason to use WDM to write a bus driver again
(/quote)

“Almost” never a reason (consider PCI.sys the exception).

For any reason that might be contemplated by the OP, I even agree with your absolute statement.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

8

There are many reasons pci.sys is not KMDF driver

(a) it is not possible to write it as a KMDF driver, no matter how badly
you want to
(b) it is a complex driver, and the investment of time and effort to
covert it to KMDF would not be justifiable
(c) it is a complex driver, but very mature, and an attempt to rewrite in
KMDF would introduce instabilities that might take years to eliminate
(d) the model of behavior used in pci.sys is quite different from the
model of behavior of KMDF, and even a bug-free driver would break {a few,
some, many, a lot, all} existing PCI function drivers
(e) there are a lot of pre-WDM PCI drivers out there, and They Would Not
Play Well with a KMDF bus driver (a somewhat more specialized version of
(d), for different reasons)
(f) any or all of the above, but upgrading PnP and Power to be correct,
given the knowledge learned in doing KMDF, is simpler than a total rewrite
(g) The PnP/Power for the WDM version is still as broken as it ever was,
but nobody is going to notice, so leave well enough alone.

Any or all of the above? Any others anyone can think of?

And going back to my “simple absolute rules”: there may be exceptions,
but newbies are more likely to get into trouble by thinking they are the
exception, so give them simple rules to start off with. Rules that tell
them to avoid the jungle. After they are experienced, and equipped with
mine detectors, and you can trust that they know how to use them, you can
let them fall into the quicksand bogs which have mines on the bottom.
Otherwise, your attrition rate is simply too high to tolerate.

joe

I consider me simple rules to be along the lines of telling a child “lying
is always wrong”, which works well until, as an adult, you get the “Honey,
do these pants make my butt look big?” question. Then you use a different
decision matrix to analyze cost/benefit.

(Quote)
There is never a reason to use WDM to write a bus driver again
(/quote)

“Almost” never a reason (consider PCI.sys the exception).

For any reason that might be contemplated by the OP, I even agree with
your absolute statement.

Peter
OSR

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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