Data Execution Prevention/No Execute (DEP/NX) causing 'Webpage has expired"


  • I believe I have found a memory issue/bug with IE 8. The outward symptom from a user's perspective is a "Webpage has expired" error in the browser, or a "This tab has been recovered" error, after they click a save button on your site. The symptom seems to be only for users using IE 8 on XP, and viewing a page that has a substantial amount of content (generally pages over 700k of data). 
       Use of the MS "Internet Explorer Compatibility Evaluator" reveals that when this issue happens, IE is throwing a Data Execution Prevention/No Execute (DEP/NX) under the hood. Turning off the DEP for Internet Explorer makes no difference, the error will occur. Also, usage of compatibility mode in IE makes no difference. Also, running IE in 'no add-ons' mode makes no difference. The users experiencing this isuue are able to work with an equivalent page that has mush smaller content just fine (with nothing else different about the page). So I believe this to me a memory management issue with IE 8. Also,  I believe the DEP error being reported is a red herring, because running IE without DEP makes no difference.
       This symptom has already cost thousand of dollars in irate customers abandoning their work on the site. Please suggest some solutions that do not involve 'reset IE settings', or 'try these random service packs'. This error users are seeing is not relevant to any install toolbars or add-ons. A clean PC running a fresh XP install with a new install of IE 8 will experience this same symptom doing the same work on the same page the users are doing. For reference, there are literaly thousands of other users with zero symptoms who are not using the XP IE 8 combination.
    As more of our users start switching to IE 8, I am sure this issue will become more pronounced. 
    So please offer some doable steps to remedy this, as telling the userbase that we don't support IE 8 will be a painful path to walk down.
    Below is the output from the IECE Tool for when the crash happens:
    <Data_x0020_Type>Internet Explorer Compatibility Evaluator</Data_x0020_Type>
    <Date_x0020_and_x0020_Time>2/19/2010 2:38:40 PM</Date_x0020_and_x0020_Time>
    <Object_x0020_Name>C:\WINDOWS\system32\urlmon.dll -1073741571 , 0 ,2014620568./Object_x0020_Name>
    <Issue_x0020_Type>DEP/NX Crash Recovery</Issue_x0020_Type>
    <root><MitigationCode>DEPNX</MitigationCode><UrlPath></UrlPath><UrlZone></UrlZone><DEPNX>C:\WINDOWS\system32\urlmon.dll -1073741571 , 0 ,2014620568.</DEPNX></root>
    Data Execution Prevention/No Execute (DEP/NX) option in Windows Internet Explorer 8 prevents code from running in non-executable memory. When a violation occurs, the browser stops responding instead of running malicious code. When Internet Explorer 8 has recovered from a crash caused by DEP/NX, this event is logged. Typically, DEP/NX failures occur due to attempts to exploit the browser or its add-ons. But it is possible that a browser add-on is not compatible with DEP/NX, and failures occur even without malicious content. If an incompatible add-on is found, contact the add-on developer for an updated version. For more information, see
    Friday, February 19, 2010 10:49 PM

All replies

  • Do you have a page that folk can look at to repro the issue? Or a crash dump you can upload and share?

    Also the forum is an informal peer support channel, the official support channel for Microsoft is through or through your account manager (if applicable). 
    Friday, February 19, 2010 10:57 PM
  •   I wish I could give you a URL, but this is a commercial business-to-business web front end application. I am not sure what you mean by crash dump in this context, but I can provide two obfuscated screen shots. One is using the site via https, the other via http. Other than that difference, the use case is the same. 

    Here is a screenshot of what the user sees after clicking the save button for the https site:

    And where is a screenshot of the same use case for the http site:

      It's important to note there is zero server round tripping in these cases (issue is completely client side), and there is no back button usage.
    Also, I believe that IE is attempting to take the user 'back' to what it believes to be a safe page for both of these use cases. In the https scenario, it appears to be one page back. In the http case, it appears to be two pages back. And, the pages use no active-x, or Java.

      I didn't mention it the prior post (wasn't sure of the relevance), but above and beyond the XP/IE8 commonality, the user agent data I track from them logging in indicates they tend to have some common '.NET' data in their agent data.
    Also, the page blows up whether in compat mode or not, running with or without add-ons disabled, or running with DEP disabled------ it makes no difference for this symptom.
     At this point I heavily leaning on a memory issue. Because users can work other transactions on the site that vary ONLY in the number of items we show on the screen (read: less data {html} on the client side).

    Below I have created  simple table that shows the common .NET fingerprints I see on users that tend to have this issue:
    The table also shows one sample complete agent header just for reference.
    An 'x' under a user indicates that their agent data I log contains that fingerprint.
    Here is a link to that graphic.

    Note, these header data items are not from when the user actually clicks the button leading to the issue-- as there is no round trip for that (browser has the crash.. there is no post/get in that scenario).
    Friday, February 19, 2010 11:40 PM
  • Thanks for the follow up information, nothing sticks in my mind about the impact of .net as that isn't even loaded into IE unless you have an extension that uses it. The crash seems to be from URLMon which is the network stack, in the case where .net isn't loaded the only interaction that seems relevant is the user agent string. It's doubtful but it might be worth trying to change the user agent string to not send the .net portion you can use to do that.

    Afraid I can't really help much more without a repro or dump as there isn't any code for me step through or analyze :(. You can also contact Microsoft Support and they can work with you. 
    Friday, February 19, 2010 11:56 PM
  • I just wanted to say that I downloaded the agent string tool you mention above, and used it, but it mode no difference.
    I set the agent string to be a Firefox one-- but it's didn't change the outcome in any way.
    Also, I verified that the server side was in fact getting that agent string, and it was.
    But.... no love...
    Saturday, February 20, 2010 12:55 AM
  • FYI, I pointed the OP to Web Development forum from IE Answers forum: 
    Saturday, February 20, 2010 1:07 AM
  • Yea I didn't think the tool would make much difference. You should go through the official developer support channel as without a repro or a dump there isn't anything I can do and other folk on the forum will be in a similar situation unless they have seen this issue before. 
    Monday, February 22, 2010 5:55 PM
  • Andy, can you point me to where you mean by 'official developer support channel'?
    This issue has caused substantial loss of revenue already, paying for some kind of expedited solution might be a tolerable route.
    I am not familiar with what you mean by 'official developer support channel'.
    Monday, February 22, 2010 9:21 PM
  • I am reasonable confident this is a memory management bug in IE. I just recreated the issue like this:

    1) Opened 'Process Explorer' product by SysInternals, and selected the Internet explorer process and right clicked and picked 'debug'.
    2) This opened visual studio.
    3) Then I performed the same act the users do to re-create the issue.
    4) This caused Visual Studio to to have a dialog that discussed a stack overflow issue. (see attached screenshot)
    5) The dialog had a 'continue' and a 'break' button. I clicked continue.
    6) Another dialog came up in Visual studio that talked about a access violation (see attached screenshot)
    7) Step 6 above causes a recursive loop where that same access violation dialog keeps coming back

    Here is a shot of the two dialogs:

    Monday, February 22, 2010 11:52 PM
  • I believe you can open a support request at

    Tuesday, February 23, 2010 6:16 PM
  • Hmm there are some circumstances where you can get stackoverflows in the JScript engine or elsewhere, but with out symbols or a repro it's impossible to know :(. 
    Tuesday, February 23, 2010 6:19 PM
  • Solved.
    I believe I have this issue figured out. It's shame that so far it has cost over 2 grand in dev time to find a solution.
    What ended up causing this issue to go away (so far) was posting much less data when the form attempts submission.
    The page has been refactored to only post deltas back to the server. The page is doing a 'post' as opposed to a get; so in theory, the amount of content pushed back shouldn't matter. I have been unable to cause the symptom now that the page is posting back a very small amount of data.
    Friday, March 12, 2010 7:10 PM