Показать полную графическую версию : [решено] Ошибка входа в систему при попытке разблокировать
:kruto: Ошибка при огировании по локальной сети после блокировки. Но пользователь не может войти в систему (ХРюха SP3), так как окна логин и пароль не активны, на них серый фон. И так на нескольких компах локалки. Выход один - перегрузка наживую. Ни на одном форуме инфы не нашел по этой теме. Может кто встречал подобный глюк. Догадка одна - для пользователя установлен лимит времени на логирование после блокировки. А может и нет... Буду рад любому совету.
А как же без домена. Но к настройкам АД у меня нет доступа - другой отдел админит его и контакт с системщиками сурово ограничен. В таких условиях приходится работать - почти вслепую. Но кому щ-щ-щас легко! Другой вопрос, что решать проблему надо. А чтоб надавить на сисадмина - надо быть уверенным хотя бы на 90 проц что причина в сетевых настройках
И еще - есть гипотеза, что в свойствах локального пользователя проставлено во вкладке "СЕАНСЫ" ограничение времени бездействующего сеанса. Хотя, это кажись для удаленного сеанса. Каким боков связать логирование по сети с сеансом - предположить могу, уверенно ответить нет. Доступа на сервер с 2003-й виндой у меня нет.
Реально раньше не было такого косяка, до того, как юзеры логинились под учеткой компа. И сам факт, что на разных машинах у тех самых юзеров проявляется эта фигня - говорит не в пользу сетевых настроек.
Если есть мыслишки на этот счет, буду рад принять, ну и - высказать свою признательность...
логин и пароль не активны, на них серый фон. И так на нескольких компах локалки. »
то бишь не на всех? Может быть в какой-то определенной подсети? ОС стоит на компах одинаковая? А Service Pack, тоже?
Да и везде SP3. Компы в общей сети (на них БД склуль, система доступа и т.д). Железо справляется с загрузкой.
А чтоб надавить на сисадмина - надо быть уверенным хотя бы на 90 проц что причина в сетевых настройках »
Давить не надо. Просто узнать - почему такая особенность. Тем более что не на всех компах. Быть может с его стороны были выполнены деяния, которые коснулись "избранных" пользователей.
Ну давить не в прямом смысле. И насчет того, что они могли недосмотреть с настройками отдельных пользователей -догадка уже была. Вот только не понять, какая настройка. Что это в политиках искать надо - тоже понятно. До конкретики докопаться наверняк тяжело, а хотелось бы. Жесть конкретная, становиться понятно. Но тсавить вопрос ребром перед системщиками хотелось бы зная конкретное направление. Чайником выглядеть не хотелось бы, копая с ними этот косяк. Попоробуем. Если разберемся - напишу.
З.Ы. Выходные на подходе, а если контролер на проходной заблокирует на перерыв комп и потом не сможет опять войти - ехать не охота. А скорее прийдется.
Petya V4sechkin
13-11-2009, 10:10
Allekss, судя по статье KB242917 (http://support.microsoft.com/kb/242917/ru) дело может быть в кривом скринсейвере.
Статью прочел. Поработаем в этом направлении. Но при возникновении описанной проблемы Ctrl-Alt-Del не действует, можно жать на клаву хоть тыщу раз.
И еще. Стоит на компах NOD32. Обновляется постоянно. Но после проверки утилиткой DrWeb (CureIt) выдал за вирус файлы DameWare - DMRWCS.exe, хотя они сами сидят в нормальной директории и вирусами не являются. По идее. Админы реально удаленкой работают.
Реестр настроен правильно. И тут проблема не в ошибке, а в недоступности полей ввода логин-пароль (серый фон).
Сегодня проблему отметил: подключаюсь удаленно, выхожу из системы (юзер подключен через домен) и вхожу чисто на комп под админом. - Такая же фигня: недоступны поля логин, пароль, но зато хотя бы доступна возможность перезагрузки через "завершение работы" (после блокирования - естественно нет, только через резет. И такое повторил два раза - один результат. После перезагрузки, естественно, - все нормаль. Удалил после прогонки докторвебовской утилитой DMRWCS.exe - пока проблема не проявлялась (но она и раньше появлялась не всегда - раз через 4-5). Если проявлений глюка не будет и далее - то вывод: это вирус стопроцентовый. И еще какой! Но как он попал туда, ведь на нод32 (последняя версия и с постоянным обновлением) включена защита онлайн? Вывод: нод не видит этой заразы.
И еще - после проверки обнаружилось два одинаковых файла DMRWCS.exe и оба в каталоге system32 под статусом "Program.RemoteAdmin.origin".
Реестр настроен нормально, со скринвервером все в порядке
Allekss, DrWEB временами тот еще параноик, а в данном случае
Program.RemoteAdmin.origin »
он просто предупреждает, что найдена программа удаленного администрирования.
Если с удалением DameWare проблема решилась, попробуй на другой машине просто отключить службу, отвечающую за DameWare - может башню сносит именно у него? Есть в этой программе режим удаленного управления с одновременной блокировкой работы локального пользователя - не помню как это выглядит на компе конечного пользователя, но может это тот самый режим и срабатывает?
Это толковая мысль. Поработаем и в этом направлении. Ведь такая ошибка на самом деле появляется периодически, а то и вообще очень редко. Сами мы удаленно работаем с Ви-Эн-Си-клиент. С ним глюков точно нет.
И еще, проверено на других компах доктором, DMRWCS.exe не обнаружен, хотя глюк также редко, но метко... Вывод позволяет сфокусироваться на более конкретных вещах.
Technocrat
17-11-2009, 09:24
Точно такая же проблема появилась пару недель назад на одной из машин. Сегодня повторилась на другой. Вечером компьютеры должны были сделать бэкап и автоматически отключиться, но иногда этого не происходит. Утром вижу, что поля логина и пароля в окне входа в Windows неактивны.
Стоит Касперский, базы обновляются ежедневно.
DameWare не установлен, DMRWCS.exe нет. AVZ ничего подозрительного не выдает, в том числе в автозапуске и в активных процессах.
Наконец-то становиться понятно, где копать. Довольно хорошо описано тут EventID (http://support.microsoft.com/kb/837115/ru)
Для устранениЯ проблемы нужно инсталлить UPHClean UPUClean (http://www.microsoft.com/downloads/details.aspx?displaylang=ru&FamilyID=1b286e6d-8912-4e18-b570-42470e2f3582)
Увы! Инсталляция UPHClean не помогла. "Изоляция" damaware также ничего недала. Пробовали отключать диск паблик при логировании юзера с помощью nnCron (as servise) - еще чаще, кажись, проявляется глюк. Остановили службу крон - нет эффекта. Грешили на нод32 - зря, не в нём дело. Еще догадки на доблесный и интеллектуальнейший СКД "Интеллект" 4.7.6 (везде как служба загружен). Это не так легко - проходную хоть ночью, остановить нелегко даже на время. Все службы подряд тестировать - тупо. А вот и скриншот и текст сист-й ошибки:
Тип события: Предупреждение
Источник события: Userenv
Категория события: Отсутствует
Код события: 1517
Дата: 17.11.2009
Время: 10:14:17
Пользователь: NT AUTHORITY\SYSTEM
Компьютер: SKUD-XX0-9
Описание: Реестр пользователя GRPZ\128205 был сохранен в то время, как приложение или служба продолжали использовать его во время выхода из системы. Используемая реестром пользователя память не была освобождена. Реестр будет выгружен, когда он не будет использоваться. Возможная причина - службы, выполняемые от имени пользователя. Попробуйте изменить настройку служб и задать их выполнение с учетными записями LocalService или NetworkService.
Technocrat
19-11-2009, 09:11
Да, мне тоже UPHClean не помогла. Кстати, ошибки 1517 не наблюдаю.
Так как проблема появилась на двух машинах в локалке с разницей в полторы-две недели, при отключенном автообновлении системы, подозреваю, что это работа какого-то вируса.
Никакой одинаковый софт на эти две машины в это время не устанавливался. Да и вообще между ними мало общего. Разве что Касперский, но у Вас, как я понял, NOD.
Technocrat
20-11-2009, 17:43
Сегодня ситуация повторилась на третьей машине в локалке.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.