Windows Vista SP1 Broke my Internet Explorer Compatibility Test Tool!

...but I fixed it. And I thought you might like to know how to fix it if you run into the issue.

So first, the problem. I was trying to launch IECTT and found this MessageBox:


Test Tool Error


The file size exceeds the limit allowed and cannot be saved




Hrm. This could be ... um ... more helpful. I have no idea what it's talking about.

Now, the fix:

Manually set the key HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsInternet ExplorerMainFeatureControlFeature_Enable_Compat_Loggingiexplore.exe = (DWORD) 1. Then, browse to some web sites which generate some issues (my trusty homepage did just fine for me).

The problem exists when the Internet Explorer event log is empty, so we just need some way to make it non-empty.

Now, let's dig into the investigation, because it's always instructive to go back over what we found and try to understand what we can learn from it.

First, I did a quick stack trace. Here's what I saw:

ChildEBP RetAddr 

002bedec 79f071ac KERNEL32!RaiseException
002bee4c 79f0a629 mscorwks!RaiseTheExceptionInternalOnly
002bef10 7a71713e mscorwks!JIT_Throw
002bef5c 7a659780 System_ni!System.Diagnostics.EventLog.get_OldestEntryNumber
002bef5c 7a6597ff System_ni!System.Diagnostics.EventLog.StartListening
002bef5c 7a655d33 System_ni!System.Diagnostics.EventLog.StartRaisingEvents
002bef5c 03cd6018 System_ni!System.Diagnostics.EventLog.set_EnableRaisingEvents
002befac 03cd52d0 TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.EventLogMonitor..ctor
002befac 03cd040c TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm.InitializeDataProviders
002befe0 03cd00b9 TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm..ctor
002befe0 79e7c74b TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm.Main
002beff0 79e7c6cc mscorwks!CallDescrWorker
002bf070 79e7c8e1 mscorwks!CallDescrWorkerWithHandler
002bf1b4 79e7c783 mscorwks!MethodDesc::CallDescr
002bf1d0 79e7c90d mscorwks!MethodDesc::CallTargetWorker
002bf1e4 79eefb9e mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot
002bf348 79eef830 mscorwks!ClassLoader::RunMain
002bf5b0 79ef01da mscorwks!Assembly::ExecuteMainMethod
002bfa80 79fb9793 mscorwks!SystemDomain::ExecuteMainMethod
002bfad0 79fb96df mscorwks!ExecuteEXE

OK, let's take a look at the OldestEntryNumber to see what it could be doing:

.method private hidebysig specialname instance int32 get_OldestEntryNumber() cil managed
    .maxstack 3
    .locals (
        [0] int32[] numArray,
        [1] bool flag,
        [2] int32 num)
    L_0000: ldarg.0
    L_0001: call instance bool System.Diagnostics.EventLog::get_IsOpenForRead()
    L_0006: brtrue.s L_000e
    L_0008: ldarg.0
    L_0009: call instance void System.Diagnostics.EventLog::OpenForRead()
    L_000e: ldc.i4.1
    L_000f: newarr int32
    L_0014: stloc.0
    L_0015: ldarg.0
    L_0016: ldarg.0
    L_0017: ldfld native int System.Diagnostics.EventLog::readHandle
    L_001c: newobj instance void [mscorlib]System.Runtime.InteropServices.HandleRef::.ctor(object, native int)
    L_0021: ldloc.0
    L_0022: call bool Microsoft.Win32.UnsafeNativeMethods::GetOldestEventLogRecord(valuetype [mscorlib]System.Runtime.InteropServices.HandleRef, int32[])
    L_0027: stloc.1
    L_0028: ldloc.1
    L_0029: brtrue.s L_0031
    L_002b: call class System.ComponentModel.Win32Exception System.Diagnostics.EventLog::CreateSafeWin32Exception()
    L_0030: throw
    L_0031: ldloc.0
    L_0032: ldc.i4.0
    L_0033: ldelem.i4
    L_0034: stloc.2
    L_0035: ldloc.2
    L_0036: brtrue.s L_003a
    L_0038: ldc.i4.1
    L_0039: stloc.2
    L_003a: ldloc.2
    L_003b: ret

Interesting - this is just a p/invoke into the native method advapi32!GetOldestEventLogRecord. If we debug into this guy, we see that this method calls advapi32!BaseSetLastNTError(-1073739516). This is, of course, STATUS_FILE_TOO_LARGE, which is what we saw in the first place. Now, we have an API returning a different result than it did before, that API has an owner, and we can contact that owner and have him take a look.

So, our debugging job is done. Remember, you want to look for opportunities to debug and investigate to sharpen your skills, but you also want to know when to stop. At this point, we have an owner, and we have a workaround, so we can wipe our hands and move on to the next problem.

Updated 20-Mar-2008

If you're having problems getting the per-user policies to take hold, you can try HKLMSoftwareMicrosoftInternet ExplorerMainFeatureControlFeature_Enable_Compat_Logging instead of HKCU. I had to do this on one configuration.

Comments (19)

  1. John says:


    I have foloowed the exact procedure for fixing the IECTT error. But still, the problem is not solved.

    Is there any other way to make it work?



  2. miguel says:

    simply uninstall sp1 update to get internet explorer working again

  3. john says:

    some tiimes wee need not fix things that in time seem to fix themselves because they where not really broken, we where just in the right place at the wrong time or at the wright time in the wrong place. personally I’m anti headache, and found that IE is a self fixer when I work on something else close to the prob. and a change comes up that is needed, and waala; the other prob. is solved. always remember computers can think on their own but they meditate so to speak and don’t care if you are there or not, they have gaps and spaces I don’t know about. wuups don’t mind me!

  4. arwidmark says:

    Changing the registry only helps for starting IECTT, not for uploading the issues… the best solution is not to change the registry and instead install this hotfix –  

    Regards / Johan Arwidmark

    Microsoft MVP – Setup / Deployment

  5. ABC says:


    yes once we install this hotfix IECTT is working fine. But just I want to know how to resolve the issues captured by this IECT tool.

    Once I opend the tool and browse some sites, it got captured some issues 1) object caching 2)windows restrictions 3)CSS fixes.

    Please could anyone help me how to resolve these issues.

  6. cjacks says:

    In most cases, you have to change the code of the web application – there is no workaround other than turning the security feature off. The comments for each issue frequently contain links to articles describing the feature and the coding recommendations.

  7. ABC says:


    So you mean to say, there is no other workaround will work like apply the shims for these kind of issues.

    Ok, if we have to change the code of the web application, then how we can change the code as we are testers and where we can find out the solutions for these( pls provide any sites or blogs where I can have much glance over)

  8. cjacks says:

    Depends on the issue. Sometimes there are workaround. You’ll have to read up on the particular issue. Sometimes you can turn off the security feature, but that typically involves a discussion with the security team. There isn’t a notion like shims for web apps.

  9. ABC says:


    Thnks….See I have seen few issues frequently…….

    1) object caching

    2) windows restriction

    3) Css Fixes

    here I could found one registry key, to resolve the Object caching. HKLMsoftwaremicrosoftinternetexplorermainfeature_controlfeature_object_cachingiexplore.exe=0

    If I change the above modification in registry, I could able to resolve the issue.So can I go with this solution, is it a correct solution?……

    if I do the above changes, this workaround is not only for the one single application. This will work for all the applications. So do I am doing correct or not?……If I want for one single specific application how could I do?…..

    and also please help me how to resolve rest of the 2 issues?….

    thnks in advance for ur reply.


  10. cjacks says:

    Hi ABC,

    There really isn’t too much you can do to "fix" these without having the developers fix the bugs in their software. You can turn off the security feature, as you point out, but then you don’t have the security feature any more, and most people don’t like loosening security to accomodate a bug in an application.

    For object caching, you shouldn’t assume you have access to an object after a navigation event. Because you shouldn’t have access.

    For window restrictions, many of these restrictions don’t break an app, they just make it behave differently. If you were trying to hide the chrome to stop showing where you are, then the chrome isn’t hidden any more. But the app should still work.

    CSS Fixes are typically just recommendations that you can start to eliminate some of your IE code branches for CSS, and typically don’t break the app.

    My recommendation: don’t blindly follow the tool, fix what is broken and use the tools to help you figure out what is causing the breakage when you notice that it is.

    And, for web apps, rather than just blindly killing off security features which have a measurable ROI, see if you can work with developers when the security feature is actually breaking the app.



  11. ABC says:

    Thnks Chris.

    So the tool will capture all kind of issues, but we need to check it out which really breaking the app, right? and then we have to fix it up, without turning off the security features.

    Here in my project, we have to present evrything like IECT logs and the screen shots of the logs. So whatever he can see on these logs, asking us to fix it?…thn how come it would be possible?

    But even I dont understand like which will cause the app break. Based on my exp. I could find almost 18 web-issues are there( which will be captured by IECT tool).

    So out of these 18, which will cause the application to fail. Please help me in this reagard.

    1) Object caching

    2) MIME Handling

    3) Windows Restrictions

    4) CSS Fixes

    5) Zone Elevation

    6) Binary Behaviors

    7) ActiveX Blocking

    8) Popup Blocking

    9) Download Blocking

    10) Local Machine Zone Lockdown

    11) Centralized URL Parsing

    12) Internationalized Domain Names

    13) Secure Sockets Layer

    14) XDOM Barrier

    15) Anti-Phishing filter

    16) Manage Addons

    17) UIPI Extension Blocked

    18) UIPI Cross Process Window Message

    Please, here on which area I have to focus and how to get resolve those?

    I guess it’s really very big deal to explain all these stuff to me and I can understand you may not get a much time to spend in reading out all these blogs.

    But really I need your help…….Pls…



  12. cjacks says:

    Hi ABC –

    I just can’t teach you everything about web application security and remediation in a comment to a post, or even a whole post. There’s tons of information out there for you to dig into. For some basics, I’d just start by reading through the config file, which has details (they also show up in the tool when you encounter the issue) – "C:Program FilesMicrosoft Application Compatibility Toolkit 5Internet Explorer Compatibility Test ToolIECEConfig.xml".

    But it’s not a matter of some issues require fixing, and others don’t. Rather, think of yourself as a doctor. When you go to the doctor, do you have to take every single test there is to figure out what is wrong with you? No, you typically start out by telling the doctor the symptoms, and then the doctor uses some tests to try to figure out what could be causing these symptoms.

    You should use the same approach. You observe the application isn’t working, or isn’t working as it used to. Perhaps it’s now displaying chrome that it didn’t used to. It looks different, yes, but it doesn’t affect users’ ability to use the app. So, do you need to do anything about it? Maybe not. Perhaps it’s now just displaying an error message. You use the tool to figure out what’s wrong, and then get suggestions for how to fix it.

    Application compatibility is simply not as easy as "here’s the flowchart for what to do, start to finish" – you have to apply yourself creatively to the problem to find a solution. There are simply more ways of doing things wrong (infinite) than we could ever build tools to detect. So, instead, we apply tools to grab the bulk of issues, and humans to clean up the rest.

    For web apps in particular, the developers should be partnering with you, as you’ll need them for the majority of fixes.


  13. ABC says:

    Hi Crish,

    Really very much Thanks for your reply. ya I could understand what you mean to say. why I was wondering is lot of issues are displyaing in the tool and not affecting the functionality of app. So for these kind of issues no need to bother and if any work around is needed have to take a help from the developers and there is no shim work around for these, it’s gud.

    I request you, if you have any other forums or blogs or any links where I can get much info. to dig into these concept, please forwrd me.



  14. ABC says:


    Just I want to know is there anyway to identify the Web application issues with out using the IECT Tool.

    I heared there is one way, let me expalin you first.

    1) while creating Data Collection Package, we will be getting an option " updating to new Internet Explorer version". If we select this option it will capture Internet compatibility evaluator.

    2) Then install the Data Collection package. and now open IE browser and run the web application.

    Now I dont know will it capture the web application issues or not? if so then what is the use of IECT Tool.?

    Pls can you give me the reply ASAP. It’s important to me.



  15. cjacks says:

    You can install the IE evaluator as part of a Windows Vista DCP, but it only works downlevel. All that the IECTT does is install the IECE and let it do the work. So, the difference between the tools is that one has to be explicitly started and stopped, and the other runs in the background and goes away when you configure it to do so. There is no other difference – use them based on how you want to interface with the collecting tool.

  16. ABC says:

    Thanks, now I am clear about the difference.

    But as you said, if we run as a part of the DCP it will capture only the downlevel, what does it mean exactly?( I mean what kind of base level issues will it capture?)

  17. cjacks says:

    ABC –

    I mistyped. Must have been in a hurry. The IE Compatibility Evaluator only runs on a system that is running IE7, because it depends on the logging implemented by IE7. So it does *not* run downlevel.

    I must have been tired that day…


  18. ABC says:

    nopblm, I can understand how much busy you are.

    So you mean to say, It will capture full-fledged results of IE compatibility. (means it will capture in and out of IE compatibility issues)

    Even I tried with both the options

    1) Running as a part of DCP

    2) Running with IECT Tool

    I could see the same kind of results in both the ways. I did not find any difference.


  19. cjacks says:

    yes, they are the exat same code. The results will be the same.

Skip to main content