DarkShadows

@Felix Okay, now we got it. Building your 7-zip installer package fails because your Download folder path contains spaces. (I'm not guessing now, I just tested and verified this on my own PC). This is a legitimate bug. Folder paths with spaces most likely worked in v4.5 and not in v5.0 because I changed the 7-zip command line. (I moved all files into WorkMSDB and filter out the unneeded ones now). So I need to play around with the 7-zip command to support folder paths with spaces again. In the mean time, change your folder path to one with none of the special characters I listed above, and no spaces, and you should be able to build your installer. If that is all I missed in my own testing, then it's a been good day! WGANotify Setup Help dialog is not an error: In fact, it is even expected, and documented! If you read the Windows Genuine Advantage Notifications section of the Guide, you will understand why. HINT: It is also mentioned in the MSDBuild.log file that you just posted above: .-- 16:14:50.42: WARNING: Could not extract WindowsXP-KB905474-ENU-x86-Standalone.exe. .-- (If you saw a WGANotify Setup dialog, the file .-- was already extracted--disregard this warning.) This is a non-issue. I could not come up with an elegant way to determine if WGAN was already extracted and renamed or not. So I just documented what happens. Read the documentation! This is the same as it was in v4.5. As to WUD saying that it is downloading v4.5: No where in the current MSDownloads.ulz update list is MSDBuild or the Guide referred to as version 4.5. So make sure you re-download the MSDownloads.ulz update list from the first post. (I clearly state in my guide that you must re-download this file with each new version.) Also, just to be sure, delete MSDownloads.ul from either (or even both) of these folders first: %ProgramFiles%\Windows Updates Downloader %UserProfile%\Local Settings\Application Data\Supremus Corporation\Windows Updates Downloader Then re-download MSDownloads.ulz from the first post. @Everyone I will look into fixing the folder-path-with-spaces bug in the next day or two. (However, it may be a 7-Zip limitation). In the mean time, do not use : "(", ")", "&", "|", "<", ">", "!", "%", or spaces in your download folder path!

@Felix Where exactly did you see "v4.5"? I'm looking for it, but I cannot find attached to my Guide or MSDBuild, except in the past-tense. (The current guide version discusses Guide v4.5 in a couple places: Version History, et cetera.) Windows Installer is also listed at v4.5 because that is the version of that Windows update.

@Felix Thanks for the report. Change the name of your download folder, removing the parens: "(" and ")". CMD.exe and NT Command scripts do not play well with any of these characters: "(", ")", "&", "|", "<", ">", "!", "%". This is also why the error count was incorrect in the last line of your MSDBuild.log: 14:07:14.53: MSDBuild.cmd ends with 0 errors and 2 warnings. The script's logic branching will get confused if your folder uses parens. @Everyone If you want to post an issue report, it's okay to copy-and-paste a small section of your log in your post (inside a code block), but please do not code block your whole log! When you post an issue, please include your entire log file (unedited) as an attachment. That way I can download it and look at it offline. Thanks! -DS

1. Personally, I launch an NT command script from CommandLines.txt. And from that script I install all of my Registry Tweaks from inside individual .reg files for each product/application/hardware driver. 2. Long file names are supported inside $OEM$ 3. I leave Windows XP prefetch alone (as it it out-the-box). As I understand it (and I can be wrong), yes, prefetch still has a positive impact on modern day PCs. This is because the slowest part of any PC system is the hard disk drive seek time—how fast the hard drive actuator arm and read/write head move radially across the rotating platter's surface. Seek times have not improved significantly in at at least five years (average about 8.5ms). This is what Windows prefetch seeks to minimize, by trying to copy frequently loaded system files into a particular area of the hard disk drive to decrease the "thrashing" of the actuator arm back and forth, allowing these files to be read in a more continuous stream. In my opinion this works for a time, until you install a number of hardware driver updates, and windows updates, which means things get dropped from and added to the prefetch cache, and (in my opinion) are likely to get fragmented. So I clean out this cache about once every 6 months (along with a thorough registry and hard disk drive defrag) to let Windows start caching things fresh again.

First I will answer your questions in general, using an NT command script example: :Start @Echo Off Mode Con: Cols=80 Lines=25 Title <your title here> :Main Call :SetVars Call :SomeOtherLabelSubroutine Call :Install Goto :EOF :SetVars Set InstallINF=rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 <set your other variables here> Goto :EOF :Install <other commands here> Start /Wait "Provide a title" %InstallINF% .\YourFile.inf <other commands here> Goto :EOF NOTE: Providing a title for the Start /Wait command is vital in order to avoid errors with parameters passed to the command being started. NOTE: The above code assumes that the NT Command Script (.cmd) and Setup Information file (.inf) reside in the same folder. The ".\" before the Setup Information file name is required. NOTE: The example above assumes the invoked .inf file contains a [DefaultInstall] section. However, now that I have given you all that, you still cannot use this technique for the .inf file that you are trying to install, which is part of the Microsoft Update Catalog Web Control Class ActiveX Control. ActiveX control .inf files are different from the type used to install hardware drivers and such (which the process shown above is for). In any event, I have already built an installer (and an installer builder) for all the Microsoft Update web sites ActiveX controls. Read Guide: Download Everything Microsoft, which is pinned in this forum (link also in my signature).

Guide and MSDBuild updated to v5.0 Please read the Version History in the first post for more information. B) -DS

A new SSIBuild version is out, go get it. B) Sysinternals Suite Installer Builder Version: 2.0 Sysinternals Suite Current Build Date: 2009-02-04 SysinternalsSuite.zip Changes: Executable Program Version Date ------------------------------------------------------ AccessChk.exe AccessChk v4.23 2008-12-17 Autoruns.exe AutoRuns v9.39 2009-02-03 Autorunsc.exe Autorunsc v9.39 2009-02-03 ProcExp.exe Process Explorer v11.33 2009-02-03 ZoomIt.exe ZoomIt v3.2 2009-02-03 Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

Thanks for the issue report! I just signed into to msfn.org to post a new SSIBuild version too! Yes, this issue is very similar to the French one. I have an idea how to fix this issue once and for all, and for all languages to (so long as they use Arabic version numbers). Chack back here in a hour or so and it will be fixed.

I believe it is me and not MS. The version inconsistency is a bug of sorts created by the original process I chose. Historically, I manually updated my Inst*.inf files for each ActiveX control with the .dll version. As time goes by, Microsoft releases a new ActiveX control .dll version, so my hard-coded Inst*.inf file version becomes outdated. (You still use the current version .dll file, but the .inf file sets the registry to an older version.) I'm thinking about how to fix this in the next version of MSDBuild so as to address .dll versions programmatically across all the ActiveX control .dll files. In fact, I am already doing this for two of them. Hey nice catch! That bug has only been there since like v1.0. You are the only person who caught it! I will fix in the next version of MSDBuild. I will be updating MSDBuild (and the guide) in the coming days, so this will change a little. But for now, download everything using WUD then run MSDBuild.exe. Do not delete the work files! Read the Issue in the guide (or Readme.txt file) regarding non-English language usage. Edit the lines noted inside of each of Inst*.inf files noted. NOTE: If an Inst*.in_ file exists, edit it instead of the Inst*.inf file of the same name, since MSDBuild will always copies the Inst*.in_ file to create the Inst*.inf file with each execution (appending some information to it and overwriting the Inst*.inf file in the process). The file on the sever is not corrupt, since I just downloaded it (over dial-up no less) and tested it. I don't publish the direct download links to any of my files since they are hosted on free file-hosting sites (the download links may change frequently). Also, I encourage using WUD because when you download everything with it, you will always have the most up-to-date files, since all of the download links are reusable now (even MS finally got their act together). Is it only that file that gets corrupted? If not, make sure you have .Net framework 2.0 installed on the PC you run WUD on. And try re-installing WUD. Thanks for the version notice. However, the posting any of the .cab download links is not required (they are already in the guide). Microsoft uses a "static link" of http://go.microsoft.com/fwlink/?linkid=39204 for LegitCheckControl.cab, which is reusable, and will always send you to the most current version (and to the same place as the longer URL that you posted). The only time these links (the static ones or the one you posted) fail us are when MS is a little slow with the housekeeping chores and they don't update the .cab file with same version of the .dll as is used inside of a related Microsoft knowledgebase/Windows Update download. (This is why MSDBuild checks the .cab and the KB downloads and uses the newest version.)

A new version is out, go get it. B) Sysinternals Suite Installer Builder Version: 1.8 Sysinternals Suite Current Build Date: 2008-12-19 SysinternalsSuite.zip Changes: Executable Program Version Date ------------------------------------------------------ Autoruns.exe AutoRuns v9.37 2008-12-17 Autorunsc.exe Autorunsc v9.37 2008-12-17 AccessChk.exe AccessChk v4.23 2008-12-17 Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

A new version is out, go get it. B) Sysinternals Suite Installer Builder Version: 1.7 Sysinternals Suite Current Build Date: 2008-12-10 SysinternalsSuite.zip Changes: Executable Program Version Date ------------------------------------------------------ Autoruns.exe AutoRuns v9.36 2008-12-10 Autorunsc.exe Autorunsc v9.36 2008-12-10 Du.exe Disk Usage v1.33 2008-12-10 ProcExp.exe Process Explorer v11.31 2008-12-10 ProcMon.exe Process Monitor v2.3 2008-12-10 Required End User Action: Read Version History in second post. Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

@Everyone Okay folks. You can forget about my challenge. I now know where my PC obtained muweb.dll v7.2.6001.788 from--from Microsoft on 12/07/2008 when I last ran Microsoft Update. This means that someone at Microsoft finally updated the .cab files on their download server (where the direct download links I posted in the guide point to). And in fact I just downloaded muweb_site.cab and verified that it now contains muweb.dll v7.2.6001.788. Most likely, just running Microsoft Update updates the ActiveX control from the Code Base url (since my .inf files ensure the update functionality actually works). And since, I now tell windows to suppress prompting the user to authorize this ActiveX control, I didn't get notified of the change. So all you really need to do right now, is re-download all of the files using WUD and you will get the latest version of muweb.dll and wuweb.dll directly from the Microsoft direct download links. I will still update the MSDBuild.cmd script...eventually. But there is really no urgency to do so right now and I have other things I need to complete. So for the time being, there will be one tiny inconsistency, which kgee reported above: the .inf file will say the previous version, but the downloaded (and installed) .dll file will be the current version. But as I have stated many times, this is of little to no consequence.

@kgee Q: Did I make a mistake in the Version History, or are you just entertained by my stumbling around this project and quasi-ranting about it? @kgee, strel, and Everyone As I mentioned in an earlier post, wuweb.dll and muweb.dll have always been in lock-step as far as version numbers go (at least as long as I've been maintaining this project). However, in my last round of updating MSDBuild and testing the hell out of it, I was never able to find muweb.dll v7.2.6001.788. And this was after re-installing my unattended XPCD (with the newest version of MSDownloads.exe integrated); and, it was after running all three Microsoft update websites: Microsoft Update, Microsoft Update Catalog, and Office Update. (After all that, I always search the hard drive looking for more up-to-date versions of any .dll included in MSDownloads.exe.) I could only find muweb.dll v7.2.6001.784. But today I just checked on an XP PC that I installed about a week or so ago; this time, I finally found muweb.dll v7.2.6001.788 inside %WinDir%\System32\. I just have no idea how or when it got there. So as far as I am aware, we still have no place to reliably download this file from Microsoft (yet). But faced with this confirmed evidence (that strel first reported), I will update the next MSDBuild package to look for muweb.dll inside the %WinDir%\System32\ folder and compare its version to that of muweb.dll inside of muweb_site.cab. MSDBuild.cmd will always use the most recent version of the two inside of your MSDownloads.exe installer. However, let me point out to you folks that you will only be able to obtain muweb.dll from inside %WinDir%\System32\ on the PC on which you are building MSDownloads.exe. I just checked and this file does not exist on a Windows Vista system. So this means, that to get the newest muweb.dll file, that you must build MSDownloads.exe on a Windows XP PC, and then after whatever unknown events conspire to download (or install) the most recent version of muweb.dll to your PC. Challenge I do not have high speed Internet access where I am currently staying, so I'm issuing a challenge to all of you good people who like to look over things and point out hidden details. After installing the current version of MSDownloads.exe, try to identify the precise point or trigger events when muweb.dll v7.2.6001.788 is downloaded to your PC. If you can find that out, I can tell you how to get the download URL, and then I can update MSDownloads.ulz so that we can download this file in advance, instead of waiting for it to show up on our PCs.

Follow the steps documented in the "Automate the Process" section. You use Windows Updates Downloader (WUD) to download everything required from Microsoft, plus my MSDBuild.exe. Just so people are aware. I am forcing the issue for people to use WUD to acquire MSDBuild.exe. Why? Because many of the required Microsoft files change quite often. So any time you go to create your MSDownloads installer, I want you all to go (re)download everything in WUD. This way everyone should always be using the most recent files.

@chtom Okay, I think found out the real problem. It wasn't your French Program group name. It was the output of the Ver command. For some reason French Windows XP uses lowercase "v" in "version", and my Find command was case sensitive. This has been fixed now. Please re-download SSIBuild.exe, rebuild your installer, and post back and let me know if it works for you now. Thanks, -DS

Okat thanks for the report and the log file. I'm won't be able to look at this any time this week, but I will look into it. At first glance I believe it's because of this: Common Start Menu REG_EXPAND_SZ %ALLUSERSPROFILE%\Menu Démarrer I'm using a Windows NT Command script for the uninstaller, and perhaps the accented letter is the issue. I may have to write a VBScript-based installer and uninstaller.

I usually integrate everything in my XPCD (or XPDVD), but I use Windows Media Player 11 Slipstreamer by Boooggy and n7Epsilon (both MSFN forum members). It has always been a very reliable tool.

I actually Googled, looking for "muweb.dll 7.2.6001.788" (without the quotes) earlier Wednesday. At the time, Google only returned three web pages, this thread being one of them with those search terms (I think there may be five web pages now). But only this thread (specifically your earlier post) mentions these two terms together in one sentence. In my testing on Virtual PC, I only have muweb.dll version 7.2.6001.784, and this is after successfully running all three updates sites: Microsoft Update, Microsoft Update Catalog, and Office Update. Now in the past, muweb.dll and wuweb.dll have always been in lock step as far as versions go. So I am surprised there is no place for us to acquire the new version. But at the moment I have no way of reliably locating muweb.dll, other than the .cab download URL I posted, and that .cab only contains version 7.2.6001.784, which as-tested works just fine. So to answer your question, no, I will not consider copying a Microsoft file from my PC and posting it online. One, I believe that is in violation of the EULA. Two, I think it would undermine my user confidence. Other people have made installers for these ActiveX controls. But you'll notice that I am not sharing my installer with you (i.e. MSDownloads.exe). Instead, I am sharing my Installer builder with you, so you can build your own installer. Now, without modification, we will both surely end up with exactly the same installer. But the builder and it's process is transparent (it's all in script and .inf files). So any system admin can review exactly what "my installer" does to their PCs. All of the operating system files come directly from Microsoft (as they should).

Guide updated to v4.5. Please read the Version History in the first post for more information. B) -DS

Sysinternals Suite Current Build Date: 2008-11-19 SysinternalsSuite.zip Changes: Handle.exe Handle v3.42 2008-11-19 ProcExp.exe Process Explorer v11.3 2008-11-19 AccessChk.exe AccessChk v4.22 2008-11-11 ZoomIt.exe ZoomIt v2.2 2008-11-11 SSIBuild Guide Changes: Minor SysinternalsSuite.ulz Changes: Updated SysinternalsSuite.zip build date and SSIBuild.exe version number SSIBuild.exe Changes: Updated Sysinternals Suite version (build date) to 2008-11-19 Added HTML application (AcceptEULA.hta and AcceptEULA.inf), which allow the current user to read and accept EULA for all Sysinternals Suite utilities at once. Accepting the EULA can still be pre-set in the installer, but it only applies to the currently logged in user (unless installed from unattended Windows XP setup at T-12 or T-13). Fixed one minor bug in uninstaller user could get prompted for EULA, when unregistering shell extensions. Required End User Action: Re-download SysinternalsSuite.ulz from first post. Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.

@atolica Hey, thanks for trying things out and reporting back, good job @Everyone The overall issue really seems to be that Microsoft has opted not to update their .cab file downloads located at the server end all of the static URLs I listed in the guide. Instead, MS has become increasingly more reliant on using Windows Updates to install these. I can't work on it today (), but trust me, I will be taking a good look at all the notes everyone has posted since the last Guide version and I will update MSDBuild.exe to handle as many things as I can. Remember, Microsoft tends to keep changing things around so it's always a moving target.

In what order did you install them? .Net Framework 1.1 must be installed last.

Follow the instructions, exactly as written, under the heading "Automate the Process"

@Everyone Sorry, I've been away awhile. It seems that Microsoft changed things again (what else is new?). They stopped updating LegitCheckControl.cab at its static download link, in favor of pushing out a new KB905474 WGA Notifications update periodically. I'm currently developing a new version of MSDBuild.exe/MSDBuild.cmd that will extract LegitCheckControl.dll from both the KB905474 WGA Notifications download and the LegitCheckControl.cab download. The new script will always use the most recent version in MSDownloads.exe. This way, if Microsoft resumes updating LegitCheckControl.cab at its static download link in the future, we will still be covered.@atomicmaniac & @kgee I appreciate the issue reports. Please answer these questions, assuming that you only used my MSDBuild.exe/MSDBuild.cmd (i.e. without kgee's workaround): Q1: Did you integrate KB905474 WGA Notifications into your XPCD source ? Q2: If you did integrate KB905474 WGA Notifications into your XPCD source, was it the most recent version? Remember to check KB905474 WGA Notifications in WUD to force it to redownload the most recent version of the update. Q3: If you did integrate the most recent version of KB905474 WGA Notifications into your XPCD source, did Microsoft/Windows Update still list KB905474 WGA Notifications as a required update? Q4: What edition and license type of Windows XP are you using?@kgee I'm doing it a little differently than your script is, but that's still that's a nice workaround you provided. Please answer these questions, regarding your workaround results: Q1: Did you integrate KB905474 WGA Notifications into your XPCD source? Q2: If you did not integrate KB905474 WGA Notifications into your XPCD source, did Microsoft/Windows Update still list KB905474 WGA Notifications as a required update? If this answer is "No", then we will still need to download KB905474 WGA Notifications, but we will not need to install it (which would be my preference). If this answer is "Yes", then integrating KB905474 WGA Notifications becomes a requirement.

Sysinternals Suite Current Build Date: 2008-10-30 SysinternalsSuite.zip Changes: ProcMon.exe Process Monitor v2.2 2008-10-29 SSIBuild Guide Changes: None SysinternalsSuite.ulz Changes: None (disregard SysinternalsSuite.zip build date) SSIBuild.exe Changes: Updated Sysinternals Suite version (build date) to 2008-10-30 — very inconsequential Required End User Action: Using WUD, re-download SysinternalsSuite.zip and SSIBuild.exe. Execute SSIBuild.exe to recreate SysinternalsSuite.exe.