![]() |
Tuesday, March 12, 2002 |
Been continuing to work the last few days on getting this load problem figured out. After creating network traces with Network Monitor it appears that in "some" cases when loading a control it sends a GET request for the assembly with a Range: 8096- header which appears to attempt to retrieve the assembly from byte 8096 onward. This is close to where the manifest appears in most assemblies so this may be the goal. The weird thing is that it doesn't do this with 100% of the controls in IE. I have two controls right now and one of them it does this with. The other it doesn't. Very, very strange. Next used Anakrino, a great tool to track down what .NET does behind the scenes. IE uses a piece called IEHost to place the control into IE. You can throw this thing into debugging mode by editing HKEY_LOCAL_MACHINESoftwareMicrosoft.NETFramework and adding a DWORD value DebugIEHost = 1. This will cause it to create a file IEHost.logX which will log some information about what is happening behind the scenes. It ends up looking like this: IEHost.Log1 After seeing this I used Anakrino to track the problem down to occuring in this line of code: System.AppDomain.CreateComInstanceFrom(this._assemblyName.CodeBase, this._typename); Problem was once I tracked this as far as possible it ended up calling an external function I have to assume is in the guts of the CLR called nLoad. This is the piece that determines what to do. I could be an interaction between this thing attempting to call into IIS and a thread in there blocking the next request for the actual DLL. I suspect this is as far as I can go without someone with inside knowledge checking it out. I sent it to some folks at MS so let's see if I get anything back... 8:21:49 AM ![]() |