Specifically, about 60% of the time, I would get an "Internet
Explorer has encountered a problem and must close" dialog.
I dutifully reported the failure to Microsoft and then repeatedly
tried reopening IE6 until it would successfully open.
The above occurred when opening my default homepage,
which is "My MSN" - and is heavily customized.
Cleaning my Internet Explorer Tempfolder and moving to a
blank opening page solved the problem. However, this was
not an acceptable solution.
I then rebooted the machine, restored my default homepage
and tried opening IE6 again. Now, the machine is working
correctly, even after multiple open/close cycles.
I suspect the KB942615 update should be coded to force a reboot
and does not. Consequently, some part of the update that requires
a reboot before the update is fully applied does not get done.
As a result, installing this update without the reboot causes IE6
to run in a "half-updated/half-not-updated" mode - which causes
the problem described above to occur.
For those experiencing this problem, please try moving to a blank
opening page - and then reboot your machine again after the
KB942615 update is installed. Once this is done, restore your
default homepage. See if this procedure resolves your problem.
Best I can do for now. <tm>
Bill
> 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"?
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.
Bye,
Freudi
Please check your %windir%/windowsupdate.log and confirm that a reboot was
not required after installing 942615.
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE, OE, Security, Shell/User)
AumHa VSOP & Admin http://aumha.net
DTS-L.ORG http://66.39.69.143/
Right click on the IE icon on your desktop/properties and change the
home page.
Alias
Alias
If your IE6 is utterly and completely reliable in its failure-to-start,
then you'll have to remove the update (which will allow IE6 to start
properly) and then go in and change your default homepage to
a blank page.
Then try reinstalling the update. Open and close IE6 about ten
times after reinstalling to confirm that IE6 is stable with a blank
opening page - and then reset your opening page to whatever
you were using before.
Then, try the whole "Open and close IE6" routine about ten times
again to confirm whether or not IE6 is now stable.
Note: The other thing I've *just* noticed is that I can get stability
and then have the things fail again after several hours of
working properly. As a result, I am not certain the fix I
described in my previous post is completely bulletproof.
The problem may require more work than just a particular
configuration change. I'm still experimenting and testing
for what's actually going on.
Bill
Ottmar Freudenberger wrote:
> "Bill Drake" <bdr...@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.
> 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.
>
I checked my add-ons and my BHOs. All are correct, none of the items
are disabled.
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.
From everything I see here, I suspect there are still some
problems with the fix in the KB942615 update for the bugs
described in KB921090.
This crash is consistent with the KB921090 bug for people who
are loading default webpages which validate their login with https://
before the page proceeds to load normally with http://. (This
behaviour is typical for Microsoft Passport-verified webpage access
and things similar.)
A race condition occurs at each page-login refresh. If the
improvements in the design of IE6 accomplished by KB942615
allow for concurrent processing of both the https:// and http://
sections of the webpage code - and as a result the http:// code
is now permitted to begin execution before the https:// code has
finished obtaining permission for the page to load with the customized
parameters saved for that user - this will create a condition where
a crash would be expected.
Up until the creation of the KB942615 update, the above race
condition was reliably handled by IE6 without error. We need to
return the new code to the same level of bulletproofing as before.
%windir%\KB942615.log
Click OK or press Enter
Scroll down to the bottom of the log and look for:
50.853: IsRebootRequiredForFileQueue: At least one file operation was
delayed; reboot is required.
If none are listed below, check above for delayed deletes.
There should be files 'listed below' after the above line.
MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============
Well we haven't seen that many postings here in the WU newsgroup on
the issue - yet ;)
>> 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.
>>
>
> I checked my add-ons and my BHOs. All are correct, none of the items
> are disabled.
Right, since you've rebooted Windows manually ;-)
Do you have Sun's Java-VM installed? If true which exact version (it's
1.6 u3 here)? Which other AddOns?
> 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.
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
> From everything I see here, I suspect there are still some
> problems with the fix in the KB942615 update for the bugs
> described in KB921090.
According to http://support.microsoft.com/kb/942615/en-us the fix
for KB921090 is contained in KB942615 already.
Bye,
Freudi
>> I suspect the KB942615 update should be coded to force a reboot
>> and does not.
>
> Please check your %windir%/windowsupdate.log and confirm that a reboot was
> not required after installing 942615.
Ehm, shouldn't the KB942615.log file be -ehm- sufficent?
9.578: UpdateSpUpdSvcInf: Source [ProcessesToRunAfterReboot] section is empty; nothing to do.
9.578: IsRebootRequiredForFileQueue: At least one file operation was delayed; reboot is required.
If none are listed below, check above for delayed deletes.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\wininet.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\urlmon.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\shlwapi.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\shdocvw.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\mshtmled.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\mshtml.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\iepeers.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\dxtrans.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\dxtmsft.dll was delayed; reboot is required.
9.578: IsRebootRequiredForFileQueue: c:\windows\system32\browseui.dll was delayed; reboot is required.
9.578: DoInstallation: A reboot is required to complete the installation of one or more files.
9.578: UpdateSpUpdSvcInf: Source [ProcessesToRunAfterReboot.RebootNotRequired] section is empty; nothing to do.
9.610: RebootNecessary = 1,WizardInput = 1 , DontReboot = 1, ForceRestart = 0
That's how the log file is looking on my machine(s) running Windows XP SP2
*not* having IE7 installed while the download and installation of KB942615
via Windows Update.
Bye,
Freudi
50.853: IsRebootRequiredForFileQueue: At least one file operation was
delayed; reboot is required.
If none are listed below, check above for
delayed deletes.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\wininet.dll
was delayed; reboot is required.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\urlmon.dll was
delayed; reboot is required.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\shlwapi.dll
was delayed; reboot is required.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\shdocvw.dll
was delayed; reboot is required.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\mshtml.dll was
delayed; reboot is required.
50.853: IsRebootRequiredForFileQueue: d:\windows\system32\browseui.dll
was delayed; reboot is required.
mshtmled.dll, iepeers.dll, dxtrans.dll , and dxtmsft.dll did not have to
be replaced on reboot
MowGreen [MVP 2003-2008]
===============
*-343-* FDNY
Never Forgotten
===============
I saw one post from Mike Le indicating that at least one company
is seeing this problem throughout their corporate environment.
Consequently we have a problem that cannot be simply swept
under the rug.
>
>>> 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.
>>>
>>
>> I checked my add-ons and my BHOs. All are correct, none
>> of the items are disabled.
>
> Right, since you've rebooted Windows manually ;-)
> Do you have Sun's Java-VM installed? If true which exact version
> (it's 1.6 u3 here)? Which other AddOns?
Running the english version of JRE 1.6 u3 here - latest and greatest as
of the date of this post - and running just fine for weeks until this new
update from MS was installed.
>
>> 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.
If this problem is caused by a race condition, (and the fact
the problem is intermittent seems to confirm that contention)
the issue will only occur if the race between the https:// stream
and the http:// stream occurs in a certain manner. All sorts of
things on the ISP side of the equation - as well as whether or
not the user's network drivers allow fast concurrent streaming
will affect whether or not this problem occurs.
I expect this problem to be worse on machines that have their
network drivers upgraded to the latest (which allows for *fast*
concurrent streaming with substantial queue-depth) - as well
as on machines which have been modified to allow a larger
number of concurrent connections to be made.
These configurations will stress concurrency management in
IE6 - and show up any deficiencies in the way that Microsoft
handles coherency requirements between streams.
> 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.
If KB942615 requires the new functionality embedded in
KB945007 - then that should have been explicitly added to
the KB942615 package. It's not the user's responsibility to
discover this dependency after-the-fact - and Microsoft
specifically warn this patch is not yet developed to a level
where the patch is bulletproof enough to apply in a
production environment.
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.
I hope that Microsoft will use the information in this
thread as input for further investigation and development
in order to reliably resolve this intermittent deadlock
condition.
>> From everything I see here, I suspect there are still some
>> problems with the fix in the KB942615 update for the bugs
>> described in KB921090.
>
> According to http://support.microsoft.com/kb/942615/en-us
> the fix for KB921090 is contained in KB942615 already.
Agreed. However, I suspect while they *think* they've fixed this
problem, real-world results indicate that the problem still remains.
This issue needs to be re-examined and further work needs
to be done to account for failure modes that have not been
addressed in the bugfixes made to date.
In the Windows Update newsgroup? Must have missed that ;)
> 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?
Do you have by any chance installed Google Toolbar or Google Desktop
Search?
>>> 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.
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*?
>> 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?
> 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.
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.
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/2007/12/11/ie-december-security-update-is-now-available.aspx#6754765
In case you don't want to try any possible workaround for the
issue, *please* contact MS directly:
http://support.microsoft.com/security
Bye,
Freudi
> Interesting ... I had all browsers closed, did a manual install, and 4
> less files were 'in use':
[...]
> mshtmled.dll, iepeers.dll, dxtrans.dll , and dxtmsft.dll did not have to
> be replaced on reboot
That looks normal to me in case you've shut down all IE instances. I've
choosen the Windows Update site installing the updates on that machine,
so IE has been running.
Bye,
Freudi
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/2007/12/11/ie-december-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.
In a home environment with Windows XP Home SP2 and IE6, I'm also
experiencing random crashes of IE6 with urlmon.dll as the faulting module
since manually installing this Update late Tuesday evening.
The following screenshot depicts the Application errors in the Event Viewer
that are incurred since installing this Update:
http://users.mikrotec.com/danadell/wwwpages/test/urlmonDllErrors.gif
While they are random in nature, as you can see by the screenshot they are
beginning to amass.
This problem does not exist on the machines with IE7 and KB942615 installed,
only on the machine with IE6 and KB942615 installed.
My two cents worth.
Donald Anadell
"Bill Drake" <bdr...@telus.net> wrote in message
news:eOtTaEJP...@TK2MSFTNGP06.phx.gbl...
I'm afraid you've got the wrong end of the stick here, Bill. The "Click to
activate" feature has been included in all Cumulative Updates for IE since
May-06, including 942615. Installing 945007 disables the "Click to
activate" feature. I believe that Freudi was suggesting that you install
945007 to see if doing so resolves your problem.
>>>> 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.
Fine. Have you *tried* to deactivate HTTP 1.1 at least for proxy
connections?
> IMO, this will not be resolved by hiding the issue -
Once again: I'm trying to find a working workaround for users having
the issue with IE6 on Windows XP SP2. I'm not trying to *resolve* the
issue, that's MS's job.
>> 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.
Since I'm not reading windowsxp.general, I'm not seeing any posting
you're referring too which posted in windowsxp.general only. Please
note, that there are *two* HTTP 1.1 options.
> 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.
Once again: I'm trying to find a working workaround for users having
the issue with IE6 on Windows XP SP2. I'm not trying to *resolve* the
issue, that's MS's job.
>>>> 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.
And that would be made sure by contacting PSS - *everyone* having the
issue should contact PSS to make *sure* that MS is aware of an issue
and push them looking for the cause of the issue.
>>> 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?
No answer? Well...
> Once I am
> sure that KB942615 and *only* KB942615 is the issue, I will say so.
It is, believe me. But the issue obviously doesn't show it's ugly
face to all users running IE6 on Windows XP SP2 after installing
KB942615.
>> 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.
> 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.
Once again: I'm trying to find a working workaround for users having
the issue with IE6 on Windows XP SP2. I'm not trying to *resolve* the
issue, that's MS's job. And no, posting into microsoft.public.*
newsgroups doesn't mean that the posting are read by "MS".
Bye,
Freudi
> We too are having this problem in a corporate production environment.
> xp sp2 ie6.
You've read the whole thread? Fine. Please contact PSS!
> Can anyone confirm uninstalling the kb solves the problem?
Yes, but it will leave the system vulnerable to the security holes
targeted to be closed by the security update. You may consider using
the "disable HTTP 1.1 for proxy workaround" instead.
Bye,
Freudi
--
Kurt Falde [MSFT]
"Donald Anadell" <dana...@nospamersmikrotec.com> wrote in message
news:uBjUv7ZP...@TK2MSFTNGP06.phx.gbl...
I've submitted for the Hotfix, when I get the link back and get it
downloaded and installed I'll post back the results.
Donald Anadell
"Kurt Falde [MSFT]" <n...@spam.com> wrote in message
news:OSCQt9bP...@TK2MSFTNGP02.phx.gbl...
I received the KB942367 Hotfix and installed it along with the associated
Registry Tweak. Only some time and some heavy Browsing will tell if this
has fixed the Urlmon.dll crashing problem in IE6, so far so good but I'll
give it a few days to see how it goes.
I am a little bewildered as to the version of Urlmon.dll that remains in the
System32 folder and dllcache folder though after applying the hotfix. The
Article(KB942367) implies that the hotfix will install version 6.0.2900.3213
of urlmon.dll(or am I reading that wrong). However, after applying the
hotfix I'm still left with the version of urlmon.dll that was installed
KB942615 Cumulative Security Update, version 6.0.2900.3231.
Does this sound right to you, the hotfix should only patch the existing
urlmon.dll file as long as it is version 6.0.2900.3213(or higher), or is it
supposed to replace the existing version with a specific version? I
extracted all the files from the hotfix setup file and I don't see a
urlmon.dll file included in the setup, maybe it's just the geek speak in the
KB Article that has me looking for something that isn't supposed to be
there:o)
At any rate,
1. I applied the hotfix offered as you suggested.
2. Performed the Registry Tweak after installing the hotfix(per the
instructions the KB942367 Article).
3. After performing steps one and two, I'm left with urlmon.dll version
6.0.2900.3231 in both the System32 and dllcache folders.
LOL...I'll be glad when SP3 arrives, fixing Updates with hotfixes it taking
it to the extreme for my 60 year old brain:)
Thanks again for your assistance,
Donald Anadell
"Donald Anadell" <dana...@nospamersmikrotec.com> wrote in message
news:uQiISOcP...@TK2MSFTNGP04.phx.gbl...
--
Kurt Falde [MSFT]
"Donald Anadell" <dana...@nospamersmikrotec.com> wrote in message
news:%23DArpne...@TK2MSFTNGP05.phx.gbl...
From the testing I have done so far, the Registry Entry item
detailed on the KB942367 page is all that is required to be added
to the system - to allow the KB942615 update to perform reliably.
MSIE6 does not intermittently crash when starting up on my
default home page (My MSN) with this Registry Edit in place.
I did not install the KB942367 update - I simply installed the
KB942613 update and added the Registry Edit specified on
the KB942367 webpage.
From everything I can see here, it would seem to me this Registry
Edit should have been applied as part of the install script for
KB942615 - since the version 6.0.2900.3231 urlmon.dll file shipped
with KB942615 has had the requisite code installed in the DLL all
the way back to version 6.0.2900.3213 - which was released on
Sept 12/07.
Regardless, I will be doing more testing over the next 24 hours in
order to ensure that the system is stable with this new Registry
Entry in place. I will report back to the group once I am reasonably
certain this bugfix is stable.
Best I can do for now. <tm>
Bill
Kurt Falde [MSFT] wrote:
> From what another engineer told me this is right. the fix in 942367
> probably did not need to be installed just the registry key needs to
> be in place as this fix is already included in the urlmon.dll thats
> in the update just released. Thanks for letting me know.
>
>
If the hotfix(KB942367) is already coded into the 6.0.2900.3231 version of
urlmon.dll(KB942615), I'm going to uninstall the hotfix and just run with
the Registry Tweak to see how that works out.
Thanks again for your assistance,
Donald Anadell
"Kurt Falde [MSFT]" <n...@spam.com> wrote in message
news:uMMymIg...@TK2MSFTNGP02.phx.gbl...
> From what another engineer told me this is right. the fix in 942367
> probably did not need to be installed just the registry key needs to be in
> place as this fix is already included in the urlmon.dll thats in the update
> just released. Thanks for letting me know.
Thanks jumping in, Kurt! :)
Now, since the "registry hack" seems to solve the problems with urlmon.dll
running IE6 under Windows XP SP2, wouldn't it be a good idea to revise the
Security Bulletin MS07-069 and the "Known Issues" section there which still
states, that there are no known problems?
Further more, what will the next steps be from MS to really fix the issue
for the average user? The release of a KB942615v2 for IE6 on Windows XP SP2
*inculding* the registry fix or even better, releasing the update package
with a fixed urlmon.dll? Me thinks it's somewhat unacceptable to force
users hacking in the heart and brain of Windows aka the registry themself
and leaving those users in the dark, which will most likely never find the
way into the newsgroups to get aware of the -well- "fix".
In the meantime I've uploaded the registry fix on my little web site the
other day: http://patch-info.de/IE/Downloads/IE6SP2_urlmon_dll-Crash.zip
The zip file contains "IE6SP2_Hotfix_KB942367_aktivieren.reg" which will
import the neccessary "registry hack" into the registry after double
clicking on it and letting it merge into the registry.
"IE6SP2_Hotfix_KB942367_deaktivieren.reg" is included in the zip file too
which will remove the registry keys again in case someone needs too.
Note that the registry fix only works for these IE6 instances, that have
been started *after* applying the registry hack/fix. So it's a good idea
to close *all* opened IE6 windows *before* applying the registry fix.
Bye,
Freudi
A huge thanks for all your efforts. On the techno radar I have nothing
but a logical mind and an ability to read "plain english" & this post
truly made sense of all the noise (& reassured me that merging
Freudi's file into the Registry would resolve the issue, which it
did). Wish, somehow, that all & sundry struggling with this problem,
fearful of regedit, still posting to various blogs, etc, etc, could
get to this post, download, open, doubleclick & get on with it, if MS
is truly not going to address this (except on a case by case
basis..monstrous & inconceivable from a Customer Service point of view
but???) until maybe the next update in January. In any case, you folks
ROCK ! Glad I found you. Thanks again & until next (I'm sure there
will be one)
THANK YOU, Freudi! Worked like a charm! :)
~Carol
thanks
sharkman
Now I could have easily followed the instructions in the article telling how
to modify the registry but since Freudi took the time to post the reg file
so we could all simply download and run it was great. Saved me time and will
save others that are afraid to go into the registry the fear of doing so.
That said. Freudi you did include a reg file to make it easy to remove the
new key in the future if one wants to. Do you think it necessary to remove
this key when the next cumulative updated comes out or at some time in the
future?
Thanks
"Ottmar Freudenberger" <fre...@gmx.net> wrote in message
news:5shfsmF...@mid.individual.net...
> That said. Freudi you did include a reg file to make it easy to remove the
> new key in the future if one wants to. Do you think it necessary to remove
> this key when the next cumulative updated comes out or at some time in the
> future?
I doubt it will be neccessary, but you never know. I'll post in this
very thread *if* MS fixes the issue themself by releasing a "repaired/
repairing" update and in case it's needed to remove the registry key.
You're welcome,
Freudi
> I'm sooo confused... All I want to do is dl the KB.
In case you are using IE6 on Windows XP SP2:
Let KB942615 download and install. Afterwards download
http://patch-info.de/artikel/2007/12/11/435 open it, double click
on the contained IE6SP2_Hotfix_KB942367_aktivieren.reg and approve
to let it merge into the registry.
> Has it been corrected
Not yet.
Bye,
Freudi
I discovered this problem (IE6 crashing after the 942615 update) on a single
machine (the others are running IE7) and manually applied the registry patch
from the 942367 article - and it is working fine again! This particular
machine runs the free AVG Antivirus along with the Windows Firewall - so if
antivirus software is suddenly interfering with automatic Windows updates in
some way, we can add AVG to the list.
BTW - the link to
http://patch-info.de/IE/Downloads/IE6SP2_urlmon_dll-Crash.zip has not been
responding for the past day or so - is that site down or possibly
inaccessible from some locales?
gfm
> BTW - the link to
> http://patch-info.de/IE/Downloads/IE6SP2_urlmon_dll-Crash.zip has not been
> responding for the past day or so - is that site down or possibly
> inaccessible from some locales?
Nope, it's working as it should and responsive. Some ~500 downloads in
the meantime are confessing that it does. What error message do you get?
You may want to try to download once more and consider, that there's a
daily maintenance between 4AM and 5AM CET.
In case you still have trouble accessing the file and site, mail me
and I'll mail you the file.
Bye,
Freudi
The .reg file is actually attached to one of the other threads in this
newsgroup, so I did get a copy of it.
OK - the site just started working for me - right after I successfully
pinging it from dnsstuff.com. Weird! I'm UTC-5h and you're UTC+1h, so I
don't think I'm hitting the maintenance window. Oh, well. Not to worry.
gfm
"Ottmar Freudenberger" <fre...@gmx.net> wrote in message
news:5srrslF...@mid.individual.net...
> OK - the site just started working for me - right after I successfully
> pinging it from dnsstuff.com. Weird! I'm UTC-5h and you're UTC+1h, so I
> don't think I'm hitting the maintenance window. Oh, well. Not to worry.
Well, thanks for testing, but the problem seems to be on your (provider's)
end (DNS setting/server) from my point of view.
Bye,
Freudi
More see: http://knowledgebase.quickbooks.ca/detail.php?&qbid=QB2202
The Help function doesn't work because of a recent security update from
Microsoft. Their update, released on Dec. 11 via automatic download for
Internet Explorer users, protects your computer from a potential security
vulnerability, but may also affect the Help function in QuickBooks.
Downloading and installing Intuit's update will fully restore the Help
function.
Jim