This bug is due to the IUSR (or whoever) not having permissions to the component.
Here's a list of work arounds...
http://connect.microsoft.com/VisualStudio/feedback/details/294241/kb937143-breaks-asp-to-net-com-interop
mmodral wrote:
80131534 error trying to instantiate interop com from asp
08-Nov-07
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
Previous Posts In This Thread:
On Thursday, November 08, 2007 2:47 PM
mmodral wrote:
80131534 error trying to instantiate interop com from asp
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
On Thursday, November 08, 2007 3:03 PM
Phil Wilson wrote:
I think that's the kind of type initialization error that you get when code in
I think that is the kind of type initialization error that you get when code
in the constructor fails, so that is where I'd look.
--
Phil Wilson
[MVP Windows Installer]
On Thursday, November 08, 2007 8:55 PM
wawan wrote:
Hi Mark,As Phil pointed out, the error is COR_E_TYPEINITIALIZATION, which
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:
2005
http://blogs.msdn.com/mikhailarkhipov/archive/2005/06/24/432308.aspx
Regards,
Walter Wang (***@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.
On Tuesday, November 13, 2007 10:18 PM
wawan wrote:
Hi Mark,I'm writing to check the status of this post.
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 (***@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.
On Wednesday, December 05, 2007 11:13 AM
mmodral wrote:
Hi Walter, Phil...Sorry I lost track of this thread.
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
""Walter Wang [MSFT]"" wrote:
On Thursday, December 06, 2007 3:56 AM
wawan wrote:
RE: 80131534 error trying to instantiate interop com from asp
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 (***@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.
On Thursday, December 06, 2007 9:56 AM
mmodral wrote:
Hi Walter...
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
""Walter Wang [MSFT]"" wrote:
On Monday, December 10, 2007 1:50 AM
wawan wrote:
RE: 80131534 error trying to instantiate interop com from asp
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 (***@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.
On Monday, December 10, 2007 9:25 AM
mmodral wrote:
Hi Walter...
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
""Walter Wang [MSFT]"" wrote:
On Tuesday, December 11, 2007 11:00 PM
wawan wrote:
Hi Mark,Thanks for the updated information.
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 (***@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.
On Wednesday, December 12, 2007 9:59 AM
mmodral wrote:
How would one go about trying to attach a debugger on a C# object exposed as
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
""Walter Wang [MSFT]"" wrote:
On Friday, December 14, 2007 12:48 AM
wawan wrote:
Hi Mark,Here's how I setup remote debugging to debug the C# assembly that is
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 (***@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.
On Wednesday, December 19, 2007 5:13 PM
mmodral wrote:
Hi Walter...I tried using your debugging steps here, with some modification.
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
On Thursday, December 20, 2007 3:48 AM
wawan wrote:
Hi Mark,Thanks for the update.
Hi Mark,
Thanks for the update.
Please use the Assembly Binding Log Viewer to see if there's any assembly
loading issues:
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:
http://blogs.msdn.com/junfeng/archive/2005/05/31/423340.aspx
Regards,
Walter Wang (***@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.
On Thursday, December 20, 2007 11:58 AM
mmodral wrote:
Hi Walter...Thanks for the blog pointers.
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
""Walter Wang [MSFT]"" wrote:
On Thursday, December 20, 2007 12:10 PM
mmodral wrote:
Hi Walter...Another interesting side note...
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
""Walter Wang [MSFT]"" wrote:
On Friday, December 21, 2007 4:25 AM
wawan wrote:
Hi Mark,I'm sorry that I didn't notice that you actually already mentioned you
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.
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 (***@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.
On Friday, December 21, 2007 9:26 AM
mmodral wrote:
Hi Walter...
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
""Walter Wang [MSFT]"" wrote:
On Monday, December 24, 2007 11:26 PM
wawan wrote:
Hi Mark,Would you please send me the Fusion log files?
Hi Mark,
Would you please send me the Fusion log files?
Thanks.
Regards,
Walter Wang (***@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.
Submitted via EggHeadCafe - Software Developer Portal of Choice
Build a Cross-Browser ASP.NET CSS-Only Menu UserControl
http://www.eggheadcafe.com/tutorials/aspnet/f32b452c-48ea-4ed8-96ce-d17d1b482676/build-a-crossbrowser-asp.aspx