О некоторых проблемах установки обновлений для .Net Framework

 

Не так давно вышли обновления KB2518870 и KB2478663 для .Net Framework 4. Как обычно сначала они появились на сайте Windows Update, а чуть позже появились они и на WSUS сервере. Как показала практика, установка этих обновлений в большинстве случаев проходит  успешно, но иногда возникают проблемы: ежедневные циклические попытки установки. Это сильно замедляет работу компьютера и вызывает недовольство пользователей.

Поиск решения в Интернете показал, что рекомендуется выполнить восстановление для .Net Framework 4. Сделать это можно через Панель управления. Находим в списке установленных программ .Net Framework 4, выбираем  «Установка/Удаление» для запуска установщика, а после его запуска выбираем режим «Восстановление». После завершения работы установщика переходим в Центр обновлений и запускаем установку обновлений – теперь обновления KB2518870 и KB2478663 устанавливаются нормально.

Но выполнять вручную такие действия на многих компьютерах слишком долго и трудоемко. Попробуем автоматизировать процесс. В Интернете есть очень полезная страничка по установке/переустановке/удалению любых версий .Net Framework. Взятая оттуда нужная нам команда выглядит так:

%windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

Для удаленного выполнения этой команды используем WS—Management (WinRM):

winrs -r:<ComputeName>  %windir%\Microsoft.NET\Framework64\v4.0.30319\SetupCache\Client\setup.exe /repair /x86 /x64 /ia64 /parameterfolder Client /q /norestart

К моему удивлению процесс восстановления .Net Framework в этом случае (удаленный запуск через WinRM) показал ошибку в журнале сообщений (источник Windows Error Reporting):

Контейнер ошибки , тип 0

Имя события: VSSetup

Ответ: Нет данных

Идентификатор CAB: 0

 

Сигнатура проблемы:

P1: Microsoft .NET Framework 4 Client Profile Setup

P2: 4.0.30319

P3: 10.0.30319.1

P4: 3

P5: Windows6.1-KB958488-v6001-x64.msu

P6: Repair_I_Silent_Error

P7: 0x5

P8: 0

P9: unknown

P10:

 

Вложенные файлы:

C:\Users\sie\AppData\Local\Temp\Microsoft .NET Framework 4 Client Profile Setup_20110628_090036892.html

C:\Users\sie\AppData\Local\Temp\Microsoft .NET Framework 4 Client Profile Setup_20110628_090036892-MSI_netfx_Core_x64.msi.txt

 

Эти файлы можно найти здесь:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Critical_Microsoft .NET F_8f22e62a32eb79ce7d44f8bc364c71574dfbf1_cab_0d66d5fe

 

Символ анализа:

Повторный поиск решения: 0

Идентификатор отчета: be1c3c2e-a135-11e0-b914-00252204071b

Состояние отчета: 4

 

После нескольких неудачных попыток устранения этой ошибки с компиляцией обновления KB958488, я просто попробовал установить обновления KB2518870 и KB2478663 через Панель управления – обновления установились успешно! Остальные компьютеры обновились автоматически в назначенное политикой для Automatic Update время.

Значит предложенное решение полностью работоспособно, а предложенная схема применима к устранению проблем с другими обновлениями для .Net Framework любых версий. (Посмотрим что будет когда появятся новые обновления для .Net Framework 4)

Полезные ссылки:

1.       Установка/переустановка/удаление любых версий .Net Framework http://blogs.msdn.com/b/astebner/archive/2009/04/16/9553804.aspx

2.       Настройка WS-Management (WinRM) http://msdn.microsoft.com/en-us/library/aa384372(VS.85).aspx

Реклама

Еще раз о Group Policy Preferences и нацеливании на 32-bit и 64-bit системы

Почти год назад в статье Group Policy Preferences –как различить 32-bit и 64-bit системы я писал о том, что Group Policy Preferences (GPP) можно нацеливать на системы разной архитектуры, но существует баг, который надо учитывать. В той же статье описаны два способа обхода бага: с помощью WMI и с помощью анализа ветки реестра.

Баг небольшой и поэтому я даже не надеялся, что его будут исправлять. Но разработчики Windows нашли время и выпустили заплатку KB2460922 для систем Windows 7. К сожалению это пока только хотфикс, что не очень удобно для его распространения, но уже что-то. Выпуск хотфикса Как минимум говорит о том, что, во-первых, GPP становится все более популярной, и во-вторых, что фикс войдет в следующий сервис пак.

Самое интересное, что в статье KB2460922 указан еще один способ обхода проблемы. Предлагается анализировать переменную окружения Processor_Architecture, которая должна быть равна AMD64 на 64-bit системах.

Объективный анализ характера ввода-вывода в Windows 7

Сейчас не редкость виртуальные машины Windows 7. При разворачивании их на системах виртуализации образы виртуальных машин размещаются на сетевом хранилище. Чем больше виртуальных машин, тем выше нагрузка на систему хранения данных, а ее ресурсы ограничены. Более того чем выше требования к пропускной способности хранилища, тем оно дороже. Поэтому критически важно снижать нагрузку на систему хранения со стороны виртуальных машин.

Все это верно и для больших систем с сотнями виртуальных машин, и для совсем маленьких (даже персональных компьютеров). Впрочем это верно и для обычных физических, не виртуальных, конфигураций.

Но прежде чем что-то настраивать и тем более оптимизировать, надо понимать суть происходящих процессов при операциях ввода-вывода. Сейчас я хочу показать лишь один момент среди целого каскада факторов, которые влияют на производительность системы ввода-вывода.

Вопрос, ответ на который я хотел получить:  какой размер блока ввода-вывода (IO block size) в Windows 7?

Почему возник такой вопрос?

Гостевая операционная система это источник всех операций ввода-вывода (если ее выключить, то останется только служебный трафик системы виртуализации, который должен быть в этой ситуации около нуля).

Поэтому характер операций ввода-вывода гостевых операционных систем будет определять характер нагрузки на систему хранения.

Для получения объективных данных я провел простой эксперимент по копированию большого файла (2 Гб) между локальным виртуальным диском в виртаульной машине с Windows 7 и папкой на сетевой шаре. Первый замер сделан при копировании на виртуальную машину – это операция записи на виртуальный диск. Второй замер был сделан для обратной операции: файл копировался с виртуальной машины на сетевую шару – операция чтения с виртуального диска.

Результаты приведены ниже.

 

Диаграмма 1. Windows 7 запись большого файла (копирование с сетевой шары на локальный диск)

 

Диаграмма 2. Windows 7 чтение большого файла (копирование с  локального диска на сетевую шару)

 

На обоих графиках видно, что размер блока чаще всего попадает в хорошо известные нам числа – 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536,… и 1048576 (1 Мб). Некоторые размеры блоков, как видно на графиках, очень популярные.

Факт первый: операции чтения и операции записи идентичны в мысле ответа на наш вопрос – вид графиков одинаковый.

Факт второй: Максимальный размер блока операции ввода-вывода в Windows 7 равен 1 Мб.

Факт третий. Windows 7 не использует один размер блока для операций ввода-вывода

               

Давайте посмотрим что будет в случае копирования (возьмем только запись – при чтении, как мы поняли, будет аналогичная картина) большого числа маленьких файлов. Копируем рабочую папку, в которой находятся несколько тысяч документов MS Office типичного размера плюс небольшое количество каких-то более крупных файлов.

 

Диаграмма 3. Windows 7 запись большого количества маленьких файлов (копирование с сетевой шары на локальный диск)

Что мы видим в этом случае?

Факт первый. Гистограмма сосредоточена в области маленьких размеров блока ввода-вывода.

Факт второй. Пики приходятся на размеры 4096 (4Кб), 16384, 65536 (64Кб), 262144 и 1048576 (1 Мб). Причем размер 4096 явный лидер.

Факт третий. Обратите внимание на пик 4Кб полученный при копировании маленьких файлов. Ничего не напоминает? Смотрим KB140365: обычный размер кластера NTFS 4Кб! Виртуальный диск, на котором проводился эксперимент, имеет именно такой размер кластера.

Теперь на основе полученных фактов можно сделать некоторые выводы.

Вывод первый: Ядро Windows 7 использует для конкретной операции ввода-вывода максимально возможный размер блока.

Получается, что Windows 7 передает драйверу физической системы ввода-вывода информацию максимально возможного размера и выравнивает ее всегда на удобную границу, например, в 4Кб, 16Кб, 64Кб, 1Мб. И теперь только от драйвера зависит насколько эффективно он выполнит задание.

Вывод второй: Ядро Windows 7 выполняет операции ввода-вывода максимально эффективно.

 

Заключение: полученные объективные данные по характеру ввода-вывода в Windows 7 можно использовать для объективного анализа системы ввода-вывода в физической системе (локальный ввод-вывод), в системе виртуализации (виртуализация дисков в виртуальной машине) или сетевой системе ввода-вывода (SAN).