[Beta] RVM Integrator 1.5.4 Beta7 [2008-09-23] [Archive]

galileo

09-07-2008, 06:35 PM

Hard drive based install using "winnt32" generates numerous file not found errors. I am completing the build and installing to another partition on the same hard drive. I am working in an XP Pro SP3 environment using 1.5.4 beta 3 + Optimize files + Integrating :

- Onepiece AIO 1.5.2
- TCP patch
- UXTheme patch
- dotNet AIO 2.2.7
- and several others

Build is fine w/o errors or warnings; when initiating via winnt32 the files are copied over to the drive without any error or warning messages; the install halts with "File not found" dialog boxes on the following files:

- napprov.mof
- napschem.mof
- rsop.mof
- wscenter.mof
- rsop.mfl
- tshoot.dll
- sniffpol.dll
- sstub.dll
- ssdprsv.dll

Inspecting for each of these files reveals that they are in fact missing from the $win_nt$.~ls\i386 install folder....they are however, present in the build i386 folder....they are apparently not copied over.....

The install halts at T13 (if I remember correctly) with "Cannot install"

- icfgnt5.dll

By clicking "Cancel" and proceding without installing the indicated files, one can successively find each of these. The install will finally proceed to completion - even without these files - and will actually boot although the setuperr.log does show numerous errors...IE is not functional.

Note that this will build with this identical set of addons with nlite 1.48 and install via winnt32 without any issues.

...I suspect setup file copying is the culprit.....

Siginet

09-07-2008, 06:52 PM

I am willing to bet that one of the addons/Updatepacks you are integrating has a built in wbem fix in it? Which would not be good. Also installing from winnt32 is never reccommended. BTW... when do you get the file missing errors?

galileo

09-07-2008, 07:13 PM

...you might lose the bet...:p LOL

OnePiece's AIO pack does not have a WBEM fix (as I read his posting info)...see RVM Forum - Other Update Packs - Windows XP Professional - Onepiece's EN-US Windows XP Post-SP3 All-in-One Update Pack...the dot net AIO does not contain any WBEM items or fixes...the other addons are simple software additions.

The file missing errors occur during between ~ T19 and T13 ~ if I remember correctly.

FWIW - This works without any issues using nlite 1.48...Simply speaking, the required files are not copied into the setup folder "$win_nt$.~ls" when using the Integrator but are copied when using nlite....thus, they are truly "missing" when they are called during installation.

Just kick off a winnt32 installation on an existing system and on the reboot after it copies the setup files pick the original OS rather than letting the setup OS start...then you can check the setup folders for the relevant files (thus avoiding the time for a complete install cycle).

Siginet

09-07-2008, 07:18 PM

I just did a full test using Media Center SP3 and these UpdatePack/Addons:

RVMUpdatePackSP3_1.0.0.7z
AcroRdr9.exe
Entrie_LANG_REMOVAL.ini
Entrie_WINNTUPG_Removal.ini
Entries_RegTweak-MyComp_MyNet_MyDocs_IE_Icons_on_Desktop.ini
entries_RegTweak-QuickLaunch_All_Users.ini
entries_TCPIP_100.ini
entries_UXTHEME_v14x.ini
Entries_WinntSif - XPMO.ini
IMGBURNV2.4.1.0ADDON.CAB
Java6u6.exe
JD976_Stimpy_DotNetFX3.5SP1_Addon_v2.0.7z
Kal_QuickLaunch_ENU_Addon_0.2.0.cab
Kels_Visual_Styles_addon_part1.2.rar
Kels_Visual_Styles_addon_part2.1.rar
Kels_Visual_Styles_addon_part3.1.rar
OEMSCAN_1.4.1_DELL-SiginetAddon_1.7Beta2.rar
OEMSCAN_1.4.1_EMA_GATE-SiginetAddon_1.7Beta2.rar
OEMSCAN_1.4.1_HPCOMPAQ-SiginetAddon_1.7Beta2.rar
OEMSCAN_1.4.1_SONY-SiginetAddon_1.7Beta2.rar
OEMSCAN_1.4.1_TOSHIBA-SiginetAddon_1.7Beta2.rar
OnePiece_Windows_Media_Player_11_True_AddOn_v1.1.0 _ENU.7z
PatchAddon_HIVESYS_v13c.cab
ProgramAddon_Ad-Aware_2008_7.1.0.8.7z
ProgramAddons_7-Zip_4.57.cab
ProgramAddons_HashTab_2.0.8.cab
ProgramAddons_K-Lite_Codec_Pack_Standard_3.7.5.cab
ProgramAddons_Media_Player_Classic_6.4.9.1.cab
Ricks_WinRAR_AddOn_v3.62.cab
Siginet_MultiTheme-AddonsPack.rar
Themes_Siginet_CrystalXP_dlb2_Addons.rar
Themes_Siginet_Cyber_Addons.rar
Themes_Siginet_IE7_Addons.rar
Themes_Siginet_LunaElement5.0.3_Addons.rar
Themes_Siginet_MindWood_Addons.rar
WindowsDefender_addon.rar
xable_Unlocker-Light-v1.8.5a_addon.cab

I performed the install using winnt32.exe. I got no indication of any missing files and no issues once setup was complete.

I will perform another test using OnePiece's AIO.

galileo

09-07-2008, 07:24 PM

I will try an integration and install using Ryan's Post-SP3 pack and my other addons....which IE7 addon would you suggest...?

Siginet

09-07-2008, 07:48 PM

Personally I don't use any IE7 addons because I like my clients to have the choice to use IE7 or not. When I do integrate it I integrate a customized svcpack installer which allows IE7 to be uninstalled. So personally I don't have much experiance directly integrating IE7. The reason I don't like direct integration is the fact that IE7 isn't compatable with every program. So I have had clients in the past who cannot use IE7.

galileo

09-07-2008, 07:58 PM

I can sympathize with that philosophy. For the sake of clarity, I will do a test build/install w/o any IE7 or WMP11 addons.

Given that I am "east coast" and work is a mere 7.5 hours away...:o...I suspect that I will do the build tomorrow night....

choman

09-08-2008, 11:30 AM

@siginet

1.5.4b3 exploded 3 times in a row, here are the log files. Looks like a memory leak

Let me know if you anything else

Siginet

09-08-2008, 11:54 AM

@siginet

1.5.4b3 exploded 3 times in a row, here are the log files. Looks like a memory leak

Let me know if you anything else

Damn! And each one is in a spot during compression of files. 2 during the ASMS files compression and 1 during Moving files around (Which also compresses files).

I'll have to look into my _compressFile Function and see if maybe I need to add a small Sleep() command into it to help prevent a loop from looping too quickly. The odd thing though is that function has been that way for a long time. :(

Siginet

09-08-2008, 11:58 AM

@siginet

1.5.4b3 exploded 3 times in a row, here are the log files. Looks like a memory leak

Let me know if you anything else

I was also able to successfully integrate OnePiece's AIO UpdatePack with basically the same addons as above... except Kals Quicklaunch.

But your issue I guess could be related to this memory leak error? Weird thing though is your integration was completed without any errors. Can you try to install the same disk by booting to it and not using winnt32.exe. See if it gets the same errors. Thanks.

galileo

09-08-2008, 01:00 PM

Will do....give me till about 10:00 p.m. ET this evening...I am wondering if the dotNET AIO pack could be the culprit. Separately, I will also check a winnt32 build this evening without the dotNET pack.

....."tape at ten"....

galileo

09-09-2008, 08:13 PM

The CD initiated install is successful when using the identical build that fails the Winnt32 initiated install.

I have performed the builds using Integrator and tried the Winnt32 install on two machines:

- Dell Optiplex SX-280 / 3.2 GHz / 4 GB RAM / XP Pro SP3 / All NTFS partitions
- Dell Dimension 4600C / 2.6 GHz / 2 GB RAM / XP Home SP3 / All NTFS partitions

I have tried builds with OnePiece's AIO 1.52 and Ryan's 1.0.0a packs - all with Integrator 1.5.4b3. All have failed the Winnt32 initiated install and all work sucessfully using a CD initiated install. Even when building solely with the update pack(s) and no other addons.

I note that the file copy failures start @ T28 - typically with the "napprov.mo_" file as noted in my earlier post. The file not found errors pop-up all the way down to T18. If one browses the install folder (i.e. the local source folder - $win_nt$.~ls) one can confirm that the files in question are, in fact, missing from the local source folder. See my earlier post for the list of files that are missing.

However, if one brings up a command prompt (shift-F10) and navigates back to the partition on which the build is located - then one can manually copy the missing files into the local source folder, as the errors occur. If this is done for each of the missing files then the install does, in fact, complete successfully. This would seem to confirm that the Integrator build itself is successful.

Apparently, the building of the list of files to copy from the build source to the local (i.e. install) source folder is not completing successfully...or rather, correctly. This is the file copy list that is created after the winnt32.exe is initiated. Again, the Integrator build itself is fine - as evidenced by the successful CD based installs.

For reference, both CD based and winnt32 based installs work without issues when using the identical packs and addons and building with nlite....

Also, for reference, I monitored the memory usage during the Integrator runs (via Task Manager)....there did not appear to be any obvious (or rather "notable") memory leaks...

...the tape @ ten was a bit late......

Siginet

09-09-2008, 08:31 PM

Hmmm.. that is odd. Is your source an original source or has it been previously integrated?

Can you attach these files:
All files that are missing plus:
txtsetup.sif
dosnet.inf
wbemoc.inf

Also Your integrator.ini

galileo

09-10-2008, 07:03 AM

@sigi

I have included the following files in the attachment (Files.7z):

- integrator.ini
- RVM_Integrator_1.5.4b3.log
- DOSNET.INF
- TXTSETUP.SIF
- WBEMOC.IN_ (still compressed)

I have not included the missing files - there were about 10+ for this particular install.....however, ALL of the missing files were in the build source. I manually copied each of the missing files from the build source as each was found missing by the install and thus, forced the install to complete successfully....in fact, I am writing this email from that completed install. Here are some of the missing file names (same as from my original post) although, for this particular install there were even more missing files (not listed here though):

- napprov.mof
- napschem.mof
- rsop.mof
- wscenter.mof
- rsop.mfl
- tshoot.dll
- sniffpol.dll
- sstub.dll
- ssdprsv.dll

The source files are "the" XP Pro SP3 "iso" direct from M$ via MSDN....thus, reliably and unquestionably pristine....

FWIW: I executed RVMI from C drive (NTFS) (XP Home SP3 - on this particular machine - single hard drive w/multiple partitions) and performed the build on files contained on D drive (NTFS) and then performed the install to E drive (NTFS) using "unattend.bat" containing the following:

set AnswerFile=.\build_b\I386\winnt.sif
set SetupFiles=.\build_b\I386

%SetupFiles%\winnt32 /s:%SetupFiles% /unattend:%AnswerFile% /tempdrive:e

I can upload my "winnt.sif" if that will help...

Siginet

09-10-2008, 09:32 AM

I mainly would like to know if these files were named napprov.mof
- napschem.mof

inside the compressed file or if they had their full names?

galileo

09-10-2008, 10:43 AM

I mainly would like to know if these files were named napprov.mof
- napschem.mof

inside the compressed file or if they had their full names?

Which compressed file are you referring to?

Hmmm, I believe the "wbemoc.inf" file was included with the attached files...it will need to be expanded (anyway - an expanded copy is attached here just in case...BTW: the extension needs to be changed back from "txt" to "inf" - I used "txt" only to pass the upload filtering).

I'll upload anything you need...just let me know what you would like.

Siginet

09-10-2008, 12:28 PM

can you upload the compressed napprov.mof, napschem.mof files?

galileo

09-10-2008, 12:59 PM

can you upload the compressed napprov.mof, napschem.mof files?

Here ya go.....these are directly out of the i386 build folder.

Siginet

09-10-2008, 06:00 PM

galileo

09-10-2008, 06:40 PM

It's odd... when I tested integrating and installing from winnt32.exe I had no issues. Your files look fine. Maybe it has something to do with the syntax and something incompatable with the way the integrator integrates the files. I am gonna try again in vmware.

So If I understand correctly you have 3 seperate partitions. C:\ D:\ and E:\.
You copy the files to the D:\ drive and use the code in your syntax to execute the install? Or is the D:\ drive the cd?

I'm gonna try now. I'll get back to you.

All 3 are hard drive partitions. The procedure is as follows:

- Working OS is installed on C drive
- Data storage is on D drive (i.e. folders containing the source and the build resulting from the integration)
- Installation is to E drive
- CD drive is F and is not involved in the setup or installation

The syntax for winnt32 points to the i386 folder and to winnt.sif in the i386 folder (the unattended "answer" file can be named anything - and my winnt.sif file is the same for either a CD or a winnt32 install - hence, pointing to winnt.sif). The tempdrive is E - thus, the local install source files ($win_nt$.~ls) are copied from D to E as a function of the winnt32 initiation. Additional boot files are copied to C drive.

There will be a setup entry in the boot.ini file which will give you an option (albeit a 3 second option) to select the original OS if you want....thus, immediately after the first reboot after kicking off the winnt32 install, you can boot into your working OS and take a look at the file structure on all drives if you wish. The whole procedure makes for a relatively quick install compared to using a CD....or a VM....just integrate then do a quick re-format of E drive and away ya go....

Siginet

09-11-2008, 01:07 AM

dolivas27

09-11-2008, 05:26 AM

Damn! And each one is in a spot during compression of files. 2 during the ASMS files compression and 1 during Moving files around (Which also compresses files).

I'll have to look into my _compressFile Function and see if maybe I need to add a small Sleep() command into it to help prevent a loop from looping too quickly. The odd thing though is that function has been that way for a long time. :(

Siginet hope you are well have you had a chance to add the Sleep command and Kal's fixes I am having crashes same as choman and was hoping to test beta 4 ;)

galileo

09-11-2008, 05:55 AM

OK... I ran a test integration of only OnePiece's AIO Updatepack. I installed it using your method. I did have only one error. Something about the ICFGNT5.DLL file. Once windows finished installing my IE was not working and it looks like a lot of other things were not installed. I did not get all of the file errors that you did though. Just the one. I'll look into this some more. I am trying an install by booting to the disk now to see if it is successful.

Yep, I have seen that particular file error and that type of faulty behavior as well. It seems endemic to prior files that failed to install (i.e. a dependency issue). Although, it is surprising that you did not receive the earlier "file not found" (or "unable to copy file") errors during the setup/install.

I have never had problems with this install process other than with integrations performed through this version RVMI with an SP3 version of XP. As a benchmark, I will try the following with this same process and report back:

- Use only a clean M$ XP SP3 version (I have the full MSDN XP ISO version)

And (only) if that fails:

- Use only an original/clean M$ XP SP2 version (I have a full retail SP2 CD)

FWIW: I note that I have executed this process ~200 times~ previously and not had any issues...

Nonetheless, this should help establish a benchmark for functionality. Per previous testing, both Ryan's and OnePiece's update packs alone both fail with RVMI but are both successful with nlite. And, OnePiece's is successful using the same RVMI build but, burned/installed via CD (did not try Ryan's via CD - assumed if OnePiece's would work via CD then by inspection...). I believe, no further testing is required to benchmark those conditions.

Will report back later today...:rolleyes:

And, thanks for taking the time to troubleshoot this issue...we all know how little time we all have vis-a-vis our "real-world" responsibilities....

Just thinking: RogueSpear focuses on RIS based installs which would be similar (I think :confused:) to this process in that the setup files are copied over to the local machine from an installation source - hard drive to hard drive - but, all via the network rather than local partition to local partition. I wonder if he has seen any of these issues in the past...? I may poke around over at his forum later on and pose these issues over there as well...more heads may shed more light....

galileo

09-11-2008, 09:09 AM

...(reporting back)...

The winnt32 initiated install of M$ clean XP Pro SP3 is flawless & fully functional - I did use my winnt.sif answer file and my unattend.bat script file. Working from an installed OS on drive C using source files residing on drive D and installing to drive E.

For grins I did an RVMI integration of Zacam's UXTheme patch by itself with NO other addons, NO update packs, NO optimize files, and NO cache enabled (very vanilla) - integrated directly into the above M$ source folder that just installed flawlessly. The integration of this one addon alone broke the winnt32 initiated install/setup. The "napprov.mo_" file not found (file copy error) came up right on schedule @ T28.....this was both disappointing and yet revealing at the same time (I killed the install after this).

For reference here are my benchmarks for winnt32 initiated installs summarized to date:

- XP Pro SP3 (pristine M$ XP Pro SP3 "iso" source) - successful
- XP Pro SP3 + OnePiece AIO 1.52 via nlite - successful
- XP Pro SP3 + OnePiece AIO 1.52 via RVMI - fails
- XP Pro SP3 + Ryan's Post-Sp3 1.0.0a via RVMI - fails
- XP Pro SP3 + Zacam Uxtheme patch ONLY via RVMI - fails

I can provide whatever files/logs you may need for further review...just let me know what you would like. All the installs used the same winnt.sif and same unattend.bat file.

I hope the testing helps narrow down the scope as to where/what is causing the file copying errors.

mr_smartepants

09-12-2008, 08:42 AM

Lonelobo

09-12-2008, 09:04 AM

when I downloaded beta 3 for testing and wanted to unrar my virusscanner (zonealarm scurity suite v8.0.020) told me the .exe fille was a virus and deleted it.

ENU_user

09-12-2008, 11:21 AM

if you must make the scanner ignore it ...the scanner possibly marked it as a threat because it doesn't know what to make out of it. when it will be signed & after it becomes a public release the scanner will have to skip marking it as a threat eventually ...

Siginet

09-12-2008, 11:50 AM

Strange, when I use 1.5.4b3 to integrate Zacam's SFC patch addon, I get a txtsetup copy error "cannot copy sfc_os.dll to hard drive".
The patch addon worked fine using previous builds. It's only the SFC patch, Zacam's other patches work fine.
I found out last night there was an error in my HexEdit portion. In certain cases it would not fix the pe header of the edited file. I have allready fixed this for Beta4. ;)

when I downloaded beta 3 for testing and wanted to unrar my virusscanner (zonealarm scurity suite v8.0.020) told me the .exe fille was a virus and deleted it.
It is a false positive. Do not worry about it. Just tell your program to ignore it.

dolivas27

09-12-2008, 02:01 PM

I found out last night there was an error in my HexEdit portion. In certain cases it would not fix the pe header of the edited file. I have allready fixed this for Beta4. ;)

It is a false positive. Do not worry about it. Just tell your program to ignore it.

Well damn that might explain the problem I am having with the raid patch and getting a copy error with this file DMADMIN.EXE on some builds it works fine on other it does not. I need that beta 4 ;)

I also have a question about the WBEM fix should we be removing it from the latest pack 1.0.1 when using the latest RVM beta? I have just rem it out in the update pack but in ryans pack he has this in the ini file ;SP3 WBEM fix in case someone's using an older version of the Integrator. This makes it sound like here is checking the version of RVM you are using?

Thanks again Siginet for all you do for us it is much appreciated;) Do you have and idea when we might see beta 4?

mr_smartepants

09-13-2008, 01:32 AM

I found out last night there was an error in my HexEdit portion. In certain cases it would not fix the pe header of the edited file. I have allready fixed this for Beta4. ;)

Here's me anxiously awaiting beta4! :)

Siginet

09-13-2008, 09:43 AM

Ryans UpdatePack uses a simular WBEM fix. So it does not interfere with the integrators fix. Once the integrator goes final the WBEM fix should no longer be needed in any addon or UpdatePack.

Beta4 is almost complete. Actually I think I may just release Beta4 in a little bit. I do however know there is some sort of bug dealing with the [FileFlags] section of txtsetup.sif. It is actually more of a bug with the UpdatePacks not adding the correct [FileFlags] (I think) but I want to research and see if I can figure out what files should go into the [FileFlags] section so the integrator can do it automatically. ;)

As for the hexedit bug in Beta 3 and prior... I think if it only happens if your hexedit is the last edit in an entries file. I think if you move that edit further up in the list of hexedits to be performed it will work fine. The issue seems to be if the last hexedit in the entries file is performed the integrator does not fix the pe checksum of the file. So it causes a file read error.

Siginet

09-13-2008, 11:44 AM

OK... in Beta4 it will automatically add any file that is added with txtsetup_files to the FileFlags section of txtsetup.sif with the value of 16. This should fix any winnt32.exe issues. ;)

I'm in the final testing stages of Beta4 now. If all goes well i should have Beta4 online very soon.

dolivas27

09-13-2008, 12:30 PM

Excellent thanks for the update....

mr_smartepants

09-13-2008, 01:23 PM

Awesome news! :)

Siginet

09-13-2008, 03:47 PM

Beta 4 is now online. :)

dolivas27

09-13-2008, 06:33 PM

Thanks Siginet first test was good running some more now. :D

galileo

09-13-2008, 07:11 PM

Thanks for the updated beta4!!!

Unfortunately, no joy with the winnt32 initiated setup....exactly the same file copy errors at exactly the same places. I made a new build using Integrator beta4 with fresh source files and Optimize System Files checked and with OnePiece's AIO 1.6 update pack.

Interestingly, all of the required/missing files are in the build following integration and were initially copied over to the $win_nt$.~ls\i386 folder during the winnt32 file copy phase (verified prior to reboot). By the time the installer is into GUI-mode setup, if one checks that same folder (via command prompt) - the required files are now missing - nor are they present in the Windows\System32 folder that is being installed. As before, as each "Copy Error" dialog box comes up with - for example: "Setup cannot copy the file napprov.mo_" (obviously since the files are missing) and leaves the browse text box with the search path of: "E:\$win_nt$.~ls\i386" (i.e. the path being searched for the files. If I open a command prompt and then manually copy each of the files from the build source into that folder, then use the dialog "Retry", then setup can complete without errors.

The file modified dates on all of my source files are 4/14/2008 - as provided by M$. However, the napprov.mo_ and napschem.mo_ in the RVMI build folder and, initially when present, in the $win_nt$.~ls\i386 folder bear the dates of 6/9/2007....is this related to what is being done with the WBEM correction in RVMI...?...it certainly seems odd.

...sorry to be the bearer of bad news...

ENU_user

09-13-2008, 07:34 PM

galileo, napprov.mo_ and napschem.mo_ yes there has been taken an attempt to work ground them

but from what i do remember when i was trying out some stuff nothing could actually be

a real fix so in a way this is no surprise to me ... installing from windows imposes a limitation with any workarounds ...

on the source these files are packed backwards "napclientprov" (long) is compressed and renamed to NAPPROV.MO_

the work ground uses expand to rename the long name into short and get it repackd with the same name as before,,the short ..

but that doesn't fully take care of the issue, does it ?

thats why i recommended to settle with MrNxDmX's fix ,add fileflag those 2 and thats all

what you had done to get the files into location seems like a good workaround for winnt32

but which way you found easier .. ? or is this happening only with the latest beta ..

galileo

09-13-2008, 08:16 PM

@ENU_user:

This has been happening on all of the 1.54 builds that I have tried. Everything works flawlessly with nlite and if I do a CD based install with RVMI it works flawlessly also. It is only the winnt32 initiated install that fails. Sigi says not to mix any other WBEM fixes into the builds with RVMI...and I would tend to agree that multiple fixes are likely to cause multiple problems :p in the end.

@Siginet:

I will break down the folder/file structures tomorrow. I think I will execute builds in both RVMI and nlite and try to only do a UXTheme patch in each - to minimize any other file changes. I can then generate a comparison between the files in each build. If needed I will upload (FTP...?) the entire builds and the entire $xxx$ installation folders....that may make it possible to actually find out what the delta is that is causing RVMI to fail.

...bed now...

ENU_user

09-13-2008, 09:16 PM

@ENU_user:

This has been happening on all of the 1.54 builds that I have tried. Everything works flawlessly with nlite and if I do a CD based install with RVMI it works flawlessly also. It is only the winnt32 initiated install that fails. Sigi says not to mix any other WBEM fixes into the builds with RVMI...and I would tend to agree that multiple fixes are likely to cause multiple problems :p in the end.
...bed now...

well forget my previous post .. & i agree multiple fixes surely cant & wont help here :P

what i can predict for winnt32 initiated install is that the workaround added in the latest build should be removed with an addition of few a few file flags then we can test to see what more will it need ;)

Siginet

09-13-2008, 10:43 PM

The MrNxDmX fix is basically implemented in the integrator... so adding his Fix will do nothing. The integrator does the same thing... plus it also fixes the names of the compressed files. Every time I try the winnt32.exe install I do not have any issues anymore. I even did my last test with an msdn sp3 disk. So I have no idea what I may be doing differently then you. :( I also will say I doubt it being a fileflag issue in beta 4 since it adds all new files into the fileflags section. But obviouslly something somewhere is not right if you are having an issue. Most people should not have any issues. But I promisse we will fix this problem as long as you are willing to keep testing and helping us find the problem.

galileo

09-14-2008, 09:06 AM

But I promisse we will fix this problem as long as you are willing to keep testing and helping us find the problem.

Well, IMHO, the greatest statesman of the 20th century said it absolutely correctly: "never give up, never give up, never give up"...(the Brits out there know well who that is !!!)

I am most definitely willing to keep testing and helping...:cool:

Given adequate time today, I am going to perform the simplest integrations that I can devise (to minimize the variables) employing both RVMI and nlite and the base MSDN source files. Then do file comparisons to find files - and file contents - that differ. I suspect that this will involve both integrations and partial installs to find out when the files seem to "go missing" or what is triggering that behavior...:mad:...

ENU_user

09-14-2008, 09:49 AM

galileo, please try integrating the file i linked and let us know if that patches the issue for you ..

thanks

galileo

09-14-2008, 11:38 AM

galileo, please try integrating the file i linked and let us know if that patches the issue for you ..

thanks

Thanks to you too. Integrated this with only one other addon (CmdOpen-1.0.3-Addon.cab). Setup fails at the same place.....and at the same file: napprov.mo_

Attached are two directory listings for $win_nt$.~ls\i386. One just after the winnt32 file copying has completed - just before T39 kicks off (ESC the reboot message and print dir>) and the other just at the first file copy failure (napprov.mo_) at T28 (power off the machine and reboot into the working partition and print dir>). Also included is the txtsetup.sif file.

galileo

09-14-2008, 11:49 AM

Attached is my winnt.sif (sans CD Keys)....just to flesh out the info (txt added to file extension to satisfy website file filters).

If useful, I can upload the "entire" (((:eek:))) folders for source, build, and setup.

ENU_user

09-14-2008, 11:51 AM

Siginet

09-14-2008, 11:53 AM

galileo, please try integrating the file i linked and let us know if that patches the issue for you ..

thanks

At first I was gonna say i doubt that would work since all the NEW files are automatically added. But looking at your Entries file it looks like a lot of those files are not new files. So it possibly could be something that may work. Where did you get that list by the way?

galileo

09-14-2008, 11:57 AM

...and finally, attached are the two directory listings for the MSDN XP Pro SP3 i386 source folder (which everyone should be able to match and confirm) and for the RVMI build i386 folder.....(might as well have the whole shooting match).

Since these are primarily just directory listings, if you need any specific files themselves...let me know.

ENU_user

09-14-2008, 11:58 AM

siginet, i didn't get to prob out the files myself in running test's ..

nlite uses those btw, so it seems the list was grown from this winnt32 method

galileo please try testing the details from my previous post to make a confirmation, so we can get things updated for all

thanks

Siginet

09-14-2008, 12:07 PM

As for the dates mismatching on those files. That is due to the fact that the files within the compressed file hold the date of 6/9/2007. So when the integrator compresses them it keeps that date. But that wouldn't cause a problem.

And reading Yumeao's explanation about FileFlags it sounds like you are onto something ENU. ;)

ENU_user

09-14-2008, 12:10 PM

siginet, did you check the previous post I made for you on privet ,yesterday, read it out please ...

ENU_user

09-14-2008, 12:16 PM

NM here it is:

the winnt32 when it uses \makelocalsource

that command copies the cd setup files physically on to the the disk @ c:\%winn_nt& ...

* when its time for inf installs :

a inf install is looking to install the files it needs from c:\%winn_nt& ... as it should

* so what seems to be actually the problem with that ...is:

some files are getting installed as normal but they are being moved with one inf install where its another inf that will install (later on.. needing one or more of the same files the previous inf-install was using\installing ..) in result some files where being moved with one inf.. (instead of copied)
by the time the next inf-install kicks in some files will be absent !

the file flags will ensure that on a loacalsource base setup they wont be moved with any inf installs. just copied ...

this is probably the popular list of files known to have the issue and require a "don't-move-me" flag

agt0406.dll = 16
agt0406.hlp = 16
agt0407.dll = 16
agt0407.hlp = 16
agt040b.dll = 16
agt040b.hlp = 16
agt040c.dll = 16
agt040c.hlp = 16
agt0410.dll = 16
agt0410.hlp = 16
agt0413.dll = 16
agt0413.hlp = 16
agt0414.dll = 16
agt0414.hlp = 16
agt0416.dll = 16
agt0416.hlp = 16
agt041d.dll = 16
agt041d.hlp = 16
agt0816.dll = 16
agt0816.hlp = 16
agt0c0a.dll = 16
agt0c0a.hlp = 16
bnts.dll = 16
cga40850.fon = 16
cga40woa.fon = 16
cga80850.fon = 16
cga80woa.fon = 16
coure.fon = 16
courf.fon = 16
dosapp.fon = 16
ega40850.fon = 16
ega40woa.fon = 16
ega80850.fon = 16
ega80woa.fon = 16
kbdnec.dll = 16
mchgrcoi.dll = 16
rsop.mfl = 16
rsop.mof = 16
sapicpl.hlp = 16
serife.fon = 16
seriff.fon = 16
smalle.fon = 16
smallf.fon = 16
sniffpol.dll = 16
speech.chm = 16
ssdpapi.dll = 16
ssdpsrv.dll = 16
sserife.fon = 16
sseriff.fon = 16
sstub.dll = 16
tshoot.dll = 16
udhisapi.dll = 16
upnp.dll = 16
upnpcont.exe = 16
upnphost.dll = 16
vga850.fon = 16
vga860.fon = 16
vga863.fon = 16
vga865.fon = 16
vgafix.fon = 16
vgaoem.fon = 16
vgasys.fon = 16
napprov.mof = 16
napschem.mof = 16
wscenter.mof = 16

siginet thats the background so i fetched galileo the list

but it seems there is one extra problem...

for that im asking to test it once again With file flags Bypassing the workaround that you had added to integrator for those files ...

so all it needs is:

replacing those webm files replacing them from the true source (not integrating )
making a iso

running the test to see if now will they get copied ... just to probe that option out

thanks

galileo

09-14-2008, 12:18 PM

what happens if you do /makesource /noreboot and go look into 1386\ ..
is the file there ...
then if not you can try

getting the original packed file from the original source with out changing anything else
create the iso and test and let us know if the file gets there at all ..

Take a quick look at the directory listings that I posted....Those may answer your question(s). The correct files are in fact copied over to the setup folders as a function of the winnt32 process. But, something is happening after kicking off either the text mode or GUI mode setup process that is removing or failing to copy those files before they are needed in the setup install process @ T28 - NOTE: this is not happening when this is done with nlite.....

BTW: no iso is involved...that is part of the beauty of this setup process...just do your integration, format an empty partition, point to that as the tempdrive and go....no make iso delay, no burn cd delay, no cd install delay due to CD drive speed....this is a very very fast process since everything is directly from the hard drive - and, you are working on a machine that already has one working OS installation - this makes for a very flexible working environment....of course only if it works...:p....in the end you wind up with a dual boot configuration from which you can execute offline maintenance on one of the OS partitions from the other partition...makes for a very desirable installation environment.

Siginet

09-14-2008, 12:29 PM

But from what I understand galileo... what enu is posting makes since. Basically that list will tell those files not to be moved... but copied. So if this works right those files should still be there when they are needed later.

ENU_user

09-14-2008, 12:30 PM

galileo i meant just run the command with /noreboot just to see if the file gets to that c:\%winn_nt& \I386 DIr at the first place ...

:) ,guess i got carried awy with the iso

galileo

09-14-2008, 12:31 PM

galileo please try testing the details from my previous post to make a confirmation, so we can get things updated for all

thanks

will do...but, /makelocalsource would seem to be related to a CD based setup (see the /? info).

the winnt32 process when pointed to the hard drive "does" copy all (? I think ?) the source files to the hard drive....so, that command would seem to be redundant...but, we will give it a go....

galileo

09-14-2008, 12:39 PM

galileo i meant just run the command with /noreboot just to see if the file gets to that c:\%winn_nt& \I386 DIr at the first place ...

:) ,guess i got carried awy with the iso

enu, that is effectively what I did in order to copy the directory listings - by hitting the ESC key when winnt32 is finished with file copying and preparing to reboot (I think that is what you are asking..?) . Please do take a look at the directory listings that I posted...I think they address your question regarding what files are present when....let me know if there is a scenario you want me to try...:D

Siginet

09-14-2008, 12:43 PM

I say just test the method the same way as you allways have. Do not change it. Just add that addon that enu posted when you integrate. ;)

If this works then I will remove the automatic FileFlags fix I added to Beta4 and implement these fileflags into the wbem fix. Then we can test from there.

ENU_user

09-14-2008, 12:51 PM

galileo

09-14-2008, 01:06 PM

actually siginet, im testing the webem fix regardless to file flags ;)

galileo:
go into the source directory E:\Windows Building\Builds\rvmi_0\I386
any build you wish ;)

form the command type winnt32 /unattended:wint.sif /makelocalsource /noreboot

then look inc:\%winn_nt&.. \I386\ and tell us in that files is missing or present under what names ..

and that file would be:

napprov.mof
napschem.mof

or

napclientschema.mof
napclientprov.mof

thanks

Following winnt32 (using /makelocalsource - but without your entries_ini file) but before text mode setup starts (i.e. immediately after the winnt32 command finishes but before rebooting - the following files are present in D:\$win_nt$\i386:

06/09/2007 01:22 AM 476 napprov.mo_
06/09/2007 01:22 AM 1,193 napschem.mo_

Reboot; then immediately after text mode setup completes but, before starting GUI mode setup (by booting into the working OS instead of letting the setup OS start) - those files are now MISSING - nor are they present (just for grins) in the Windows\system32 directory that is being installed.

I will try a rerun using your entries_ini file with the /makelocalsource....

ENU_user

09-14-2008, 01:21 PM

galileo, please leave out file flags completly its unrelated ...

did you place the original files from an original cd by hand .. ?

i mean these ones :

napprov.mo_
napschem.mo_

I can only guess you, didn't ...
if I am guessing right .. then you should try that

if that makes the files reappear in this test you just did then the webem workaround inside integrator needs to go leaving just the MrNxDmX one ...

thanks galileo

ENU_user

09-14-2008, 01:32 PM

its very hard to test because the beta is using workarounds

you can try 1.5.3 to test with the file_flags

and i will edit it to do something else

will you be interested to test ... if yes you can grab 1.5.3
grab back original:

napprov.mo_
napschem.mo_

and ill prepare you another ini so you can integrate it with the public version of integrator also found in my signature

ENU_user

09-14-2008, 01:39 PM

this is for 1.5.3 at you free time ;)

galileo

09-14-2008, 01:40 PM

...I did try earlier (1.5.4.b3) without your entries_ini file (see above post) and got the same errors. No I did not replace any files by hand.

Between text mode and GUI mode setup, I took a look at the files that had already been installed in the D:\Windows...etc. folders. The files: napclientprov.mof and napclientschema.mof do in fact exist in the D:\windows\system32\wbem folder following text mode setup...as do other files (in their respective folders) that are identified as "missing" @ T28.

Is there a bust in the setup file copy list/process? Were these "missing" files already copied to their correct folders during text mode setup and thus, should never be called during GUI mode setup? - i.e. the copying process appears to be attempting to copy files that have already been copied during text mode and "correctly" deleted from the $win_nt$.~ls\i386 folder following text mode....?

Thus, the file copy errors @ T28 during GUI mode should never occur because they should never be called at that time....?

ENU_user

09-14-2008, 01:44 PM

Siginet

09-14-2008, 01:54 PM

ENU_user

09-14-2008, 02:00 PM

I was going to test it all yesterday

but for some odd reason when i use that winnt32 command i receive

"setup was unable to build the list of file to be copied the system cannot find the path specified."

and no files where removed (weird) so i had to let go of this test .. ;)

siginet, this is what i changed

[ExtraFileEdits]

wbemoc.inf|napclientprov.mof,napprov.mof|napclient prov.mof|0
wbemoc.inf|napclientprov.mof|;napclientprov.mof,na pprov.mof|1
wbemoc.inf|napclientschema.mof,napschem.mof|napcli entschema.mof|0
wbemoc.inf|napclientschema.mof|;napclientschema.mo f,napschem.mof|1

ENU_user

09-14-2008, 02:52 PM

galileo when you are done testing
and still nothing works I can add other different workarounds to get this fixed

galileo

09-14-2008, 02:53 PM

had the wrong one uploaded get the new one ...

thats for 1.5.3 the public one

galileo you got the symptoms right now we need the cure

try the new entries.ini i linked when you get to it ... take your time :)

SUCCESS !!! MSDN XP Pro SP3 + RVMI 1.5.3 + Entries__fileflags+wbemoc + Optimize Files. Nothing else integrated. Flawless install....I am typing this from within the new installation.

Now to do another integration with OnePiece AIO 1.6 + all my addons and registry files.....after a break for dinner....will post later this evening...

galileo

09-14-2008, 02:58 PM

galileo when you are done testing
and still nothing works I can add other different workarounds to get this fixed

I think you got it !!! at least for that go round - I will do some further testing later this evening with more fully loaded integrations/builds. If we have a fix, now we need to put it to the test to see if it breaks or if this is the real deal...;)

Can/would that fix approach become the built-in fix in RVMI 1.5.4...?

ENU_user

09-14-2008, 02:59 PM

removed

ENU_user

09-14-2008, 03:00 PM

I think you got it !!! at least for that go round - I will do some further testing later this evening with more fully loaded integrations/builds. If we have a fix, now we need to put it to the test to see if it breaks or if this is the real deal...;)

Can/would that fix approach become the built-in fix in RVMI 1.5.4...?

yes it will go in

thanks for tolerating me galileo ,and standing throughout the test

now integrator can work happily :D

thanks again

galileo

09-14-2008, 03:01 PM

...never give in, never give in, never give in... Churchill (1941)

...not "tolerating"...."teaming"...:cool:

Thank You & Sigi !!!

Siginet

09-14-2008, 03:03 PM

Which wbemoc fix? The MrNxDmX one? Or Enu's?

ENU_user

09-14-2008, 03:04 PM

ENU extra edits one siginet + file_flags

Siginet

09-14-2008, 03:08 PM

OK Cool...

So this one then:
http://siginetsoftware.com/forum/showpost.php?p=4270&postcount=64

So we will instead comment out the napp* files in wbemoc.inf? I thought about that in the past too... but I never tried it. It makes since though. The wbemoc file is messed up. And txtsetup.sif allready copys those files anyways. So by us commenting them out of wbemoc it should skip the problem and not mess up anything else.

So what I can do is change the wbemoc fix in the integrator to represent this... and change the fileflag fix so that it only adds the files specified in your fix and then this bug can be squashed for good... I hope. ;)

ENU_user

09-14-2008, 03:10 PM

yes it is :)

Siginet

09-14-2008, 03:17 PM

Man what a releif!!! I was really getting agrivated about this! LOL! :P

galileo

09-14-2008, 06:24 PM

Tried a fully loaded build: XP Pro SP3 + RVMI 1.5.3 + Entries_fileflags+wbemoc + Optimize Files + Advanced (Cached Driver) + OnePiece AIO 1.6 + other addons + cmdlines silent installs + registry tweaks + oempnpdrivers + runonce items.

Failed on file copy errors @ T28: "rsop.mof, wscenter.mof, and oddly "napclientprov.mov or Unknown" (yes, the dialog actually did say that). Clicked "Cancel" for each and proceeded with install. The original napprov.mo_ and napschema.mo_ errors did NOT appear - so, we can hopefully assume that those are indeed fixed.

Got file copy errors @ T19: "tshoot.dll, sniffpol.dll, sstup.dll, and ssdprsv.dll" - clicked "Cancel" for each and proceeded with install. I have seen these errors previously when clicking "Cancel" for the T28 errors so, these are/were not surprising.

Got "Unable to install icfgnt.dll" @ T15 - clicked "Cancel" and proceeded.

Got an unusual error @ T13 when installing RogueSpear's dotNet20SP2 - attribute this to the earlier file errors - have never seen or had problems with this installer in the past (his work is usually golden). Completed the install without further errors.

Booted into Windows and received a file "Open, Save, or Cancel" dialog for "oobe.html" (if I remember the file name correctly) - really weird to receive this while still on the black Windows logo screen - clicked "Cancel" and the system hung...(maybe I should have clicked "Open"...:p...). Powered-off and then on...and booted without further issues.

IE does not work but, LAN does....and there are some other missing items...as would be expected...

Perhaps rsop.mof and wscenter.mof need to be included in the entries_ini+wbemoc fix.....if not other files as well? Let me know if you need any of the RVMI log files.

That's it for me for today...

ENU_user

09-14-2008, 06:44 PM

seems to me the list for flags needs to be extended

hang on till i can prepare one ...

so you can try out in with the next test ...

ENU_user

09-14-2008, 07:13 PM

http://siginetsoftware.com/forum/showpost.php?p=4270&postcount=64

galileo

09-14-2008, 07:58 PM

http://siginetsoftware.com/forum/showpost.php?p=4270&postcount=64

ENU - are you sure that file list is correct...? It seems to be missing some of the files that were in the V0.1 list...

ENU_user

09-14-2008, 08:29 PM

I put up v3 which combines the other file_flags

siginet, can you just change the wemoc-fix with nothing else leaving the automatic for "new files -flag creator" for now so it will may help advancing the test for better results testing this HD-base install

perhaps all this can go into some advanced switch for those who need it in "winnt32 compatibility" [x] switch so both the list and the auto creator will kick in, only when that switch is set to $true

choman

09-15-2008, 08:00 AM

@siginet

Quick note. Things appear better, yeah. I've done 10+ consecutive builds without crashes. Unfortunately, I will not have time to continue onto testing system installs, as I am heading out of town for a few weeks. I will attach one of the build logs so you know all the addons that I am testing with.

Keep up the great work, see ya first half October

Siginet

09-15-2008, 10:03 AM

galileo

09-15-2008, 10:58 AM

The next beta will comment out the Nap* files in wbemoc.inf. It also will not automatically add every txtsetup_files file into fileflags. It will automatically add the files listed in the fileflags list enu has posted.

@Everybody Thanks for all of the testing! It looks like we are actually getting somewhere now. ;)

@siginet

Will run test this evening integrating the V3 fileflags ini file...using 1.5.3

Will run using next beta of 1.5.4 when it is posted...I am assuming that ENU_user's fileflags ini will NOT be required to be "integrated" in the next beta...(i.e. the beta will have those flags "built-in")...?

ENU_user

09-15-2008, 12:28 PM

@siginet

Will run test this evening integrating the V3 fileflags ini file...using 1.5.3

Will run using next beta of 1.5.4 when it is posted...I am assuming that ENU_user's fileflags ini will NOT be required to be "integrated" in the next beta...(i.e. the beta will have those flags "built-in")...?

if theres a good base to update believe, siginet isn't hesitant to update accordingly

users who test need to come up with evidence, if they don't then the author never is eager to update

galileo, take the time to test properly like if there are any other issues showing up in your

test, don't hesitate to consult the issues ...

once you confirm it all works as you expected them I'm sure the fixes will work as built-in with next

beta which will probably make it final from the sp3 compatibility aspect

Siginet

09-15-2008, 02:39 PM

Yes enu's fileflags fix will be in Beta 5. Then if we find any other fileflags that need to be added then I will add them before the final release. ;)

The way I am implementing them the integrator will first check to see if the file exists in i386 (compressed or not compressed)... if the file exists then it adds it to the fileflags.

As for wbemoc.inf... it will just comment out the nap* files instead of commenting them out and changing them to reflect the full and 8.3 filename. Because there is no reason to do that if they are being commented out anyways. ;)

I will also add the latest makecab and the latest pechecksum in Beta 5 as well.

galileo

09-15-2008, 02:48 PM

if theres a good base to update believe, siginet isn't hesitant to update accordingly

users who test need to come up with evidence, if they don't then the author never is eager to update

galileo, take the time to test properly like if there are any other issues showing up in your

test, don't hesitate to consult the issues ...

once you confirm it all works as you expected them I'm sure the fixes will work as built-in with next

beta which will probably make it final from the sp3 compatibility aspect

Thanks for the encouragement! I intend a fully loaded test with 1.5.3 + your V3 entries ini addin this evening...and thanks for offering continuing help on resolving the issues as they arise. I am hoping that these testing cycles will benefit everyone as Siginet works through the 1.5.4 and SP3 issues. Fortunately each test cycle is relatively quick due to avoiding the iso and CD time aspects.

galileo

09-15-2008, 02:52 PM

Yes enu's fileflags fix will be in Beta 5. Then if we find any other fileflags that need to be added then I will add them before the final release. ;)

Great! I will give it a "whirl" (...or a "beating"...:p...) whenever you are ready!

galileo

09-15-2008, 08:59 PM

This is a somewhat "tongue-in-cheek" post (most likely due to my oversight)...so enjoy it as that !!! :)

Houston...we have a problem !!! RVMI 1.5.3 + entries_v3_fileflags+wbemoc.ini...I had three failed installs with the same file errors as noted in previous posts (although, not the napprov or napschem files)...I did integrate "entries_v3_fileflags+wbemoc.ini" directly from the downloaded file....it resulted in failed installs...this was...well...disappointing :( (needless to say, the "try it now Vern" philosophy was failing)

Now, it occurs to our local rocket scientists (those being me, myself, and I) that ENU_user most likely knows what he is doing with the fileflags...and that he not only expects that to work...but, is pretty darn sure that it "should" solve this issue....But, it is failing for our local rocket scientists (plural, of course). Thus, it occurs to "them" that "they" must be failing to do something correctly...brilliant deduction n'est pas?...:o (on "their" part of course)

The ini file is integrated and is in fact present in the i386 folder...exactly as named (hint) - again, for clarity: "exactly as named" = "entries_v3_fileflags+wbemoc.ini"...once again a hint...A HA !!! the wheels are turning - are they not - EUREKA: perhaps the file name length....truly, a brilliant deduction Watson.....

So, to make short what has by now become an obvious ending, I renamed the file "entries3.ini" and re-integrated (in fact over top of the first integration just to save time) and (switching languages) UND, WUNDERBAR - ES GEHT SEHR (or, if you prefer, it works)...:D

A flawless winnt32 initiated install with all obvious Windows components working. This now raises the question as to whether or not any of the earlier (and perhaps simpler) "entries_fileflags.ini" solutions would also have worked. I will need to perform some tests using the earlier files (only with short file names) that ENU_user had prepared to verify at what point any of those would have worked. Any thoughts are appreciated......particularly since I am apparently "8.3 challenged"...LOL

Sorry guys, if I had recognized the file name length issue yesterday we would have verified the solution more expeditiously. But, it looks like this really is the path to the solution.

Following is the full configuration:

RVMI 1.5.3 + NO Optimize + NO Cached Drivers

Source:
XP Pro SP3 MSDN source files

Update & Addons:
OnePiece AIO 1.6 Update Pack
entries3.ini (entries_v3_fileflags+wbemoc.ini Addon)
Zacam TCPIP 100 Patch 14a
Zacam UXTheme Patch 14a
Kels Royale Remixed 1.47 Addon
CmdOpen-1.03 Addon
ProgramAddons LClock 1.62b
xable CalcPlus-v1.3
xable ContextAttributes-v1.1 Addon
xable DateEdit-v1.0 Addon
xable PathCopy-v1.1 Addon
Kels MS MSICleaner v4.71 Addon

OemPnpDrivers:
Chipset
Graphics
Network
Audio

Cmdlines installs:
RogueSpear dotNET20SP2 -ai
RogueSpear Visual C++ 2005 switchless
RogueSpear Java 6 Update 7 -ai
RogueSpear Adobe Flash /S
RogueSoear Adobe Shockwave -ai
RogueSpear InfraRecorder -ai
PDF Exchange Viewer /silent
PDF Toolkit /silent
7-Zip /S
Winroll /S
CCleaner /S
Defraggler /S
Recuva /S
Taskbar Shuffler /verysilent
Visual Subst /S
Unlocker /VERYSILENT /NORESTART
Cleartype Tuner Powertoy /S /qn
TaskSwitch Powertoy /S /qn
Image Resizer Powertoy /S /qn
User Profile Hive Cleanup /quiet
ImageBurn /S
iQ-Notes /s
bxNewFolder (scripted install)
regedit /s .\tweak1.reg
regedit /s .\tweak2.reg

RunOnce installs:
RogueSpear Adobe Reader 9.0 -ai
Menu adjustment script

Thanks to both of you - ENU_user and Siginet - for the patience. I will take a look at the other fileflag solutions tomorrow.

ENU_user

09-15-2008, 09:44 PM

i had a hunch that there was something getting in the way ,never the less i was sure you will find the way.. ;)

& wow thats great news

thanks galileo!

ENU_user

09-15-2008, 11:15 PM

As for wbemoc.inf... it will just comment out the nap* files instead of commenting them out and changing them to reflect the full and 8.3 filename. Because there is no reason to do that if they are being commented out anyways. ;)

true however if you wanted that for doc sakes
this is how it should get composed, suitable for reruns ( unlike the one that is linked ) ;)

wbemoc.inf|;napclientprov.mof,napprov.mof|napclien tprov.mof|0
wbemoc.inf|napclientprov.mof|;napclientprov.mof,na pprov.mof|1
wbemoc.inf|;napclientschema.mof,napschem.mof|napcl ientschema.mof|0
wbemoc.inf|napclientschema.mof|;napclientschema.mo f,napschem.mof|1

Siginet

09-16-2008, 01:12 AM

Acyually the entries file does not need to be 8.3 compliant. I am more inclined to think the + in the name was messing it up for some reason. It may have for some reason confused the integrator. But that aside. I am glad you yourself and ummm... that person at your computer figured it out and we are looking good. ;) I didn't get beta 5 completely done in time today... so I will make sure I post it sometime tommorrow. It is almost ready.

Siginet

09-16-2008, 04:05 PM

Beta5 is now online. :D

ENU_user

09-16-2008, 07:01 PM

thanks, siginet are you sure its the correct build ?

i cleared out FileFlags section for doing the quick test ...and nothing is being added there !!

or its only me to notice ..?

galileo

09-16-2008, 07:09 PM

thanks, siginet are you sure its the correct build ?

i cleared out FileFlags section for doing the quick test ...and nothing is being added there !!

or its only me to notice ..?

Nope you're not the only one....winnt32 build using RVMI 1.5.4b5 fails @ T28 starting with rsop.mof...followed by his usual friends...:(...

FWIW: I did a build/install earlier today using different hardware with RVMI 1.5.3 and the entries_v3 file....it worked flawlessly.

Siginet

09-16-2008, 08:09 PM

ENU_user

09-16-2008, 08:11 PM

thanks siginet ...:)

i think you should remove the check if file exist before applying a flag

even if a file should be removed in some cases the flag may still be needed ...

i will next check on what occasion a flag should get removed if the corresponding file is missing on the source ...

@ galileo here is a small list of file flags for integrator 1.5.3 & for a clean txtsetup.sif which mustn' include any previously file flags edited to it ..

galileo

09-17-2008, 06:05 AM

will test both beta 1.5.4b5.1 and 1.5.3 + new entries ini - using original clean source with no prior integrations...most likely this evening unless I can squeeze one in during the day sometime.

galileo

09-17-2008, 07:25 PM

@siginet

perfect install - no file errors: winnt32 using 1.5.4b5.1 + Optimize + Cached Drivers and fully loaded updates/addons/...etc. Everything appears working after first light (i.e. after final reboot, final setup items, and runonce)....am writing this via IE7 from within the new install. :D (by George I think eez got it)

BTW: I have "never" had Integrator crash with either 1.5.3 or 1.5.4 - even though I have probably done some really dumb things with them....

@ENU_user

will try install with 1.5.3 and your latest entries file tomorrow...(sorry - no time tonight...:(...)

galileo

09-18-2008, 10:39 AM

ENU_user

09-18-2008, 11:04 AM

@ENU_user

winnt32 initiated install fails with: RVMI 1.5.3 + entries_fileflags_minimals.ini

file copy error @ T28 starting with rsop.mof...I notice that this file and the usual group that fail are missing from fileflags list in entries_fileflags_minimals.ini...I'm guessing that the test was intended to evaluate the list w/o those files...:confused:

(siginet's 1.5.4b5.1 did work w/ winnt32 w/o errors)

rsop.mof .. heck, that defiantly indicates we stay with the extend one!!!

again thanks for all the work in testing & confirming everything so nicely

that was plain joy ;):D

Siginet

09-18-2008, 12:46 PM

I want to thank everyone for their help in fixing this winnt32 issue. :D A big thank you to enu_user and Yumeyao for help with fileflags! And a big thank you to galileo for constantly testing installs! :D Great teamwork! I went ahead and ticked the "Thanks" button on you guys... I know it's not much but I do really appreciate the help and dedication! :thumbsup:

galileo

09-18-2008, 06:55 PM

sub thankyou ()
dim peeps(3) as string, comment as string
peeps(1)="Siginet"
peeps(2)="ENU_user"
peeps(3)="Yumeyao"
For i = 1 to 3
comment="THANK YOU " & peeps(i) & " I enjoyed the opportunity to help out"
next i
end sub

.....yeah, I know, it's VB code....:D

Siginet

09-18-2008, 07:27 PM

vb and autoit are very much alike.

Func ThankYou()
dim $peeps[0] = 3
$peeps[1]="Siginet"
$peeps[2]="ENU_user"
$peeps[3]="Yumeyao"
For $i = 1 To $peeps[0]
MsgBox(0, "Thanks", "THANK YOU " & $peeps[$i] & " I enjoyed the opportunity to help out")
Next
EndFunc

As you can see.. aside from the $'s it is almost identical.

Siginet

09-18-2008, 08:55 PM

just running the final test integration with Beta6 before I upload it to the public. ;) So it should be online within the hour.

Siginet

09-19-2008, 01:20 AM

beta6 online.

galileo

09-19-2008, 08:41 AM

beta6 online.

winnt32 install works perfectly...:cool:

integration: beta51 ~ 12 min. versus beta6 ~ 13.5 min

so, about 12%-13% slowdown - not huge, but it is noticeable

Joe K

09-21-2008, 05:48 PM

Siginet
Just finished integrating Ryan's SP3 update pack with beta6 and it installed on Virtualbox with no problems. I only used Ryan's current addons. Many thanks for all the work.
Joe

Siginet

09-23-2008, 10:26 PM

Beta 7 is now online! :D

SuperFreak

10-03-2008, 11:19 PM

Kaspersky Internet Security
Detected: Trojan.Win32.Autoit.dt
Microsoft Windows Search Protocol Host
X:\...\RVM_Integrator_1.5.4b7.1.exe/script.au3

Siginet

10-03-2008, 11:37 PM

Yes Kaspersky detects any AutoitScript as a False Positive. Which is very dumb. I know nod32 used to do the same thing but recently fixed this. Hopefully Kaspersky will fix this issue soon.

galileo

10-04-2008, 07:53 AM

Using RVMI 1.5.4.b71 I seem to have an issue - both with CD based and winnt32 based installs. Textmode setup file copying is failing to copy "mdmusrf.inf"...strange that this has never happened previously. Following are the items being integrated:

OnePiece AIO 1.6
DotNet AIO 2.2.7
Zacam UXTheme Patch v14a
Kels Royale Remixed 1.47
CMDOpen 1.05
LClock 1.62b
xable calcplus v1.3
xable context attributes v1.1
xable dateedit v1.0
xable pathcopy v1.1
Kels MSICleaner v4.74
Code's fontfix.exe 1.2

...any thoughts..???

I am doing further testing to attempt to find if an addon is causing this...although, I have used these addons previously (except Code's) without any issues...

galileo

10-04-2008, 08:47 AM

(removed)

Siginet

10-04-2008, 09:47 AM

mr_smartepants

10-04-2008, 10:10 AM

Code's fontfix.exe 1.2

This is NOT an addon. It is meant to be run from runonceex (or from the desktop).

galileo

10-04-2008, 01:20 PM

This is NOT an addon. It is meant to be run from runonceex (or from the desktop).

Not to generate an argument....but, respectfully, please read Code's post more carefully over on Ryan's forum:

http://www.ryanvm.net/forum/viewtopic.php?t=6729

To the point: "I haven't packaged this as an addon; if someone wants to do that, they can. For most users, you could just directly add the appropriate executable to SVCPACK (pretend that it's a switchless installer) using the Integrator or nLite."

Integrator is intended to directly handle switchless installers...hence, including an "exe" which can run without switches in the "addons" is a "tolerable" method - provided (and this is critical) - that the actions executed can be run at T13/T12 successfully....which in this case (per Code), they can.

Soooo, it is true that this is not an "addon" per se in the explicit sense.....but, it fulfills the requirements for being treated as a switchless installer....methinks...:)

Siginet

10-05-2008, 12:42 AM

mr_smartepants

10-05-2008, 01:08 AM

Not to generate an argument....but, respectfully, please read Code's post more carefully over on Ryan's forum:

Yes, you are correct. But you need to extract the appropriate .exe from the .7z. The archive contains both 32-, 64-bit .exe files as well as the source. The .7z isn't meant to be integrated on it's own.
I wasn't sure how you were integrating, so I was just pointing out the obvious. :)
No worries!

galileo

10-05-2008, 08:27 AM

Yes, you are correct. But you need to extract the appropriate .exe from the .7z. The archive contains both 32-, 64-bit .exe files as well as the source. The .7z isn't meant to be integrated on it's own.
I wasn't sure how you were integrating, so I was just pointing out the obvious. :)
No worries!

...(see post #115)..."fontfix.exe"...(not .7z)...however, your comments may well be beneficial to other folks who may not have caught that...:)...thanks for chiming in..."all donations are tax deductible"...:p

galileo

10-05-2008, 09:10 AM

Yes... if it is the exe that is being integrated the integrator will handle it correctly and place it in svcpack properly. ;)

I don't think it is the cause of your problem.
mdmusrf.inf is a part of windows setup. I am curious to know how you are installing? From booting to the cd or launching setup from within windows?

BTW: I left out one addon in my post #115 that was also included in that group that has failed: Zacam's TCPIP_100_v14d patch (the latest one)

I tried the install both ways - CD and winnt32 - and got the filecopy error each time...strange. Since then I have done the following (all using winnt32 initiated install for speed of testing) :

Integration #1: XP Pro SP3 + Onepiece AIO 1.6 - install/run OK
Integration #2: Added below items to Int #1 / install / run OK

DotNet AIO 2.2.7
Zacam UXTheme Patch v14a
Kels Royale Remixed 1.47
CMDOpen 1.05
LClock 1.62b
xable calcplus v1.3
xable context attributes v1.1
xable dateedit v1.0
xable pathcopy v1.1
Kels MSICleaner v4.74

Integration #3: Added to Int #2 Zacam's TCPIP_100_v14d / install / run OK
Integration #4: Added to Int #3 Code's fontfix.exe 1.2 / install / run OK

After using a sequential integration process, everything installs and runs without errors...will try the following to see where the error is generated:

Integration #5: Fresh XP SP3 + all addons EXCEPT Zacam's TCPIP_100_v14d - this is the only "new" (actually updated) addon that I have introduced into the mix since the previous beta versions of Integrator wherein we were using the ENU_user's "entries" files.

Integration #6: Fresh XP SP3 + all addons EXCEPT Code's fontfix.exe (but, INCLUDING Zacam's TCPIP_100_v14d)

Curious that the integration will work when done sequentially but fails when done in one simultaneous integration...I need to sort out which addon is triggering the filecopy error when it is integrated in a single "batch" integration.

The fontfix.exe item is being treated as a switchless installer....while one wouldn't think so, could triggering the Integrator coding for including a switchless installer - simultaneous with other true addons - be affecting something...???

Siginet

10-05-2008, 11:15 AM

The fontfix.exe item is being treated as a switchless installer....while one wouldn't think so, could triggering the Integrator coding for including a switchless installer - simultaneous with other true addons - be affecting something...???

No that wouldn't cause an issue either. Can you check your source files for mdmusrf.inf and also check your integrated files for mdmusrf.inf?

I don't know why that file would be missing. But you can also check the entries*.ini files for any refference to mdmusrf.inf.

Doing research on the mdmusrf.inf file and figured out it is for a modem driver? If that helps in any way?

galileo

10-05-2008, 01:07 PM

No that wouldn't cause an issue either. Can you check your source files for mdmusrf.inf and also check your integrated files for mdmusrf.inf?

I don't know why that file would be missing. But you can also check the entries*.ini files for any refference to mdmusrf.inf.

Doing research on the mdmusrf.inf file and figured out it is for a modem driver? If that helps in any way?

Yes, it is a modem driver inf file which is why the filecopy error is so strange since nothing in the integration would have dealt with it...at least not directly. It is/was present in the source and in the $win_nt$ folders and it retains it original size and date...so, the file itself does not seem to be the cause of the issue.

Further testing was/is very inconclusive:

Integration #5: XP SP3 + all addons except TCPIP patch - no filecopy error
Integration #6: XP SP3 + all addons except fontfix.exe - no filecopy error
Integration #7: XP SP3 + ALL addons but using TCPIP patch "14a" - no filecopy error
Integration #8: XP SP3 + All addons using TCPIP patch "14d" - and oddly, no filecopy error...??? (this is the group that had failed)

...puts chin on desk...scratches head...hmmmm...

Thought #1: The machine on which the integration is performed may have some impact. The original failed integration and the Int #8 were performed on different machines...with notably different CPU/MB/HD speeds...perhaps a timing/race issue...?

Thought #2: The particular file system registry settings may have some impact...the filecopy error occurred from an integration that had been performed on a machine on which the OS (XP SP3) had 8.3 file naming and last access file timestamping DISABLED while Int #'s 1-8 were performed on a machine that left both ENABLED...:confused:

Thought #3: today is Sunday....perhaps it works on Sunday and not other days...:p...(sic)

Very distressing that the failure initiator is still an unknown...:mad:...at any rate the current condition is that the complete from scratch build installed without the text mode filecopy error. The build was conducted on an XP SP3 (5512) machine with 8.3 (and timestamping) enabled.

user_hidden

10-09-2008, 07:07 AM

posted this at RyanVM but figured i'd do the same here as it is the integrator home :)

did an integration or rather failed integration with b7.1
crashed at "gathering temp files" stage....
it happenned 4 times.

**as a side note i then used 1.5.3 and all went perfectly

Running OS: WIN_XP Service Pack 3 X86
RVMIntegrator v1.5.4

"C:\RVM\RVM_Integrator_1.5.4b7.1.exe"

16:37:03 - Windows XP Professional - Corporate SP3 Found
16:37:08 -
16:37:08 - Source Drive = D:\XP3
16:37:08 - Destination Drive = D:\XPx
16:37:08 - Destination Size = 13.02 GB
16:37:08 - Working Directory = D:\XPx\I386
16:37:08 - Temp Directory = D:\XPx\I386\rvmtemp
16:37:08 -
16:37:08 - Starting Integration
16:37:08 - Warning: The destination directory is not empty
16:37:09 - Processing Resumed, User Selected OverWrite.
16:37:09 -
16:37:09 - Copying Files To The Destination Directory.
16:37:09 - Copying Working Directory...
16:38:02 - 6950 Files Copied in 52 Seconds
16:38:02 -
16:38:02 - Checking Destination For OS Type.
16:38:02 - Windows XP Professional - Corporate SP3 Found
16:38:02 -
16:38:02 - Extracting RVMUpdatePackSP3_1.0.1.7z
16:38:16 - MD5 Hash = DD68C8DC7137DC0AE27EBAE505072F0D
16:38:16 - Extracting OnePiece_Windows_Media_Player_11_True_AddOn_v1.2.0 _ENU.7z
16:38:23 - MD5 Hash = 530884BAF6CBA28FCF127BF1B5572F26
16:38:23 - Extracting Addon_7zip_457.7z
16:38:23 - MD5 Hash = 10EAFCF03BE15E7A591910CE0D7FF55B
16:38:23 - Extracting Addon_Kels_Runtimes_v4.7.CAB
16:38:26 - MD5 Hash = C11A4AB61F434AE7382D648801D01A63
16:38:26 - Extracting Addon_K-LiteCodecPackMega_4.1.7.7z
16:38:31 - MD5 Hash = CFB7A67302F8B00775B83FB5AE617053
16:38:31 - Extracting Addon_QuickTimeAlt_270.7z
16:38:34 - MD5 Hash = 7A416CBAA61C30594BA346D23C31B769
16:38:34 - Extracting Addon_RogueSpearDotNET11SP1.7z
16:38:37 - MD5 Hash = 6693B7779FAB16F1779B3A94ADF5F62D
16:38:37 - Extracting Addon_RogueSpearDotNET20SP2.7z
16:38:41 - MD5 Hash = BA42A2260F08285B6C404DCB32BFC769
16:38:41 - Extracting DirectX_9.0c_End-User_Runtime_AddOn_0.5.1_-_redxii.7z
16:38:45 - MD5 Hash = 4D8307364BC07ED592CB800BE3572980
16:38:45 - Extracting DirectX_for_Managed_Code_1.0.0_AddOn_-_redxii.7z
16:38:46 - MD5 Hash = 3E8DA84D6DD47ADB2AFD286735D41440
16:38:46 - Extracting OnePiece_IE7_WinXPSP3_v2.3.1_AddOn_ENU.7z
16:38:50 - MD5 Hash = C805B64E750200E49E4AA756E70982D4
16:38:50 - Clearing any Read Only Attributes.
16:38:52 -
16:38:52 - Gathering temp files

Babyboy

10-12-2008, 07:40 AM

Hai..

RVM Integrator 1.5.4 Beta7 test

When i make a XpHome it works fine....

But when a make XpPro,it end's with a critical Error
I try 2 different XpPro versions.....(More times)
The error came up on different points..not the same place

Bytheway:RVM Integrator 1.5.3 (Old one) gives no trouble.Then it works fine..

All versions are NL

Grt BBoy

choman

10-13-2008, 05:07 PM

@siginet

Hey, back in town. Anyways, thought I would get this log file to ya
only crash I had since running 1.5.4 B7.1. Done about 4 (or 5) builds,
no test installs

Babyboy

10-18-2008, 02:24 AM

Hai there Siginet:

I think that the problem not only your RyanVM Integrator is:

I try this and it works more times,to make XPpro integration.

I know this post is a little old, but I wanted to share my experiences with this error. Upon further research, I found the MS KB article 841532 (http://support.microsoft.com/kb/841532). It suggests what was suggested earlier, to unregister the dll in question to resolve the issue. I tried it and received the same error 0x8000ffff. I decided to review the KB article and it notes something at the bottom of the article:

The Microsoft Office XML MIME Filter (Msoxmlmf.dll) is registered under the following registry key:
HKEY_CLASSES_ROOT\Protocols\Filter\text/xml
Removing this key also prevents the filter from loading in a custom application.

Going out on a limb, I decided to remove the key in question. Guess what? That resolved the error and loaded the application. I'm making a bit of amateurish guess here, but I get the feeling the registry key in question may have been registered to an old and/or nonexistant version of the dll and windows for some reason could not or would not unregister the faulty or nonexistant dll. I'll leave that statement for the code monkeys to validate.

http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/37c8d3e4-a6cd-46d7-83be-da364977e53c/

I hope you like it

Grt BBoy

Pho3nX

10-19-2008, 03:16 AM

Hi all. (Use XP Home SP3 French)

The Same bug since v1.5.4b5

http://img115.imageshack.us/img115/1599/pressepapiers1ud2.png

Strange bug because on 1.5.3 > 1.5.4 B4/5 no problem, with the same integration.

Please, read the log file in attachment

:(

Siginet

10-19-2008, 11:50 AM

Could you post your z_datastore.ini which will be in the same directory as your integrator program after you perform a failed integration.

This is more than likley caused by a typo in one of your entries files. Probably in the [EditFile] section.

Pho3nX

10-19-2008, 05:01 PM

ok, sorry...

Look my datastore, thx

Siginet

10-20-2008, 11:53 AM

ok, sorry...

Look my datastore, thx

OK... the error is caused by an addon. But... may also be considered a bug of the integrator as well.

I can tell by looking at this portion of your z_datasore.ini:

[EditFile]
i386\SVCPACK.INF,Version,AddelRVM=1337
mettez un ; avant ce que vous souhaitez désactiver=1650
I386\SVCPACK.INF,SetupHotfixesToRun,AddProgram=159 1

The line in bold should not be there.

Can you find the addon that is doing this and post the entries file so I can look at it.

From the looks of this line it looks like this is baddly formatted in the entries file because it is not commented out at the beginning of the line but in the middle. Which would make the integrator think it is supposed to use the line. The reason it crashes the integrator is because it is finding no comma's , in the line.

user_hidden

10-24-2008, 11:27 AM

siginet,

any news or update on beta 7.2+ ?
i still have all types of crashes with 7.1

thedexmonster

10-27-2008, 10:44 AM

User_Hidden,
the reason beta's are released is for people like us to test and report the problems to be fixed. It doesn't do much good to just say it's broken. Help to fix it!

user_hidden

10-27-2008, 12:15 PM

User_Hidden,
the reason beta's are released is for people like us to test and report the problems to be fixed. It doesn't do much good to just say it's broken. Help to fix it!

i have made posts about the bugs and crashes.
maybe you should read the entire thread about what has been going on with 1.5.4 betas.

there was new code that was submitted to the project and some other
sleep commands that siginet was going to update the build but it has not
made it out yet. i was in no way rushing any release but there was quick movement on the project and then it stopped.

attached are 2 log files.
1 is from a FAILED integration with 1.5.4.b7.1 and the other from a SUCCESSFUL integration with 1.5.3.
1.5.4.b7.1 crashed at "gathering temp files" as usual for me.

i have noticed depending on the main update pack used, the interator may pass the gathering temp files stage until crashing at the
file compression areas. this has been tested with optimize files checked and unchecked.

mr_smartepants

10-28-2008, 12:13 AM

I have a feeling that the operating environment has something to do with the crashes.
RVMI is dependent on certain functions within that environment (XP, Vista, Linux Wine, etc.).

On my quad-core Q6600 rig, I get sporadic errors "No entries*.ini found, exiting" when I run RVMI b7.1 on it's own either as a user or admin.
When I run RVMI as spawned from AutoImage (API-mode command line), I get zero errors. In fact, I don't think RVMI has crashed a single time when spawned from AutoImage for me.
I run from within Vista x64 Ultimate (8 gb RAM)

redxii

11-06-2008, 12:03 AM

I could be wrong, without having done more testing yet, but if [obsolete_files] is empty even in one addon it will delete every security catalog and there'll be no svcpack folder.

I tried with 1.5.3, no problems, I tried with 1.5.4 again with the same files, my update pack and dx addon 0.6 and the svcpack folder was still there. This is very unpredictable...

ENU_user

11-11-2008, 04:35 PM

Ding! Ding! round 8

Ok, so whats with this beta Release:

among other areas of the file's code that have been changed, tossed cleaned with a few touch ups here&there in making integrator more stable & reliable .. ( some code was mastered to make the User Interface clearer then before in overall )

all areas of the code that managed file compression and decompression in with the previous integrators code, have been refurbished by code65536's excellent effort in introducing "cablite.dll" that he wrote especially for integrator to help sort a few basic problematic matters that where constantly creeping a head.

with some autoit help arriving from siginet .. code65536 finally got around his deed with autoit as well ;) and did it big time .

besides this main Update: their are some other specs in *Updates* that siginet will rearrange notes for ..

dolivas27

11-11-2008, 04:59 PM

ENU_User I can't download the file ... :( Please help I want to test this SOOO BAD....:eek:

ENU_user

11-11-2008, 05:06 PM

done

dolivas27

11-11-2008, 05:16 PM

Thanks got it getting ready to test now......:D

ENU_user

11-11-2008, 09:24 PM

for comments regarding b08 please use this new thread started over here:
http://siginetsoftware.com/forum/showthread.php?t=493

Tinkerer

12-22-2008, 11:56 PM

Just downloaded the beta & before I even open it AVG says it's got a Autoit.DFV WORM!!!!!!!!!!.
Is this a false report or is there one in it??:o:mad:
AVG has the latest updates.

Tinkerer

12-23-2008, 12:37 AM

What about a version where it uses the Windows PE (Free cutdown version of Windows) to load and then run a Install version of the integrator so you can have one install disk, USB drive were the Integrator has tabs with presets e.g. Internet computer only, Graphics standalone were all services and internet programs etc are removed so the OS starts faster and has no services running to slow down the computer, Gaming system - either with or without internet connections etc.

The Addons - or Delete programs etc would be bundled in either one or several 7z files with access through tick boxes in the tabbed interface to speed up installs without finding & downloading seperate files and runi the integrator multiple times.