.NET Forum / .NET Framework / Interop / December 2007
80131534 error trying to instantiate interop com from asp
|
|
Thread rating:  |
Mark - 08 Nov 2007 19:47 GMT Hi...
One of my colleagues is have a problem that's driving him crazy.
We have a number of assemblies that expose some C# objects as COM. One particular one is throwing an 80131534 error on instantiation from an ASP page. The error message doesn't really say diddly about what it doesn't like, just that it can't make one of those objects.
We checked the registry, and it looks like it's registered fine. He made a little vbs script instantiating one of the objects and ran it from cmd, and that worked fine, so it seems like the plumbing is okay in general.
But we're at a loss why ASP is having trouble instantiating one of these. Does the old asp engine have a shadow cache somewhere that it could be wedged?
Thanks Mark
Phil Wilson - 08 Nov 2007 20:03 GMT I think that's the kind of type initialization error that you get when code in the constructor fails, so that's where I'd look.
 Signature Phil Wilson [MVP Windows Installer]
> Hi... > [quoted text clipped - 17 lines] > Thanks > Mark Walter Wang [MSFT] - 09 Nov 2007 01:55 GMT Hi Mark,
As Phil pointed out, the error is COR_E_TYPEINITIALIZATION, which means a .NET type failed to initialize.
You can also try to debug the ASP code:
#Mikhail Arkhipov (MSFT)'s WebLog : How to debug classic ASP pages in VS 2005 http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Walter Wang [MSFT] - 14 Nov 2007 03:18 GMT Hi Mark,
I'm writing to check the status of this post. Please feel free to let me know if there's anything else I can help. Thanks.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 05 Dec 2007 16:13 GMT Hi Walter, Phil...
Sorry I lost track of this thread. My co-worker came by yesterday and said it is still a problem.
To Phil's point, the argumentless constructor for the object really doesn't do anything (it sets 3 member variables to null) so it's hard to figure what would blow up about that.
I googled around a bit this morning and found a few articles suggesting it might be file system permissions and/or registry key permissions, so I tried putting IUSR_<host> in the administrator's group temporarily; it didn't help (do you have to reboot for that to take effect or would iisreset suffice?)
I found another article vaguely related saying that there could be some interaction with the timezone registry keys and to delete all zones that didn't have all 7 values. That didn't help.
I'm not sure what more I can find by attaching a debugger to the asp engine; I know the line of the Server.CreateObject() and it's just blowing up out of there.
I found another article saying that in some circumstances regasm doesn't set up all the right registry keys. But I went through all the reg keys and they all looked okay. The only difference I could see between the article I was reading and my setup was that they appeard to GAC their component while we don't; we had the Codebase reg value instead. But that file:/// path was correct both to the dll and tlb in the registry.
Any other ideas?
Thanks for your help Mark
> Hi Mark, > [quoted text clipped - 17 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 06 Dec 2007 08:56 GMT Hi Mark,
First, let's confirm some information:
* Does this issue occur everytime you try to instantiate the .NET component from ASP or does it occur intermittently? * Which .NET version are you using to compile the .NET component? * I assume you're using IIS 6.0, do you have other websites configured to run in the same application pool as this ASP website?
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 06 Dec 2007 14:56 GMT Hi Walter...
This error occurs every time we try to instantiate the object in ASP, but not in a separate snippet of vb script run at the command line. It's also occurring with some of our .Net COM objects and not others. As mentioned before, the object ASP fails to instantiate for me has a constructor that does no work that could blow up (initializing 3 members to null). The only other possibility is that maybe there's some base class constructor doing something to explode.
We're compiling/running with VS 2005/.Net framework 2.0.50727 in dev. The same code apparently is being set up with .net 1.1 in our production environment (where there have been no reported problems)
Most of our development machines are XP Pro, so most developers are using single-site IIS 5. We do have one developer using Vista, so he's got IIS 6 and he's seeing the problem too.
Any ideas would be appreciated.
Thanks Mark
> Hi Mark, > [quoted text clipped - 16 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 10 Dec 2007 06:50 GMT Hi Mark,
Here's my understanding and summary of the issue so far:
1) You are running ASP.NET 2.0 on Windows XP 2) You registered .NET 2.0 assembly as COM-visible and it's working correctly if you invoke it using a simple script and execute it using an interactive user account 3) Your ASP script cannot access the COM server and it returns error E_COR_TYPEINITIALIZATION.
Please try following tests and let me know the results:
* Try to create a new and simple class library in .NET 2.0 and register as COM-visible and have a test in the ASP script; if this works, it proves the issue is related to your specific assemblies * Try to configure your IIS worker process to run under the user account that you were using to log in interactively, this might prove if it's related to the user account or permission.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 10 Dec 2007 14:25 GMT Hi Walter...
Additional bits of information mentioned earlier: 1) We have other C# objects exposed as COM and those are working in ASP
2) I had tried earlier putting IUSR_<machine> in the admin group but that didn't change the symptoms.
I tried your suggestions and found no change.
New bit of information: 1) Our production environment is 2003 Server, and all our .net com objects are working there.
Any new ideas would be helpful
Thanks Mark
> Hi Mark, > [quoted text clipped - 26 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 12 Dec 2007 04:00 GMT Hi Mark,
Thanks for the updated information. Honestly I don't have further ideas on what might be wrong without getting a reproducible project and debugging it.
If it's ok and the C# project isn't very big or dependent on other projects, maybe you could send me the project for further investigating.
Otherwise, I'm afraid you will need to contact our Customer Support and Service which can provide live (remote) debugging or dump analysis.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 12 Dec 2007 14:59 GMT How would one go about trying to attach a debugger on a C# object exposed as COM? If the thing is in-proc and I set my IIS isolation to low and I pre-load the C# dll, would I be able to attach to inetinfo.exe and set breakpoints?
Given this is coming out of the instantiation I may not even get to my C# class code, but it would be worth a shot.
Thanks Mark
> Hi Mark, > [quoted text clipped - 17 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 14 Dec 2007 05:48 GMT Hi Mark,
Here's how I setup remote debugging to debug the C# assembly that is called by ASP code:
Configuration:
Server "V1": Windows 2003, IIS 6.0, installed .NET 2.0 Client "H3": Windows XP, Visual Studio 2008
1. Create ClassLibrary1 on H3, enable "Make assembly COM-Visible" and "Register for COM interop"; with Class1 as following:
namespace ClassLibrary1 { public class Class1 { public string Hello() { return "Hello"; } } }
2. Install Visual Studio Remote Debugger (you can find the installation files from your Visual Studio 2005/2008 setup disk) on V1, configure it to use a service account that is part of Administrators group.
3. Copy over the generated .dll, .pdb, .tlb files from H3 to V1, run %windir%\Microsoft.NET\Framework\v2.0.50727\regasm.exe /codebase <path_to_ClassLibrary1.dll> to register it on V1
4. Create test.asp on V1:
<% set x = CreateObject("ClassLibrary1.Class1") %> <%= x.Hello() %>
5. Create a dummy ASP.NET 2.0 website in the same application pool as the ASP website and create a dummy ASP.NET WebForm in it (This step is required to make sure the IIS worker process is recogonized as a managed process to successfully attach it in later steps)
6. Run command "iisreset" to make sure the IIS worker process is closed first; then visit the ASP.NET 2.0 WebForm first to make sure .NET 2.0 runtime is loaded into the worker process.
7. Test test.asp in browser to make sure it works.
8. On H3, in Visual Studio, select "Debug/Attach to Process...", input "V1" in the "Qualifier" field and click button "Refresh"; select w3wp.exe from the list (make sure its type is shown as "Managed,x86"; then click button "Attach".
9. Now if you add a breakpoint on the managed code and refresh the ASP page in browser, it should hit successfully.
Without steps 5 & 6, the w3wp.exe is not shown as managed type and we cannot make the breakpoints in managed code to be hit.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 19 Dec 2007 22:13 GMT Hi Walter...
I tried using your debugging steps here, with some modification. I don't have access to a 2003 box or IIS 6 from development. Our developers have XP/IIS 5.1, so I set the isolation level on my dev website to low and attached to inetinfo.exe.
I didn't get to any of the breakpoints, though, which makes me think there's something about the assembly load that's not working properly under the ASP environment.
I did find a few things with unrelated work, though.
In the deep, dark past someone made our release build process using Wix. The Wix project GACs all of our dlls. When they are all in the GAC, the C# COM objects work in ASP, too. This reinforces the concern that it's an assembly load issue with exposing the C# as COM.
For our debug build, however, the C# COM objects are regasm'd where the sit. In this case, the work with script from the command line but they don't instantiate from ASP.
I found this: http://msdn.microsoft.com/msdnmag/issues/06/03/TestRun/ a little project to map out some of the dependencies for assemblies.
Experimenting with this tool, I found that Assembly.LoadFrom(fileName) works, but when I go through the referenced assemblies and try to load them from the AssemblyName, it doesn't work unless the utility has all the dependent dlls in the local dir. To be expected I guess.
Not sure where to go further with this. Obviously there's something different happening with how IIS/ASP is instantiating the COM objects vs script at the command line. It sounds like it's some kind of permissions thing, but I've put IUSR_<machine> in the admin group and that didn't fix the problem.
If you think there's some other debug step I should take for IIS 5.1 (other than isolation low, attach to inetinfo.exe), I'd be happy to try it.
Thanks Mark
Walter Wang [MSFT] - 20 Dec 2007 08:48 GMT Hi Mark,
Thanks for the update.
Please use the Assembly Binding Log Viewer to see if there's any assembly loading issues:
#Junfeng Zhang's Windows Programming Notes : Fusion binding log and fuslogvw.exe http://blogs.msdn.com/junfeng/archive/2004/02/14/72912.aspx
You might also find following blog useful about Assembly.LoadFrom and COM interop:
#Junfeng Zhang's Windows Programming Notes : Assembly.LoadFrom http://blogs.msdn.com/junfeng/archive/2005/05/31/423340.aspx
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 20 Dec 2007 16:58 GMT Hi Walter...
Thanks for the blog pointers. I've been experimenting with Fusion, as the first link suggests. I was just looking at the 2nd blog about interpreting Fusion results and I find that others have seen the same symptoms though there wasn't really an answer as to why.
I turned Fusion to logging all binding events, and as people noted in the Assembly.LoadFrom discussion, I see 2 events/logs for each COM-enabled .Net assembly - 1 with the assembly full name, which invariably fails with the lookup paths it tried, and a 2nd called
WhereRefBind!Host=(LocalMachine)!FileName=(assembly.dll)
which invariably has the path from the CodeBase registry entry and says it succeeded.
The interesting thing is that this pattern *is the same* whether the C# COM invocation comes from the command-line executed script or from ASP. What makes that especially interesting is that the command-line executed script invocation *works* where the ASP blows up with an instantiation error.
I can send you the logs Fusion produced if you're interested, but there is definitely something different in the way ASP is binding these references compared to other ways of invocation.
Thanks Mark
> Hi Mark, > [quoted text clipped - 23 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Mark - 20 Dec 2007 17:10 GMT Hi Walter...
Another interesting side note... We have a C# COM object that is instantiated from C++ code in an ISAPI filter (also in inetinfo.exe). That invocation produces the same 2 log entries (first one saying lookup failed and the 2nd WhereRefBind saying it succeeded).
The interesting bit is that the C++ invocation in the ISAPI filter also succeeds in creating the object (like the commandline script) where the ASP blows up.
More breadcrumbs leading to what seems to be a bug in how ASP Server.CreateObject() is working when it instantiates C# com objects.
Thanks Mark
> Hi Mark, > [quoted text clipped - 23 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 21 Dec 2007 09:25 GMT Hi Mark,
I'm sorry that I didn't notice that you actually already mentioned you were using Server.CreateObject instead of using CreateObject directly. One difference between Server.CreateObject and CreateObject is that Server.CreateObject goes through MTS (COM+). I'm not sure if you need transaction support and requires using Server.CreateObject explicitly. If not, maybe you could have a try to use CreateObject directly.
#Should I use CreateObject or Server.CreateObject? http://classicasp.aspfaq.com/components/should-i-use-createobject-or-server- createobject.html
Please feel free to send me the fusion log file if needed.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Mark - 21 Dec 2007 14:26 GMT Hi Walter...
Thanks for the interesting article on the difference between CreateObject and Server.CreateObject. Unfortunately, it didn't make any difference in my situation. In ASP, either CreateObject or Server.CreateObject fails to instantiate the C# COM while everyone else succeeds.
The Fusion log still shows the same behavior in all cases - 2 logs get created, one for the assembly fullname, which always shows failure, and the WebRefBind for the same dll just after saying it succeeded. We get both these log entries whether the COM instantiation works (from C++ or with CScript) or doesn't (ASP). It still seems like ASP is doing something differently than all the others on the CreateObject call.
Thanks Mark
> Hi Mark, > [quoted text clipped - 21 lines] > > This posting is provided "AS IS" with no warranties, and confers no rights. Walter Wang [MSFT] - 25 Dec 2007 04:26 GMT Hi Mark,
Would you please send me the Fusion log files?
Thanks.
Regards, Walter Wang (wawang@online.microsoft.com, remove 'online.') Microsoft Online Community Support
================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|