locked
IE 10 crashes RRS feed

  • Question

  • Running IE10 on Windows 7 Enterprise 64 bit with Microsoft System Center Endpoint protection.  IE10 crashes whenever I click a button (favorites, print, Suggested sites, etc.).  I have tried with and without add-ons enabled.  I have tried everything I can find on the forums.  I am running EMET 3.0 which was suggested this is a problem, but without it, crashes still occur.

    I tried Safe Boot with Networking and there were no crashes.  I then tried Clean Boot with only MS services running and all of the crashes returned.  Here is the latest crash report from Action Center.  This crash was result of my clicking the Favorites "star".

    Source
    Internet Explorer

    Summary
    Stopped working

    Date
    ‎5/‎31/‎2013 2:48 PM

    Status
    Not reported

    Description
    Faulting Application Path:    C:\Program Files\Internet Explorer\iexplore.exe

    Problem signature
    Problem Event Name:    APPCRASH
    Application Name:    iexplore.exe
    Application Version:    10.0.9200.16576
    Application Timestamp:    515e31c3
    Fault Module Name:    mscorwks.dll
    Fault Module Version:    2.0.50727.5466
    Fault Module Timestamp:    503ef7aa
    Exception Code:    c0000005
    Exception Offset:    0000000000502990
    OS Version:    6.1.7601.2.1.0.256.4
    Locale ID:    1033
    Additional Information 1:    7d57
    Additional Information 2:    7d57da16462c37e8bbf97e59affe90f5
    Additional Information 3:    6715
    Additional Information 4:    6715b3d86641c64c0beac2eda0664146

    Any help/suggestions would be welcome.

    Friday, May 31, 2013 7:05 PM

Answers

  • Any idea where I can get mscorwks.dll, most current version?

    Check your WinSxS.   You may already have it.

    E.g. this PowerShell pipeline

    dir *mscorwks* | foreach-object {dir $_\mscorwks.dll} | sort-object LastWriteTime | select -Property LastWriteTime, @{Name="FileVersion";Expression={$_.VersionInfo.FileVersion}}

    suggests that I have a (more recent) Hotfix version (aka LDR version) called

    2 2.0.50727.5737 (QFE.050727-5700)

     
    Then the next obvious question would be what would you need to do to (try to) take advantage of it?

     C.f.

    http://social.technet.microsoft.com/wiki/contents/articles/3323.how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx

     
    which seems to be just a way of downloading some XML which does that once you have a relevant patch which refers to it.

    The simplest way that I know of for doing that is to see if there has been a security patch which involves the module in question and then try to find the latest one and the one before that.   So, then presumably what you could do is back off the latest, install the LDR branch for the preceding, and then wait for the LDR branch of the latest to be reapplied.   (FWIW that is what I did once with an IE Cumulative update to provide proof of concept.)

     

    A search of Support KB articles provided this

    http://technet.microsoft.com/en-us/security/bulletin/ms12-074

    from November of last year.

    Is it the latest?  Use the TechNet Security Bulletin Search tool (link in the top of the preceding page) to check.

     

    Ooh.   A problem you are going to have is that apparently .NET does not always get patched cumulatively and the TechNet Security Bulletin Search Tool does not refer to individual modules (e.g. the way the DLL Help Database once did).   In fact, I just realized that this explains why my PowerShell pipeline for this example did not run cleanly.   There have been subsequent patches made to the MSCORWKS components which do not include that module.   Who knew?   Thanks for making me see this.

    Also, I don't know how much the LDR propagation occurs.   E.g. if you install an LDR version of a patch which does not include the module that you are interested in (e.g. as a way of signalling your interest in getting on the LDR track of its component) will you get it on the update to that component?  Who knows?  E.g. if that hypothesis were true all you would need to do is find the last two patches to MSCORWKS, regardless of whether they included this module or not, uninstall the latest, patch the one before it and then allow updates to proceed.   I don't want to speculate on the result.  TBD?    <eg>

     
    Oops.   I just noticed the context of your question.   I don't think you actually have proof that this module is the problem cause.   It may just be (in fact probably is) a victim.   In that case, a better way to proceed IMO would be to find out the callers, e.g. extract the Stack Back Trace for the crashing thread and see which other modules were involved in the event.  Then, from clues like that you could do things to try to change those aspects of your symptom description.   E.g. eliminate unnecessary modules from the problem scenario.

     

    Since you have found a condition where your crash is avoided you might not even have to go that far.  E.g. just finding out what is being loaded in each case may provide a sufficient clue about a likely culprit.   Tools for doing that are Resource Monitor or ProcExp (from TechNet).   Both allow you to capture editable lists which could then be sorted and used with a difference program such as WinDiff.

     
    HTH

     
    Robert Aldwinckle
    ---

    • Marked as answer by Doc Tuesday, June 4, 2013 8:15 PM
    Monday, June 3, 2013 4:09 PM
    Answerer

All replies

  • Hi,

    try running in Safe Mode with Networking.. if the issue disappears go Start>Run>MSconfig (no home versions of windows only) >Startup tab and disable all non-Microsoft startup services....

    here is a description of the faulting module... mscorwks.dll

    http://www.file.net/process/mscorwks.dll.html

    here is one known hotfix from MS....

    http://support.microsoft.com/kb/913384


    Rob^_^

    Saturday, June 1, 2013 1:04 AM
  • Rob,

    Thank you so much for your response.  As noted in my original message, I tried rebooting in Safe Mode with Networking, and the crashes did not occur.  I then did a Clean Reboot (only MS services), and the crashes returned. 

    I just tried the hotfix you referenced, but it would not install because it refers to a different version of the product.  My system is 64-bit and I conjecture that this hotfix from 2007/2008 may have been developed for an older 32-bit version. 

    Any idea where I can get mscorwks.dll, most current version?  I have VS2010 and VS2012 Ultimate installed on my computer with all of the updates applied.

    Thank you in advance.

    Monday, June 3, 2013 1:54 PM
  • Any idea where I can get mscorwks.dll, most current version?

    Check your WinSxS.   You may already have it.

    E.g. this PowerShell pipeline

    dir *mscorwks* | foreach-object {dir $_\mscorwks.dll} | sort-object LastWriteTime | select -Property LastWriteTime, @{Name="FileVersion";Expression={$_.VersionInfo.FileVersion}}

    suggests that I have a (more recent) Hotfix version (aka LDR version) called

    2 2.0.50727.5737 (QFE.050727-5700)

     
    Then the next obvious question would be what would you need to do to (try to) take advantage of it?

     C.f.

    http://social.technet.microsoft.com/wiki/contents/articles/3323.how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx

     
    which seems to be just a way of downloading some XML which does that once you have a relevant patch which refers to it.

    The simplest way that I know of for doing that is to see if there has been a security patch which involves the module in question and then try to find the latest one and the one before that.   So, then presumably what you could do is back off the latest, install the LDR branch for the preceding, and then wait for the LDR branch of the latest to be reapplied.   (FWIW that is what I did once with an IE Cumulative update to provide proof of concept.)

     

    A search of Support KB articles provided this

    http://technet.microsoft.com/en-us/security/bulletin/ms12-074

    from November of last year.

    Is it the latest?  Use the TechNet Security Bulletin Search tool (link in the top of the preceding page) to check.

     

    Ooh.   A problem you are going to have is that apparently .NET does not always get patched cumulatively and the TechNet Security Bulletin Search Tool does not refer to individual modules (e.g. the way the DLL Help Database once did).   In fact, I just realized that this explains why my PowerShell pipeline for this example did not run cleanly.   There have been subsequent patches made to the MSCORWKS components which do not include that module.   Who knew?   Thanks for making me see this.

    Also, I don't know how much the LDR propagation occurs.   E.g. if you install an LDR version of a patch which does not include the module that you are interested in (e.g. as a way of signalling your interest in getting on the LDR track of its component) will you get it on the update to that component?  Who knows?  E.g. if that hypothesis were true all you would need to do is find the last two patches to MSCORWKS, regardless of whether they included this module or not, uninstall the latest, patch the one before it and then allow updates to proceed.   I don't want to speculate on the result.  TBD?    <eg>

     
    Oops.   I just noticed the context of your question.   I don't think you actually have proof that this module is the problem cause.   It may just be (in fact probably is) a victim.   In that case, a better way to proceed IMO would be to find out the callers, e.g. extract the Stack Back Trace for the crashing thread and see which other modules were involved in the event.  Then, from clues like that you could do things to try to change those aspects of your symptom description.   E.g. eliminate unnecessary modules from the problem scenario.

     

    Since you have found a condition where your crash is avoided you might not even have to go that far.  E.g. just finding out what is being loaded in each case may provide a sufficient clue about a likely culprit.   Tools for doing that are Resource Monitor or ProcExp (from TechNet).   Both allow you to capture editable lists which could then be sorted and used with a difference program such as WinDiff.

     
    HTH

     
    Robert Aldwinckle
    ---

    • Marked as answer by Doc Tuesday, June 4, 2013 8:15 PM
    Monday, June 3, 2013 4:09 PM
    Answerer
  • Robert,

    Thank you for your very informative answer.  It turns out that while you were answering, I was biting the bullet and reinstalling Windows.  That seems to have resolved the problem - though at the cost of a lot of time and effort.

    Again, thank you for your help.  It is sincerely appreciated.

    Tuesday, June 4, 2013 8:14 PM