Can a DriverEntry routine of a boot start driver wait for an arbitrarily
long time or will this hang the system boot? I’m revisiting the
text-mode install of a NDIS driver and because NDIS isn’t loaded yet my
DriverEntry crashes when it tries to call NdisMRegisterMiniport, so I
want to wait until the required NDIS driver(s) is loaded (presumably by
detecting the appearance of a device interface).
I suspect that the system is going to wait for all boot start drivers to
complete their DriverEntry routine before proceeding with other drivers
so waiting on a later-than-boot-start driver is going to cause a
deadlock, but the documentation is a little vague on this (or more
likely, I’ve missed where this is spelt out).
Thanks
James
Nevermind. I tested by putting a 60 second delay in the DriverEntry, and
all it seemed to do was delay the crash by 60 seconds.
Thanks
James
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-425202-
xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Friday, 17 September 2010 16:49
To: Windows System Software Devs Interest List
Subject: [ntdev] long wait in DriverEntry
Can a DriverEntry routine of a boot start driver wait for an
arbitrarily
long time or will this hang the system boot? I’m revisiting the
text-mode install of a NDIS driver and because NDIS isn’t loaded yet
my
DriverEntry crashes when it tries to call NdisMRegisterMiniport, so I
want to wait until the required NDIS driver(s) is loaded (presumably
by
detecting the appearance of a device interface).
I suspect that the system is going to wait for all boot start drivers
to
complete their DriverEntry routine before proceeding with other
drivers
so waiting on a later-than-boot-start driver is going to cause a
deadlock, but the documentation is a little vague on this (or more
likely, I’ve missed where this is spelt out).
Thanks
James
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
IIRC all the DriverEntry routines are called synchronously
You need to specify dependencies for your driver, to make sure NDIS started.
Try registering a boot reinit callback and see if ndis is ready then.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@oracle.com
Sent: Friday, September 17, 2010 8:47 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] long wait in DriverEntry
IIRC all the DriverEntry routines are called synchronously
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 revisiting the text-mode install of a NDIS driver and because NDIS isn’t loaded yet
To which group does your driver belong in “ServiceGroupOrder”? If the driver belongs to “NDIS” group it should loaded after ndis.sys.
Igor Sharovar
Hi Doron - Could you elaborate on a “boot reinit callback”? Is this something that you register for with ExRegisterCallback? If so, I don’t see anything about it in the WDK.
IoRegisterBootDriverReinitialization
http://msdn.microsoft.com/en-us/library/ff549494(VS.85).aspx
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@oracle.com
Sent: Friday, September 17, 2010 10:22 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] long wait in DriverEntry
Hi Doron - Could you elaborate on a “boot reinit callback”? Is this something that you register for with ExRegisterCallback? If so, I don’t see anything about it in the WDK.
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 pretty sure that stuff is ignored in text mode setup
Sent from my iPhone
On 18/09/2010, at 2:57, xxxxx@broadcom.com wrote:
You need to specify dependencies for your driver, to make sure NDIS started.
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
>
Try registering a boot reinit callback and see if ndis is ready then.
I was heading down that path but I was under the impression that I still
had to init the driver in DriverEntry and that the reinit
(IoRegisterDriverReinitialization I assume) was to create non-pnp
devices manually after all the pnp devices had been created.
Still… I guess it’s only a few lines of code so I’ll give it a go.
Thanks
James
> >
> Try registering a boot reinit callback and see if ndis is ready
then.
>
I was heading down that path but I was under the impression that I
still
had to init the driver in DriverEntry and that the reinit
(IoRegisterDriverReinitialization I assume) was to create non-pnp
devices manually after all the pnp devices had been created.
Still… I guess it’s only a few lines of code so I’ll give it a go.
No good. Even if I re-register the reinit routine in the reinit routine
and let it loop 10000 times it still beats NDIS.
This is a baremetal restore boot which still uses the text mode setup to
load drivers under windows 2003, if that makes any difference. Maybe it
loads NDIS much later.
Thanks
James
> This is a baremetal restore boot which still uses the text mode setup to
load
drivers under windows 2003, if that makes any difference. Maybe it loads
NDIS much later.
Out of the box, I believe W2K3 did not support iscsi boot over NDIS nics,
and the NDIS driver was originally not a boot load driver. You could add an
iscsi boot device after the OS was running, and this would change the start
type of the NDIS wrapper. There also were iscsi boot devices that used
hardware iscsi, so the iscsi driver was a storage driver (iscsiprt based),
not an NDIS device.
You might be able to set the start type of your driver in the txtsetup.oem
file to not boot start, and then in the real INF for the device, make the
service be boot start.
W2K3 text mode install has a lot of painful constraints.
Jan
>
> This is a baremetal restore boot which still uses the text mode
setup to
load
> drivers under windows 2003, if that makes any difference. Maybe it
loads
> NDIS much later.
Out of the box, I believe W2K3 did not support iscsi boot over NDIS
nics,
and the NDIS driver was originally not a boot load driver. You could
add an
iscsi boot device after the OS was running, and this would change the
start
type of the NDIS wrapper. There also were iscsi boot devices that used
hardware iscsi, so the iscsi driver was a storage driver (iscsiprt
based),
not an NDIS device.
Mine isn’t an iSCSI device, just a regular miniport (virtual network
driver for xen). I’m doing test restores of backups, restoring into
virtual machines under Xen. Xen provides an emulated PCI network device
but it’s pretty slow so I wanted to get my PV network driver loaded to
speed things up a bit and reduce CPU load etc. The restore environment
is Backup Exec IDR which is a PE of some sort. The backup server gets
restored first (via a scsi tape drive which is passed through from Xen
via another of my drivers). Subsequent servers are restored via the
network.
You might be able to set the start type of your driver in the
txtsetup.oem
file to not boot start, and then in the real INF for the device, make
the
service be boot start.
I don’t think you can change the load order (and I’ve tried to see if it
worked). Text mode drivers get loaded in the order they are added in
press-F6 driver selection.
I’m now wondering if I’ve been chasing the wrong cause. I changed my
driver entry routine to simply return a failure instead, and the system
crashed when the emulated PCI network adapter was loaded later on during
restore. I think that text mode setup doesn’t let me set per-device
registry keys (ndi key), only per-driver registry keys. Maybe that’s
causing a problem…
Backup Exec IDR does provide a way to load network drivers later on but
this needs to be prepared in advance. I was hoping to be able to pile
all my drivers onto a single floppy and have done with it.
Thanks
James
>
I’m now wondering if I’ve been chasing the wrong cause. I changed my
driver entry routine to simply return a failure instead, and the
system
crashed when the emulated PCI network adapter was loaded later on
during
restore. I think that text mode setup doesn’t let me set per-device
registry keys (ndi key), only per-driver registry keys. Maybe that’s
causing a problem…
I ran it past the debugger and the crash in the rtl8139 driver (emulated
pci) is happening as follows:
nt!MmLockPagableSectionByHandle+0x29
NDIS!ndisReferencePackage+0xe
NDIS!ndisRegisterMiniportDriver+0x294
NDIS!NdisMRegisterMiniport+0x17
RTL8139!DriverEntry+0xb2
nt!IopLoadDriver+0x689
This only happens if I load my PV network driver and return an error
status immediately in driver entry.
James
>This is a baremetal restore boot which still uses the text mode setup to
load drivers under windows 2003, if that makes any difference.
And even if you will manage to load ndis.sys this early - how will you load the Ethernet chip drivers? can they be loaded by pre-Vista text mode setup?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>
>This is a baremetal restore boot which still uses the text mode setup
to
>load drivers under windows 2003, if that makes any difference.
And even if you will manage to load ndis.sys this early - how will you
load
the Ethernet chip drivers?
My driver is the ‘Ethernet chip driver’. Now that I have the debugger
working under text mode setup I can see that ndis.sys is actually
loaded, and that the crash happens in MmLockPagableSectionByHandle, eg:
nt!MmLockPagableSectionByHandle+0x29
NDIS!ndisReferencePackage+0xe
NDIS!ndisRegisterMiniportDriver+0x294
NDIS!NdisMRegisterMiniport+0x17
Curiously, this also happens when my DriverEntry returns a failure
status (as the first statement) and then a subsequent NDIS ‘ethernet
chip’ driver loads (eg rtl8139). It’s got me puzzled but I don’t think
I’m going to persist with it because…
can they be loaded by pre-Vista text mode setup?
As it turns out, I don’t think so. NDIS needs some per-device registry
settings to work (the NDI subkey) and all I can load in textmode setup
is per-driver registry settings. Unless NDIS can work without those keys
there isn’t much point pursuing this any further.
Thanks
James