Ottmar Freudenberger wrote:
> "Bill Drake" <bdrake@telus.net> schrieb:
>> Ottmar Freudenberger wrote:
>>> "Bill Drake" <bdrake@telus.net> schrieb:
>>>> Ottmar Freudenberger wrote:
>>>>> "Bill Drake" <bdrake@telus.net> schrieb:
>>>>>
>>>>>> When I installed the Patch Tuesday updates on my WXP Box
>>>>>> with MSIE6 installed. I had the same problems with IE6 startup
>>>>>> as others are mentioning in these newsgroups.
>>>>>>
>>>>>> Specifically, about 60% of the time, I would get an "Internet
>>>>>> Explorer has encountered a problem and must close" dialog.
>>>>>
>>>>> Mentioning an error in iexplore.exe in association with
>>>>> "urlmon.dll"?
>>>>
>>>> Yes, that is correct. The standard error everyone else
>>>> has been mentioning.
>>>
>>> Well we haven't seen that many postings here in the WU
>>> newsgroup on the issue - yet
>>
>> I saw one post from Mike Le indicating that at least one company
>> is seeing this problem throughout their corporate environment.
>
> In the Windows Update newsgroup? Must have missed that
This may have been reported in WindowsXP.General. This thread
is being maintained in both environments because users in both
groups have reported the problem.
>
>> Consequently we have a problem that cannot be simply swept
>> under the rug.
>
> Well, I'm not even trying to swep something anywhere. I'm not working
> for MS nor am associated by any means to MS. What I'm trying to do
> is to help users running into issues, researching the cause for these
> issues and finding workarounds for possible issues *without* leaving
> the user's systems beeing vulnerable to the fixed security holes which
> will be there without an update.
>
>>>>> If true, *and* in case you've installed a Java-VM from Sun, please
>>>>> check via "Tools -> Manage AddOns" that all three(!) AddOns
>>>>> present for the Sun Java-VM are activated. In case one of these is
>>>>> deactivated, activate that one, shut down all IE windows and see
>>>>> if that fixes the problem after a restart of IE. I've ran into
>>>>> that issue on one of my (virtual and physical) machines and that
>>>>> fixed the issue without having to reboot Windows itself.
>
>> Running the english version of JRE 1.6 u3 here
>
> Okay, that's something in common. Now, does the AddOn Manager in IE
> show *three* entries for the JavaVM on your system too?
Yup. All working fine as already mentioned.
>
> Do you have by any chance installed Google Toolbar or Google Desktop
> Search?
Nope. No google stuff touches my systems. Considering the long history
of system instability induced by installation of either or both of those
software packages - I consider both items as completely unsuitable for
systems that are intended to run stably in production environments.
>
>>>> As mentioned in my post to whomike in this same thread - I've now
>>>> found that the crash recurs after the system has been sitting idle
>>>> on a web page for a while - even with the workaround applied as
>>>> described in my previous post.
>>>
>>> Hm, I know, it's just another workaround (for an issue I'm *not*
>>> seeing here so far), but in the past disableing HTTP 1.1 in the
>>> Internet Options under Advanced "solved" some of these
>>> problems IIRC.
>>
>> I haven't seen this problem before now. This particular set of
>> updates to the MSIE6 dll-set seems to be the cause of the issue.
>
> Sure, there may or my not be issues caused by KB924615 for those
> (still) running IE6 on Windows XP SP2. But a workaround is a
> workaround and "may" be faster than waiting for MS to fix a possible
> issue (of what they still seem to be not aware as of yet, see the
> revised Security Bulletin - have you opened a call to MS?) *and*
> protecting the system from the security holes.
I was involved in a lot of the detective work that went into discovering
the early mouse-driver problems with latency-conditions that caused
lockups and instability with early versions of IE. I am very familiar
with race-condition errors - and I have yet to find a workaround for a
race-condition error that does not involve massive sacrifices in
performance or features.
Similarly to the mouse driver problems, this problem requires resolution
by proper architecture in the DLL-set for IE6. IMO, this will not be
resolved by hiding the issue - but only by dealing with the problem in a
productive and efficient manner - similar to what was required in the
Microsoft mouse drivers to deal effectively with the instability the
mouse drivers induced in MSIE.
> So, have you *tried* to disable HTTP 1.1 in the Internet Options and
> checked whether the issue you're seeing is still present after that
> *workaround*?
Nope. As Mike Le mentioned, he has already done the investigative
work on that issue. It solves the problem only by massive loss of
feature capability. This is not a viable solution to the problem. It
is a workaround in name only. To dignify this by calling it a "solution"
is to allow Microsoft to sweep this issue under the rug. This is
completely unacceptable.
>
>>> You've tried installing KB945007 (not offered via WU but in
>>> DonwloadCenter) which contains another version of mshtml.dll?
>>> http://support.microsoft.com/kb/945007/en-us
>>
>> No, I have not tried this, since this is a regression testing
>> issue I expect Microsoft to handle before issuing KB942615.
>
> Huh? You're actively working with MS on the issue already?
No. As mentioned earlier, Mike Le already has an open PSS
issue on this subject. I don't need to duplicate Mike's work - all
I need to do is let MS know that Mike is not alone in his problems
and that MS needs to get to work on solving this properly.
>
>> If KB942615 requires the new functionality embedded in
>> KB945007 - then that should have been explicitly added to
>> the KB942615 package.
>
> That's the theory, yes. Now to the practice: does the issue
> exists with KB945007 for IE6 on Windows XP SP2 beeing
> installed?
>
>> For now, I have reverted to the Ghost image I made of
>> the machine just before Patch Tuesday. I am now
>> running without any of the Patch Tuesday patches in
>> place.
>
> "Fine" and your system is vulnerable to the security holes trageted
> to be closed with the released updates. Doesn't look like a good
> idea/advice to me. I'ld recommend to download and install at least
> "the other" updates.
Now that I have verified that I'm running stably again without all the
Patch Tuesday updates in place - 12 hours of testing - I've installed
all the updates other than KB942615. I'm now at about 8 hours of
testing in this new configuration and all seems stable. Once I am
sure that KB942615 and *only* KB942615 is the issue, I will say so.
I fully expect the above to be the case - but I've already been fooled
once on this particular problem. So now I'm being more thorough in
my testing before saying that something works a particular way or
not.
>
> And yes, of course, I have another possible workaround in mind:
> Downloading KB942615 manually, save it and installing the update whith
> parameter "/b:SP2QFE" - see http://support.microsoft.com/kb/897225/
> for your reference.
It is possible but not probable this will affect the issue. I may look at
this
if I have time next week, but I consider this kind of testing to be
something
PSS needs to do as part of their research into the problem.
Personally, I'm buried in a Server Install right now - and to be dragged out
of that to deal yet another bunch of Patch Tuesday issues is annoying as
hell. I don't have time right now to do any more than I've already done on
the issue.
>
> FWIW, I've dropped a comment under the related IE-Blog entry linking
> to this very thread some minutes ago:
> http://blogs.msdn.com/ie/archive/20...security-update-is-now-available.aspx#6754765
Great! That will help - as at least others on the blog will see the issue
and know they are not alone. Hopefully this will generate enough interest
in the problem to ensure that MS commits to actively researching and
developing a real solution to this problem - not a workaround.
Best I can do for now. <tm>
Bill