GreenMachine

That's an easy one: I'll take it! Try this ... [COMMANDS] "useraccounts.cmd" "REGEDIT /S regtweaks.reg" "RunOnceEx.cmd" Welcome to MSFN!

Up until recently, on the bottom of the main MSFN page (http://www.msfn.org/board/index.php?), you could show a list of Online Users by Last Click (or something like that). I cannot find it anymore! Was I ... mistaken? Has this function been creuly disposed of?

Thanks again, Virindi, it's works for me. For those testing, the line to add in XPCREATE.INI is: DLURL=http://msfn.wiretapped.us/XPFILES Attached is the corrected list. Sorry about that! (Ooops, beat me to it, file removed.)

Wow, a volunteer! Thanks, Virindi! I hope you enthusiaism lasts. Now, fo rthe bad news ... there is a bug in your list ... ADD SVC-HF2\OE6.0sp1-KB837009-x86-ENU.exe http://download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/OE6.0sp1-KB837009-x86-ENU_53c7328bc3225121977ae394f92def0.exe 1996032 should be ADD SVC-POS\OE6.0sp1-KB837009-x86-ENU.exe http://download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/OE6.0sp1-KB837009-x86-ENU_53c7328bc3225121977ae394f92def0.exe 1996032As for the multilingual versions, I would suggest waiting till another volunteer takes on another language, and that person could send it to you for hosting. Or something like that ... Thanks again!

My idea ... Copy all the files of your 2003 CD to the HDD (e.g. C:\XPCD\). Use your modified CDImagePro and create an ISO image using only the original files, without WINNT.SIF. (The boot image file is the same for 2000, XP and 2003. It just differs per language.) If that does not have the delay, add WINNT.SIF WITHOUT the Windows Path, and test again. If you still do not have the delay, add the Windows Path. This will at least help in pinpointing the problem. You may also want to validate the CD with a program such as CDCheck, as well as test the CD on different hardware (I know, I know, but that really is one of the first tests to perform, in all cases. Like looking at the gas gauge when the car dies.)

Cool, another bug solved!

Yes, but I can handle a "Version greater than expected" error much better than a "Hotfix not installed" error!

I have released a test version that supports this File List, providing the user provides a download URL, and updates XPCREATE.INI to use that URL. Please see the XPC Test Thread.

Thanks to all those that contributed. I'll leave the collection as is, until new additions are requested.

I have made a few changes to XPCREATE, and have posted a version for testing HERE. Hotfix Downloading has been incorporated, however I have not hosted the Hotfix List. In order to use the list, you must host it using this directory structure: <URL>/<WINVER>/<WINLANG>/XPCTHLST.TXT. This could look something like: http://www.microsoft.com/XPFILES/XPP/ENU/XPCTHLST.TXT for the English XP Pro Version. Other changes include: On first run, source is copied to CDSOURCE. On first Service Pack Slipstream, SP is slipped into CDSOURCE if it exists, and the SP is moved to OLDFILES. Optionally updates WINNT.SIF with OEMPnPDriversPath. You must set the XPCREATE.INI file to include DOPATH=YES, and the .NET framework is required. DOSNET now updated with new file names of files in sub-directories HotFix Downloading (You must provide the DLURL.): All hotfixes are checked for correct size. If an existing hotfix has incorrect size, it is moved to OLDFILES, and a new file downloaded Service packs are always moved to OLDFILES once slipstreamed into CDSOURCE, or if DL List shows Source already up to date. If a download error occours, downloading continues, and program gracefully exists after all possible downloads.

Please post the files LOGFILES.CAB and DOSNET.INF that you can find in the NEWFILES directory. I believe that the file IS in DOSNET.INF, and that is the problem. as it is not an 8.3 type name. If this is the case, the only clean workaround will be to install that update from GuiRunOnce when doing a DOS mode install. Please post those files, so I can figure it out. Thanks.

But it is! Keep the oemxx.inf, name doesn't matter. You should find the .cat if you can, probably named oemxx.cat somewhere, if not, use DriverSigningPolicy=Ignore (or whatever). Put all the files in the same $OEM$ ... directory, not the inf (unless yo really ant, it is up to you ... ) In answer to your question, maybe yes, maybe no. Looking at the driver list you mention is not a "fool proof" way to get your drivers.

The easiest way is to use the DriversGuide Toolkit. Site: http://www.driverguidetoolkit.com/ Download: http://www.driverguidetoolkit.com/cgi/download.pl?dgt.exe It does not save the CAT files, but you should be able to identify them as well. It is a trial version, but if you are formatting the disk, no big deal.

OK, I'm getting desperate ... Even links to drivers are welcome. Feel free to send any along: I can handle doubles. To those (few) of you that dd send me some, thanks! Again, my email address is in that ugly signature, just below.

Well, I guess I was in a generous mood!

Welcome, joesu, to XPCREATE! Sorry, I have neither seen nor heard that one before. Your log files look just fine. I'm afraid the only advice I have is trial and error to determine which of the hotfixes/updates may be causing this. If you do find the answer, please share it!

Failsafe is the next step: Go to the Current hotfix list on the web site, and start clean, using only those hotfixes listed in bold. No other programs. No reg tweaks. Just plain vanilla. If that does not work, attach the file LOGFILES.CAB, that you will find in the NEWFILES directory.

Welcome to XPCREATE, Quin! I cannot think of anything you have missed. I do, vaguely, remember seeing this once before. It sounds almost as if after acepting the conditions, or whatever, WMP did not have the necessary permissions to store your settings, thus looped back to accept. As usual, I am sure that this is not an XPCREATE issue. Did you try as administrator? If you re-install WMP9 does it go away? What happens with NO WMP9? If nothing else ... what does the Failsafe Install say?

Send 'em anyway. The point is the difference in versions, so I'm internested in as many as possible. If it is a double, I'll just toss it ... There are still a bunch from RyanVM's list that I don't have a copy of. If you have some of these, with the txtsetup.oem, .sys, .inf and .cat files, don't be bashfull. In fact, I've only recieved two drivers ... So, in the meantime, ...

Mute point ... the Security Rollup superceeds that hotfix, which just has the ntkrnl*.exe files (or whatever they were called). Otherwise it would be on the list. The Microsoft Baseline Security Analyzer is my reference point for hotfix installations. Windows Update is ... flakey. Welcome to MSFN, powaking!

I was just lettin' ya stew! Welcome to XPCREATE! Also, as stated, you can use CDROOT instead of the ISO if you require the files in that form. With extracting you would probably would end up with a corrupted DRIVER.CAB or something ...

Attached is a prototype XPCREATE Service Pack\Hotfix Download List. This list is current. The planned XPCREATE integration will be that XPCREATE.INI will contain a URL where the download lists are stored, using a predefined directory structure. The file will always be named XPCTHLIST.EXE (until I change it ... ). My criteria for the hotfixes in the list are that they can be included in the SVC* or SPACK directories, are downloaded directly from Microsoft, and are required as determined by the MS Baseline Security Analyzer. More or less ... The user must define this URL, and is responsible for it's content. Anyone with a Web Server can host these files. I do it on my local server. As to how it will be implemented, that remains to be seen. Tasks that will need to be done, by someone other than myself, include: Keep the list up to date per Windows Version and Language and Service Pack and Hotfixes Host the list In the meantime, anyone interested may already start collecting the data and create their own Version/Language specific list. I will continue this integration after my current SATA/RAID quest, at which time I will also unlock this thread! Till then, feel free to create any localized lists, and send them to me for testing. Thanks. [Attachment removed]

So ... this is going to be a Little Red Hen kind of deal? "Who will help me eat my bread" ... I would appreciate a hand here ... you have been warned!

I wish I could do that ... Before deciding to use the simplified raskren method, I attempted to get the [MassStorageDevices] with no luck. I do like that it does not require TXTSETUP.SIF modification, though the way it is done is still very clean (tacking on the OEM info at the end, but you know that ... ) As soon as I get some time, I may have to have another look at this. Still, the XPCREATE way seems to work fine for for nearly everyone. The few that don't go off and post elsewhere ... Nice job! Thanks!

@VAD: The long answer ... \SETUPS\SETUPS.EXE would refer to the SETUPS directory at the root of the CD, something like D:\SETUPS\SETUPS.EXE. .\SETUPS\SETUPS.EXE would be relative to the local directory, in the typical case D:\$OEM$\SETUPS\SETUPS.EXE. ..\SETUPS\SETUPS.EXE would refer to SETUPS\SETUPS.EXE, relative to the parent directory, in this case again D:\SETUPS\SETUPS.EXE. If CMD1.CMD is in the same directory, both "CMD1.CMD" and ".\CMD1.CMD" can be used to call the script, as well as possibly, "..\$OEM$\CMD1.CMD", or even "\$OEM$\CMD1.CMD". To call REGEDIT, "REGEDIT.EXE" could be used, but ".\REGEDIT.EXE", and all the rest do not work. When using MSIEXEC, the MSI installer, I seem to remember that when passing the filename of the MSI file, it was necessary to specify .\INSTALL.MSI, or MSIEXEC would look in the directory in which it resides: SYSTEM32. Never having attempted do disect the DOS interpreter, I would suspect that the \, .\, and ..\ notations are expanded to the absolute paths, while notations that start directly with the file name, or directory name, are not expanded to the absolute path. All that is, of course, based on my uneducated observation of what seems to be happening. For my purposes, that explanation works fine! The short answer: yes, that syntax should be fine. Also, as my memory serves me ... I have used more than one command line in CMDLINES.TXT, even in Windows 2000.