In my previous entries I talked about the WinFX September CTP and Microsoft Max. Unfortunately after installing them on my system I was presented with a great error message:

This is the message you get when Max does something wrong and we don't have an explanation. We thought you'd prefer an honest answer instead of "Unknown error." Please start Max again. And hopefully we'll fix this problem in the next update.

I figured this was a problem with Microsoft Max so I left it as is. But today I wanted to do some development against the new WPF. So I fired up VS2005 plugged in some very basic code and hit F5. Bang.

Method not found: 'Void System.Runtime.ConstrainedExecution.ReliabilityContractAttribute..ctor(System.Runtime.ConstrainedExecution.Consistency, System.Runtime.ConstrainedExecution.CER)'.

What the? Upon inspection of my BCL I find the method .ctor on ReliabilityContactAttribute takes a second parameter of type System.Runtime.ConstrainedExection.Cer - not CER. Did I have a bad install? I uninstalled both WinFX, CLR 2.0. Reinstalled - same problem. Conclusion, there is bad IL floating around somewhere. I examine the stack trace. This looked interesting:

System.Windows.SystemResources.ResourceDictionaries.LoadThemedDictionary(Boolean isTraceEnabled)

Is it related to my theme? I changed from Energy Blue to Lua to Classic - no effect. Is there bad IL in the theme resources? I ILDASM'd all of the WPF assemblies, no problems there. Spent a bit more time looking at the stack trace. Dug in a bit deeper with ILDASM. Looks like WPF is trying to load some Theme specific BAML. Mapper is trying to resolve a type, XmlnsCache is passed an Assembly from somewhere and finally inside EnumerateXmlnsAttributes we see the call to GetCusomAttributes - which the top of where the failure is happening inside the BCL. So I make some basic assumptions. The bad assembly is not part of WPF. WPF is trying to resolve something and is looking at another bad assembly somewhere on my system. Another guess. It's probably in the GAC. I need to find the bad assembly. Can I enumerate the GAC from managed code and test them myself? Not sure. Quick MSN search turns up some examples in C++ using fusion.dll. But I'm too lazy to bother with that. Next best solution? Watch access to the filesystem. I grab Filemon from sysinternals.com and start tracing. This turns up some interesting results. XmlnsCache.dat - this looks good presumably matches up to the XmlnsCache.CreateUserCache in the stack trace. What follows in the file access trace is the system scanning through various assemblies in the GAC. Finally it stops, there is a bit of randomness and then this. The last file the system examined in the GAC before pulling in diasymreader.dll (the symbol reader to break back into debug mode) was Microsoft.SqlServer.Replication.dll. Is this the problem? Lets see:

C:\temp\unpack>copy c:\WINDOWS\assembly\GAC_32\Microsoft.SqlServer.Replication\9.0.242.0__89845dcd8080cc91\Microsoft.SqlServer.Replication.dll . 1 file(s) copied. C:\temp\unpack>ildasm /text /all Microsoft.SqlServer.Replication.dll > rep.txt C:\temp\unpack>dir 1,322,192 Microsoft.SqlServer.Replication.dll 18,208,613 rep.txt C:\temp\unpack>grep CER rep.txt valuetype [mscorlib/*23000001*/]System.Runtime.ConstrainedExecution.CER/*0100001B*/) /* 0A000014 */ = ( 01 00 01 00 00 00 01 00 00 00 00 00 ) valuetype [mscorlib/*23000001*/]System.Runtime.ConstrainedExecution.CER/*0100001B*/) /* 0A000014 */ = ( 01 00 01 00 00 00 01 00 00 00 00 00 )

Thats it allright! So I pulled it out of the GAC and.... same problem, different assembly. After locating and blowing them all away everything is fine!