Ars Longa, Vita Brevis » Windows http://blog.sjinks.pro Quod scripsi, scripsi Mon, 06 Feb 2012 17:56:02 +0000 en hourly 1 Несколько лёгких web-серверов для Windows http://blog.sjinks.pro/windows/377-several-lightweight-web-servers-for-windows/ http://blog.sjinks.pro/windows/377-several-lightweight-web-servers-for-windows/#comments Mon, 24 Nov 2008 05:17:15 +0000 Vladimir http://blog.sjinks.pro/?p=377 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Сборки , и для

В силу тех или иных причин многие web-разработчики работают под Windows: в силу привычки либо по каким-либо еще причинам. Но мир устроен так, что большая часть серверного программного обеспечения работает под UNIX/Linux.

Тем не менее, разработчикам хотелось бы иметь возможность тестировать разработки локально. Я не рассматриваю вариант с установкой виртуальной машины, ибо не все хорошо разбираются в Linux.

В статье про nginx я приводил примеры, когда необходимо использовать что-нибудь более легковесное, чем Apache. Но выбор не всегда ограничивается nginx, есть и другие лёгкие web-сервера.

Я собрал под Windows три web-сервера:

С nginx всё понятно, про него уже не раз писали. Но в поисках альтернативы nginx я случайно обнаружил тесты производительности web-серверов (хотя и 10-летней давности).

На диаграмме видно, что Zeus вне конкуренции. Но покупать его у меня не было желания, поэтому я стал рассматривать бесплатные альтернативы, а именно: thttpd и mathopd.

Для mathopd, thttpd и nginx я собрал версии под Windows (в ). Планирую собрать Boa, а для Cherokee есть сборка под Windows.

Скачать:

В архивы включены все (я надеюсь) требуемые динамически подключаемые библиотеки (DLL).

mathopd и thttpd, возможно, смогут работать и без установленного Cygwin, а nginx — вряд ли.

nginx конфигурировался следующим образом:

./configure --with-mail --with-mail_ssl_module --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_flv_module --with-http_gzip_static_module --with-http_stub_status_module

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/windows/377-several-lightweight-web-servers-for-windows/feed/ 11 Пять слов длиной в 56 мегабайт http://blog.sjinks.pro/windows/281-five-words-56-mb-length/ http://blog.sjinks.pro/windows/281-five-words-56-mb-length/#comments Wed, 30 Jul 2008 06:16:01 +0000 Vladimir http://blog.sjinks.pro/?p=281 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> За что я люблю

Всё-таки у Miscrosoft'овцев забавное чувство юмора… Дней двадцать назад вышло одно очень забавное обновление (KB955020) для системы проверки орфографии. Всё, что оно делает, это добавляет в словари английского и немецкого языка пять слов: название социальной сети Friendster, фамилии модели Heidi Klum, баскетболиста NBA Mohammed Nazr, политиков Barack Obama и Marc Racicot.

Всё бы ничего, только размер этого обновления составляет 56.4 МБ. Да и к тому же требует проверку подлинности .

KB955020

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/windows/281-five-words-56-mb-length/feed/ 0 Доказана критичность уязвимости в Safari для Windows http://blog.sjinks.pro/security/196-vulnerability-in-safari-for-windows-proves-critical/ http://blog.sjinks.pro/security/196-vulnerability-in-safari-for-windows-proves-critical/#comments Sat, 14 Jun 2008 21:12:43 +0000 Vladimir http://blog.sjinks.pro/?p=196 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Insecure By Design, или, Не там уязвимости ищите, товарищи!

Всё-таки как можно переставить всё с ног на голову… Прочитал сегодня статью на CNews.com; она небольшая, привожу полностью:

Исследователь безопасности разработал сайт, наглядно демонстрирующий риск, с которым сталкиваются пользователи при использовании браузера от Apple.

ИБ-команда уже предупредила, что «смешанная угроза» настолько серьезна, что пользователям Windows следует ограничить использование Safari до тех пор, пока не выйдет патч. В своем блоге исследователь Лю Ди Ю (Liu Die Yu) показал, что это предупреждение не было преувеличением.

При клике по указанной исследователем ссылке в Safari с настройками по умолчанию на рабочий стол пользователя Windows загружается файл-ловушка. В следующий раз, когда пользователь открывает Internet Explorer, файл автоматически запускает notepad.exe и открывает несуществующий файл. Разумеется, злоумышленники могут найти менее безобидное применение данной уязвимости, пишет The Register.

По словам Apple, не является критической. Эта демонстрация свидетельствует об обратном.

Вопросы, возникающие при прочтении:

  1. Если уязвим Safari, почему нужно запускать Internet Explorer? На мой взгляд, найденная "смешанная уязвимость" свидетельствует о том, что ограничить нужно как раз-таки использование Ишака, пока Micro$oft не выпустит патч.
  2. Фраза "следует ограничить использование Safari до тех пор, пока не выйдет патч" — это свидетельство нечестной борьбы — более честным было бы выложить описание как изменить настройки Safari, чтобы не подвергать риску уязвимости Windows.

Озвучив для себя эти вопросы, я решил найти оригинал статьи, благо это было нетрудно.

Две фразы, которые мне очень понравились:

  1. Microsoft used some vague wording in the advisory: "Suggested Actions" are "Restrict use of Safari as a web browser…", as if it's a flaw rooted in Safari.
  2. In sub-folder of "Suggested Actions" Microsoft admits "Workarounds" as Change the download location of content in Safari to a newly created directory. The full statement should be "Change the download location of content in Safari to a newly created directory(to save the integrity of Windows Internet Explorer)".

Причем, судя по всему, фраза "Change the download location of content in Safari" появилась только 6 июня (то есть почти через неделю после того, как статья была опубликована на сайте Microsoft).

Теперь несколько слов об уязвимости. Права ли Microsoft, обвиняя Safari в уязвимости? Я согласен, загрузка файла без разрешения пользователя — это не хорошо. Но что заставляет Internet Explorer открывать этот файл? Ответ прост: Windows. То есть уязвимость здесь в ядре Windows, даже не в Internet Explorer. Объясню почему. В своём тестовом примере Liu Die Yu показывает, что в том, что Internet Explorer запускает Блокнот, "виновато" имя файла, который Safari сохраняет — schannel.dll (также сработают sqmapi.dll и imageres.dll).

Причина уязвимости здесь заключается в порядке поиска динамических библиотек (кому интересны все технические подробности — читайте MSDN про функции LoadLibrary и LoadLibraryEx). Идея состоит в том, что LoadLibrary ищет загружаемую библиотеку в рабочем каталоге (перед тем, как искать ее в системном каталоге). При запуске Ишака с Рабочего стола рабочим каталогом является Рабочий стол (вполне логично). Далее IE загружает библиотеки, дело доходит до schannel.dll. Благодаря стараниям Safari, на Рабочем столе файл с таким именем имеется; в результате Windows загружает именно его. А он выполняет своё "черное дело".

В итоге получаем, что в ядро Windows эта уязвимость была встроена изначально — что называется, "уязвимость по дизайну". Я бы на месте Некрософт не баги бы в Safari искал (хотя молодцы, ничего не скажешь: обставили уязвимость в ядре так, что виноват оказался другой продукт), а свои собственные ошибки исправлял :-)

По сути дела, "уязвимой" может оказаться любая программа, которая положит что-нибудь на Рабочий стол. Кстати, и FireFox можно обвинить в "уязвимости", даже если он спросит пользователя о сохранении файла: многие пользователи очень доверчивы (к сожалению), и сохранят файл, если их попросят. А так как, по словам Microsoft, большинство пользователей оставляют настройки по умолчанию, то файл попадет на Рабочий стол.

Так что, господа Microsoft'овцы, исправляйте вы лучше свои ошибки, а не обвиняйте в них сторонние программы :-)

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/security/196-vulnerability-in-safari-for-windows-proves-critical/feed/ 5 Кто живёт у нас в системе, или, как просмотреть полный список сервисных процессов в Windows http://blog.sjinks.pro/c-cpp/69-who-lives-in-my-system-how-to-display-full-list-of-service-processes/ http://blog.sjinks.pro/c-cpp/69-who-lives-in-my-system-how-to-display-full-list-of-service-processes/#comments Sat, 05 Apr 2008 09:42:46 +0000 Vladimir http://blog.sjinks.pro/?p=69 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Маленькая программа для отображения полного списка установленных сервисных процессов

Не секрет, что список сервисных процессов (служб), отображаемый (например, при помощи консоли services.msc), является далеко не полным. Когда-то давно меня заинтересовало, как же можно посмотреть, какие службы/драйвера/системные процессы живут в системе.

Самое простое решение — открыть Редактор реестра (regedit) и посмотреть. Список сервисов и не только находится в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. Однако по тем данным, которые представлены в реестре, трудно определить, какая из служб работает в данный момент времени, чем она является (напрмер, драйвером ядра или драйвером файловой системы) и т.п.

В Windows Recovery Console есть команда, listsvc, позволяющая получить полный список сервисных процессов. Мне стало интересно написать что-то подобное, и вот результат:

  1. /*-------------------------------------------------------------------------*/
  2. #include <windows.h>
  3. #include <stdlib.h>
  4. #include <stdio.h>
  5. #include <string.h>
  6. /*-------------------------------------------------------------------------*/
  7. const char* unknown_error = "<Unknown error!>";
  8. const char* get_error_code(DWORD dwCode)
  9. {
  10.     const char* msgbuf;
  11.     return (!FormatMessage(
  12.                 FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM |
  13.                 FORMAT_MESSAGE_IGNORE_INSERTS, NULL, dwCode,
  14.                 MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR)&msgbuf,
  15.                 0, NULL
  16.              )
  17.            ) ? unknown_error : msgbuf;
  18. }
  19. /*-------------------------------------------------------------------------*/
  20. const char* servicetypes[] = {
  21.     "File System Driver",
  22.     "Kernel Driver",
  23.     "Own Process",
  24.     "Share Process",
  25.     "Unknown"
  26. };
  27. /*-------------------------------------------------------------------------*/
  28. const char* get_service_type(DWORD dwType)
  29. {
  30.     size_t i = 4;
  31.     if (SERVICE_FILE_SYSTEM_DRIVER == (dwType & SERVICE_FILE_SYSTEM_DRIVER)) {
  32.         i = 0;
  33.     }
  34.     else if (SERVICE_KERNEL_DRIVER == (dwType & SERVICE_KERNEL_DRIVER)) {
  35.         i = 1;
  36.     }
  37.     else if (SERVICE_WIN32_OWN_PROCESS == (dwType & SERVICE_WIN32_OWN_PROCESS)) {
  38.         i = 2;
  39.     }
  40.     else if (SERVICE_WIN32_SHARE_PROCESS == (dwType & SERVICE_WIN32_SHARE_PROCESS)) {
  41.         i = 3;
  42.     }
  43.  
  44.     return servicetypes[i];
  45. }
  46. /*-------------------------------------------------------------------------*/
  47. const char* states[] = {
  48.     "stopped",
  49.     "start pending",
  50.     "stop pending",
  51.     "running",
  52.     "continue pending",
  53.     "pause pending",
  54.     "paused",
  55.     "unknown"
  56. };
  57. /*-------------------------------------------------------------------------*/
  58. const char* get_state(DWORD dwState)
  59. {
  60.     --dwState;
  61.     if ((unsigned int)dwState > 6) {
  62.         dwState = 7;
  63.     }
  64.  
  65.     return states[dwState];
  66. }
  67. /*-------------------------------------------------------------------------*/
  68. int main(int argc, char* argv[])
  69. {
  70.     SC_HANDLE Handle;
  71.     BOOL Status;
  72.     LPENUM_SERVICE_STATUS Buffer = NULL;
  73.     DWORD BytesNeeded;
  74.     DWORD ServicesReturned;
  75.     DWORD ResumeHandle;
  76.     DWORD Error;
  77.     DWORD i;
  78.     const char* ErrCode;
  79.  
  80.     Handle = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT | SC_MANAGER_ENUMERATE_SERVICE);
  81.     if (NULL == Handle) {
  82.         ErrCode = get_error_code(GetLastError());
  83.         printf("Call to OpenSCManager failed: %s\n", ErrCode);
  84.         LocalFree((HLOCAL)ErrCode);
  85.         return EXIT_FAILURE;
  86.     }
  87.  
  88.     ResumeHandle = 0;
  89.     Status = EnumServicesStatus(
  90.         Handle, SERVICE_DRIVER | SERVICE_WIN32, SERVICE_STATE_ALL,
  91.         Buffer, 0, &BytesNeeded, &ServicesReturned, &ResumeHandle
  92.     );
  93.  
  94.     Error = GetLastError();
  95.     if (FALSE == Status && ERROR_MORE_DATA == Error) {
  96.         Buffer = (LPENUM_SERVICE_STATUS)calloc(BytesNeeded, 1);
  97.         if (NULL == Buffer) {
  98.             printf("Failed to allocate %ld bytes of memory!\n", BytesNeeded);
  99.             CloseServiceHandle(Handle);
  100.             return EXIT_FAILURE;
  101.         }
  102.  
  103.         Status = EnumServicesStatus(
  104.             Handle, SERVICE_DRIVER | SERVICE_WIN32, SERVICE_STATE_ALL,
  105.             Buffer, BytesNeeded, &BytesNeeded, &ServicesReturned, &ResumeHandle
  106.         );
  107.  
  108.         if (FALSE == Status) {
  109.             ErrCode = get_error_code(GetLastError());
  110.             printf("Call to EnumServicesStatus failed: %s\n", ErrCode);
  111.             LocalFree((HLOCAL)ErrCode);
  112.             free(Buffer);
  113.             CloseServiceHandle (Handle);
  114.             return EXIT_FAILURE;
  115.         }
  116.     }
  117.     else {
  118.         ErrCode = get_error_code(GetLastError());
  119.         printf("Call to EnumServicesStatus failed: %s\n", ErrCode);
  120.         LocalFree((HLOCAL)ErrCode);
  121.         CloseServiceHandle(Handle);
  122.         return EXIT_FAILURE;
  123.     }
  124.  
  125.     printf ("Service\tDisplay Name\tType\tState\n");
  126.  
  127.     for (i=0; i<ServicesReturned; ++i) {
  128.         printf ("%s\t%s\t%s\t%s\n",
  129.                 Buffer[i].lpServiceName, Buffer[i].lpDisplayName,
  130.         get_service_type(Buffer[i].ServiceStatus.dwServiceType),
  131.         get_state(Buffer[i].ServiceStatus.dwCurrentState));
  132.     }
  133.  
  134.     free(Buffer);
  135.     CloseServiceHandle(Handle);
  136.     return EXIT_SUCCESS;
  137. }
  138. /*-------------------------------------------------------------------------*/

Хотя это код трёхгодичной давности, работает до сих пор :-)

Скачать исходный код listsvc.
Скачать EXE-файл (7168 байт).

Сумма MD5 listsvc.exe: a04735a4ea104d96af78d234ae4e35b6
Сумма SHA1 listsvc.exe: 6d24bf22e48fc8f8e2b8a49f9fce51e973ff0a00

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/c-cpp/69-who-lives-in-my-system-how-to-display-full-list-of-service-processes/feed/ 0 Настройка nginx и PHP/FastCGI в Windows http://blog.sjinks.pro/windows/58-nginx-php-fastcgi-in-windows/ http://blog.sjinks.pro/windows/58-nginx-php-fastcgi-in-windows/#comments Fri, 28 Mar 2008 06:14:02 +0000 Vladimir http://blog.sjinks.pro/windows/58-nginx-php-fastcgi-in-windows/ © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Как настроить связку + в и не иметь головной боли.

Принято считать, что замечательный Web-сервер nginx работает только под Unix-подобными операционными системами. Верно, но лишь отчасти. nginx превосходно собирается и в . Возникает вопрос: а зачем это надо, собирать nginx под Windows? Ответ: я знаю достаточно много web-разработчиков, работающих в силу тех или иных причин под Windows. И в работе встречаются ситуации, когда на рабочей машине нужно создать конфигурацию, максимально похожую на конфигурацию сервера (production или development в данном случае не важно).

Начну с примера: есть сайт, который позволяет зарегистрированным пользователям скачивать что-либо (музыку, программы, фильмы — не суть важно). Одним из самых распространённых решений в этом случае является использование нескольких серверов. Во многих конфигурациях, которые я видел, "web-мордой" занимается Apache, а на обслуживании закачек стоит nginx+PHP+ (PHP занимается вопросами авторизации, ведения статистики и т.п.). Сразу оговорюсь, что есть альтернативное решение, когда nginx используется в качестве reverse proxy перед Apache — nginx проксирует запросы к PHP-скриптам Apache, а PHP-скрипт, если ему надо отдать что-то статическое, делает X-Accel-Redirect. Подробнее описано в статьях «Использование X-Accel-Redirect с Nginx для реализации контролируемых скачиваний» и «Использование Nginx Как Reverse-Proxy Сервера На Загруженных Сайтах».

Отвлекусь от темы и скажу пару слов про альтернативную конфигурацию: она работает на «ура», если сайт отдаёт в основном статический контент. Если же большая часть запросов идёт к PHP, то логичнее поставить nginx за Apache (в противном случае будет тратиться время на проксирование запроса). Еще один минус у такой конфигурации — использование менеджеров закачек (всякие там ReGet, FlashGet) "ложит" Apache. Можно, конечно, ввести ограничения на одновременное количество закачек, а можно настроить PHP работать в паре с nginx.

Возвращаясь к теме разговора: а теперь предположим, что это всё нужно реализовать локально (для тестирования). Вот в таких ситуациях nginx для Windows очень хорошо помогает :-)

В Cygwin сборка nginx проходит практически без проблем (хотя более старые версии приходилось немного патчить руками), на выходе получаем nginx.exe :-)
Я не буду вдаваться в детали конфигурирования nginx, потому что есть замечательная статья «Настройка Nginx для поддержки PHP при помощи FastCGI», просто отмечу некоторые детали, упрощающие жизнь.

Итак, у нас есть PHP, Cygwin и nginx. К сожалению, nginx не поддерживает PHP как модуль (подобно Apache), поэтому nginx и PHP могут работать только по протоколу FastCGI (возможно, и по обычному CGI, я не пробовал — в любом случае, производительность при работе через CGI будет значительно ниже).

Для определённости будем полагать, что nginx у нас сконфигурирован следующим образом (я привожу только часть, относящуюся к FastCGI):

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  disk:/path/to$fastcgi_script_name;
    include        conf/fastcgi_params;
}

Ключевой момент: в fastcgi_param должен быть путь, который поймёт интерпретатор PHP. Если интерпретатор собран в Windows, то путь тоже должен быть в формате Windows (например, c:/web/mysite.com/scripts). Хвостового слэша быть не должно, потому что $fastcgi_script_name именно с него и начинается. То есть если пользователь запросил http://mysite.com/test.php, то $fastcgi_script_name будет равен /test.php.

Файл conf/fastcgi_params:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

Для удобства, установим nginx как Windows. Для этого можно использовать, например, cygrunsrv:

cygrunsrv --install nginx --path /path/to/nginx.exe --disp nginx --neverexits

Ключевым здесь является параметр --neverexits — без него Windows будет жаловаться, что процесс был остановлен (из-за того, что nginx fork()'ается). Хотя это неправильное использование --neverexits.

Переходим к настройке PHP. По счастью, в Windows-версии PHP уже есть модуль с поддержкой FastCGI (он называется php-cgi.exe), так что пересобирать PHP не придётся (сборка PHP под Cygwin — неблагодарное занятие из-за парочки глюков в libtool; если у меня будет желание, как-нибудь напишу). В статье приводится скрипт для запуска PHP/FastCGI, но мы поступим проще.

Сначала об одной не очень документированной особенности PHP/FastCGI: он имеет тенденцию «незаметно умирать» после некоторого числа запросов. Это связано со значением переменной окружения PHP_FCGI_MAX_REQUESTS, определяющей, какое максимальное количество запросов может «пережить» PHP. Можно, кончено, поставить «космическое» значение, но 2 миллиарда запросов — так ли это много? :-) На отрицательные значения переменной PHP громко ругается. Экспериментально было выяснено, что 0 — это то, что нужно (в документации я это не нашел).

Запускаем PHP:

set PHP_FCGI_MAX_REQUESTS=0
php-cgi -b 127.0.0.1:9000 -c path/to/php.ini

А теперь как установить PHP/FastCGI сервисом Windows:

cygrunsrv --install php-cgi --path /cygdrive/f/web/php/php-cgi.exe --disp "PHP/FastCGI" --env "PHP_FCGI_MAX_REQUESTS=0" --args "-b 127.0.0.1:9000 -c path/to/php.ini"

Строка -b 127.0.0.1:9000 -c path/to/php.ini будет передана интерпретатору в качестве командной строки, поэтому путь path/to/php.ini должен быть путем Windows, если интепретатор собран под Windows.

Собственно, всё :-)

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/windows/58-nginx-php-fastcgi-in-windows/feed/ 44 Если Service Pack 2 не ставится на Windows XP… http://blog.sjinks.pro/windows/56-when-sp2-fails-to-install-on-windows-xp/ http://blog.sjinks.pro/windows/56-when-sp2-fails-to-install-on-windows-xp/#comments Thu, 27 Mar 2008 07:07:27 +0000 Vladimir http://blog.sjinks.pro/windows/56-when-sp2-fails-to-install-on-windows-xp/ © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Как поставить на с заблокированным ключом продукта

Если второго пакета обновлений XP (aka Service Pack 2) аварийно завершается со словами "Внутренняя ошибка" на стадии "Проверка ключа продукта", значит, вы плохо активировали Windows :-) Это особенно относится к читателям статей типа "Лицензионный Windows XP всем и каждому" :-)

Сценарий: не оказалось под рукой нормального установочного диска с WinXP Pro SP2, пришлось ставить "голую" XP Pro безо всяких -паков, активировать ее и ставить кучу обновлений. WGA говорит, что с лицензией всё в порядке, Windows подлинная, а SP2 устанавливаться отказывается. Как такое возможно? Да очень просто: патченная WGA и ключик продукта в блэклисте.

По счастью, лечится просто.
При установке Windows создаёт весьма полезную папочку — что-то вида WINDOWS\repair. В ней хранится полезный файлик с именем software. Так вот, этот файлик — часть реестра (HKEY_LOCAL_MACHINE\Software). Этот файлик нужно испортировать в реестр. Для этого запускаем regedit, создаем где-нибудь раздел (например, test) и в него импортируем (через Файл - Импорт) файл с %WINDIR%\repair\software (в поле "Тип файлов" нужно предварительно поставить "Файлы кустов реестра"). Windows выдаст предупреждение, что "Раздел будет восстановлен поверх раздела: test. Все параметры и подразделы будут удалены". Нажимаем "Да", и через некоторое время в подразделе test появится копия HKEY_LOCAL_MACHINE\Software, созданного при установке. Допустим, что наш раздел test находится в том же HKEY_LOCAL_MACHINE. Заходим в подраздел HKEY_LOCAL_MACHINE\test\Software\\Windows NT\CurrentVersion. Оттуда нам нужны следующие значения (ибо обычно именно они меняются активаторами):

  • CurrentBuild;
  • InstallDate;
  • ProductId;
  • DigitalProductId;
  • LicenseInfo.

и копируем их в HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion.

Аналогично поступаем с OOBETimer и LastWPAEventLogged из HKEY_LOCAL_MACHINE\test\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WPAEvents — их копируем в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WPAEvents. После этого запускаем инсталляцию SP2 и радуемся жизни :-)

А дальше? Не знаю, сервис-пак еще устанавливается :-)

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/windows/56-when-sp2-fails-to-install-on-windows-xp/feed/ 1