WebResource.axd or ScriptResource.axd not working

Http compression with client-side scripting should be handled with care. The problem can have different symptoms and manifest in different ways, but essentially it has a common root cause and I have already discussed some of the aspects (for example see here and here). This time the customer whom reported the problem was using Forms Authentication in his application so the first time an unauthenticated user browsed it, he was redirected to the login page configured in web.config. So far so good.

In this case the problem was a javascript error notified by the standard yellow icon in the bottom left corner of IE; the error was an “Object expected” on “WebForm_AutoFocus()” which is a method generated by ASP.NET as a result of an object.SetFocus() call on the server-side.

Some quick theory

WebResource.axd and ScriptResource.axd are Http Handlers used by ASP.NET and Ajax to add client-side scripting (usually javascript) to the outgoing web page for example to have client-side input validation, set the focus on a specific control (as in this example) etc… Note that if you search your disk for .axd files, you’ll not find them; they are created on the fly in memory and executed from there.

Well, this is not completely true… if you want to have a look at them you can search the IE temporary cache on your client, you’ll likely find quite a few instances of WebResource.axd and ScriptResource.axd, but you’ll not find them on the server to be used by IIS.


At this point I already had some suspects but still no real clue, so let’s go hunting for them.

First thing is to check if you are using HTTP compression: if you do, test if disabling it resolves the problem:

HTTP compression in IIS 6.0


Another possibility is that the application mappings are not configured correctly (try with “aspnet_regiis –i”) or for some reason for the extension .axd the flag “Verify that file exists” flag has been set: if it is, remove it.

Verify that file exists for .axd


Anyway everything looked good on the faulting server so far… So next step is to have a look at the IIS logs.

Using LogParser you can quickly check what IIS returns when it comes to serve WebResource.axd (or the handler you’re looking for):

    "select distinct sc-status, count(*) as hits from *.log 
    where index_of(to_lowercase(cs-uri-stem), 'webresource.axd') > 0 
    group by sc-status order by hits desc" -i:iisw3c

Result? Every time WebResource.axd is requested, IIS returns a 404 (File not Found):

sc-status hits 
--------- ----
404       306


This time let’s check the Wildcard application mappings… If you have your IIS Manager at hand, give a quick look at the following screenshot:

Wildcard application maps in IIs 6

Otherwise if you are like me and have only the IIS metabase at hand, you can have a look at the ScriptMaps elements you have in there:


Pay attention to the last entry:


What is important here is the “Flags” part: “4” means “The server attempts to access the PATH_INFO portion of the URL, as a file, before starting the scripting engine. If the file can't be opened, or doesn't exist, an error is returned to the client”.

Here we are again… Check and clear the flag “Verify that file exists” for your wildcard application mapping. The point is that a wildcard ISAPI extension intercepts all requests and is executed as the first step for every of them; since WebResource.axd does not exist as a file on disk, IIS will not find it, will return a 404 error and will abort the request without passing it to aspnet_isapi.dll for further handling.

Verify that file exists for wildcard app maps


This error can con in different forms, sometimes obvious and sometimes not so obvious; but when “dynamic” resources come into the field, spending a couple of minutes to take case of HTTP compression and Application Mappings configuration can save you from complains by your users and hours of troubleshooting and headaches…



Quote of the day:

The folly of mistaking a paradox for a discovery, a metaphor for a proof, a torrent of verbiage for a spring of capital truths, and oneself for an oracle, is inborn in us. - Paul Valery

Comments (3)

  1. Icefront says:

    Thanks for the article.

    I was looking for a way to create an msi installer which

    creates an additional script map to some virtual directory.

    The script map maps some extension to the aspnet_isapi.dll. However, i noticed that on my computer

    (XP), the extension is created with the "verify that file exists" checkbox not checked, while on some other servers (2003 server) the check box is checked.

    I’ll try to fiddle with the flags part.

    Do you know what other flag options exists and what do they mean?

  2. Adrian says:

    Thanks so much for this article. We’ve been banging our heads against this problem for months. It was that last little step that we’ve been missing, checking the wildcard file exists flag. As soon as that was unticked at the root and propagated down everything worked fine.

  3. Dyte says:

    Yes! This helped me to solve my problem. Thanks a lot!

Skip to main content