Устранение ошибки в службе спулинга

Ошибка переименования файлов в Windows 2000

Ошибка функционирования оснастки DFS

Исправленный алгоритм пересылки DNS

HP SECURE PATH переполняет системный журнал событий

Windows 2000 блокирует входящие TCP-соединения

«Голубой экран» при завершении работы Windows

Диагностика проблем с задержкой при регистрации

Устранение ошибки в службе спулинга

Ошибка в службе спулинга может привести к катастрофическому сбою многопроцессорной системы, используемой в качестве принт-сервера, если он работает с чрезвычайно высокой нагрузкой. В этих условиях функция в локальном коде спулера некорректно удаляет структуру памяти, которая определяет локальный порт принтера, пока тот занят. Обновлены четыре файла: localspl.dll, spoolss.dll, win32spl.dll и sp3res.dll; большинство файлов датировано 15 января 2003 г. Чтобы получить их, следует обратиться напрямую в службу PSS; при этом можно ссылаться на статью Microsoft «The Spooler Service May Crash Under Stress» ( http://support.microsoft.com/?kbid=321614). ***

В обновленной версии Windows DNS исправлены две ошибки

Служба DNS на всех платформах Windows 2000 вплоть до Windows 2000 Service Pack 3 (SP3) подвержена сбоям при необычных обстоятельствах. Если служба DNS обнаруживает скобку в хост-записи файла зоны, то она прекращает работу и записывает в системный журнал сообщение с ID 7031 и текстом «The DNS Server service terminated unexpectedly. It has done this x time(s). The following corrective action will be taken in 0 milliseconds: No Action». Кроме того, удаление или добавление нескольких зон за короткое время может привести к потере параметров конфигурации службы DNS. При возникновении любой из этих проблем следует обратиться в службу PSS и получить новейшую версию файла dns.exe с датой выпуска January 30, 2003. Версия от 30 января заменяет две программы коррекции для DNS, выпущенные 28 декабря 2002 г. и 16 января 2003 г., после выхода Windows 2000 SP3. При обращении за помощью следует ссылаться на статьи Microsoft «DNS Service Ends Unexpectedly and Event 7031 Error Message Appears» (http://support.microsoft.com/?kbid=813425) и «DNS Server Settings Are Lost When You Rapidly Delete and Re-Create a Directory Service Zone from a File» (http://support.microsoft.com/?kbid=810714). ***

Кластерная ошибка VPN в Windows XP

Если клиенту не удается установить соединение VPN, проблема может иметь несколько причин. Одна из них связана с VPN-серверами, объединенными в кластер. В статье Microsoft указывается, что попытка клиента Windows XP Service Pack 1 (SP1) установить соединение с VPN-сервером с использованием виртуального IP-адреса может окончиться неудачей. При этом выдается сообщение «Error 721: Remote PPP peer is not responding». Сбой происходит из-за ошибки в процессе начального согласования соединения, когда сервер посылает клиенту пакет Generic Routing Encapsulation (GRE). Клиент запрашивает соединение с виртуальным TCP/IP-адресом сервера, но пакет GRE содержит TCP/IP-адрес сетевого адаптера, указанного первым в порядке привязки на VPN-сервере. Клиент обнаруживает, что адрес в пакете GRE отличается от того, по которому был послан запрос соединения, и игнорирует пакет. После отклонения пакета GRE происходит тайм-аут запроса соединения, и клиент сообщает, что удаленный компьютер не отвечает. В качестве временного решения можно отключить функцию проверки адреса VPN в сетевом адаптере, используемом клиентами для VPN-соединений. О том, как изменить реестр, чтобы отключить эту функцию, рассказывается в статье Microsoft «Your Windows XP-Based Client Cannot Establish a VPN Connection» ( http://support.microsoft.com/?kbid=810839). Чтобы избавиться от проблемы раз и навсегда, необходимо установить исправление с сайта Windows Update или обратиться в службу Microsoft Product Support Services (PSS) за обновленным клиентом VPN; при обращении следует ссылаться на номер статьи, указанной выше.***

Ошибка переименования файлов в Windows 2000

Иногда при попытке удаленного переименования файла компьютер с Windows 2000 зависает. Согласно статье Microsoft «File Server Stops Responding (Hangs) When You Rename a File» (http://support.microsoft.com/?kbid=810340), программная ошибка в процедуре переименования может вызвать взаимную блокировку двух потоков на сервере, которые будут бесконечно ожидать доступа к блоку управления файлом (file control block). Если сервер перестает отвечать, его можно разблокировать, перезагрузив систему. В статье нет сведений о том, как часто возникает сбой, но указывается, что служба Microsoft Product Support Services (PSS) располагает новой версией файла ntfs.sys (дата выпуска — January 16, 2003), в котором данная ошибка исправлена. Проблема временной синхронизации затрагивает все версии Windows 2000.***

Ошибка функционирования оснастки DFS

При администрировании корня Dfs с помощью оснастки Dfs консоли управления Microsoft Management Console (MMC) время от времени происходят сбои. В статье Microsoft «DFS Manager Does Not Show DFS Roots» (http://support.microsoft.com/?kbid=812680) указывается, что служба Dfs ошибочно считывает начальные параметры в реестре при первом запуске системы или перезапуске службы Dfs. Проблема свойственна исключительно Dfs-серверам, настроенным на использование в ссылках полных доменных имен (Fully Qualified Domain Name, FQDN). Если для конфигурирования Dfs-серверов используется этот метод, то нужно обратить внимание на следующие симптомы: оснастка Dfs выдает сообщение об ошибке «The specified domain either does not exist or could not be contacted», а Dfs-утилиты dfscmd.exe и dfsutil.exe — загадочное сообщение «System error 2662 has occurred». Чтобы устранить возникшую неполадку, необходимо получить последнюю версию Dfs, dfssvc.exe, выпущенную 11 февраля 2002 г. Исчерпывающий список серверных сообщений Dfs из файла dfs.sys и клиентских сообщений из mup.sys, вместе с идентификационными номерами и текстом, приведен в статье Microsoft «List of Windows 2000 Distributed File System Event Log Messages» (http://support.microsoft.com/?kbid=315919). В ней же можно найти ссылки на материалы по реализации и отладке служб Dfs.***

Исправленный алгоритм пересылки DNS

В алгоритме DNS-сервера Windows 2000 есть слабое место, которое может вызвать длительные задержки при преобразовании имен, когда один сервер пересылает запрос на другой сервер в зоне ответственности. Проблема возникает, если первый сервер в этой зоне по какой-то причине недоступен. Локальный DNS-сервер некорректно записывает время запоздавшего запроса к первому уполномоченному серверу и продолжает безуспешно посылать запросы на преобразование имен тому же компьютеру, вместо того чтобы направить запросы к альтернативному уполномоченному DNS-серверу. Данная ошибка устранена в новой версии DNS-компонента dns.exe, выпущенного Microsoft 20 января 2003 г. Пользователям следует обратиться в службу PSS и сослаться на статью Microsoft «Slow Response Times Occur If a Delegated Name Server Is Down» (http://support.microsoft.com/?kbid=812785).***

HP SECURE PATH переполняет системный журнал событий Пользователям подсистем хранения данных Hewlett-Packard (HP) StorageWorks Secure Path следует обратить внимание на проблему несовместимости Windows Workgroup Edition с системами Windows 2000 SP3. В пакете SP3 появилась новая команда SCSI, Synchronize Cache. Компания HP не обновила Secure Path для работы с ней, и Secure Path ошибочно полагает, что команда SCSI Synchronize Cache указывает путь к отказавшему дисковому массиву (несмотря на корректное выполнение операций записи и чтения с диска). Получив эту команду, Secure Path помещает в системный журнал сообщение ID 7772. Если контроллер SCSI выдает много таких команд, то журнал размером 32 Мбайт будет заполнен менее чем за минуту. Данная проблема существует на системах RA4000 и RA4100, работающих с Secure Path версий 3.1B и 4.0. Пользователям системы хранения данных MSA1000 и Secure Path версий 3.1B или 4.0 следует обновить программное обеспечение ROM MSA1000 и установить исправление для программы Secure Path. Пользователям подсистем RA4000 и RA4100 необходимо получить в компании HP новый драйвер хост-адаптера. Чтобы избежать переполнения системного журнала событий, нужно перед применением SP3 модернизировать подсистемы Windows Workgroups Secure Path. Более подробная информация приведена в статье Microsoft «Many Event ID 772 Entries Are Recorded with HP SecurePath Software (http://support.microsoft.com/?kbid=810637). Рекомендации по устранению проблемы опубликованы HP по адресу: http://wwss1pro.compaq.com/support/reference_library/ viewdocument.asp?countrycode=1000&prodid=2067| sanworks+securepath&source=oi021115_cw01.xml& amp;dt=3&docid=13489.***

Windows 2000 блокирует входящие TCP-соединения

В статье Microsoft «Windows 2000 Stops Accepting Incoming TCP Connections» (http://support.microsoft.com/?kbid=811044) указывается, что система Windows 2000 может неожиданно отказывать входящим соединениям, не указывая никаких причин подобного поведения. Такие сбои случаются на файл-, принт- и VPN-серверах. Для диагностики проблемы следует отобразить состояние TCP-соединений с помощью команды netstat -an. Если многие соединения находятся в состоянии Closing, необходимо установить исправление для TCP. Исправление обновляет пять компонентов: afd.sys, msafd.dll, tcpip.sys, tdi.sys и wshtcpip.dll. Дата выпуска большинства файлов — декабрь 2002 г.; получить программу можно только в службе PSS.***

«Голубой экран» при завершении работы Windows

При завершении работы некоторых систем Windows 2000 время от времени происходит катастрофический сбой, сопровождаемый «голубым экраном». Причиной его может быть ошибка в серверной службе srv.sys. Системный сбой возможен в том случае, если серверная служба закрывается прежде, чем будут завершены все задачи в очереди. Проблема связана с особенностями взаимодействия между серверной службой и подсистемой печати. Когда данная ошибка приводит к краху системы, отображается код остановки 0xCE для компонента srv.sys. Компания Microsoft выпустила исправление, которое обновляет семь компонентов — printui.dll, spoolss.dll, srv.sys, srvsvc.cll, win32spl.dll, winspool.drv и winotify.dll. Все файлы датированы 18 декабря 2002 г. Ссылаться следует на статью Microsoft «Bugcheck with Stop Message ?STOP 0x000000CE? and Svr.sys in Crashdump When Computer Shuts Down» (http://support.microsoft.com/?kbid=810022).***

Диагностика проблем с задержкой при регистрации

Теперь несколько слов о способах диагностики и устранения задержек в регистрации, вызванных тремя конкретными неисправностями. В задержку регистрации входит время, необходимое для удаления экрана регистрации после ввода пароля и имени пользователя, а также время, которое требуется системам Windows XP и Windows 2000 для отображения «рабочего стола» после исчезновения диалогового окна регистрации. Задержки регистрации происходят в трех случаях: при локальной регистрации на рабочей станции или сервере, при подключении к VPN-серверу и при доступе к ресурсам на локальном сервере, требующем локальной учетной записи вместо доменных пароля и имени пользователя. Типичная причина задержек регистрации — проблемы с профилем. Слишком большой, недоступный или испорченный профиль может вызвать зависание системы или привести к появлению пустого «рабочего стола» после задержки длительностью 10 и более минут.

Некорректный или пустой адрес DNS-сервера. Наиболее распространенная проблема задержки регистрации в домене Windows 2000 — неопределенный или неверный TCP/IP-адрес сетевого DNS-сервера. Симптом этой проблемы — знакомые «песочные часы» на экране Welcome. Иногда появление «песочных часов» сопровождается сообщением о подготовке сетевых соединений в нижней части экрана Welcome. Если у локальной машины нет TCP/IP-адреса для DNS-сервера или адрес недействителен, то система может не обнаружить контроллер домена (DC). Если локальный компьютер имеет действительный адрес DNS-сервера, то он может указывать на DNS-сервер в Internet или на сервер, подключенный через медленный канал WAN. В обоих случаях задержка регистрации объясняется выбором неоптимального пути пересылки и маршрутизации запросов преобразования имен. Например, если запрос преобразования имен DNS направляется на сервер имен Internet-провайдера, он должен обнаружить сервер имен, которому известен адрес DNS-сервера внутренней сети. Чтобы проверить параметры TCP/IP для соединения, в котором происходят задержки, достаточно открыть командную строку и ввести команду

ipconfig/all
Если использовать команду Ipconfig без параметра /all, то будет показано подмножество информации TCP/IP для первичного сетевого адаптера, но не для нескольких сетевых адаптеров и активных VPN-соединений. Если локальный компьютер подключен к сети и располагает единственным сетевым адаптером, то Ipconfig/all отображает сведения о конфигурации в двух разделах. В первом разделе содержится имя хост-узла DNS и имя домена DNS (суффикс); тип узла WINS, данные о режиме маршрутизации (обычно на рабочей станции или сервере он не активизирован); proxy-адрес WINS (обычно пустой); доменный поисковый список DNS, который также может быть пустым. На типичной рабочей станции второй раздел содержит данные о конфигурации TCP/IP для сетевого адаптера. Если система располагает несколькими адаптерами или активными VPN-соединениями, то в разделе содержится несколько групп конфигурации TCP/IP, по одной для каждого сетевого адаптера и для каждого VPN-соединения. Если DNS-адрес правильный, то с помощью команды Nslookup можно проверить, подключен ли DNS-сервер к сети и принимает ли он запросы на преобразование имен. Nslookup устанавливает связь с DNS-сервером, назначенным первичному сетевому адаптеру. Если компьютер оснащен несколькими сетевыми адаптерами, подключенными к разным сетям, то первичным адаптером считается первая сетевая плата в порядке привязки. Чтобы увидеть привязки, следует щелкнуть на Start, Settings, Network and Dialup Connections, выбрать меню Advanced и щелкнуть на кнопке Advanced Options. Если DNS-сервер подключен к сети и доступен, то Nslookup показывает DNS-имя и адрес сервера. Если Nslookup не может установить связь с DNS-сервером, то на экран выводятся имя и адрес сервера с сообщением, в котором говорится, что сервер не дает своевременного ответа.

Образы, созданные с использованием Sysprep. Из-за ошибки в утилите Sysprep, предназначенной для создания образов Windows 2000, рабочей станции Windows 2000 (а возможно, и компьютеру XP) приходится загружать с сервера полное описание объекта Group Policy Object (GPO) каждый раз, когда пользователь регистрируется в домене Windows 2000. Обычно система загружает GPO, только если была изменена политика. Задержка регистрации возможна, если система загружает вложенные объекты GPO — во многих случаях для обновления политики требуется несколько минут. В показанном ниже разделе реестра задано максимальное время (в минутах) ожидания перед загрузкой полного GPO. Sysprep некорректно устанавливает интервал равным 1 мин, в результате чего система должна перезагружать GPO при каждой регистрации пользователя. Чтобы устранить эту ошибку, следует запустить редактор реестра и перейти в раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NT CurrentVersionWinlogonGPExtensions{GUID}. Затем нужно отыскать параметр MaxNoGPOList ChangesInterval типа REG_DWORD. На моей тестовой системе корректный глобальный уникальный идентификатор — GUID — был по счету пятым от GPExtensions. Возможно, для обнаружения параметра MaxNo GPOListChangesInterval придется просмотреть несколько подразделов. Если значение параметра равно 1, значит, в системе произошла данная ошибка Sysprep. Чтобы вернуть систему в нормальный режим работы, следует восстановить стандартное значение MaxNoGPOListChangesInterval 960 мин; соответствующее шестнадцатеричное значение — 0x3C0. В результате устраняются задержки регистрации из-за лишних обновлений GPO.

Системная ошибка XP. При использовании сложного набора GPO ошибка в XP и XP Service Pack 1 (SP1) может привести к зависанию системы после ввода верного пароля и имени пользователя. В таких случаях система не реагирует на действия пользователя при выведенном на экран регистрации сообщении Applying your personal settings. Разработчики Microsoft исправили эту ошибку, выпустив новую версию файла userenv.dll, датированную 14 ноября 2002 г. Ссылаться следует на статью Microsoft «Computer Seems to Hang When You Log On» (http://support.microsoft.com/?kbid=329457).

Наряду с командами Ipconfig/all и Nslookup существует еще два метода обнаружения источника задержек регистрации. Оба приема связаны с изменениями реестра.

Полные сообщения. Сначала нужно активировать режим полного вывода сообщений для запуска, завершения работы, регистрации и завершения сеанса. Для включения этой функции следует запустить редактор реестра и перейти в раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows CurrentVersionPoliciesSystem. В раздел нужно добавить новый параметр VerboseStatus типа REG_DWORD со значением 1. Затем требуется завершить работу, а потом вновь зарегистрироваться и поискать ключи к пониманию проблем в дополнительных сообщениях в журналах событий System и Application. Перед возвращением системы в рабочее состояние полный режим нужно отключить (просто удалив параметр VerboseStatus).

Отладка пользовательской среды. Протоколирование пользовательской среды обычно приносит больше пользы, особенно если задержка связана с применением GPO. С помощью редактора реестра нужно отыскать раздел HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NTCurrentVersionWinlogon, добавить новый параметр UserEnvDebugLevel типа REG_DWORD и присвоить ему шестнадцатеричное значение 10002 (0x00010002). Данный параметр заставляет операционную систему записывать полные сообщения для операций запуска, завершения работы, регистрации и завершения сеанса в файл %systemroot%debugusermodeuserenv.log. Можно выполнить точную настройку сообщений отладки, установив значение UserEnvDebugLevel равным любой комбинации следующих величин:

NONE 0x00000000

NORMAL 0x00000001

VERBOSE 0x00000002

LOGFILE 0x00010000

DEBUGGER 0x00020000a

Если параметру присвоено значение 10002, то операционная система будет записывать полные сообщения в журнал. Стандартное значение этого параметра — NORMAL|LOGFILE (0x00010001). Затем следует завершить работу и вновь зарегистрироваться, после чего проверить файл журнала; не следует теряться при виде огромного количества данных — выбрать нужные сообщения и установить источник проблемы нетрудно. После завершения работы можно присвоить параметру нулевое значение или удалить элемент UserEnvDebugLevel.

Паула Шерик — редактор Windows & .NET Magazine и консультант по вопросам планирования, реализации и взаимодействия сетей. С ней можно связаться по адресу: paula@winnetmag.com.