Greetings!

As my subject says, I have two questions I hope everyone in this group
can provide opinions/comments/experiences about.

First, Kernel DLL's. I've scanned a number of newsgroups and
discovered Kernel DLL's are possible, and have looked over OSR's NT
Insider archives (thanks OSR!!). I currently have a couple of drivers
- one is a bus filter and the other a class driver for storage - and I
would like to move alot of the work into a DLL. As long as I setup
the Registry correctly I can get the DLL (ie. *.sys file) to load
before my other drivers do. My question is this: Lets say I wanted
to update the DLL file with a new version. As written today I call
UpdateDriverForPlugAndPlayDevices() which will install the new
driver(s) into place and restart the devices. My goal behind moving
most of the work into a DLL is to allow an update of the driver to
only affect the DLL itself. As far as I know this is possible, but
getting the drivers using the DLL to recognize this is another matter.
Is something like this possible?

Second, hooking AddDevice(). First I should say I've done it on other
Operating Systems with alot of success but haven't tried it in
Windows. As briefly mentioned above I have an upper filter bus
storage driver that attaches itself to the HBA adapter FDO's and
intercepts the QueryDeviceRelations() request returned from ScsiPort
and attaches an upper filter on the Disk PDO's which can be used to
manipulate the QUERY_ID information returned on the PDO's to force Pnp
to load my disk class driver. I've had this solution in place for
quite a few years now, but prior to this my solution was a single
driver that installed itself as a lower filter on the disk class
driver. As some of those in this group know, with Windows 2003 you
can no longer do this for multi-path drivers.

The problem I'm faced with are both test and customer configurations
where they have a large number of luns masked to their host, with
multiple paths (ex. 250 volumes with 6 paths). The
update/installation/removal of my driver package uses the SetupAPI()
functions documented by Microsoft to perform the appropriate steps,
but the process of updating the various pieces/parts of the Registry
can make this process take hours. With my older solution the process
was darn near instananeous (well, at least compared what I have to
deal with now). This problem is, of course, compounded by the fact
that part of the testing process is installing/updating/removing the
driver package.

So, I'm trying to revisit this process to see where I can reduce the
time it takes. I've looked at the disk driver source from the DDK,
and as I understand it if there were some way to have Microsoft's disk
driver return STATUS_SUCCESS in AddDevice() things would be okay -- I
could make by driver a lower-level filter driver and claim the disk
devices myself. Any thoughts or comments abou this?

Thanks,
Bob

for your new DLL to be loaded, all existing references need to be removed
.... basically all stacks which are using your driver must be torn down
before the new DLL image is loaded into memory. essentially, this is the
same problem as if you had a monolithic sys file. using a DLL for this does
not bring anything better/new to the table.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only.

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402191803.1bb72bee@posting.google.c om...

Just copy the new kernel DLL to system32\drivers. Then reboot, or at least stop
the drivers in question and start them back.

BTW - kernel DLLs can even be not registered in the registry. They are loaded
by the drivers by import resolution.

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

Consider using IoRegisterDeviceInterface and IoGetDeviceInterfaces, instead
of a DLL. While you will still have to release all the references as Doron
points out, but with this model you have a fairly easy way to know when the
new support code is present.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402191803.1bb72bee@posting.google.c om...

Doron,

Thanks for your prompt reply!

When you say "references" are you refering to the device objects
created by the DLL? What if, instead of having the DLL create and
attach the device objects, my bus and filter driver create them, and
the rest of the code resides in the DLL?

Bob

"Doron Holan [MS]" <doronh@nospam.microsoft.com> wrote in message news:<uCNNNr39DHA.2308@TK2MSFTNGP09.phx.gbl>...

references in this case is the loaded module itself, ie the driver that
links agains the DLL. as long as a driver which imports a function from
your DLL is loaded, your DLL will remain loaded as well. it does not matter
where the call to IoCreateDevice lives.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only.

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402200537.1ce0e790@posting.google.c om...

Doron, Maxim, Don

Thanks for your comments!

I've never used DeviceInterface's before so please bear with me on
this :-) Are there any performance issues in using these interfaces?
I've also thought about a private IOCTL interface between the drivers
where you could pass function entrypoints between them. If the "core"
driver was updated it could first notify the other drivers of a change
to prevent them from calling the "old" entrypoints then send an
updated list of entrypoints to call.


On the nasty subject of AddDevice(), any ideas on how to make the
whole PnP/Registry update issue work any faster? :-)

Regards,
Bob



"Don Burn" <burn@stopspam.acm.org> wrote in message news:<103c2s218tfnece@corp.supernews.com>...

DeviceInteface can be thought of as the private IOCTL model in that the
driver provides a block containing data and pointers to routines. The nice
thing with this is that there is a built in system mechanism for
notification. Additionally, since the interface uses a GUID for
identification it is strongly unique.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402201029.4db6e6f7@posting.google.c om...

Look at the SmartCard interface to the 'kernel DLL' that Microsoft
provides. It is rather simple and provides a good example of how
Microsoft implements this type of driver. If they do it, it will
probably not break anytime soon or you will be able to see the change in
the beta DDKs.

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402201029.4db6e6f7@posting.google.c om...

No. Just a way to generate symlink names, which are registered in the registry
and accessible from user mode.

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

There's an example at my private web site (not connected to Microsoft),
http://home.mindspring.com/~antognini/; look for "kernel dll." But there's
really no magic in this stuff. A driver could locate another driver's
device object, track down a table of entry points and employ them. Of
course, the first driver has to know how to find the second driver's device
object.

Don mentioned device interfaces. Another approach -- one that works across
systems -- is WMI. That, too, is illustrated at the web site, under "WDM
filter driver." This sample particular value is in providing the user-space
code to talk to a driver via WMI.

James Antognini
Windows DDK Support

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Greetings!

As my subject says, I have two questions I hope everyone in this group
can provide opinions/comments/experiences about.

First, Kernel DLL's. I've scanned a number of newsgroups and
discovered Kernel DLL's are possible, and have looked over OSR's NT
Insider archives (thanks OSR!!). I currently have a couple of drivers
- one is a bus filter and the other a class driver for storage - and I
would like to move alot of the work into a DLL. As long as I setup
the Registry correctly I can get the DLL (ie. *.sys file) to load
before my other drivers do. My question is this: Lets say I wanted
to update the DLL file with a new version. As written today I call
UpdateDriverForPlugAndPlayDevices() which will install the new
driver(s) into place and restart the devices. My goal behind moving
most of the work into a DLL is to allow an update of the driver to
only affect the DLL itself. As far as I know this is possible, but
getting the drivers using the DLL to recognize this is another matter.
Is something like this possible?

The question of hooking AddDevice so as to speed up (or circumvent) the
installation process is not recommended. The process for your driver would
be to build the registry entries in ENUM and CLASS as usual for each disk
instance. Granted this is time consuming, but at this time, this is the
only way to properly build the device stack. And currently there is no way
to arbitrate multiple class drivers of the same class type (like creating a
subtype), or disk miniclass.

This posting is provided "AS IS" with no warranties, and confers no rights.

I'll look into the smartcard example and brush up on DeviceInterface's.

My thanks to all who have responded to this!!
Bob

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:<#elT#e#9DHA.1936@TK2MSFTNGP12.phx.gbl>...

device interfaces can only be enabled on devices that are a part of a pnp
stack though (they require a PDO). if you were planning on having the DLL
use this with a control device object, it won't work.

d

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please reply to newsgroups only.

"Robert Stankey" <robert.stankey@lsil.com> wrote in message
news:a4303378.0402201745.2d1fa5c2@posting.google.c om...