See KB 922780: Error message when a CGI program that is written by using the .NET Framework 2 makes Web service calls: "System.ArgumentException: Illegal characters in path"
and the associated blog post. Your code is failing during a call to GetCurrentDirectory, just like the one in the blog post.
I'm not sure you need to reach for ADPlus just yet - what he found using ADPlus, you already know - namely that the most likely culprit is something which is changing the current directory.
A key point seems to be that IISReset cures the problem for a time, but the problem comes back after some point, as soon as something happens on one of the sites on the server. By "sites" here, I assume you mean ASP.NET application - please confirm if this isn't the case.
The act that multiple sites are exhibiting the problem indicates that the problem could well be an ISAPI filter or extension, or an .EXE file which is mapped to a wildcard mapping on one or more specific ASP.NET applications.
So, fire up IIS Manager, and update your question with information on ISAPI filters and wildcard mappings. The ISAPI filter information will be in the "ISAPI Filters" tab on the Properties dialog box for the web site (under "Web Sites" in the tree view in IIS Manager). The wildcard mappings will be in the "Application Configuration" dialog which you invoke from the "Configuration..." button on the Properties dialog for your specific ASP.NET application.
As well as wildcard mappings, see exactly what mappings are registered against .aspx extensions, and report those in your update.
The problem could also be in HttpHandlers installed in individual ASP.NET web sites - so look in the <httphandler> section in Web.config to see if a handler is defined with something like
<add verb="*" path="*.aspx" type="..." />
This may be on an application which is other than the one you're working with. To see if you can track down which one, check the server logs after an IISReset to see which is the first entry to return a 5xx HTTP status code (indicating an internal server error) and look at the request which triggered it. The application which handled it may be the one to focus on.
All the things I've suggested should be safe to do on a production server :-) I'm not suggesting you actually do an IISReset, just check the logs immediately after the last one you did.
Update: I've seen the updated information you posted. It might be ISAPI_Rewrite3 or not; I've certainly used it before without any problems. However, I'm surprised to see the ASP.NET_2.0.xxx in the ISAPI filters list - I don't have it in mine (I'm running Windows Server 2003). So, I would (when time permits - you may have to schedule an outage) temporarily remove those two ISAPI filters from the list (in such a way that you can easily restore them again) and see if that makes a difference. If it seems to have gotten worse, add the ASP.NET filter back in (what's the exact path of that entry?) and leave out ISAPI_Rewrite3, then try again.
The reason I'm surprised to see an ASP.NET DLL in the ISAPI filters list is that it's normally configured using the mappings on a per-application basis (where the applications inherit a default configuration). It normally works as an ISAPI extension, not an ISAPI filter.
Can you also please check the <httpmodules> sections in the same way as for <httphandlers>?
It may be necessary to run aspnet_regiis again, which initialises the ASP.NET system for IIS; This is, however a big step that could break lots of things. If possible, copy the entire server to a spare machine on a separate test or dev network and do it there. Can you use your local mirror for this kind of testing?
In Global.asax put 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; }