So, you’re booting from the network?
Then please tell us how the additional driver can help in this case.
The bootloader will use the card’s BIOS (or EFI driver) to access the LUN. Yes, it will allow Windows kernel and lots of other stuff, like tcpip.sys, to be loaded.
But then, when your additional driver will get control, there will be no ways (except probably some “generic EFI driver”, which is absent on non-EFI systems) to access the LUN to load your NIC driver.
So, the solutions are:
- rely on some “generic EFI” way (which ends in the card’s BIOS chip) to access the boot LUN. Does not work on non-EFI system.
- pre-patch the existing OS image to add the NIC adapter object there. For this, you need not only a driver in the driver store, but also a PnP devnode for a NIC and NDIS registration entries. Probably CriticalDeviceDatabase can help. Probably not.
- CriticalDeviceDatabase will surely work for storage controllers. So, if you can write a driver for your NIC which will expose it as storage controller (iSCSI-based), then this will be much simpler.
Also search the list archives, the problem was discussed here in some months.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> “PnP itself is this “listener” driver, which invokes the driver installation
> procedure when a new NIC is found.”
>
> As per this theory then driver for new NIC should get installed, right? I’ve placed them in the driver store yet they don’t get installed. And I’ve tried using “devcon dp_add” long back, it does not work. You receive the same BSOD as mentioned here,
> http://support.microsoft.com/kb/976042
>