Ndis protocol driver and windows 7
in [Device Drivers]
|
Prev: opening volume handle in kernel mode
Next: Can I determine if an installed printer driver is WHQL-signed? How?
From: Guilherme Moro on 15 Dec 2009 17:18 Hello all, I have a protocol driver that works perfect in windows XP, and Vista, but in the Windows 7 I cant make it binds the same way. If I use the protocol after the machine have booted from a hard drive, its all ok, everything looks just fine, but if I try to boot from my virtual disk ( network backed ) the protocol simply dont bind. I receive a NetEventBindsComplete, but the bind never occur. I have checked the protocol name and all this kind of stuff, and cant find any clue, and as I said, the problem its just when booting, if the machine boots from another disk the bind occur as expected. Anyone has any clue? Guilherme
From: eagersh on 16 Dec 2009 19:44 On Dec 15, 3:18 pm, Guilherme Moro <guilherme.m...(a)gmail.com> wrote: > Hello all, > > I have a protocol driver that works perfect in windows XP, and Vista, > but in the Windows 7 I cant make it binds the same way. > If I use the protocol after the machine have booted from a hard drive, > its all ok, everything looks just fine, but if I try to boot from my > virtual disk ( network backed ) the protocol simply dont bind. I > receive a NetEventBindsComplete, but the bind never occur. > I have checked the protocol name and all this kind of stuff, and cant > find any clue, and as I said, the problem its just when booting, if > the machine boots from another disk the bind occur as expected. > > Anyone has any clue? > > Guilherme Is your protocol driver need to be in the early stage of booting? There are some dependencies in NDIS stack which could affect binding. If you want to force the protocol driver run as Start=0 (bootable) driver you need to be sure that Miniport and Intermediate drivers, which belong to the same stack as your protocol driver, have Start=0 too. Igor Sharovar
From: Guilherme Moro on 17 Dec 2009 12:11 hello, Yes, need to be in early boot, the boot is made over the network. I had tried several configurations for the drivers involved in boot, no success. Everything works fine for XP, but I could recall that some tests in Vista had showed up the same problem. I made some tests yesterday, and the bind occurs somewhere in time, but it takes much longer than I was expecting. What exactly has changed in the Vista/7 mechanisms of binding, that make the process take so much longer, I still dont know. I will keep trying to do this, and I will return with some more test results for you guys to think about! =) Anyone suggest some way to test and find some useful information? Perhaps NDIS tracing give some clue?(I must confess that the output of NDIS tracing doesnt help, because I dont know what exactly to look for in it). Guilherme Moro On Dec 16, 10:44 pm, eagersh <eagers...(a)gmail.com> wrote: > On Dec 15, 3:18 pm, Guilherme Moro <guilherme.m...(a)gmail.com> wrote: > > > Hello all, > > > I have a protocol driver that works perfect in windows XP, and Vista, > > but in the Windows 7 I cant make it binds the same way. > > If I use the protocol after the machine have booted from a hard drive, > > its all ok, everything looks just fine, but if I try to boot from my > > virtual disk ( network backed ) the protocol simply dont bind. I > > receive a NetEventBindsComplete, but the bind never occur. > > I have checked the protocol name and all this kind of stuff, and cant > > find any clue, and as I said, the problem its just when booting, if > > the machine boots from another disk the bind occur as expected. > > > Anyone has any clue? > > > Guilherme > > Is your protocol driver need to be in the early stage of booting? > There are some dependencies in NDIS stack which could affect binding. > If you want to force the protocol driver run as Start=0 (bootable) > driver you need to be sure that Miniport and Intermediate drivers, > which belong to the same stack as your protocol driver, have Start=0 > too. > > Igor Sharovar
From: Pavel A. on 16 Dec 2009 20:34 "eagersh" <eagersh20(a)gmail.com> wrote in message news:8fa28d31-43eb-4ddc-9f8a-cbcad8b6f33f(a)z3g2000prd.googlegroups.com... > On Dec 15, 3:18 pm, Guilherme Moro <guilherme.m...(a)gmail.com> wrote: >> Hello all, >> >> I have a protocol driver that works perfect in windows XP, and Vista, >> but in the Windows 7 I cant make it binds the same way. >> If I use the protocol after the machine have booted from a hard drive, >> its all ok, everything looks just fine, but if I try to boot from my >> virtual disk ( network backed ) the protocol simply dont bind. I >> receive a NetEventBindsComplete, but the bind never occur. >> I have checked the protocol name and all this kind of stuff, and cant >> find any clue, and as I said, the problem its just when booting, if >> the machine boots from another disk the bind occur as expected. >> >> Anyone has any clue? >> >> Guilherme > > Is your protocol driver need to be in the early stage of booting? > There are some dependencies in NDIS stack which could affect binding. > If you want to force the protocol driver run as Start=0 (bootable) > driver you need to be sure that Miniport and Intermediate drivers, > which belong to the same stack as your protocol driver, have Start=0 > too. .... which won't happen, as the miniport is a PnP driver; start=0 has no effect. --pa
From: eagersh on 17 Dec 2009 20:53
On Dec 17, 10:11 am, Guilherme Moro <guilherme.m...(a)gmail.com> wrote: > hello, > > Yes, need to be in early boot, the boot is made over the network. > I had tried several configurations for the drivers involved in boot, > no success. > > Everything works fine for XP, but I could recall that some tests in > Vista had showed up the same problem. > > I made some tests yesterday, and the bind occurs somewhere in time, > but it takes much longer than I was expecting. > > What exactly has changed in the Vista/7 mechanisms of binding, that > make the process take so much longer, I still dont know. > > I will keep trying to do this, and I will return with some more test > results for you guys to think about! =) > > Anyone suggest some way to test and find some useful information? > Perhaps NDIS tracing give some clue?(I must confess that the output of > NDIS tracing doesnt help, because I dont know what exactly to look for > in it). > > Guilherme Moro > > On Dec 16, 10:44 pm, eagersh <eagers...(a)gmail.com> wrote: > > > On Dec 15, 3:18 pm, Guilherme Moro <guilherme.m...(a)gmail.com> wrote: > > > > Hello all, > > > > I have a protocol driver that works perfect in windows XP, and Vista, > > > but in the Windows 7 I cant make it binds the same way. > > > If I use the protocol after the machine have booted from a hard drive, > > > its all ok, everything looks just fine, but if I try to boot from my > > > virtual disk ( network backed ) the protocol simply dont bind. I > > > receive a NetEventBindsComplete, but the bind never occur. > > > I have checked the protocol name and all this kind of stuff, and cant > > > find any clue, and as I said, the problem its just when booting, if > > > the machine boots from another disk the bind occur as expected. > > > > Anyone has any clue? > > > > Guilherme > > > Is your protocol driver need to be in the early stage of booting? > > There are some dependencies in NDIS stack which could affect binding. > > If you want to force the protocol driver run as Start=0 (bootable) > > driver you need to be sure that Miniport and Intermediate drivers, > > which belong to the same stack as your protocol driver, have Start=0 > > too. > > > Igor Sharovar You need to be sure that a miniport, Pschd( it is intermediate driver and it has Start = 1 by default), and likely NdisCap( by default Start =3), WfpLwf ( by default Start=1) have Start=0. If you install any additional network devices, which have NDIS intermediate drivers, make sure that such driver has Start=0 too. I suggest to you to check all drivers, which belong to NDIS group, and analyze order in NDIS stack. The bottom line is that if you have NDIS Protocol driver with Start=0 but there are underlying NDIS drivers, both intermediate and miniport, have Start != 0 it binds the Protocol driver to miniport driver latter than you expect. Igor Sharovar |