
jvidal
Content Type
Profiles
Forums
Events
Posts posted by jvidal
-
-
Mimo, I renew my objection to 977377, have you even read the KB article?
It is intended for some very specific issues, not verified yet by microsoft and what is worse is that it will probably break more things than it fixes.
You should really remove it, don't include it, not even as optional.
bye!
0 -
Hi everyone (especially tommyp).
I just rebuilt my xp64 CD with yesterday's updates and I noticed that KB975713 didn't take, even though it was present in the HF folder.
any ideas?
bye!
0 -
why does hfslipc want kb977377? it is not a critical update.
0 -
Mimo, new updates just released today. We need a new version of HFSLIPC...
thx & bye!
0 -
Mystery Solved
0 -
Doesn't matter, I catched it myself
Thx for the help!
0 -
Of course there are a few exceptions, like that OGA or WGA crap, but this is not the case.
I think that naming convention change is appropriate.
0 -
thx!
0 -
I think the point is to keep MU completely happy with all high priority updates, that's the whole idea behind hfslip. So, if an update is listed under "high priority", like 951978, then IT IS high priority and NOT optional...
bye!
0 -
So, it's functionally identical to beta D for us "mortals"?
0 -
I believe those are called "Important" in your tables...Optional means optional...
0 -
So, tommy, what exactly was FDV's "special request" for beta E?
0 -
Have you setFYI, KB951978 does not show missing if not in HF folder.OPT=1
in the INI? Reporting optional updates are not the default-setting.
Regards, Mimo
But Mimo, 951978 is NOT optional, should be reported if not present.
0 -
Oh, and I got another tip for ya:
I don't use KB946648 (messenger 4.7 update), instead I place messenger.msi (messenger 5.1) in HFGUIRUNONCE, which renders KB946648 obsolete and/or unneeded. Maybe HFSLIPC should check for messenger.msi v5.1 and not complain if it does not find KB946648. It should only flag it as missing if messenger.msi v5.1 is not present in either HFSVCPACK or HFGUIRUNONCE (or wherever it might go).
And, finally, I got an idea (it might not be possible). I don't know if this can be done form within a .cmd file, but I think it might be worth the try.
How about having HFSLIPC download the most current list of updates from a server especially designated for that? It could simplify things a lot.
In that way, we wouldn't have to download hfslipc several times a day, it could automatically update its list of updates...
bye!
0 -
Thanks!
Nice job, this is a VERY useful utility.
keep up the good work!
0 -
Mimo, you still haven't addressed the KB951978 issue I mentioned earlier.
bye!
0 -
Mimo, there's a problem with KB951978, you say that's not needed when integrating IE8, when it actually is.
I just built my HFSLIPed CD with IE8 and without KB951978 and MU still wants it.
IE8 jscript update (KB971961, updates ONLY jscript.dll, whereas KB951978 updates several other files, like
"SP3GDR\wscript.exe" = "_sfx_0008._p", "SP3GDR\wshom.ocx"
"SP3GDR\cscript.exe" = "_sfx_0009._p", "SP3GDR\wscript.exe"
"update\update.ver" = "_sfx_0010._p", "SP3GDR\cscript.exe"
"SP3QFE\wshom.ocx" = "_sfx_0011._p", "SP3GDR\wshom.ocx"
"SP3GDR\vbscript.dll" = "_sfx_0012._p", "SP3GDR\cscript.exe"
"SP3QFE\scrrun.dll" = "_sfx_0015._p", "SP3GDR\wscript.exe"
"SP3GDR\wshext.dll" = "_sfx_0016._p", "SP3GDR\wscript.exe"
"SP3QFE\wshext.dll" = "_sfx_0017._p", "SP3GDR\wshext.dll"
"SP3GDR\scrrun.dll" = "_sfx_0019._p", "SP3QFE\scrrun.dll"
"SP3QFE\vbscript.dll" = "_sfx_0020._p", "SP3GDR\vbscript.dll"
"SP3QFE\jscript.dll" = "_sfx_0021._p", "SP3QFE\vbscript.dll"
"SP3QFE\scrobj.dll" = "_sfx_0022._p", "SP3QFE\jscript.dll"
"SP3GDR\jscript.dll" = "_sfx_0023._p", "SP3QFE\jscript.dll"
"SP3GDR\scrobj.dll" = "_sfx_0024._p", "SP3QFE\scrobj.dll"
0 -
Alright, after running chkdsk (it fixed a few small errors), I rechecked MU and now it was 100% happy.
The weird thing is that the file xpshims.dll was not present in system32 anymore (it was previously). Now it's present only in dllcache, with ver 18876 and in syswow64, version 22967...(and eventhough I installed the HF again)
Also in dllcache, there is wxpshims.dll v22967 (seems that this is the 32-bit version, the one that goes into syswow64)
weird, but it seems to be OK now.
Now, correct me if I'm wrong but it seems that when you copy a 32 bit dll into system32, it gets moved automatically to syswow64, right?
(While on this subject, does anyone know a utility than can tell apart a 32 bit exe/dll from a 64 bit one??)
Thanks for your help!
0 -
Ok, did some testing.
Visited MU, installed the HF, looked at the file ver, no change. Rechecked, MU still wanted the update (although the event viewer showed it was installed SUCCESFULLY).
Then, I manually tried to copy the file, got several weird errors.
First, after copying and overwriting the file, the file STILL had v 22945, no matter how many times i tried.
Then I checked xpshims.dll in dllcache and it had the correct version (22967). Tried to copy it to system32 and got the weirdest error...
"would you like to replace the file xpshims.dll size xxxx with this one xpshims.dll SIZE -1"...
WTF?????
Maybe I need to run chkdsk on my drive.
0 -
IT IS an IE8 HF...
file versions? Hmm, let's see (I finally told MU to ignore this HF, it was getting pretty annoying):
ie4uinit.exe 8.0.6001.22967
iedkcs32.dll 18.0.6001.22967
ieframe.dll 8.0.6001.22967
iepeers.dll 8.0.6001.22967
ieproxy.dll not present in system32, file present in dllcache, v 8.0.6001.22967, file present in %programfiles%\internet explorer, same ver.
iertutil.dll 8.0.6001.22967
inetcpl.cpl 8.0.6001.22967
jsproxy.dll 8.0.6001.22967
msfeeds.dll 8.0.6001.22967
msfeedsbs.dll 8.0.6001.22967
mshtml.dll 8.0.6001.22967
occache.dll 8.0.6001.22967
urlmon.dll 8.0.6001.22967
wininet.dll 8.0.6001.22967
xpshims.dll 8.0.6001.22945 (*)
what gives?
0 -
Did you finally sort out what was causing the problem?
0 -
Hi, TP!
I always install updates manually (I go to the KB article and download the update for several OSes).
When that didn't work, I went to MU and let it install it, same result, it keeps asking for it.
Strangely enough, I also have a VM running xp64 and when it asked for the update, I installed it and "voila", that was it, it never asked for it again...
weird...
Maybe s/thing wrong with my config, but that would be weird, I installed windows about a month ago or so...
I installed this windows with a HFSLIPed CD I made with hfslip64 1.1.4 (the one we worked on for several days).
Oh, and BTW, other updates work fine, it's this one only. Maybe a permissions problem on a registry key that needs to be modified by the HF?
any clues?
0 -
Hi guys, I know this might by off-topic, but I didn't know where else to turn.
The problem is that since yesterday, MU keeps asking me to install IE8-KB978207, no matter how many times I install it, it keeps coming back...
Anyone else experiencing the same issue? I'm on XP64 right now...
Is this a MU/WU problem? (most likely), or a bug in the hotfix installer...
bye!
0 -
Besides that, no other changes?
So if one does use WMP11, then we don't need this version, right?
bye!
0
Hflsip64 1.1.4 and KB975713
in HFSLIP
Posted · Edited by jvidal
Thx for answering, tommy.
Here's what you wanted:
The HF contains two folders:
SP2GDR and SP2QFE.
inside SP2GDR there is shlwapi.dll v6.0.3790.4603 and a 'wow' folder, with wshlwapi.dll v6.0.3790.4603
inside SP2QFE there is shlwapi.dll v6.0.3790.4603 and a 'wow' folder, with wshlwapi.dll v6.0.3790.4603
In the OS, after a clean install of the hfsliped CD, the files are:
system32\shlwapi.dll v6.0.3790.2795
syswow64\shlwapi.dll v6.0.3790.4603
system32\dllcache\shlwapi.dll v6.0.3790.2795
system32\dllcache\wshlwapi.dll v6.0.3790.4603
And after manually installing the HF, I've got:
system32\shlwapi.dll v6.0.3790.4603
syswow64\shlwapi.dll v6.0.3790.4603
system32\dllcache\shlwapi.dll v6.0.3790.4603
system32\dllcache\wshlwapi.dll v6.0.3790.4603
Finally, the files in sourcess are
AMD64\shlwapi.dll v6.0.3790.2795 (incorrect) (although it has today's date!)
I386\wshlwapi.dll v6.0.3790.4603 (correct)
Hope this helps!