duveldj

I've never been able to successfully get the driver_fix.cmd to run automatically on boot, even making absolutely no changes to the build files. Is there anybody else having this problem? Network connectivity functions fine after I run Driver Fix, but I'd like to do it automatically so that the only time I need to interact with the system is once network connectivity is fully functional.

Have you tried to just load the driver into WinPE offline so they are already integrated when you boot? For example I have integrated all the HP drivers in their latest Proliant support pack into my PE boot image and it finds all the hardware etc without having to run a custom driver load script. copy all your drivers to a folder like DRIVERS each driver can be in its own subfoler Mount the WinPE image - normal command you always use use this command to install all the drivers into the winpe image dism /image:Mount /add-driver /driver:Drivers /recurse /ForceUnsigned where Mount is the actaul directory you mounted your pe image. then do all your other normal things liek copy additional files or custom startnet.cmd install packages etc. save the WIM file and now all the drivers will already be in WinPE and there is no need to do the driverload scripts manually after boot Just my 2cents Yup, that was the first path I took. I discovered something interesting on playing with it a little bit more though...ALL of the drivers I needed, including the 3 different brands of RAID controllers I've been testing with, were included in the original WinPE.wim from the AIK. The problem I've been having is that it's not loading the drivers on boot; I have to force them to load with PnPutil. Originally, I was just loading the entire \Windows\inf directory, but I came to discover that the only driver I needed to load to get everything seen and functional (except the add-in RAID controllers) was the machine.inf file. Everything - from system registers to the NICs - gets recognized just by loading that inf with PnPutil.The problem I'm stuck with now is that the machine.inf file works fine on my Intel 5000 chipset-based system, but on my 5500 chipset-based system, I get a huge amount of system lag after the inf gets loaded. Everything still shows up in Device Manager, but if I look at system utilization in Task Manager, the first CPU core spikes to 100% every 5 seconds or so. The lag is so intense that the mouse stops moving for a half-second, every 5 seconds. I was digging around in the machine.inf file in Notepad to see if I could isolate the problem, but it's way over my head. Really, the ONLY thing that I care about is getting the NICs functional on boot. I don't care about seeing the rest of the devices, I just need to be able to automatically map an iSCSI target on boot, and the NICs need to be functional before I can do that. The driver that machine.inf loads for the NICs in my 5500 chipset-based system is a *.sys file in \Windows\System32\drivers, so I'm working on a way to forceload a sys driver - not an inf.

Nope, none whatsoever. Just to make sure I wasn't giving you bad information last night, I got a fresh winpe.wim out of the PE3 AIK. Mounted it with imagex, copied a LICENSED ("evaluation" option doesn't put key.dat file in install directory and causes BIT to error out on opening) portable install of BIT v6.0 over, then copied msvfw32.dll into the System32 dir. Unmounted and committed changes, exported it with imagex, then threw the resulting WinPE.wim onto my syslinux PXE server. 4 separate test systems (Intel SR1600URHS, Intel SR2600URLX, Intel S5520HCR custom system and Intel S5000PSLR custom system) brought up the full BIT GUI when running bit.exe in winpeshl. It really should be invoked with -x in any vanilla WinPE environment, as I see no need to mess around with the DirectX shenanigans. I also recommend deleting the 4 DirectX-related files from the BurnInTest directory before unmounting (dsetup.dll, dxsetup32.dll, DXSETUP.exe and dxupdate.cab) to save about 2MB on the final wim.

If it hangs on the TFTP, it's unlikely to be DHCP settings; particularly if you boot successfully some of the time but not all the time. Is the TFTP server itself firewalled? That might cause some issues, if it is. I can only speak in generalities unfortunately, as I'm using an Ubuntu box and syslinux for my PXE booting.

For some reason, I can't get drvload to perform as expected; rather than exiting out of the command window, it seems to just hang there (yes, I made sure the "EXIT" command was at the end of both startnet.cmd and driver_fix.cmd). For now I'm just using PnPUtil to install my drivers as needed. Weirdly, even though it will still install all of my second test system's chipset drivers, they won't show as being installed in Device Manager until I use PnPUtil to forceload machine.inf. Even more weirdly, installing machine.inf causes the CPU load on the first core to jump to 100% every 5-6 seconds; the CPU utilization gets so high that USB input (i.e., mouse) freezes up each time it does, making the system much more difficult to use. Still figuring out what's causing that issue, because it didn't happen on my first test system, and this second system is MUCH more powerful. Specs of each system:System 1: Xeon E5450A 3.0GHz Quad-Core 16GB DDR2-667 FB-DIMM RAMM System 2: Xeon X5570 2.93GHz Quad-Core (Hyper-Threaded to 8 cores) 24GB DDR3-1066 ECC RAM If I figure out what's going on there, I'll let you guys know. In case anybody here is trying to do the same thing, I forgot to mention one thing; I needed to copy over "msvfw32.dll" from my workstation's Windows\System32 folder into the PE System32 folder. That's the only thing needed to get BIT Pro v6.0 working in PE3. Actually, if you look at the documentation for BIT on WinPE, you will note it is only for WinPE 2.x. Also if you look on page 2 of the manual, you will see a familiar name. If you find any differences between those instructions and how things are done with WinPE 3.0 (ie not using any third party apps like Make_PE, etc) I can get Passmark to update that guide. Pffft...who uses only the manual as a guideline for what will work? I think most of the people in this forum are deviating pretty far from any published manuals. The only thing that I can think of that won't work under WinPE (as far as I know so far, anyway) is the 3D tests. Even with msvfw32.dll copied over into the System32 directory, starting BurnInTest under PE 3.0 will pull up a prompt saying that you'll need to install DirectX 9 to run the 3D tests, and asking if you'd like to do so. The install obviously fails. If you click No, however, all of the rest of the tests are fully functional. Reading your install guide, I see that this is a known issue and the test can be invoked with a parameter to skip the DirectX check. So no, other than msvfw32.dll, no changes from your install guide (with one additional note that you CANNOT "install" BIT Pro to a USB key under an evaluation version; it has to be fully licensed. Trying to load BIT v6.0 Pro on a PXE boot with just an evaluation license yields a startup error because it can't find the key.dat file. I just ran BurnInTest over the weekend on a system, on RAM, CPU and the locally attached storage (only about 5TB). It ran without errors for nearly 72 straight hours. This was the result: BurnInTest results BurnInTest Version V6.0 Pro 1020 Date 05/17/10 10:31:56 Logging level Normal System summary System summary Windows 7 Ultimate Edition build 7600 (32-bit), 1 x Intel® Xeon® CPU X5570 @ 2.93GHz, 23.9GB RAM, 40GB HDD, 4843GB HDD, General System Name MININT-1D9HOQM Motherboard Manufacturer Intel Corporation Motherboard Name S5520HC Motherboard Version E26045-453 Motherboard Serial Number QSHN01500091 BIOS Manufacturer Intel Corp. BIOS Version INTEL - 0 BIOS Release Date 2010/02/27 CPU CPU manufacturer GenuineIntel CPU Type Intel® Xeon® CPU X5570 @ 2.93GHz Codename: Gainestown CPUID: Family 6, Model 1A, Stepping 5, Revision D0 Socket: LGA1366 Lithography: 45nm Physical CPU's 1 Cores per CPU 4 Hyperthreading Enabled CPU features MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 DEP PAE Intel64 VMX Clock frequencies - Measured CPU speed: 2934.8 MHz - Multiplier: x22.0 - Base Clock: 133.3 MHz - Muliplier range: Min: x12, Max non turbo: x22 Cache per CPU package - L1 Instruction Cache: 4 x 32 KB - L1 Data Cache 4 x 32 KB - L2 Cache 4 x 256 KB - L3 Cache 8 MB TDP Limit: 95 Watts TDC Limit: 85 Amps Memory Total Physical Memory 24516MB Available Physical Memory 23706MB Disk volumes C: Local drive, New Volume, NTFS, (40.00GB total, 20.28GB free) D: Local drive, New Volume, NTFS, (4842.92GB total, 4782.82GB free) X: Local drive, Boot, NTFS, (0.03GB total, 0.03GB free) Disk drives Fixed disk (Size: 40.00GB) Fixed disk (Size: 4842.92GB) Optical drives Network Ports Result summary Test Start time Fri May 14 17:10:19 2010 Test Stop time Mon May 17 10:31:36 2010 Test Duration 065h 21m 17s Test Cycles Operations Result Errors Last Error CPU 37779 1.1Quadrillion PASS 0 No errors Memory (RAM) 1159 17.552 Trillion PASS 0 No errors Disk (C:) 6351 5.840 Trillion PASS 0 No errors Disk (D:) 60 6.250 Trillion PASS 0 No errors Seeing as how these are servers I'm building and not gaming systems, I'd say I'm pretty happy with having just those pieces working.

In case anybody here is trying to do the same thing, I forgot to mention one thing; I needed to copy over "msvfw32.dll" from my workstation's Windows\System32 folder into the PE System32 folder. That's the only thing needed to get BIT Pro v6.0 working in PE3.

Thanks for the reply! Given your new advice, I went back through to retrace your steps with the additional clarification, and a lot more made sense to me. Do I understand correctly that you've basically incorporated Microsoft DaRT 6.5 into your environment and are using its files to initialize networking? It took me quite a bit of searching to realize that only MSDN and Technet subscribers can get their hands on that; while I do have an MSDN subscription, it looks as though MDOP 2009 R2 (Microsoft Desktop Optimization Pack, the suite that includes DaRT) is out of my subscription limitations. I'll see what I can do to get a hold of it somehow; it seems like it would be useful to have in my PE environment if only for its deployment and troubleshooting tools.I had read on TechNet that the InitializeNetwork switch for wpeutil does this: "Initializes network components and drivers, and sets the computer name to a randomly-chosen value." I had been looking at a lot of solutions for about 6 hours at that point, and in my haze I read that as installing all the drivers, not just the networking drivers. BurnInTest v6.0 Pro is what I'm using. Company already had the license, and v6.0 actually has an "Install Portable" option. I can literally mount my WinPE.wim and install BurnInTest to the Program Files; completely works. The funny thing is, even if I haven't run PnPUtil to install my test system's device drivers, I can run BurnInTest and have it correctly detect the motherboard model number (and even the serial number), the model number, stepping and revision of the processors, the NIC and the RAID controllers. Apparently BurnInTest is better with unknown devices than WinPE. Ahh; so you're calling drvload to install drivers. I could theoretically make that work, but only with a fair amount of leg work. This is going to be a manufacturing environment PXE server, so there will be a fair amount of diversity amongst the systems. I'd rather not hunt down individual drivers (and potentially install conflicting drivers) for each specific system. Ideally, what I'm trying to do is just put all of the specific drivers that I might need for all of the systems into the PE build, and have the boot process automatically load the drivers that each specific system needs. It's starting to look like injecting the drivers into the .wim and running PnPUtil before my shell is the only way to accomplish that, but I'll keep you informed if I find a more elegant / faster solution.

I've recently been tasked by my company to deploy a PXE server that can boot up into a WinPE environment for us to run Burn-in cycles and remotely image systems. I've got the PXE portion working without a doubt, and I've even gotten WinPE largely functional (mainly because of the efforts of Kullenen_Ask and wimb - thank you very much to you two!). In fact, I'm using the Make_PE3 program to get the Explorer shell working, as I found I couldn't follow along with all of Kullenen_Ask's instructions for doing it manually. The only problem at this point is that I cannot seem to get the drivers for most of the devices to load at boot. I have to run PnPUtil, and then run PENetwork to get the environment functional. If I edit my wipeshl.ini to run the WinPE Shell instead of PEShell or Explorer, it appears that it has proper networking support; I can ping other computers in my network without having to run PnPUtil to load drivers. If wipeshl.ini is set to load Explorer or PEShell, my test system's NICs (and a bunch of other devices) show up as unrecognized in Device Manager. Running PnPUtil resolves these conflicts without having to load additional drivers into the image. Now, I know that I can just edit my wipeshl.ini to launch PnPUtil before it launches either PEShell.exe or explorer.exe, but this seems to add quite a bit of time to the bootup sequence, and regardless, I still have to run PENetwork to get the NIC to pull an IP from my DHCP server. Trying to ping anything without running PENetwork beforehand (even though the NIC drivers are installed) results in an error. My two questions, and I would be extremely appreciative if anybody could help out since I'm at my wit's end: 1) Can I get the WinPE environment to load the PNP drivers without running PnPUtil beforehand, or is this not possible? It seems that WinPE loads most of the drivers in the Windows\inf directory, but not all of them. Running PnPUtil seems to be the only way to get the rest of the drivers to load, currently. 2) Is there any way to get networking to automatically start the way it does if I configure wipeshl.ini to load wipeshl.exe? That is, without running PENetwork? I tried adding "%SYSTEMROOT%\System32\wpeinit.exe" as a line above the line invoking PEShell.exe (as it exists by default after using wimb's Make_PE3 app to make the image) but this doesn't seem to do anything. According to Microsoft's documentation, running wpeutil.exe with the flag "InitializeNetwork" will "load networking support and PnP drivers," but that also doesn't seem to work. Thanks!