Skip to content
April 10, 2013 / ahriman hpc mode

Windows Azure Troubleshooting Guide

Этот гайд будет пополняться по мере решения проблем, возникающих при работе с Windows Azure. Всё пока абсолютно неструктурировано, структуры будут добавлены позже, когда проблем станет достаточно много.

Проблема: При запуске проекта в локальном эмуляторе вычислений возникает ошибка There was an error attaching the debugger to the IIS worker process for URL ‘http://127.0.0.1:5100/’ for role instance  ‘deployment(591).sx.Webrole1.0.

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

Возможные пути решения:

1) При появлении проблемы не нажимать ОК, а перейти в IIS и обновить список сайтов. В списке должен появиться запускаемый сайт. Обращаю внимание, что у меня эта проблема возникала в том числе и из-за того, что старое развертывание некорректно убивалось и сайт оставался жить. Удаление старого сайта помогало. Если же сайт один, попробуйте нажать на Browser *.[порт] в окне Actions. Если сайт откроется, должна будет выведена уже информативная ошибка.

2) Переустановка Azure SDK.

3) Переход в режим Hostable Web Core – необходимо закомментировать элемент Sites в файле ServiceDefinition.csdef.

4) В IIS перейти на вкладку Application Pools и на каком-либо пуле нажать Set Application Pool Defaults… и указать Enable 32-Bit Applications в True.

5) Проверка web.config на элементы-дубликаты и в принципе ошибки.

6) Снятие флажка Encrypted в свойствах папки проекта.

7) Снятие атрибута debug-true в разделе compilation в web.config либо снятие флажка Enable Diagnostics в свойствах облачной роли.

8) Перенос проекта в другую папку (особенно если проект находился на сетевом диске).

Проблема: При запуске проекта в локальном эмуляторе вычислений возникает ошибка There was an error attaching the debugger to the IIS worker process for URL ‘http://127.255.0.0:82/’.

Возможное описание проблемы: Ошибка похожа на свою подругу, но первое, что должно броситься в глаза – это странный IP-адрес. DNS, hosts и прочее, относящееся каким-бы то ни было образом к разрешению имён, здесь ни причем. Локальный эмулятор вычислений использует свою собственную реализацию балансировщика нагрузки, которая привязывается на 127.0.0.1:80 (или 81, или 82). Windows Azure Tools же для каждого экземпляра веб-роли создаёт виртуальный IP-адрес, который, собственно, и выглядит как 127.255.0.Х (Х – 0, 1, 2, 3 и так далее). Как только вы запускаете отладку, браузер открывает http://127.0.0.1:80 – адрес балансировщика нагрузки, который переводит запрос на IIS и 127.255.0.Х:YY.

Возможные пути решения:

1) Если совсем срочно, то к веб-роли можно обратиться по ее адресу 127.255.0.Х. Однако таким образом обходится балансировщик нагрузки. В случае наличия множества экземпляров можно воспользоваться кодом ниже для того, чтобы определить, какой из экземпляров имеет какой адрес.

public override bool OnStart()
{
Trace.WriteLine(“IP Address: ” + RoleEnvironment.CurrentRoleInstance.InstanceEndpoints[“Endpoint1”].IPEndpoint.Address.ToString());
Trace.WriteLine(“Port: ” + RoleEnvironment.CurrentRoleInstance.InstanceEndpoints[“Endpoint1”].IPEndpoint.Port);
return base.OnStart();
}

2) Очистка решения (Clean).

3) Переустановка Windows Azure Tools & SDK.

4) Установка скрипта в автозагрузку, который включает поддержку 32-битных приложений. Подробнее: http://blogs.msdn.com/b/zxue/archive/2011/10/31/enabling-support-for-32-bit-iis-applications-in-windows-azure.aspx

5) Посмотреть наличие ошибок в %UserProfile%\AppData\Local\dftmp\IISConfiguratorLogs\IISConfigurator.log.

6) Переход в режим Hostable Web Core – необходимо закомментировать элемент Sites в файле ServiceDefinition.csdef.

7) Aspnet_regiis –I на 4-й Framework.

8) Как последняя мера – переустановка IIS.

Проблема: При настроенном SSO оно не работает – появляется окно «введите свои учетные данные» при том, что пользователь уже вошел в систему под доменной учетной записью. Не получается ни в Internet Explorer, ни в Firefox/Chrome.

Возможное описание проблемы: Если всё настроено и аутентификация работает, то проблема в отсутствии SSO может заключаться в отсутствии сервера AD FS в зоне Local Intranet Sites в Internet Explorer. В других же браузерах проблема немного другая – они не поддерживают Kerberos (из коробки).

Возможные пути решения:

1) IE: добавить сервер AD FS в зону Local Intranet Sites. В домене может возникнуть еще одна проблема – список настроек IE управляется администратором. При этом, даже если в Default Domain Policy указать список сайтов, эти сайты не появляются у клиента. Появление сайтов блокируется фичей IE ESC, которая отключается в Server Manager во вкладке Security Information.

2) Firefox: необходимо перейти на страницу about:config, после чего найти настройки network.negotiate-auth.delegation-uris и  network.negotiate-auth.trusted-uris и указать в качестве их значения адрес AD FS сервера.

3) Chrome: необходимо запустить браузер следующей командой: google-chrome –auth-server-whitelist=”адрессервераADFS”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: