Пустой файл .net, генерирующий ошибку «Недопустимые символы в пути»

Question

У меня полностью пустой файл ".aspx", находящийся на веб-сервере IIS6. На сервере установлен .net 3.5.

При выполнении этот файл генерирует ошибку «Недопустимые символы в пути». Полная трассировка стека этой ошибки доступна здесь .

Проблема может быть временно устранена с помощью IISReset. Однако, как только любой сайт на этом сервере начинает показывать эту проблему, каждое попадание на каждую страницу .aspx на этом сайте вызовет ту же проблему (включая мой полностью пустой файл примера).

Что может быть причиной, и как я могу это исправить?

Редактировать : Я добавил вознаграждение в надежде получить дополнительную помощь, прежде чем мы откроем дело о поддержке в Microsoft. Я видел статьи в базе знаний и в блоге , на которые указал Адам Хьюз, но эта информация сама по себе не предлагает полного решения. Блог написан для людей, которые обладают знаниями и навыками, которых мне не хватает, но, видимо, мне нужно подобрать. Мне нужна помощь в понимании некоторых связей и рассуждений, происходящих здесь.

Я специально ищу помощи по любому из этих вопросов, какие из них приведут меня к функционирующей системе:

1. В обход статьи базы знаний я выбрал программу CGI, исполняемую на шестом шаге. Что я должен выбрать здесь? Должен ли процесс отладки, описанный в блоге, привести меня к поиску какой программы выбрать для этого?

2. В блоге рассказывается о способах отладки, но предполагается, что у меня есть знания, которых у меня нет (пока). Хотя я сделал вывод, что мне понадобится ADPlus , я никогда не использовал этот инструмент или иным образом не нуждался в проверке дампа памяти раньше. Я не уверен, что делать, когда автор говорит это:

   Со временем нажима на не много потерять я пошел на живой отладки подход. Таким образом, благодаря проблема легко воспроизводима в на этот раз я скоро получил необходимое дамп памяти.

   Как мне использовать ADPlus (или любой другой инструмент) для генерации дампа памяти, и как мне убедиться, что он содержит информацию, необходимую мне для отладки этого? Будет ли "adplus -crash -iis" делать то, что я хочу?

3. Проблема возникает на рабочем сервере. Несмотря на то, что я могу перезагрузить этот сервер, если мне действительно это нужно, я должен по возможности избегать перебоев в работе. Безопасно и разумно ли создавать дамп памяти на живом сервере? Повлияет ли это на другие функции сервера, и если да, то на что мне обратить внимание?

4. Звучит так, будто я на правильном пути? На какие другие пути я должен смотреть, чтобы решить эту проблему?

Редактировать: Vinay, вот информация, которую вы запрашивали, включая фильтры ISAPI и сопоставления с подстановочными знаками:

_{(источник: photobooks.com )}

_{(источник: photobooks.com )}

Полный путь к файлу, связанному с файлами .aspx: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll.

У нас есть зеркало этого сервера в нашей локальной сети. Я смог использовать это для поиска по всем экземплярам web.config, и я не нашел ничего необычного. На самом деле, похоже, что мы никогда не используем этот раздел web.config, так как все записи были идентичны этому:

<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>

Глядя на это, мне кажется, что я должен с подозрением относиться к ISAPI_Rewrite3 , который мы в настоящее время используем для поддержки "дружественных" URL-адресов на некоторых сайтах ASP Classic. Это тоже ваш диагноз? Правильно ли я считаю, что «исправление» этой проблемы будет означать замену ISAPI_Rewrite3?

Редактировать: Я удалил запись ASP.NET из списка фильтров ISAPI. Полный путь для этого был C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll. Нет очевидных побочных эффектов от удаления этого. MSDN заявляет , что он используется для поддержания состояния сеанса без файлов cookie, что в любом случае не является жизненно важным для этого сервера.

Прошло несколько часов, и проблема не возникла после удаления фильтра ASP.NET. К сожалению, у меня нет средств воспроизвести проблему, кроме как ждать ее повторения. Я оставлю это до завтрашнего вечера. Если проблема повторится, я также уберу фильтр ISAPI_Rewrite3 и попробую еще раз (к счастью, функциональность этого фильтра широко не используется нашими клиентами). В любом случае, я вернусь и сообщу о своих результатах.

Я проверил секцию в соответствии с запросом. Все такие записи во всех файлах web.config на этом сервере идентичны этому примеру:

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

Спасибо за вашу помощь!

Answer 1

Я пока не уверен, что вам нужно обратиться к ADPlus - то, что он обнаружил с помощью ADPlus, вы уже знаете - а именно, что наиболее вероятный виновник - это то, что меняет текущий каталог.

Ключевым моментом, по-видимому, является то, что IISReset устраняет проблему на некоторое время, но проблема возвращается через некоторое время, как только что-то происходит на одном из сайтов на сервере. Под «сайтами» здесь я предполагаю, что вы имеете в виду приложение ASP.NET - подтвердите, если это не случай.

То, что проблема возникает на нескольких сайтах, указывает на то, что проблема может быть связана с фильтром или расширением ISAPI или файлом .EXE, который сопоставлен с символом подстановки в одном или нескольких конкретных приложениях ASP.NET.

Итак, запустите IIS Manager и обновите свой вопрос информацией о фильтрах ISAPI и сопоставлениях с подстановочными знаками. Информация о фильтре ISAPI будет находиться на вкладке «Фильтры ISAPI» в диалоговом окне «Свойства» для веб-сайта (в разделе «Веб-сайты» в древовидном представлении в диспетчере IIS). Подстановочные сопоставления будут отображаться в диалоговом окне «Конфигурация приложения», которое вы вызываете с помощью кнопки «Конфигурация ...» в диалоговом окне «Свойства» для вашего конкретного приложения ASP.NET.

Как и сопоставления с подстановочными знаками, точно посмотрите, какие сопоставления зарегистрированы для расширений .aspx, и сообщите о них в своем обновлении.

Проблема также может быть в HttpHandlers, установленном на отдельных веб-сайтах ASP.NET - поэтому посмотрите в разделе <httphandler> в Web.config, чтобы увидеть, определен ли обработчик с чем-то вроде

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

Это может быть приложение, отличное от того, с которым вы работаете. Чтобы узнать, можете ли вы отследить, какой из них, проверьте журналы сервера после IISReset, чтобы увидеть, какая из записей первой возвращает код состояния HTTP 5xx (указывающий на внутреннюю ошибку сервера), и посмотрите на запрос, который его вызвал. Приложение, которое обработало это, может быть тем, на котором сосредотачиваются.

Все, что я предложил, должно быть безопасно на производственном сервере :-) Я не предлагаю, чтобы вы на самом деле делали сброс IIS, просто проверяйте журналы сразу после последнего, который вы сделали.

Обновление: Я видел обновленную информацию, которую вы разместили. Это может быть ISAPI_Rewrite3 или нет; Я, конечно, использовал его раньше без проблем. Тем не менее, я удивлен, увидев ASP.NET_2.0.xxx в списке фильтров ISAPI - у меня его нет (у меня Windows Server 2003). Таким образом, я бы (если позволит время - вам может потребоваться запланировать отключение) временно удалил эти два фильтра ISAPI из списка (таким образом, чтобы вы могли легко восстановить их снова) и посмотрел, имеет ли это значение. Если кажется, что ситуация ухудшилась, добавьте фильтр ASP.NET обратно (каков точный путь к этой записи?) И пропустите ISAPI_Rewrite3, затем повторите попытку.

Причина, по которой я удивляюсь, что ASP.NET DLL в списке фильтров ISAPI заключается в том, что она обычно настраивается с использованием сопоставлений для каждого приложения (где приложения наследуют конфигурацию по умолчанию). Обычно он работает как расширение ISAPI , а не как фильтр ISAPI .

Можете ли вы также проверить <httpmodules> разделы так же, как для <httphandlers>?

Может потребоваться снова запустить aspnet_regiis, который инициализирует систему ASP.NET для IIS; Это, однако, большой шаг , который может многое сломать. Если возможно, скопируйте весь сервер на запасной компьютер в отдельной тестовой сети или в сети разработчиков и сделайте это там. Можете ли вы использовать свое локальное зеркало для такого рода испытаний?

Answer 2

См. КБ 922780 : сообщение об ошибке, когда программа CGI, написанная с использованием .NET Framework 2, выполняет вызовы веб-службы: «System.ArgumentException: недопустимые символы в пути»

и связанный пост в блоге . Ваш код терпит неудачу во время звонка на GetCurrentDirectory, точно так же как тот в сообщении в блоге.

Answer 3

В Global.asax поставить следующее:

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;
}