problems with 1.5.0 - logagent.exe / 7008

[bprsystems]

updated from 1.4.3 to 1.5.0. added a few recent KB's and tried to install > crash at registering components"logagent.exe not found". also 7008 patch did not take nor did the sp rollup with halamacpi.dl_ in fix folder. also crashed when using MDAC 2.8 sp1 because silient switches are not set correctly - should be > mdac_typ /Q:A /C:"dasetup /Q /N" (see link http://msdn2.microsoft.com/en-us/library/ms693148.aspx) needs to be fixed!!! (BTW once i changed the switches and got it to install MDAC CHECK showed an incomplete installation with some files still at version 2.53 with most at 2.8). anyhow, went back and removed a few KB's and retried > no good , crash at logagent.exe. finally, reverted to EXACT SAME KB setup that was working with 1.4.3 but using 1.5.0 build and > crashed again!!! ran my old disk with 1.4.3 > no problem. have spent over 30 hours now with this version 1.5.0 installing the os and still unable to get it to work. strange thing is, during the first reset during os install no logagent.exe files on drive > restartes, then the crash > then when i continue from error at finish there are the logagent.exe files in sys32 and program files\media player? is something being run in the wrong order?

big question - WHY IS THE PREVIOUS VERSION UNAVAILABLE ANYWHERE?????

perhaps it could have saved me a few dozen hours if it had - something to consider.

why oh why did i delete it!!!!

make no mistake - love the program and appreciate the effort, just very frustrating doing an os install 30 times in one day.

any help?

btw: timezone fix is sweet as is hive clean up > both installed right!

[Tomcat76]

Hi there. Welcome...

crash at registering components"logagent.exe not found".

Can you provide a copy of your HFSLIP.LOG file (zipped)?

also 7008 patch did not take

7008 patch?

nor did the sp rollup with halamacpi.dl_ in fix folder.

Why would you put it there? The second version of UR1 works fine. HFSLIP hasn't deleted that file in several months.

also crashed when using MDAC 2.8 sp1 because silient switches are not set correctly - should be > mdac_typ /Q:A /C:"dasetup /Q /N" (see link http://msdn2.microsoft.com/en-us/library/ms693148.aspx) needs to be fixed!!!

Not sure what you're doing here. HFSLIP 1.5.0 slipstreams MDAC 2.8 SP1 + hotfixes. Did you place these files in the correct folder?

[bprsystems]

first, thanks for the super quick response, a rarity these days!

1. will provide hfslip log zipped but how do i send/attach (newbie here).

2. referring to KB917008 update - i think i have always gotten this and the SP rollup in WU after install - i just repatch.

3. did it trying to get rid of the SP rollup in WU. didn't make any difference anyway. must be something else flagging it.

(i'm assuming the fix refers to the CPU idle problem with the HAL.DLL in multi-processors?)

4. i put MDAC_TYP.EXE in HFSVCPAK_SW2 folder. during OS setup it gave me a EULA. i accepted and then it crashed.

so, i edited the SVCPACK.INF file and changed the switch from /Q:A /R:N to /Q:A /C:"dasetup /Q /N" per MDAC install

instructions at the link posted above. i re-ran it and it installed ok, but i got some inconsistencies in the file versions when

i ran the MDAC Version Checker. went back to MDAC2.5 SP3 patched and all the files checked with very minor version

differences.

do i need to keep a eye on the file dates of these KB's - or is each one unique / has version number - like the Malicious Code

updates.

btw: really enjoy the new features of this version - such a powerful utility for us IT guys. thanks man!

[bprsystems]

did a w2k 1.5.0 install again today. after first reset during 0S install i booted to CD and manually put a logagent.exe into the winnt\system32 folder. restarted the install and no error - install went all the way through no problem. still have the 2 KB's in WU though. any chance something is getting executed out of order or something is deleting the file?

i have also tried turning "mplay = on" and "mplay = off" in components section of my winnt.sif file with no change.

log.zip file attached! thanks.

LOG.ZIP

Edited June 16, 2007 by bprsystems

[Tomcat76]

This is the source of your logagent.exe and KB917008 problem:

CDTAG - undefined

You MUST have the CD identification files in your SOURCE folder, else copying of logagent.exe and other files will fail. These files are copied at a later stage during Windows setup because most of these have to be placed in the Program Files folder which can't be done from TXTSETUP.SIF.

MDAC 2.8 SP1 and the hotfix go in HF (remove the MDAC 2.5 SP3 updates). You can also put MPSetup.exe and the Roots update in HF. They are all slipstreamed.

You should also remove all obsolete updates. Check the_guy's Windows 2000 list in this forum or my Windows 2000 list (linked from my signature) if in doubt.

See if WU still complains about the rollup after fixing the above.

[bprsystems]

allright!!!

added CDROM_NT.5 and CDROM_SP.TST into SOURCE folder and re-applied SP4 then complied and everything went smooth.

man, what one little file can do! (i've been programming since 1975 and i still love finding bugs!)

strange that i never had a problem not having it before - maybe because i used to have mplay = off in winnt.sif so it didn't execute during install.

only thing left is i'm still getting rollup in WU. any ideas?

my new log attached. thanks for all the help!

HFSLIP.zip

[Tomcat76]

WindowsMedia-Q828026-x86-ENU.exe is out of place here. That update is obsolete for Win2K and is the only one from your list that may interfere with the proper slipstreaming of the rollup, though the binary in question (msdxm.ocx) is older than the one in the rollup so HFSLIP should've kept the newer one.

Either way, if removing WindowsMedia-Q828026-x86-ENU.exe doesn't help you should try installing without WINNT.SIF once.

You're missing two security updates, btw. Don't know if that's important.

KB917537 and KB926247.

Edit...

Does xpicons_silentv2.ex_ replace any binaries that exist in the rollup?

Edited June 17, 2007 by Tomcat76

[bprsystems]

ok. removed xpicons / WindowsMedia-Q828026-x86-ENU.exe / WINNT.SIF and added KB917537 and KB926247. still get rollup in WU - not willing to give up yet!!

i saved an image of the install before applying the rollup so i can get you copies of any files that might help pre/post re-application.

during rollup re-application it inspects the system files and it looks like it only replaces about a dozen or so files, although it is hard to tell as they fly by pretty quick.

going to try to catch which files are being replaced and what versions they are pre/post.

latest log for what it's worth.

HFSLIP.zip

[Tomcat76]

Can you zip HFSLIPWU.INF and TXTSETUP.SIF from SOURCESS\I386 and attach it here?

If you really feel like checking what installing the rollup afterwards does... I use a program called InstallRite. Are you familiar with it? You basically install the rollup from within that program and build an "install kit". You can then see which changes were made (files & registry). It's important you reboot after installing InstallRite (before installing the rollup through it) to keep the amount of unrelated changes at a minimum.

[bprsystems]

zip files attached. will try installrite later today.

HFSLIPWU.zip

TXTSETUP.zip

[Tomcat76]

Nothing special there. I hope InstallRite comes up with something...

[bprsystems]

been a while. updated HF files with latest updates. installed and still get update rollup in WU. ran install rite and made a snapshot. installed update rollup and analysed. sent results to text files. any help is appreciated. pretty minor inconvience but the bug hunter side of me still wants to figure it out. thanks again. bpr.

Update_Rollup_1_for_Windows_2000_SP4___Added_Files.txt

Update_Rollup_1_for_Windows_2000_SP4___Added_Registry.txt

Update_Rollup_1_for_Windows_2000_SP4___Deleted_Files.txt

Update_Rollup_1_for_Windows_2000_SP4___Modified_Files.txt

Update_Rollup_1_for_Windows_2000_SP4___Modified_Registry.txt

[Tomcat76]

Bit difficult, but it seems Windows Update is tripping over olecli32.dll and sfcfiles.dll. What are the versions of these files before and after installing the Rollup on top?

The latest version of olecli32.dll can be found in Windows2000-KB913580-x86-ENU.EXE. The sfcfiles.dll file should be the one from the Rollup.

[bprsystems]

EUREKA!!!!!!!!!!!!!!!!!!!!!!!!!!!! YES!!!!!!!! YOU ROCK!!!! :)

after ~40 hours......................

sfcfiles.dll is the culprit!!!

pre-update rollup version = 5.0.2195.6717 with a date of 6/19/2003

post-update version = 5.0.2195.7038 with a date of 4/8/2005

on freshly patched install (with WU asking for rollup only) i went into DOS (using fat32 here) and copied sfcfiles.dll version 7038 over older 6717 version in system32 and system32\dllcache (must do both!!)

rebooted and VOILA! nothing in WU!!

my i386 source folder has:

sfcfiles.dl_ 53kb 6/19/2003

sfcfiles.dll 974kb 7/26/2000

my i386 sourcess folder has:

sfcfiles.dl_ 53kb 6/19/2003

sfcfiles.dll 951kb 4/8/2005

is it the sourcess files or something during installtion? (using "c" compression method during compile)

also, 2 days ago did an install using a fresh copy of w2ksp1 slipstreamed with sp4 and hfslip. no winnt.sif file. and same thing - WU wants rollup. sfcfiles had same dates and sizes in source and sourcess folders as above.

GETTING CLOSER! :)

bpr.

[Tomcat76]

Well there's your problem. You have both sfcfiles.dl_ and sfcfiles.dll in your SOURCE folder. Windows setup can only copy one and it prefers the compressed one. HFSLIP updates only one file and it takes the non-compressed file.

This is an unusual situation because a Windows source should only contain SFCFILES.DL_. My guess is that you used a modified (and uncompressed) sfcfiles.dll some time before applying SP4 to that source.

You don't need to run HFSLIP again per se; you can just delete the file that wasn't updated by HFSLIP from your SOURCESS folder. In any case, deleting the uncompressed file in your SOURCE folder (the SP4 version is the compressed one judging by the dates you mention) should prevent this issue from happening again in the future.