Скорее всего, потому что один или несколько компонентов, используемых Вашим приложением, является 32-разрядным.
Или, потому что один или несколько компонентов, используемых Вашим приложением, не найдены при переключении режима App Pool из-за их разрядности и перенаправления файловой системы.
Вообще говоря, IIS будет делить Модули и Обработчики в 32-и 64-разрядные двоичные файлы, и препятствовать тому, чтобы одна разрядность или другой видели другую разрядность с bitness32 или bitness64 предварительными условиями.
Пример вершины головы:
Если Вы изменяете пул приложений на 32 бита, имеете в виду:
тот же модуль/обработчик мог бы иметь запись как это:
Который будет только работать, если something32.dll будет в Программных файлах (x86).
Журналы событий должны помочь Вам разыскать, какой модуль проблематичен, если это - модуль или отказ загрузки обработчика.
Если Ваши модули или обработчики не указывают предварительное условие разрядности и могли бы использовать различные пути, когда выполнено от другой разрядности из-за перенаправления, у Вас есть своя проблема. (журналы событий будут обычно указывать на Вас на то, чему не удалось загрузиться, когда Пул приложений не запустится).
См. также:
Использование WMIC кажется более надежным (хотя и не идеальным). Вот что я в итоге использовал:
wmic /node:"%WEB_SERVER_MACHINE_NAME%" /namespace:\\root\WebAdministration path ApplicationPool where name='%APP_POOL_NAME%' call start
wmic /node:"%WEB_SERVER_MACHINE_NAME%" /namespace:\\root\WebAdministration path ApplicationPool where name='%APP_POOL_NAME%' set AutoStart=true