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?