wonka

Martin, Thanks for the advice. Yes I manage my INF cache very closely. And I have used that tool before. It really doesn't do me any good however as thats not where the Slow NIC response time comes from. I can use devcon to manually load the driver after booting from a CD into WinPE and it takes the same amount of time to load the driver, finish initializing.. or whatever it should be called. Once the driver is inserted(?) the TCP stack binds swiftly and the whole stack comes up immediately. There is no network traffic during this "phase" so I would guess its running tests or detection routines to figure out which specific NIC chipset is there. I've almost thought.. well perhaps writing my own e100 driver from the Windows DDK is the only approach to getting around this.. Intel seems to publish lots of details on the chips and Linux people seem to write drivers.. trying to be optimistic here.. maybe we need a third party WinPE driver only club (ironic since Microsoft released WinPE to get around dual drivers for 16 bit and 32 bit.. now we need dual for WinPE 32 and Mainstream Intel 32 support of Windows..

Hi, Thanks for answering Mat. Nope all P4, some Xeon Nacona trials.. depending on what I could get my hands on. No PIII processor based gear. Although the Xeon boards with e100 nics were the worst at 25 minutes for the NIC drivers to load under WinPE 2005. I strongly suspect something in the drivers and its driving me crazy I've thought about it, and wonder if maybe the drivers aren't tested for hyperthreading and multiprocessor compatibility. A friend is recommending running a Kernel Debug or Driver Exerciser session to "watch" the drivers and see which specific call they are taking so long to execute.. I may go down that road.. but Kernel debugging seems a lot to learn to solve this problem. The fastest darn NIC card I have is a PCI Intel Desktop Pro 100/S adapter (cheap) loading on a uniprocessor machine with hyperthreading turned off at 40 seconds from power on to WinPE desktop... from 40 sec to 25 minutes?.. I would think Intel would be very concerned.

a b c

I've had a very similar experience. Going strictly with WinPE 2005 (all legit and properly licensed). Virtual PC 2004 SP1 is pxe booting off a RIS server using the RFGB floppy image, it loads all of the files it needs to boot (effectively this means it passes tftp textmode downloading, gets the binl service reply for which driver to use, downloads dc21x4.sys.. runs right up to loading the ntoskrnl.exe.. then produces the WinXP gui complete with beamers.. 14 shots.. and goes toes up.. it produces a Blue Screen of Death). The error message is rather obscure but documented in the Microsoft Technet as Debug error 0xBB with parameter 0x3 which means [ DHCP IOCTL to TCP failed]. On some Intel boards I've had 7,15,25 minutes an then a successful boot. I'm pretty sure it's driver related. Sure wish we could get a handle on how to fix this.