KB937143 breaks ASP to .NET COM interop by ThoughtfulCoder

Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.

Unfortunately, we do not support Internet Explorer through this site. We recommend you try discussing this issue on the IE blog. Please see http://blogs.msdn.com/ie/ for more information.

Thank you,
Visual Studio Product Team.

I apologize if I didn't explain the problem clearly or I am misunderstanding. We do not have an issue with Internet Explorer. A patch for Internet Explorer broke IIS ASP to .NET COM interop. Would the Internet Explorer support team support .NET COM Interop?

Well I had precisely the same problem with my site. I stumbled on this link, uninstalled the update and so far so good. It is quite annoying this kind of issue, as it was holding our customers back from doing their work.

It is a sad reality that while I would love to be using a .NET 2.0 solution for our website - I have to make do with ASP VBSript with extra features using .Net via COM Interop for the time being.

We also had exactly the same problem on our server and the same solution worked for us too.

I thought the original developer was very clear in his or her description of the problem and solution. How can this site suggest that it does not support COM to .NET interoperability?

Same issue here we are not able to access some COM object from Asp and Asp.Net

I have exactly the same problem, and its not permissions on the .net DLL, help!!! I have noticed lots of people are having this problem. THe registry under manual inspection looks fine, yet vbscript just cannot see the dll!

IE7 patches could download a new vbscript/scripting library version that might have an issue looking at .net COM interop DLL's? I have the same issue, but it did work once, but doing a regasm on a newly compiled DLL again seemed to blow it up! I personally think its the registry getting messed up somehow, but manual inspection reveals no issues!

One point that no one has mentioned on this thread is that the problem goes away if IUSR_X is added to the Administrators group. Obviously, doing this is not a good workaround but it suggests that the problem is with permissions rather than with the registry

After getting back to this issue and searching around the internet I found what nmackenzie has found. It seems to be a permissions issue.

The following doesn't fix the original problem, but is a viable workaround. You can change the Application Pool identity to a custom account other than Network Service.

We run ASP alongside ASP.NET code so I went through a number of steps to get this working.

Please note we do not put our web servers on the domain, so this is all for a local account.

- Create a new user.
- Add the user to the IIS_WPG group.
- Give the user read&execute,list folder contents, and read access to your web application folder.
- Go into the group policy editor (run gpedit.msc) then navigate to Local Computer Policy/Computer Configuration/Windows Settings/Local Policies/User Rights Assignment. Add your user to Adjust memory quotas for a process, Generate Security Audits, Log on as a service, and Replace a process level token. Basically I decided to give my user everything assigned to Network Service.
- Run aspnet_regiis -ga <user> to grant all necessary rights for ASP.NET.
- I also needed to grant special rights to c:\windows\temp. You need List Folder / Read Data and Delete rights on this folder. You need to click on the Advanced button on the Security tab to get to special permissions. Our XmlSerializer would not work without these rights as it uses a temporary file for compilation.
- In IIS Manager go to the properties of the application pool you are using. Go to the identity tab, click the Configurable radio button, and enter your new user.

Here are some helpful links:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/12a3d96c-65ea-4210-96ad-86a801f6a88c.mspx?mfr=true
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f05a7c2b-36b0-4b6e-ac7c-662700081f25.mspx?mfr=true
http://beyondthispoint.blogspot.com/2006/04/setting-up-iis6-application-pool.html
http://msdn2.microsoft.com/en-us/library/ms998297.aspx

I hope this helps someone else :-)

A workaround to this problem has been <a href="http://tinyurl.com/3co6o9">posted</a> on the web. It involves changing the permissions on a single registry entry.

I am posting this for informational purposes since I have not tested the workaround. Furthermore, I do not know the security implications of changing the permissions on this registry entry.

Hello, I also stumbled upon this page when my COM Callable Wrapper (.Net 2.0, C#) stopped working within my ASP 3.0 pages. I have a different error that is being reported and while I'll don't have Internet Explorer 7 installed it looks like the KB update was also installed for Internet Explorer 6 as well. The error I receive is:

Server object error 'ASP 0177 : 800401f3'
Invalid class string

This only occurs when I try to create an instance of the assembly's class through ASP (.asp, in vbscript). Strangely however If I try to create the same instance using Windows Scripting Host (.vbs file) it works.

I don't know if this is related or not. This functionality in our web applications stopped working sometime in August, 2007.

I can confirm this issue. I have a very simple C# .NET 2.0 component being used from within ASP. It works fine but seems to break after a while, this happens on both 32bit and 64bit Windows 2003 enviroments.

I have been unable to verify a working workaround, but it would seem as reverting to .NET 1.1 possibly works in a 32bit enviroment.

This is currently causing a lot of problems in a very sensitive hosting enviroment where we don't have the possibility of playing around with security settings and uninstalling security updates.

An update or at least an acknowledgement from Microsoft would be wonderful at this point. I have also confirmed that the KB937143 Security Update caused this problem as uninstalling it removed the error. That is not the ideal workaround so we reinstalled the update (which broke it, of course) and then simply gave IUSR account read access to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones

I had to set read for IUSR on whole HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Then it worked.

I see there is now a hotfix available (KB945701) though not published.

Also wanted to note that the exact same problem just happened with our App in Server 2008/IIS7 and the same workaround fixed the problem. I simply had to give the IUSR account (or whomever the site is running as) Read access to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones
all fixed...

Hello, this was incorrectly assigned to the CLR team, this is actually an IE issue. I cannot assign this bug to IE since they use TFS for bug tracking.

Yesterday we did a Windows Update on our Windows 2003 SP2 server and it triggered this exact issue (but intermittently and only under moderate to heavy load.) We used the same registry permission workaround, but I am reporting it here because our urlmon.dll is already much newer than the version supplied in the hotfix at http://support.microsoft.com/kb/945701. It appears that one of the recent updates we installed from this list has re-injected this defect:

Security Update for Windows Server 2003 (KB954155)
Security Update for Windows Server 2003 (KB955069)
Security Update for Windows Server 2003 (KB956572)
Security Update for Windows Server 2003 (KB956802)
Security Update for Windows Server 2003 (KB956803)
Security Update for Windows Server 2003 (KB952004)
Security Update for Windows Server 2003 (KB957097)
Security Update for Windows Server 2003 (KB958469)
Security Update for Windows Server 2003 (KB958644)
Security Update for Windows Server 2003 (KB958687)
Security Update for Windows Server 2003 (KB958869)
Security Update for Windows Server 2003 (KB959426)
Security Update for Windows Server 2003 (KB960225)
Security Update for Windows Server 2003 (KB960803)
Security Update for Windows Server 2003 (KB960859)
Hotfix for Windows Server 2003 (KB961118)
Security Update for Windows Server 2003 (KB961371-v2)
Security Update for Windows Server 2003 (KB961501)
Update for Windows Server 2003 (KB967715)
Security Update for Windows Server 2003 (KB967723)
Update for Windows Server 2003 (KB968389)
Security Update for Windows Server 2003 (KB968537)
Security Update for Windows Server 2003 (KB968816)
Security Update for Windows Server 2003 (KB969059)
Security Update for Windows Server 2003 (KB970238)
Security Update for Windows Server 2003 (KB970483)
Hotfix for Windows Server 2003 (KB970653-v3)
Security Update for Windows Server 2003 (KB971032)
Security Update for Windows Server 2003 (KB971486)
Security Update for Windows Server 2003 (KB971557)
Security Update for Windows Server 2003 (KB971633)
Security Update for Windows Server 2003 (KB971657)
Security Update for Windows Server 2003 (KB971961)
Security Update for Windows Server 2003 (KB973354)
Security Update for Windows Server 2003 (KB973507)
Security Update for Windows Server 2003 (KB973525)
Security Update for Windows Server 2003 (KB973540)
Update for Windows Server 2003 (KB973815)
Update for Windows Server 2003 (KB973825)
Security Update for Windows Server 2003 (KB973869)
Security Update for Windows Server 2003 (KB974112)
Security Update for Windows Server 2003 (KB974455)
Security Update for Windows Server 2003 (KB974571)
Security Update for Windows Server 2003 (KB975025)
Security Update for Windows Server 2003 (KB975467)
Security Update for Windows Server 2003 (KB952069)
Security Update for Windows Server 2003 (KB923561)
Security Update for Windows Server 2003 (KB951066)
Security Update for Windows Server 2003 (KB956844)

Please assign this issue to the correct team (email them manually if you have to :-) so that you can prevent it from re-injecting into further shipping patches or products.

Jordan Rieger
Software Developer
Ripe B2B Inc. for Webnames.ca Inc.

I found a simple workaround:

Give Everyone Read access to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones

I also made a .NET 2.0 executable that makes this change: http://www.frijters.net/MS07-045-patch.zip

Please use regmon and add permission for only the user who is getting access denied indicated in regmon log.

For more details check here
http://blogs.msdn.com/sukeshak/

Safest workaround:
Give the IUSR (or whoever your site is running as) read access to HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones - this key might change depending on who your app pool is running as (default is Network Service [aka S-1-5-20])

Other workarounds:
- Uninstall KB937143
- Add IUSR (or whoever your site is running as) to the Local Administrator group

Add IUSR to the Local Administrator group is not recomended....