...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_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.

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 HKLM\Software\Microsoft\Internet Explorer\Main\FeatureControl\Feature_Enable_Compat_Logging instead of HKCU. I had to do this on one configuration.