Getting (Some) Virtualization Data from the Internet Explorer Compatibility Test Tool

If you run the Internet Explorer Compatibility Evaluator on Windows Vista, you get back some data when an ActiveX control tries to write to a file that a standard user used to be able to write to. However, that data doesn’t show up when you are using the Internet Explorer Compatibility Test Tool.


It’s configured not to.


Um … I don’t know? (Perhaps because the quality of the output is qualitatively different than every other test in the tool?)

But I do know how to turn it back on.

Open up Notepad elevated, and then open up “C:Program FilesMicrosoft Application Compatibility Toolkit 5Internet Explorer Compatibility Test ToolIECEConfig.xml”.

If you then search for the word EXCLUDE, you’ll find this:


Just comment this out (or delete it) and we’ll stop excluding data from the view. Now your tool is configured to stop hiding data that must be useful. Is it perfect? Nope – it doesn’t collect it all. But at least it shows you what it did collect.

Why doesn’t it collect it all? I don’t know, but I can speculate. The Internet File System and Internet Registry are implemented on IE7 using shims (specifically, shims sitting in acredir.dll, such as RedirectFiles and RedirectRegistry). While most of IECE’s output is based on the browser itself, the browser would have to predict what the shim infrastructure was doing. While you can turn on shim diagnostics and pull some of this out depending on the debug spew and log spew the shim writer included, that really complicates things. So, unlike rules where the browser explicitly knows “hey, I’d have to do this bad thing which the following code will specifically prevent, better log it” here we have API interception happening at a completely different layer where the browser code would have to either attempt to predict (could have false outcome), hook into the shim infrastructure, or parse ACLs and duplicate security logic.

But the things we are detecting, we really ought to show, wouldn’t you agree?

Comments (5)

  1. ABC says:


    Now we are completely working only on web applications. So I guess this update will help us in our project.

    Now we are running all the applications in admin mode with the IECT tool. is it correct?( or do we need to test the applications in standartd user mode?, does it make any difference?)

    Please let me know about it.


  2. cjacks says:

    I would *not* run the browser as admin while testing. You want to run the tests in the configuration end users will be using it, and an admin browser isn’t a good idea for anybody. I don’t trust the entire Internet as admin on my box…

  3. ABC says:


    Admin user:

    sorry chris, Just I would like to reframe the question, I am not running my browser as admin instead I am directly logging into the machine as admin user then I am launching the IECT Tool and now browing the web application. is it correct?

    Standarad User:

    or do I need to log in as a standard user into the machine and then I have to open the IECT tool and have to run the applications.

  4. cjacks says:

    In general, you should always strive to test your applications in the same configuration that end users will be using the application wherever possible. If they’ll be standard users, then you should try to be also.