And, when you double click on the status bar, you will see the below window depending on the version of IE you are running:
Internet Explorer 8
Internet Explorer 7
Let’s go ahead, and look at the line of script reported in the error by opening up the HTML source(right click in the browser and choose view source) sent by the server to the client, and see what’s present at the line number 47, and char 1. You will see the below:
Interestingly this is not something which you wrote yourself on the page, but this is added at the runtime by the ASPX handler which served your page, and this is done by the server side ScriptManager you have in your ASPX page.
If you search for ‘Sys’ in your HTML source, you might not find it. Because this is something which is sent to the client from a different file which is included in the HTML source. You might see the below (with a different value for the query string d) in the page:
Let’s now see how to troubleshoot this problem we are facing. First thing to check is the IIS logs where all the requests with the corresponding response status would be logged. Below is the corresponding log for ScriptResource.axd on the server.
2009-02-26 21:00:28 W3SVC1 GET /AJAXTimer/ScriptResource.axd d=9tk5luWIQHpRBi2jvaLA3ovu_ryV3iBlv84cuaA3MT–_e3q9KdLubgmmRoMp9ixB0N1se3B9f-x_KQriM4xUb90HPABW5aUQb_PG3gbAH41&t=556b0a58 80 – 22.214.171.124 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+.NET+CLR+1.1.4322) royalchallenger 404 0 2 1405 567 15
So, we know for sure that the server is sending a HTTP 404 (Page not found) for the AXD request. Below are some possible reasons why a 404 might be sent from the server:
- File doesn’t exist on the server
- There is no ISAPI extension configured to serve this request
- An ISAPI filter plugged in the request pipeline sends a 404 for some reason
- URLScan rules might prevent it
- “Verify that file exist” is selected for the ISAPI extension configured to serve the request
- ISAPI Extension configured for the request (.axd in this example),is a prohibited web service extension
If you are running IIS7 (and above), you should consider using FREB for 404 errors, and from the logs you will be able to know which module is setting the 404.
If you check if there is a file named ScriptResource.axd is present in the website folder, I’m sure you will be surprised to see none. Because, ScriptResource.axd is a file which would be generated by the ASP.NET runtime on the fly, and would be sent to the client.
In one of plenty issues I’ve worked on AJAX, my customer was having a wild card ISAPI extension which on sight was advised for removal by me as a troubleshooting step, but only after taking a backup of IIS configuration. After removing the ISAPI extension, it started working – AJAX scripts are been sent to the client without any problem.
But the ISAPI extension which my customer had seemed to allow the ASPX requests to be processed by aspnet_isapi.dll, but it wasn’t allowing .AXD requests. It was the “Verify that file exists” causing the trouble because there is no physical file called ScriptResource.axd.
If you are running into this problem, I would like you to check for the below things on the server.
- Check if .axd requests are mapped to the aspnet_isapi.dll
- In IIS6, you can check this in the Website properties –> Home Directory –> Configuration
- In IIS7, you can check this in Website Features View –> Handler Mappings
- Check if the web.config file has handler mappings added
- In IIS6 or (IIS7 classic mode), you might need to place this under <system.web/httpHandlers>
- In IIS7 (integrated mode), you might need to place this under <system.webServer/handlers>
You might also want to check this blog by Scott where he explains about xhtmlConformance, and problems of it with AJAX. You can choose to remove that line from the web.config, or can set the mode to “Transitional” instead of “Legacy”.