...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
OK
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_USER\SOFTWARE\Microsoft\Windows\Internet Explorer\Main\FeatureControl\Feature_Enable_Compat_Logging\iexplore.exe = (DWORD) 1. Then, browse to some web sites which generate some issues (my trusty live.com 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.
First, I did a quick stack trace. Here's what I saw:
ChildEBP RetAddr
002bedec 79f071ac KERNEL32!RaiseException002bee4c 79f0a629 mscorwks!RaiseTheExceptionInternalOnly002bef10 7a71713e mscorwks!JIT_Throw002bef5c 7a659780 System_ni!System.Diagnostics.EventLog.get_OldestEntryNumber002bef5c 7a6597ff System_ni!System.Diagnostics.EventLog.StartListening002bef5c 7a655d33 System_ni!System.Diagnostics.EventLog.StartRaisingEvents002bef5c 03cd6018 System_ni!System.Diagnostics.EventLog.set_EnableRaisingEvents002befac 03cd52d0 TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.EventLogMonitor..ctor002befac 03cd040c TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm.InitializeDataProviders002befe0 03cd00b9 TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm..ctor002befe0 79e7c74b TestTool!Microsoft.ApplicationExperience.ApplicationCompatibilityToolkit.TestTool.MainForm.Main002beff0 79e7c6cc mscorwks!CallDescrWorker002bf070 79e7c8e1 mscorwks!CallDescrWorkerWithHandler002bf1b4 79e7c783 mscorwks!MethodDesc::CallDescr002bf1d0 79e7c90d mscorwks!MethodDesc::CallTargetWorker002bf1e4 79eefb9e mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot002bf348 79eef830 mscorwks!ClassLoader::RunMain002bf5b0 79ef01da mscorwks!Assembly::ExecuteMainMethod002bfa80 79fb9793 mscorwks!SystemDomain::ExecuteMainMethod002bfad0 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 HKLM\Software\Microsoft\Internet Explorer\Main\FeatureControl\Feature_Enable_Compat_Logging instead of HKCU. I had to do this on one configuration.
Hi,
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?
Thanks,
John.
simply uninstall sp1 update to get internet explorer working again
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!
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 - http://support.microsoft.com/KB/950923
Regards / Johan Arwidmark
Microsoft MVP - Setup / Deployment
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.
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.
Chris,
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)
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.
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. HKLM\software\microsoft\internetexplorer\main\feature_control\feature_object_caching\iexplore.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.
-ABC
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.
Chris
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...
Thnks
ABC
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 Files\Microsoft Application Compatibility Toolkit 5\Internet Explorer Compatibility Test Tool\IECEConfig.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.
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.
Chrish,
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.
Regards
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.