KB937143 breaks ASP to .NET COM interop - by ThoughtfulCoder

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


9
0
Sign in
to vote
ID 294241 Comments
Status Closed Workarounds
Type Bug Repros 7
Opened 8/20/2007 12:51:54 PM
Access Restriction Public

Description

This problem is happening on Windows Server 2003 with the latest service pack and MS updates.  The server has Internet Explorer 7 installed.  We applied MS update Security Update for Windows Internet Explorer 7 (KB937143) and then our web site would no longer load properly.  We get an error on the first line of ASP code loading one of our .NET COM objects using a Server.CreateObject call.  Just to be clear this is not ASP.NET, but classic ASP.  At some point we want to convert the old ASP code, but that is on the backlog :-)

Our environment is ASP pages which load .NET COM objects to perform data access and such. This version of the site has been in production for over a year now.   We are using the .NET Framework 2.0.  I created a very simple .NET COM object and try to load it from a very simple ASP page and it fails.

If we uninstall the KB937143 update then everything works fine.

It seems strange an IE7 update is affecting .NET interop to ASP, but it is.

I've attached sample code.

I'm not sure if this is an ASP issue or a .NET issue.  It could be coming from either side. 

Another note, as a test I created a COM object using VB6 and it worked fine with KB937143 installed.
Sign in to post a comment.
Posted by Orange Peel90 on 11/30/2011 at 5:43 AM
So, this problem is back!

Windows Server Standard 2008

Service Pack 2

...but not fixed by any of the workarounds.

We have both the app pool & web site running as (the same) domain service account.
Posted by dukeEB on 11/16/2011 at 12:01 PM
Even if the urlmon is newer than what is in the hotfix, the Feature Control Key (FCK) is still present in urlmon. You will not need to update urlmon, but you must add the FCK from the hotfix article to resolve the issue.

Posted by Jordan Rieger on 10/22/2009 at 4:59 PM
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.
Posted by Microsoft on 8/1/2008 at 4:38 PM
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.
Posted by lseangel on 4/28/2008 at 2:58 PM
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...
Posted by JiriZ1 on 4/3/2008 at 11:53 AM
I had to set read for IUSR on whole HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Then it worked.
Posted by lseangel on 11/8/2007 at 12:47 PM
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
Posted by Cloaked Alien on 10/22/2007 at 6:52 AM
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.
Posted by iisdev on 10/2/2007 at 12:43 AM
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.
Posted by nmackenzie on 9/6/2007 at 11:21 AM
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.
Posted by ThoughtfulCoder on 8/30/2007 at 11:00 AM
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 :-)
Posted by nmackenzie on 8/30/2007 at 9:59 AM
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
Posted by Garry Lindsay on 8/30/2007 at 9:48 AM
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!
Posted by Garry Lindsay on 8/30/2007 at 9:44 AM
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!
Posted by Eric Lacroix on 8/28/2007 at 5:33 AM
Same issue here we are not able to access some COM object from Asp and Asp.Net
Posted by johnlau64534578 on 8/24/2007 at 10:05 PM
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?
Posted by chili on 8/23/2007 at 11:41 PM
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.
Posted by ThoughtfulCoder on 8/22/2007 at 6:19 AM
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?
Posted by Microsoft on 8/21/2007 at 10:38 PM
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.
Posted by Microsoft on 8/20/2007 at 8:06 PM
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.