After installing MS07-045 Cumulative Security Update for Internet Explorer - CreateObject call fails with 8000ffff
We have noticed an issue of CreateObject call failure after installing MS07-045 IE update. This issues goes away if you uninstall the patch. As per the information available it's happening only when .NET managed component (using interop) is called from an ASP page.
Error shown in the browser looks like below
Server object error 'ASP 0177 : 8000ffff'
Server.CreateObject Failed
/hellocom.asp, line 2
8000ffff
Repro steps given below
- Install MS07-045 security patch
- Create a .NET managed component (helloworld.dll)
- Make it COM visible and register it using "regasm helloworld.dll /codebase"
- Create an ASP page (inside your website folder) which calls this component using CreateObject (hellocom.asp)
- The page fails with the error mentioned above
For repro and testing I'm attaching following repro files
- helloworld.dll (managed component)
- hellocom.asp (which uses the above component using CreateObject call)
Code inside helloworld.dll
using System;
using System.Collections.Generic;
using System.Text;
public class HelloWorldClass
{
public HelloWorldClass()
{}
public String SayHello()
{
return "Hello World!";
}
}
Code inside hellocom.asp
<% 1:
2: Set hello = Server.CreateObject("HelloWorldClass")
3: Response.Write hello.SayHello()
%>
In my repro I get access denied for these registry keys for IUSR account
Till an official update is available on this issue, please run regmon and fix the permission issues shown in the logs. Please give permission to only the user account shown in regmon logs and not for everyone group since it would increase security risk.
For testing if the permission requirement is only for IUSR account, add IUSR account to administrators group and test. In my case it works and confirms that it's missing permission only for IUSR. This step is for only for testing and needs to be reverted immediately.
Uninstalling this patch is not recommended since it's a security update.
Comments
Anonymous
November 06, 2007
We encountered the same issue, but resolved it by GAC'ing the interop assembly that was failing. The problem seems to be CAS related and running the assembly as Full Trust sorted it. Obviously that approach isn't suitable for all scenarios - ours is a shared assembly with a fixed interface and it doesn't do anything naughty, so it fits the bill - but it is another workaround to bear in mind.Anonymous
November 07, 2007
Thanks David for the pointer and workaround. The issue is actually with how url's are handled by urlmon related to different zones. IE Dev is working on the bug.Anonymous
November 08, 2007
THANK YOU! We've been encountering this issue for a couple of months and now finally know what caused it. Uninstalling the security update verified this. Since that is not the best option, put it back on and just decided to give the IUSR account read access to the necessary reg keys until there is a fix. From what I've seen online there has yet to be any official acknowledgement from Microsoft on this. Any updates that you're aware of?Anonymous
November 14, 2007
Since I don't work in IE team, I'm trying to get a status of this issue now. Will update this blog once I get that.Anonymous
December 19, 2007
This issue has a hotfix now with KB 945701. KB is getting cooked and might take some more days.Anonymous
December 19, 2007
I had reported an issue which happens after installing MS07-045 IE security update. "After installingAnonymous
December 19, 2007
I had reported an issue which happens after installing MS07-045 IE security update. "After installingAnonymous
April 01, 2008
Following seems to help to a similar problem: Create a new user and make it a member of IIS_WPG (IIS 6.0) or IIS_IUSRS (IIS 7.0). Create an application pool. Change the application pool's Identity to the new user. Change the application pool for web application in question to the new application pool. Change the web application's anonymous user to the new user.Anonymous
April 14, 2008
Hakan, If you are facing the issue mentioned on this post please call PSS and get the hotfix. What you have mentioned would give the new user higher priviledge which is not a workaround/resolution for the issue mentioned above.Anonymous
April 29, 2008
I see there is now a Hotfix available for this which I'm sure is specific to Server 2003/IIS6. I just wanted to note that I just experienced the exact same issue in Server 2008/IIS7. As soon as I gave the IUSR Read access to HKEY_USERSS-1-5-20SoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones and error went away. Must say I'm surprised this issue followed through to 2008/IIS7Anonymous
April 29, 2008
The comment has been removedAnonymous
April 30, 2008
Thank you for the update! I apologize for my incorrect assumption that it was tied to Server or IIS vesrion. I'd forgotten that the issue only occured after installing IE7 (was fine with IE6).Anonymous
May 03, 2008
The comment has been removedAnonymous
September 04, 2008
Hi, this post helped me fix the described issue by granting IUSER read access to the HKEY_USERSS-1-5-20SoftwareMicrosoftWindowsCurrentVersionInternet SettingsZones key, but do you have a link to the hotfix mentioned for Server 2003/IIS6? Thanks!Anonymous
September 06, 2008
Scott, You can open a hotfix case with PSS (no charges) to get the fix. Check the update on the issue here... http://blogs.msdn.com/sukeshak/archive/2007/12/20/IE_2D00_Fix_2D00_945701.aspx