Empty .net file generating the error "Invalid characters in the path"

Question

I have a completely empty .aspx file located on the IIS6 web server. The server has .net 3.5 installed.

When executed, this file generates an "Invalid characters in path" error. A full stack trace of this error is available here .

The problem can be temporarily fixed using IISReset. However, as soon as any site on this server starts showing this problem, every hit on every .aspx page on this site will cause the same problem (including my completely empty example file).

What could be causing this, and how can I fix it?

Edit : I added a reward in the hope of getting more help with this before we open a support case with Microsoft. I saw a knowledge base article and a blog post that Adam Hughes pointed to, but this information alone does not offer a complete solution. The blog is written for people who have the knowledge and skills that I lack, but apparently I need to pick up. I need help understanding some of the connections and reasoning taking place here.

I specifically seek help on any of these issues that will lead me to a functioning system:

1. Bypassing the knowledge base article, I chose the CGI program, which is executed in the sixth step. What should I choose here? Should the debugging process described in the blog lead me to finding which program to choose for this?

2. The blog post talks about debugging methods, but it is suggested that I have knowledge that I don’t have (yet). Despite the fact that I came to the conclusion that I will need ADPlus , I never used this tool or otherwise did not need to check the memory dump before. I'm not sure what to do when the author says this:

   Over time, squeezing not so much to lose, I went for a lively debugging approach. Thus, thanks to a problem that is easily reproducible at present, I soon got the necessary memory dump.

   How can I use ADPlus (or any other tool) to create a memory dump, and how can I make sure that the memory dump contains the information needed to debug this? Will adplus-crash -iis do what I want?

3. The problem occurs on the production server. Despite the fact that I can restart this server, if I really need it, I should avoid interruptions whenever possible. Is it safe and reasonable to dump memory on a live server? Will this affect other server features, and if so, what should I look for?

4. Does it sound like I'm on the right track? What other ways should I look to solve this problem?

Edit: Vinay, here is the information you requested, including ISAPI filters and wildcard mappings:

_{(source: photobooks.com )}

_{(source: photobooks.com )}

The full path to the file associated with the .aspx files: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll .

We have a mirror of this server in our local network. I was able to use this to search all instances of web.config, and I did not find anything unusual. Actually, it looks like we never use this section of web.config, since all the entries were identical to this:

 <httpHandlers> <remove verb="*" path="*.asmx"/> <add verb="*" path="*.asmx" validate="false" type="..." /> <add verb="*" path="*_AppService.axd" validate="false" type="..."/> <add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type="..." /> </httpHandlers> 

Looking at this, it seems that I should be suspicious of ISAPI_Rewrite3 , which we currently use to support "friendly" URLs on some ASP Classic sites. Is that your diagnosis too? Do I think that correcting this problem will mean replacing ISAPI_Rewrite3?

Edit: I removed the ASP.NET entry from the ISAPI filter list. The full path for this was C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll . There are no obvious side effects from removing this. MSDN claims that it is used to maintain session state without cookies, which in any case is not vital to this server.

Several hours passed and the problem did not occur after removing the ASP.NET filter. Unfortunately, I have no means to reproduce the problem, except to wait for its recurrence. I'll leave it until tomorrow evening. If the problem persists, I will also remove the ISAPI_Rewrite3 filter and try again (fortunately, this filter functionality is not widely used by our clients). In any case, I will return and report on my results.

I checked the <httpModules> section as requested. All such entries in all web.config files on this server are identical to this example:

 <httpModules> <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> </httpModules> 

Thank you for your help!

Answer 1

I’m not sure that you still need to contact ADPlus - what he found using ADPlus, you already know, namely, that the most likely culprit is that it changes the current directory.

The key point is that IISReset heals the problem for a while, but the problem occurs after some time, as soon as something happens on one of the sites on the server. By "sites" here, I assume that you mean an ASP.NET application - please confirm if this is not the case.

The operation of several sites demonstrates the problem that the problem can be a filter or an ISAPI extension or an .EXE file that maps to wildcard matching in one or more specific ASP.NET applications.

So, start IIS Manager and update your question with information about ISAPI filters and wildcard mappings. Information about the ISAPI filter will be located on the ISAPI Filters tab in the Properties dialog box for the website (under the Websites section in the tree structure of IIS Manager). The wildcard mappings will be in the Application Configuration dialog box that you call from the Configuration ... dialog box in the Properties dialog box for your specific ASP.NET application.

As well as wildcard mappings, see what mappings are registered with the .aspx extensions and report this in your update.

The problem could also be with the HttpHandlers installed on separate ASP.NET websites, so look in the <httphandler> section of Web.config to see if a handler is defined with something like

 <add verb="*" path="*.aspx" type="..." /> 

This may be an application other than the one you are working with. To find out if you can track which one, check the server logs after IISReset to see which one is the first to return an HTTP 5xx status code (indicating the internal server error) and see the request that caused it. The application that processes it may be focused on.

Everything that I suggested should be safe to do on the production server :-) I do not suggest that you really do IISReset, just check the logs immediately after the last one.

Update: I saw the updated information you posted. It can be ISAPI_Rewrite3 or not; Of course, I used it without any problems. However, I am surprised to see ASP.NET_2.0.xxx in the ISAPI filter list - I don’t have it (I am running Windows Server 2003). Thus, I would (when time permits - you may have to schedule downtime) temporarily remove these two ISAPI filters from the list (so that you can easily restore them again) and see if this has changed. If it seems to get worse, add the ASP.NET filter back (which path to this entry?) And leave ISAPI_Rewrite3, then try again.

The reason I am surprised that the ASP.NET DLL in the ISAPI filter list is because it is usually configured using mappings for each application (where applications inherit the default configuration). It usually works as an ISAPI extension, not an ISAPI filter.

Can you also check the <httpmodules> sections in the same way as for <httphandlers> ?

You may need to run aspnet_regiis again, which initializes the ASP.NET system for IIS; This, however, is a big step that can break a lot of things. If possible, copy the entire server to a spare machine in a separate test or dev network and do it there. Can you use a local mirror for such testing?

Answer 2

See KB 922780 : Error Message When a CGI Program Written Using the .NET Framework 2 Invokes Web Service Calls: "System .ArgumentException: Illegal Characters in the Path"

and related blog post . During the GetCurrentDirectory call, your code does not work, as in the blog post.

Answer 3

In Global.asax enter the following:

 private static string EnvironmentDir = null; void Application_Start(object sender, EventArgs e) { EnvironmentDir = System.Environment.CurrentDirectory; } void Application_BeginRequest(object sender, EventArgs e) { System.Environment.CurrentDirectory = EnvironmentDir; }