I know, I know, I’m sure this topic has been beaten to death. But my searches came up dry, so here I am.
I’m porting an NT4 legacy virtual serial port driver to WDM. I have a bus enumerator which is connected to Root, and the virtual serial ports now live in a separate driver as FDO’s which are loaded via the bus enumerator creating the appropriate PDO’s.
So this arrangement is basically working, but I’m having problems at reboot.
In its former life as a legacy driver, during DriverEntry it would create several ancillary device objects and background threads to provide system services to the virtual serial ports. This used to work fine, as the legacy driver was tagged auto-start in its services key, so the driver loaded fairly late.
But now in its new role as a Root-enumerated bus driver, it loads at boot time. And since the PDO’s descriptions resolve to devices of type “Ports”, the FDO driver also loads soon thereafter (i.e., at boot time). But several of these ancillary objects and threads in the bus enumerator have a dependence on TDI, so boot time loading is too early.
I’ve tried both “System” and “MultiportSerial” setup class for the bus enumerator’s INF file. I’ve tried SYSTEM_START and DEMAND_START for the service entry. No luck, still loads at boot.
I’m about to resort to using Driver Reinitialization to delay some of the work done in DriverEntry. I’m assuming this will also delay the initial call to AddDevice() in the bus driver as well. The downside here is that the error handling in driver reinit is more limited (not a huge problem in this case, but still), and I’m concerned that I may be missing a cleaner solution that accomplishes my actual goal, which is to get out of the boot sequence entirely.
Any other thoughts on how to get the Root device to wait until system start to load my bus driver?
How about having your bus driver delay enumerating anything until it
is appropriate to do so? Your PDO enumeration is entirely under your
control. Don’t expose any PDOs to PnP until the network stack is up
and running.
Mark Roddy
On Thu, Jul 2, 2009 at 3:41 PM, wrote:
> I know, I know, I’m sure this topic has been beaten to death. ?But my searches came up dry, so here I am.
>
> I’m porting an NT4 legacy virtual serial port driver to WDM. ?I have a bus enumerator which is connected to Root, and the virtual serial ports now live in a separate driver as FDO’s which are loaded via the bus enumerator creating the appropriate PDO’s.
>
> So this arrangement is basically working, but I’m having problems at reboot.
>
> In its former life as a legacy driver, during DriverEntry it would create several ancillary device objects and background threads to provide system services to the virtual serial ports. ?This used to work fine, as the legacy driver was tagged auto-start in its services key, so the driver loaded fairly late.
>
> But now in its new role as a Root-enumerated bus driver, it loads at boot time. ?And since the PDO’s descriptions resolve to devices of type “Ports”, the FDO driver also loads soon thereafter (i.e., at boot time). ?But several of these ancillary objects and threads in the bus enumerator have a dependence on TDI, so boot time loading is too early.
>
> I’ve tried both “System” and “MultiportSerial” setup class for the bus enumerator’s INF file. ?I’ve tried SYSTEM_START and DEMAND_START for the service entry. ?No luck, still loads at boot.
>
> I’m about to resort to using Driver Reinitialization to delay some of the work done in DriverEntry. ?I’m assuming this will also delay the initial call to AddDevice() in the bus driver as well. ?The downside here is that the error handling in driver reinit is more limited (not a huge problem in this case, but still), and I’m concerned that I may be missing a cleaner solution that accomplishes my actual goal, which is to get out of the boot sequence entirely.
>
> Any other thoughts on how to get the Root device to wait until system start to load my bus driver?
>
>
> —
> 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
>
Actually, exposing the PDO’s is the least of my problems. The FDO’s are also dependent on the network stack, but only if they are actually opened—at which time they may call upon one of the system services initialized during DriverEntry. So that’s unlikely to be a primary issue.
The larger issue is the TDI-dependent initialization done in DriverEntry. If I’m stuck having my DriverEntry called during boot, and my sole strategy is to delay things, then Driver Reinitialization would appear to be the most straightforward route (and most “official”, for what that’s worth).
What if the network card is hot plugged later? Or enumerated after driver init? You have a built in problem that you need to address more fundamentally
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: xxxxx@rfdsoftware.com
Sent: Thursday, July 02, 2009 4:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver boot-time load order
Actually, exposing the PDO’s is the least of my problems. The FDO’s are also dependent on the network stack, but only if they are actually opened—at which time they may call upon one of the system services initialized during DriverEntry. So that’s unlikely to be a primary issue.
The larger issue is the TDI-dependent initialization done in DriverEntry. If I’m stuck having my DriverEntry called during boot, and my sole strategy is to delay things, then Driver Reinitialization would appear to be the most straightforward route (and most “official”, for what that’s worth).
—
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
I’m not convinced that’s really a big issue. It’s valid to create UDP endpoints even if there are no interfaces yet (so long as you don’t bind to a specific address or interface), correct? Which is all that’s really happening in DriverEntry—the UDP endpoints see no traffic until one of the virtual serial devices are opened. But TDI does need to be available, which isn’t the case during early boot.
It’s sounding like there is no formal procedure to indicate my bus driver’s preference to be loaded at system start. So I guess I need to use Driver Reinitialization.
I don’t think that Driver Reinitialization is the answer. Your reinit
function might be called thousands of times before TCP is ready. I have
tried this.
I have not been following this discussion too close but I thought that
someone suggested a second driver that was dependant on tcp/ip. This driver
whould then notify the bus driver when it gets loaded.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@rfdsoftware.com
Sent: Friday, July 03, 2009 2:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver boot-time load order
I’m not convinced that’s really a big issue. It’s valid to create UDP
endpoints even if there are no interfaces yet (so long as you don’t bind to
a specific address or interface), correct? Which is all that’s really
happening in DriverEntry—the UDP endpoints see no traffic until one of the
virtual serial devices are opened. But TDI does need to be available, which
isn’t the case during early boot.
It’s sounding like there is no formal procedure to indicate my bus driver’s
preference to be loaded at system start. So I guess I need to use Driver
Reinitialization.
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
Not sure what you mean by TCP being ready. All I really need is for my TDI to be sufficiently “on the air” for the init code to be able to create an unbound UDP endpoint. I don’t need an interfaces to be created at all yet, never mind be on the other side of a DHCP configuration, if that’s what you are referring to.
In the extremely unlikely event that these system services get invoked by the port driver before TCP/IP is fully available, those types of errors are handled gracefully. But what’s not easily accounted for at the moment is the inability for the init code to even create an unbound UDP endpoint.
What do you mean by TDI being sufficiently “on the air”. UDP endpoints are
created in the TCP/IP driver, not the TDI driver. TDI is an export driver
that supports network protocol drivers and their clients. TCP is the
protocol driver, your driver is the client. You need the TCP/IP driver up
and running in order to create a UDP endpoint.
One method that I have used is to use TdiRegisterPnPHandlers to get notified
of interfaces and their addresses. When tcpip finally gets loaded and binds
to an adapter you will get notified. You will also be notified if that
interface is removed.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of xxxxx@rfdsoftware.com
Sent: Friday, July 03, 2009 9:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver boot-time load order
Not sure what you mean by TCP being ready. All I really need is for my TDI
to be sufficiently “on the air” for the init code to be able to create an
unbound UDP endpoint. I don’t need an interfaces to be created at all yet,
never mind be on the other side of a DHCP configuration, if that’s what you
are referring to.
In the extremely unlikely event that these system services get invoked by
the port driver before TCP/IP is fully available, those types of errors are
handled gracefully. But what’s not easily accounted for at the moment is
the inability for the init code to even create an unbound UDP endpoint.
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
> One method that I have used is to use TdiRegisterPnPHandlers
This is a good idea, but requires your code to load after TDI.SYS is loaded.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
TDI.sys is an export driver and will load when your driver loads if your
driver imports a function from it. This is documented in the TdiInitialize
function.
I have a driver that does exactly this. My driver is in one of the FSFilter
groups which loads before the TDI group. This driver registers for the TDI
callbacks and gets called when tcpip loads and assigns ip addresses to
interfaces.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Maxim S. Shatskih
Sent: Saturday, July 04, 2009 7:13 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver boot-time load order
One method that I have used is to use TdiRegisterPnPHandlers
This is a good idea, but requires your code to load after TDI.SYS is loaded.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
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
Instead of trying to load your driver later than boot time, do you see any
issue in starting the networking stack before you load?
i.e. Change the driver Start type to 0 i.e. boot time for drivers:
tcpip.sys, ipsec.sys, gpc.sys, psched.sys and the NDIS miniport driver which
is serving your NIC.
Change the Tag values of IpSec, GPC and TCPIP so that they load in the order
so that IPSec is first, GPC is Second and TCPIP is third.
And last, change the List key in
HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder so that the groups
NDIS Wrapper, NDIS, Base and PNP_TDI (in this order only) are before your
serial port driver’s group.
This is what we did when we had a dependancy on TDI and TCP/IP at boot time.
Thanks,
Charan
On Fri, Jul 3, 2009 at 1:11 AM, wrote:
> I know, I know, I’m sure this topic has been beaten to death. But my
> searches came up dry, so here I am.
>
> I’m porting an NT4 legacy virtual serial port driver to WDM. I have a bus
> enumerator which is connected to Root, and the virtual serial ports now live
> in a separate driver as FDO’s which are loaded via the bus enumerator
> creating the appropriate PDO’s.
>
> So this arrangement is basically working, but I’m having problems at
> reboot.
>
> In its former life as a legacy driver, during DriverEntry it would create
> several ancillary device objects and background threads to provide system
> services to the virtual serial ports. This used to work fine, as the legacy
> driver was tagged auto-start in its services key, so the driver loaded
> fairly late.
>
> But now in its new role as a Root-enumerated bus driver, it loads at boot
> time. And since the PDO’s descriptions resolve to devices of type “Ports”,
> the FDO driver also loads soon thereafter (i.e., at boot time). But several
> of these ancillary objects and threads in the bus enumerator have a
> dependence on TDI, so boot time loading is too early.
>
> I’ve tried both “System” and “MultiportSerial” setup class for the bus
> enumerator’s INF file. I’ve tried SYSTEM_START and DEMAND_START for the
> service entry. No luck, still loads at boot.
>
> I’m about to resort to using Driver Reinitialization to delay some of the
> work done in DriverEntry. I’m assuming this will also delay the initial
> call to AddDevice() in the bus driver as well. The downside here is that
> the error handling in driver reinit is more limited (not a huge problem in
> this case, but still), and I’m concerned that I may be missing a cleaner
> solution that accomplishes my actual goal, which is to get out of the boot
> sequence entirely.
>
> Any other thoughts on how to get the Root device to wait until system start
> to load my bus driver?
>
>
> —
> 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
>
Amazingly dirty hack.
If the person changes his Ethernet adapter - then his OS is killed and cannot boot.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Charansing Rajput” wrote in message news:xxxxx@ntdev…
Instead of trying to load your driver later than boot time, do you see any issue in starting the networking stack before you load?
i.e. Change the driver Start type to 0 i.e. boot time for drivers: tcpip.sys, ipsec.sys, gpc.sys, psched.sys and the NDIS miniport driver which is serving your NIC.
Change the Tag values of IpSec, GPC and TCPIP so that they load in the order so that IPSec is first, GPC is Second and TCPIP is third.
And last, change the List key in HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder so that the groups NDIS Wrapper, NDIS, Base and PNP_TDI (in this order only) are before your serial port driver’s group.
This is what we did when we had a dependancy on TDI and TCP/IP at boot time.
Thanks,
Charan
On Fri, Jul 3, 2009 at 1:11 AM, wrote:
I know, I know, I’m sure this topic has been beaten to death. But my searches came up dry, so here I am.
I’m porting an NT4 legacy virtual serial port driver to WDM. I have a bus enumerator which is connected to Root, and the virtual serial ports now live in a separate driver as FDO’s which are loaded via the bus enumerator creating the appropriate PDO’s.
So this arrangement is basically working, but I’m having problems at reboot.
In its former life as a legacy driver, during DriverEntry it would create several ancillary device objects and background threads to provide system services to the virtual serial ports. This used to work fine, as the legacy driver was tagged auto-start in its services key, so the driver loaded fairly late.
But now in its new role as a Root-enumerated bus driver, it loads at boot time. And since the PDO’s descriptions resolve to devices of type “Ports”, the FDO driver also loads soon thereafter (i.e., at boot time). But several of these ancillary objects and threads in the bus enumerator have a dependence on TDI, so boot time loading is too early.
I’ve tried both “System” and “MultiportSerial” setup class for the bus enumerator’s INF file. I’ve tried SYSTEM_START and DEMAND_START for the service entry. No luck, still loads at boot.
I’m about to resort to using Driver Reinitialization to delay some of the work done in DriverEntry. I’m assuming this will also delay the initial call to AddDevice() in the bus driver as well. The downside here is that the error handling in driver reinit is more limited (not a huge problem in this case, but still), and I’m concerned that I may be missing a cleaner solution that accomplishes my actual goal, which is to get out of the boot sequence entirely.
Any other thoughts on how to get the Root device to wait until system start to load my bus driver?
—
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
Whenever the adapter is changed you have to make it boot start as soon as it
is changed. And AFAIK this is how most network booting solutions work.
Thanks,
Charan
On Sun, Jul 5, 2009 at 4:55 PM, Maxim S. Shatskih wrote:
> Amazingly dirty hack.
>
> If the person changes his Ethernet adapter - then his OS is killed and
> cannot boot.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> “Charansing Rajput” wrote in message
> news:xxxxx@ntdev…
> Instead of trying to load your driver later than boot time, do you see any
> issue in starting the networking stack before you load?
>
> i.e. Change the driver Start type to 0 i.e. boot time for drivers:
> tcpip.sys, ipsec.sys, gpc.sys, psched.sys and the NDIS miniport driver which
> is serving your NIC.
> Change the Tag values of IpSec, GPC and TCPIP so that they load in the
> order so that IPSec is first, GPC is Second and TCPIP is third.
> And last, change the List key in
> HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder so that the groups
> NDIS Wrapper, NDIS, Base and PNP_TDI (in this order only) are before your
> serial port driver’s group.
>
> This is what we did when we had a dependancy on TDI and TCP/IP at boot
> time.
>
> Thanks,
> Charan
>
>
>
> On Fri, Jul 3, 2009 at 1:11 AM, wrote:
>
> I know, I know, I’m sure this topic has been beaten to death. But my
> searches came up dry, so here I am.
>
> I’m porting an NT4 legacy virtual serial port driver to WDM. I have a bus
> enumerator which is connected to Root, and the virtual serial ports now live
> in a separate driver as FDO’s which are loaded via the bus enumerator
> creating the appropriate PDO’s.
>
> So this arrangement is basically working, but I’m having problems at
> reboot.
>
> In its former life as a legacy driver, during DriverEntry it would create
> several ancillary device objects and background threads to provide system
> services to the virtual serial ports. This used to work fine, as the legacy
> driver was tagged auto-start in its services key, so the driver loaded
> fairly late.
>
> But now in its new role as a Root-enumerated bus driver, it loads at boot
> time. And since the PDO’s descriptions resolve to devices of type “Ports”,
> the FDO driver also loads soon thereafter (i.e., at boot time). But several
> of these ancillary objects and threads in the bus enumerator have a
> dependence on TDI, so boot time loading is too early.
>
> I’ve tried both “System” and “MultiportSerial” setup class for the bus
> enumerator’s INF file. I’ve tried SYSTEM_START and DEMAND_START for the
> service entry. No luck, still loads at boot.
>
> I’m about to resort to using Driver Reinitialization to delay some of the
> work done in DriverEntry. I’m assuming this will also delay the initial
> call to AddDevice() in the bus driver as well. The downside here is that
> the error handling in driver reinit is more limited (not a huge problem in
> this case, but still), and I’m concerned that I may be missing a cleaner
> solution that accomplishes my actual goal, which is to get out of the boot
> sequence entirely.
>
> Any other thoughts on how to get the Root device to wait until system start
> to load my bus driver?
>
>
> —
> 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
>
Which is more or less my initial suggestion modified by wrapping it
within the tdi version. The OP has already rejected the notification
approach as he insists on doing stuff in driver entry. The OP needs to
let go of ‘have to initialize stuff in driver entry’ and have a more
flexible event driven approach that can perform the initialization
when appropriate based on the arrival of the network stack.
Mark Roddy
On Sat, Jul 4, 2009 at 10:30 AM, Bill Wandel wrote:
> TDI.sys is an export driver and will load when your driver loads if your
> driver imports a function from it. This is documented in the TdiInitialize
> function.
> I have a driver that does exactly this. My driver is in one of the FSFilter
> groups which loads before the TDI group. This driver registers for the TDI
> callbacks and gets called when tcpip loads and assigns ip addresses to
> interfaces.
>
> Bill Wandel
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
> On Behalf Of Maxim S. Shatskih
> Sent: Saturday, July 04, 2009 7:13 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Driver boot-time load order
>
>> One method that I have used is to use TdiRegisterPnPHandlers
>
> This is a good idea, but requires your code to load after TDI.SYS is loaded.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> 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
>
> Amazingly dirty hack.
Unfortunately, as Charan said, there is not another solution for such type of product. There is some relief in Vista SP1. In this version of Windows tcpip.sys has Start = 0 by default but still require changing Start value in NDIS drivers.
Does Windows Kernel Socket, which start in Vista, require such Registry modification or it could start in boot time by default? Could somebody from Microsoft clarify this?
Igor Sharovar
Hewlett-Packard
Why is there no other solution? At least one other solution has been
described here. Forcing the design into ‘must be done at driver entry’
is an error that simply needs to be corrected.
Mark Roddy
On Tue, Jul 7, 2009 at 4:59 PM, <igor.sharovar> wrote:
>> Amazingly dirty hack.
> Unfortunately, as Charan said, ?there is not another solution for such type of product. There is some relief in Vista SP1. In this version of Windows ?tcpip.sys has Start = 0 by default but still require changing Start value in NDIS drivers.
> Does Windows Kernel Socket, which start in Vista, require such Registry modification or it could start in boot time by default? Could somebody from Microsoft clarify this?
>
> Igor Sharovar
> Hewlett-Packard
>
> —
> 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
></igor.sharovar>
I mean that changing Start value in networks drivers is only solution for network booting stuff. Unlike Linux Windows does not have any standard solution that could provide networking in early stage of booting.
Igor Sharovar
Hewlett-Packard
On Wed, Jul 8, 2009 at 1:36 PM, <igor.sharovar> wrote:
> mean that changing Start value in networks drivers is only solution for network booting stuff.
Fair enough, but I doubt the OP is booting off a virtual serial port 
Mark Roddy</igor.sharovar>
Yes, it was off topic. I just add some comments to Charansing Deore message. There are some products( not many) which could load Windows through network.And I use any possibility to discuss this topic with people who work in this area.
Igor Sharovar
Hewlett-Packard
OP does not want to boot off virtual serial port. But he wants to have
networking support for his driver at the boot time. So although he does not
want to boot off network or serial port he can follow this approach.
I would be really grateful if somebody could explains why it is a dirty
hack, and what could be better solution for:
- Having networking support for OP’s vserial port early in the boot stage,
and
- Having networking support for for drivers that use networking for booting
the machine off network.
I am sure answer to above would be answer to OP’s problem as well as it will
a lot of people who are trying to boot off network.
Thanks,
Charan
On Thu, Jul 9, 2009 at 12:09 AM, Mark Roddy wrote:
> On Wed, Jul 8, 2009 at 1:36 PM, <igor.sharovar> wrote:
> > mean that changing Start value in networks drivers is only solution for
> network booting stuff.
>
> Fair enough, but I doubt the OP is booting off a virtual serial port
>
>
> Mark Roddy
>
> —
> 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
></igor.sharovar>