Cumulative Security Update for Outlook Express 6 Service Pack 1 (KB837009)
in [Windows Update]
|
From: XO on 1 Apr 2005 16:15 On Fri, 1 Apr 2005 10:31:56 -0900, "Home User" <Home_User(a)no.spam.net> wrote: >snip >I thought I was keeping up pretty well, for not being a techie. But, I'm >throwing in the towel. UNLESS, you can come up with a less time-consuming >suggestion? --- I threw in towel several days ago. Much easier to uncheck the Critical download than try to figure this mess out! :-)
From: Robert Aldwinckle on 1 Apr 2005 18:41 "Home User" <Home_User(a)no.spam.net> wrote in message news:114rbdsfvsboh86(a)corp.supernews.com... > Yes, my msinfo32 doesn't have the feature which allows me to capture the > version information easily. And, I can do a sort to quickly see if there > are multiple occurrences of files. Thanks for the suggestion! > > But, you lost me with "One possibility (for WinME) is (ironically) if those > modules all somehow had been (incorrectly) added to its SFP directory at > that level SFP could continually undo any update made to them which did not > also update the SFP copy." Did you try looking for files and directories called SFP? Find a file called SFPLOG.txt? Etc. <title>KB260195 - Description of the Sfplog.txt File</title> > > I thought I was keeping up pretty well, for not being a techie. But, I'm > throwing in the towel. UNLESS, you can come up with a less time-consuming > suggestion? Ron Jenner's approach may be less time-consuming--if it works. That's the problem: it is hit-or-miss and hides information which may be useful to understand the problem and therefore how to fix it. But really, what I suggested is hardly time-consuming as some problem analyses go. All I asked you to do was find all occurrences of the modules which had regressed, check their versions, and tell me what the latest one is and where it is. There are only 5 to find, according to your report. I don't think that there should be as many as 4 each; so that would be at most 20 file properties to check and record. An alternative which would give you a bit more control than Ron's approach would be to find the uninstall directory for the update before doing the uninstall and then check to see whether it contains versions of the problem modules and if so if reverting to them will change your symptom. In this scenario you would be hoping that if SFP was involved that its copies of the modules would be updated by the uninstall procedure at the same time. If SFP already contained the regressed modules and was not properly updated by the uninstall procedure I think you would have the same problem all over again. > > Besides ignoring it, what else can I do? For example, can I hide it from > showing up in my Windows Update? I don't know your UI. XP users can decline an update using its AU feature. However, that would be suppressing a symptom not fixing a problem. You have already refined the symptom description and identified that there is a problem under it: you have regressed versions of modules. What we are trying to do now is decide on the best way to get a consistent enough set of modules so that either: Windows Update doesn't think you need an update related to them or: Windows Update picks an update to install *and* it is capable of being installed without causing the same problem to recur. > You know, something like the option of > "Choose which categories and updates to display on Windows Update" (I had to > do that already for Microsoft .NET Framework version 1.1, for some reason > Windows Update thinks I have .NET Framework on my system.) > > BTW, I started out in the Windows ME newsgroup, and they referred me here! > Go figure! I think it was useful for you to come here to get general information. For how that information applies specifically to your OS using its UI I was suggesting you could find more possibilities of collaboration in newsgroups where everybody sees the same UI and the same modules and has experience with that UI and that OS tools. Good luck Robert --- > > > "Robert Aldwinckle" <robald(a)techemail.com> wrote in message > news:%23QQALsoNFHA.3220(a)TK2MSFTNGP14.phx.gbl... >> "Home User" <Home_User(a)no.spam.net> wrote in message >> news:114ohmpq32mpp99(a)corp.supernews.com... >> > Here is what I have found: >> > >> > WABMIG.EXE REGRESSED >> > WABIMP.DLL *NEWER VERSION >> > WABFIND.DLL REGRESSED >> > WAB32.DLL *NEWER VERSION >> > WAB.EXE REGRESSED >> > Msoert2.dll regressed >> > Msoeacct.dll regressed >> > MSOE.exe *NEWER VERSION >> > inetcomm.dll *NEWER VERSION >> > >> > *Newer version than what was listed in the manifest, whereas REGRESSED > was >> > an older version. The rest of the file versions matched. >> >> That's interesting... ;) >> I take it that your msinfo32 doesn't have the feature which >> would allow you to capture the version information easily >> as I suggested? <eg> >> >> The four modules with newer versions correspond to the only ones >> that I have in KB887797\SP2QFE Although there is no manifest >> for that update and (the last time I checked) the DLL Help Database >> was not up-to-date and although I have a different OS let's assume >> that those four are from your 887797 update. (As I mentioned >> you could probably get more people with common experience >> to collaborate with in a newsgroup which specializes in your OS.) >> >> Since you are comparing with 887797's pre-requisite 823353, >> "regressed" may only mean that somehow you managed to apply >> 887797 without first applying 823353. E.g. you might find that >> those modules' versions match the manifest for the previous >> cumulative OE update 837009 (listed by MS04-013) >> >> Oh, I see, you have listed only some of the modules in the manifest >> and the ones which you didn't list have the correct version? >> Then that implies that the ones you list as regressed are true limited >> regressions of individual modules. E.g. it is not a case of regressing >> a complete update. >> >> In fact, the correct version of all those modules is 6.00.2800.1123 >> which would have come initially from another incompletely documented >> patch: 331923 (again, because it wasn't a security update). >> >> So, where would modules which regress those have come from? >> Probably from OE6, the pre-requisite for 331923. >> And why would they be regressing? One possibility (for WinME) >> is (ironically) if those modules all somehow had been (incorrectly) >> added to its SFP directory at that level SFP could continually undo >> any update made to them which did not also update the SFP copy. >> >> Please check on that possibility. E.g. see if those modules are >> referenced in your SFPLOG. Also search your harddrive >> for all instances of them. (Make sure that you are able to see >> all modules, including System and Hidden modules.) >> Tell us the latest version of each that you can find and where >> you found it. >> >> >> Good luck >> >> Robert >> --- >> >> > >
From: Home User on 4 Apr 2005 23:20 There are only one occurrence of each: msoeacct.dll, ver.6.0.2800.1106, C:\WINDOWS\SYSTEM msoert2.dll, ver.6.0.2800.1106, C:\WINDOWS\SYSTEM wab.exe, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS wabfind.dll, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS wabmig.exe, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS >>All I asked you to do was find all occurrences of the modules which had regressed, check their versions, and tell me what the latest one is and where it is. There are only 5 to find, according to your report. <<
From: Robert Aldwinckle on 5 Apr 2005 16:06 "Home User" <Home_User(a)no.spam.net> wrote in message news:115412pbnpq0k7d(a)corp.supernews.com... > There are only one occurrence of each: That seems too few. I'm curious how you got to this level without having at least, e.g. copies to restore for an uninstall. I wonder what normal ME users have? > msoeacct.dll, ver.6.0.2800.1106, C:\WINDOWS\SYSTEM > msoert2.dll, ver.6.0.2800.1106, C:\WINDOWS\SYSTEM > wab.exe, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS > wabfind.dll, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS > wabmig.exe, ver.6.0.2800.1106, C:\PROGRAM FILES\OUTLOOK EXPRESS In any case I think what this means is that those modules are all at the OE6sp1 level. They need to be at 331923 level in order to look as if 823353 has been installed. I have no idea why you are being offered 837009 instead, since you have 887797. (Ah. I just realized what it probably is: 837009 has a Maximum Severity Rating of Critical while 823353 has a Maximum Severity Rating of Moderate. You are probably only being offered patches with ratings of critical.) I would try downloading, saving and installing 823353 just to see if it might patch this up. You might have the same symptom with it; i.e., it refuses to do anything because it sees a superseding patch already installed. In that case uninstalling 887797 would satisfy that criterion, even though none of its modules update the ones that you want to change. The point is that 823353, being a cumulative update contains earlier versions of the modules that 887797 updated; so that could be something which would prevent 823353 from being reapplied. Hopefully not. If you're lucky the correct versions will be picked up from 823353 and then 8237009 won't appear necessary any more. In the (hopefully unlikely) event that 823353 does not install the necessary updated modules by downloading and saving it you will have the option of expanding it and extracting the modules from it manually. What may be more likely though, which you should check for is whether the 887797 versions become regressed by installing a cumulative update. So, I would back up those ones before trying to reapply 823353. Good luck Robert ---
From: Home User on 5 Apr 2005 22:05
I tried downloading, saving and installing 823353. It would not install, noting that it needed "...5.5 Service Pack 2 to be installed." I then uninstalled 887797. However, I found that 823353 doesn't have the option of expanding it and extracting the modules from it manually. I ran Windows Update again and it still sees a need for Cumulative Security Update for Outlook Express 6 Service Pack 1 (KB837009). Windows Update hasn't noticed that 887797 has been uninstalled. |