n7Epsilon

Solution: Copy over a svcpack.in_ from a fresh xp sp3 source to your source. The error is occurring because somewhere in your build process something is deleting svcpack.inf. WMP11Slipstreamer expects to find one in order to modify it. I will make it create a new one if not found in next version.

Because optical drives (CD / DVD) communicate using a special command set (the ATAPI inteface) over the IDE / SATA bus and there is a way for the optical drive's firmware to notify the operating system when there is inserted media or not. But old drives that communicate via fdd interface don't work properly with this design because they have no way of notifying the operating system, instead they depend upon checking to see if there is media or not by trying to access drive directly (also there is supposed to be mechnical way of detecting thise case IIRC) and then Windows is supposed to consider the drive failing to read as no media detected... Sometimes this doesn't work, so you see this exception, MS doesn't try to fix because floppy drives / ZIP drives today are a thing of the past.

Unfortunately this error is not generated by WMP11Slipstreamer, it is generated by Windows itself outside of my control, so I can't do anything about it unfortunately (and so can't most apps that scan all drives). Meanwhile apps that do trap this error don't try to display that dialog box (Windows scans the drives by itself when you open the dialog box outside of the calling app's control). So I cannot fix this. This is an issue also with old style floppy drives and legacy removable drives.

Ok let me clarify the problem: 1. The light red color is because the folder you selected is the I386 folder itself, wmp11slipstreamer is looking for its parent folder, in your case you need to select: (H:\VRMPVOL_EN), this will make the light red colour go away and it will also re-enable the integrate button (it gets disabled when prerequisites are not satisfied). 2. The "windows - no disk" is happening because Windows is trying to access your ZIP drive for some reason. When you choose a drive and press OK or type manually into the box, I try to access the path to see if it has an I386 folder, but it shouldn't do this in the Select folder dialog unless you specifically mouse over it or some buggy AV is trying to overzealously scan the drive (and still thinks it has media in it). In any case, I am not doing anything besides calling the standard Windows functions to display that dialog in my program, I don't know why its happening to you and I don't have a ZIP drive to try. But in any case, if you look at point number 1, you will be able to get past the issue and continue.

If you compare both sets of files, the 2 wbemoc.inf are identical, except that nLite just stripped all comments from the file (and it seems you removed System Restore and Security Center with it). If you compare both SVCPACK.INF, they are formatted correctly... It seems that there is a broken addon you are integrating that is breaking your SYSOC.INF, so when WMP.INF is trying to register itself, the file isn't there. This is not the slipstreamer's fault. (only then it was because it was editing wbemoc.inf incorrectly, but this has been fixed since).

Issue confirmed, this is due to my localizing efforts moved the code that processes parameters before the code that fills the output type box, leading to this issue. It will be fixed in next version.

@TranceEnergy: I am working on this (customizations), this should arrive in a 2.0 release, most of the changes are (as you have noticed) not really affecting the resultant wmp11 install, these were cosmetic fixes and localization changes, the INFs were not touched or changed from last version. @lol69002: I'll post a quick fix for that soon. Stupid mistake from my part (and couldn't test because using english xp with english regional settings)....

Can you please tell me the md5 of the wmp11 installer that you have ? If it is not: D1A08DAB82A85BD18CFD54C70EE05671, please upload it somewhere and post a link because I want to look at the wmp installer you are using (it maybe corrupt in such a way that I am not detecting it).

What did you choose in the wmp11 installer box ? What is the path to the installer ?

Ok some more questions: 1. Is the problem reproducible every time ? Does it crash at exactly the same point while extracting wmp11 installer every time ? 2. Disable (not uninstall) Webroot spysweeper and try again. Does it happen now ? 3. Repeat after disabling Symantec AV as well. 4. Repeat after enabling just Webroot. Let me know your results so I can start investigating. - I tried installing Spy sweeper 5.5 alone in a VM and running the slipstreamer and didn't get any crash. I don't have Symantec AV so can't test with that.

Can you please tell me what antivirus you have ? What OS are you running the slipstreamer from ? Do you have any antispyware program ?

Please read the first post carefully: The correct md5 of this fix is: 06CE672191834692B8C69EDE69B7D89E Try to double-click on it and you will see a flashing window. The hotfix download is corrupt. (Look at the red note near the end of the first post)

I have seen and confirmed this issue, thanks for reporting it. It will make a point release later today if no other issues arise to fix this problem.

Did you install the special nLite Runtime Components package ? If so, then that is the problem, remove it and reinstall .NET 2.0 If you didn't, then your .NET 2.0 installation has been modified by something else that damaged it, uninstall .NET 2.0 and reinstall it.

The original wbemoc.inf is encoded as UCS-2 Little Endian (UTF16-LE) with the byte-order-mark at the beginning of the file. It seems that hfslip when saving the file, strips the byte-order-mark, so when wmp11slip reads it. It thinks it is reading an ANSI file. This is the reason on the error. This is HFSLIP problem, not slipstreamer problem.

Some info about the what exactly the error was ? what message ? Details ? when did the error happen ? That would really be nice.

One of your hotfixes is a corrupted download, go and double-click on each of your hotfixes, the one that flashes a console window without working is the one that is corrupt. I am guessing: windowsmedia11-kb946665-x86-intl.exe

It doesn't technically need all the components of the .NET Framework, but I haven't built any lite framework packages for this program, so you should install the full version of .NET Framework 2.0 (or higher). I did not test with nLite's lite framework package, so I can't guarantee that it will work with that. I already know your error message (Application failed to initialize...), it indicates that .NET needs to be installed.

First of all a MSU file is an update for Windows Vista, not XP. There is a mixup of download links in one of the KB articles, all of the hotfixes should be exe files. This is the reason of this error. Also if one of the hotfixes is corrupt (corrupt download) this will also happen. Go into your hotfix folder and double-click on each hotfix (get rid of the MSU first and get the XP version) and the one that just flashes a console window without running is the culprit. Redownload it since it is corrupt and causing this issue. In the next version I will build in a check for corrupted files.

This is not a bug in the slipstreamer, it is a problem with your source: From your txtsetup.sif: It seems that you integrated ie7 twice, once in english and another in russian. or you integrated ie7 on a source in which ie7 was previously added with nLite. Start over with a clean source. This one will not work.

I have analysed your txtsetup.sif, one of the addons or something you are doing is breaking your txtsetup.sif, DirId 247 = l2schemas is repeated twice. You can edit manually to remove the second reference and wmp11slip should work, but I feel that there maybe other issues with your source.

Yes, this is because of MS changing up hotfix structure, they released this hotfix as a "Security Update" for Windows XP type. However internally it uses conditional inf extensions to search for wmasf.dll file versions and apply the correct version of the hotfix to Windows. WMP11Slipstreamer can handle this fix correctly (I specifically wrote a parser that reads and executes these commands and applies the correct version of the hotfix to the source).

Does this problem still happen with the latest release of Comodo 3.0.15.277 ?

Defense+ is a good idea and they're certainly on the right track to getting it right, but it looks like it is still buggy (interferes with accessing cryptographically signed files, I think it is a bug in their Trusted Providers facility or perhaps in Defense+ somehow having a call to access a file in exclusive mode by mistake or without any sharing rights set)... Anyway I am working on making the way I extract more friendly to such annoying protection measures so this will improve in future versions...

Does the problem still happen if you go to Defense+ Behavior Options and put a checkmark in "Disable Defense+ permanently" and reboot ? Does nLite crash as well in the same conditions that WMp11Slip crashes with the "file in use by another process" error ? Can you post full error messages please ?