WARNING: KB942615 may require an extra reboot to apply correctly

[Bill Drake]

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.
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

 

[Ottmar Freudenberger]

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

 

[Andre]

I always reboot after updates whether specified in the up date or not,
because I do manual updates....and my problems started after I cleaned the
cache. I tried the usual fixes first with my machine, but went directly to
unistall on my wife's PC after of course trying it to see if it would react
the same way as mine first and it did.

 

[whomike]

Bill--
I am having a problem-- "please try moving to a blank page"--
I do not have a shortcut to any blank page on my desktop and I cannot enter
"about-blank" in the url line while the "IE has encountered an error and must
close" box is showing on the re-launch of IE after the update.
Any ideas of how to get a blank page before the update?
Thanks--Mike

 

[Bill Drake]

Hi, Mike. I find that I've just got to be stubborn and keep restarting
IE6 until I finally get a valid start. It sometimes takes as many as
6 or 8 tries in a row before the timing-error that causes the problem
does not occur.

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

 

[PA Bear]

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.

 

[Bill Drake]

Hi, Freudi. See comments inline.

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.


Best I can do for now. <tm>


Bill

 

[MowGreen [MVP]]

Please check the KB942615.log
Click Start > Run > type in or copy and paste the below into the Open: line

%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
===============

 

[Ottmar Freudenberger]

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 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

 

[Ottmar Freudenberger]

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

 

[MowGreen [MVP]]

Interesting ... I had all browsers closed, did a manual install, and 4
less files were 'in use':

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
===============

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

 

[Bill Drake]

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.

Consequently we have a problem that cannot be simply swept
under the rug.

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.

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.

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.


Best I can do for now. <tm>


Bill

 

[Ottmar Freudenberger]

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

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.

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?

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*?

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/20...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

 

[Ottmar Freudenberger]

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

 

[Bill Drake]

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.

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.



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.

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.

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.

That's the theory, yes. Now to the practice: does the issue
exists with KB945007 for IE6 on Windows XP SP2 beeing
installed?


"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

 

[PA Bear]

Bill Drake wrote:

If KB942615 requires the new functionality embedded in
KB945007 - then that should have been explicitly added to
the KB942615 package.

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.

 

[Donald Anadell]

Since this seems to be the Tread most relevant to the Urlmon.dll crashes in
IE6 after applying KB942615 I'll post my experiences with this Patch here.

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

 

[Ottmar Freudenberger]

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.

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.

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.

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.

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

 

[Kurt Falde [MSFT]]

Please try http://support.microsoft.com/kb/942367 and let us know if this
resolves your issues.
Use the online request form to get the fix.

 

[Donald Anadell]

Thanks for the feedback Kurt,

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

Please try http://support.microsoft.com/kb/942367 and let us know if this
resolves your issues.
Use the online request form to get the fix.


--
Kurt Falde [MSFT]

Since this seems to be the Tread most relevant to the Urlmon.dll crashes
in
IE6 after applying KB942615 I'll post my experiences with this Patch
here.

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