Доброго времени, уважаемый Janpit!
Большое спасибо за оперативные рекомендации.

Позвольте несколько прояснить ситуацию...
В моём случае:
в C:\WINDOWS\system32\dllcache имеет место быть означенный файл «NULL.sys» – 2,87 КБ (2 944 байт),
в C:\I386 – он же, но 1,38 КБ (1 421 байт),
в C:\WINDOWS\system32\drivers – он же 2,87 КБ (2 944 байт)
Тот, который скачан из подобного указанному Вами места – 2,87 КБ (2 944 байт).

Так каковы должны быть мои действия на текущий момент? Простите за «тупость»...

С уважением, Бельянинов Е.А.

P.S. К стати: у нескольких человек из мною опрошенных на сей предмет установлен именно SP-3, но проблема та же...

Жаль, что Вы не сообщаете полностью Ваш источник информации и действия, предписываемые им. Я пошел по пути поиска аналогичного решения исключительно потому, что мне непонятен был сам процесс как Вы написали и Ваш результат (reg-файл я читать умею и понимаю): после внесений изменений в реестр и первоначальной загрузки у Вас все в порядке, а вот вторичная приводит "на круги своя".
Поэтому я предположил и продолжаю настаивать на верности: Вы удаляете файл из папки System32 (система предупреждает при удалении устройства, что оно "...будет полностью удалено из системы..."), а он вновь возвращается из dllcache.
Я не сторонник "впихивания" в систему незнакомых файлов, поэтому лично я-бы не стал ставить скачанный, а просто взял бы его из дистрибутива с переименованием с из null.sy_ в null.sys. Но сначала скопировал бы его в dllcache. По большому счету, в System32 его уже можно не менять. Можете его просто удалить и система сама восполнит потерю из dllcache.
Т.о. я склонялся к мысли повторить все, что Вы делали, но заменив файл в dllcache на оригинальный. "Старый" можете не удалять, а просто переименовать на одну букву (у меня это в привычке). Например, null.sy или nul.sys (мало-ли).

Я и не утверждал, что SP3 - панацея от всех бед. Я просто говорю, что мелких проблем стало меньше. У меня, к примеру, с null.sys за всю мою, смею уверить, довольно обширную практику не было проблем ни разу. И у клиентов не встречал. Я не думаю насчет его "поражения" в Вашем случае, но о такой возможности руткитов упомянул.

Уважаемый Janpit!
К сожалению, я не отложил для себя адрес источника данной информаци, но смею Вас заверить, что текст в нём и в том, который привели Вы абсолютно идентичен.
Итак, я позаимствовал из дистрибутива C:\I386 файл null.sy_, переименовал и поместил его и в C:\WINDOWS\system32\dllcache и в C:\WINDOWS\system32\drivers. (Интересен тот факт, что при попытке переименовать null.sys в nul.sys система «запротестовала» и сообщила, что файл с таким именем уже существует...)...

Но, тем не менее – проблема осталась...
Вновь при повторной перезагрузке в «диспетчере устройств» строка «NULL» имеет ту самую жёлтую пометку...

Хочу особо отметить, что имею также «здоровую» и чистую систему, поскольку полностью переустановил таковую 10 дней назад.
Процесс переустановки в моём случае проходит практически в автоматическом режиме, поскольку в силу того, что я в своём активе имею «белую» IBM IntelliStation E Pro с уже предустановленной на ней лицензионной и активированной системой, дистрибутив которой залит на скрытый раздел жёсткого диска, весь процесс переустановки системы сводится лишь к нажатию в нужный момент при загрузке F11...

Что же касается безопасности – пользуюсь лицензионным пакетом Dr.Web Security Space, базы которого регулярно обновляю (практически перед каждым выходом в Интернет, и не только). Полное сканирование на предмет «заражения» не выявило никаких отрицательных активностей...
Неужели дело в самом файле драйвера, в содержащейся в нём внутренней ошибке? Тогда почему эффект повторяется при замене файла драйвера на оригинальный из дистрибутива?

Право же не знаю, на что грешить... Но в свою очередь данная неприятность порождает чувство «глубокого морального неудовлетворения»...

С уважением, Бельянинов Е.А.

Интересен тот факт, что при попытке переименовать null.sys в nul.sys система «запротестовала» и сообщила, что файл с таким именем уже существует...

Действительно интересно. Даже - возмутительно интересно, потому что в системе такого файла нет и быть не должно. Во всяком случае мне его в написании nul.sys видеть не приходилось. И сейчас такого нет ни на одной из двух десятков машин, находящихся у меня в сети. Вопрос: откуда он в системе? Сама ОС так не переименует - это неоспоримый факт. Системные переименования сводятся к изменению расширений и только. Здесь же мы имеем изменение имени файла, что для системы - табу. Вы не вторично переименовываете файл?
Мой ответ был основан (и это действительно факт) на том, что замена файла производилась неправильно, потому что система просто не давала его изменить, восстанавливая заменяемый. Об этом говорил и тот факт, что до перезагрузки эффект был. Теперь имею несколько непонятных вещей, а именно:
1) nul.sys
2) И после "правильной" замены система работает нормально только до перезагрузки
По первому Вы ответите, надеюсь, сам - я вопрос задал выше.
А вот по второму я могу снова только предположить, основываясь прежде всего на здравом смысле, анализируя Ваши действия в плане команд для системы:
REG-файл, выполняемый Вами, предписывает прописать изменения в ветку [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\
Позвольте, а на каком основании Вы слепо это выполняете? Какую роль в Вашей системе играет именно ControlSet001 - Вы знаете?
Поясняю: в системе обычно два нумерованных раздела ControlSet - ControlSet001 и ControlSet002 (могут быть и другие, и отличные, но в данном случае это неважно и на этом останавливаться не буду). Они отражают текущую конфигурацию и последнюю удачную (Last Known Good Configuration). CurrentControlSet просто указывает на конфигурацию, которая использовалась при последней загрузке компьютера. Для определения текущей конфигурации нужно смотреть раздел HKLM\System\Select, параметры Current, Default, LastKnownGood (названия говорят сами за себя).
Таким образом, если у Вас текущая, к примеру, 002, а Вы по файлу реестра прописываете в 001, то вот Вам и причина утраты изменений после перезагрузки. Мысль поняли? В файле реестра (Приложение вопроса) ControlSet00Х должен указывать на Вашу ТЕКУЩУЮ конфигурацию, а не тупо на 001.
Вот Вам еще одна возможная ошибка. Проверяйте.

Итак, я позаимствовал из дистрибутива C:\I386 файл null.sy_, переименовал и поместил его и в C:\WINDOWS\system32\dllcache и в C:\WINDOWS\system32\drivers

Вообще-то файлы не просто так переименованы: они сжаты.



Конечно же, делать это лучше всего из консоли восстановления.

Подробнее:
- expand;
- Описание консоли восстановления.

Доброго времени, уважаемы коллеги!
Прежде примите мои извинения за недалёкость в вопросах «системных внутренностей», так как я по большей части имею дело с «более реальными» образами, как то – графика, видео и т.д. А, собственно, эта моя недалёкость в вопросах устройства системы и заставила меня прибегнуть к Вашей квалифицированной помощи!..

Итак, по порядку...
Уважаемы Janpit!
Следуя Вашей рекомендации, я открыл редактор реестра и обнаружил, что в моём случае имеют место две ветки:
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001
и
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003.

Теперь, ежели я сделал надлежащий вывод из сказанного Вами, мне необходимо обратить внимание именно на вторую ветку, и именно её указать в reg-файле, прописываемом в реестр?

Именно во второй ветке у меня есть отличия от рекомендуемых (в reg-файле), в частности:
в [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control]
значение "ActiveService"="Null" у меня в реестре отсутствует (не присвоено).

Следовательно, мне необходимо внести коррективы в предлагаемый reg-файл и изменить ControlSet001 на ControlSet003?

Уважаемый Denisss!
В моём случае использовать консоль восстановления представляется несколько затруднительным, поскольку, как я уже говорил выше, я не имею на руках отдельного дистрибутивного диска ОС. Последний (дистрибутив) «зашит» на скрытом разделе жесткого диска.
Кстати, мои действия на предмет «тупого» копирования фала null.sy_ из C:\I386, судя по всему, являются некорректными, и даже по той простой причине, что данная директория прописалась в корне диска (как кэш) вследствие установки системы до инсталляции поверх второго пакета обновлений. И «заимствовать» скорее надо было из C:\WINDOWS\ServicePackFiles\i386, но, что примечательно, в данной директории этого «бедного» файла нет, как не было... Из чего позвольте мне сделать вывод, что данный драйвер или же вообще не присутствует во втором пакете, или у меня в системе имеет место быть «патологическая» ошибка...

Не знаю, имею ли я «право» сравнивать файлы драйвера по их «весу», но примечательно то, что практически на всех машинах (и у меня в частности), на которых установлены XP, как с корректной «пропиской» null.sys, так и с ошибкой, аналогичной моему случаю – везде null.sys имеет один и тот же «вес» 2,87 КБ (2 944 байт).

Что же касается попытки установить консоль восстановления из-под системы, последняя выдаёт предупреждение о невозможности данного действа по причине (о которой я уже говорил выше) того, что версия системы установленной на текущий момент является более свежей, чем та, консоль которой я таким образом пытаюсь установить (по материалам, полученным по приведённой Вами ссылке на предмет консоли восстановления). Следовательно, ежели мне и использовать консоль восстановления, – то только загрузившись с какого либо стороннего дистрибутивного диска, а уже командами (не в автоматическом режиме!) в самой консоле указывать те пути (откуда и куда), по которым следует распаковывать оговоренный файл...

С уважением, Бельянинов Е.А.

Бельянинов Е.А
1) Перечитал и подумал, что немного "дал маху" в плане изложения. Бросилось в глаза Ваше, заключенное в кавычки (кстати, скорее всего - написанное в редакторе, а не в WEB-форме) "...на предмет «тупого» копирования..." и моё без оных "...а не тупо на 001..." Можно расценить как что я иносказательно говорю о чьей-то тупости. Приношу извинения, - и в мыслях не было. В данном случае это лишь образное выражение разговорной речи, данное в смысле "не думая", "не рассуждая".
2) В Вашем случае надлежит пройти в реестре до ветки
[HKEY_LOCAL_MACHINE\SYSTEM\Select]
и просмотреть следующие значения
"Current"=dword:00000001
"Default"=dword:00000001
"Failed"=dword:00000007
"LastKnownGood"=dword:00000002 (взято у меня лично)
"Перевожу": у меня в ОС текущей является ветка ControlSet001 (выделено мной), по умолчанию грузится она-же, "сбойной" является ControlSet007, а последней удачной конфигурацией остается ControlSet002. Но это не означает, что у меня целых СЕМЬ веток ControlSet !
Что у Вас является текущей конфигурацией, туда и надо вносить изменения, понимаете? Всё это определяется в кусте SELECT (см. чуть выше в этом сообщении). Это ответ на Ваш вопрос

Теперь, ежели я сделал надлежащий вывод из сказанного Вами, мне необходимо обратить внимание именно на вторую ветку, и именно её указать в reg-файле, прописываемом в реестр?

Что касается

Именно во второй ветке у меня есть отличия от рекомендуемых (в reg-файле)

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

Следовательно, мне необходимо внести коррективы в предлагаемый reg-файл и изменить ControlSet001 на ControlSet003

Подытожу: изменения необходимо вносить только в текущую конфигурацию. В случаях, когда система в этом отказывает по допуску (ветвь "занята" системой - вносятся в "последнюю удачную" и после перезагрузки принудительно грузят ЕЁ. В этом случае она после загрузки поменяет свое назначение и станет "текущей".
Здесь все довольно просто, если чуток разобраться. Как видите, сложного ничего нет (когда все по порядку разложишь).

Кстати, вот сейчас я пишу это не с домашнего ПК и здесь null.sys присутствует только в system32\dllcache, полностью отсутствуя в system32\.

Доброго времени, уважаемый Janpit.
Большое спасибо Вам за то, что тратите на меня столько времени, за Ваше терпение и стремление разобраться и помочь!..

Вот «цитата» из моего реестра»:
[HKEY_LOCAL_MACHINE\SYSTEM\Select]
"Current"=dword:00000001
"Default"=dword:00000001
"Failed"=dword:00000000
"LastKnownGood"=dword:00000003

Если я правильно понял, текущей в моём случае является ControlSet001, по умолчанию – она же (как и у Вас), последней удачной – та самая ControlSet003, а вот со «сбойной» в моём случае... забавно, не правда ли?.. Иными словами, получается, что у меня «сбойной» просто нет?..

Я проверил, что в «текущей» всё в точности соответствует тому предлагаемому для изменения reg-файлу.
Ну уж коли «сбойная» не определена, значит её надо создать?

А вот в ветка
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control] – это в моём случае,

а в предлагаемом файле:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control]
"ActiveService"="Null"

Как это объяснить? И почему данные изменения, вносимые предлагаемым reg-файлом вновь сбрасываются при повторной перезагрузке?..

Боясь избежать эффекта «испорченного телефона» (в некотором понимании), привожу Вам полностью выдержку из своего реестра HKEY_LOCAL_MACHINE\SYSTEM Ссылка на архив (загрузить).

Рискуя показаться навязчивым, буду Вам крайне признателен, ежели Вы изыщите ещё некоторое время и проанализируете мою ситуацию, как говориться, «опираясь на предмет»...

С уважением и благодарностью, Бельянинов Е.А.

Бельянинов Е.А.
Да не за что меня благодарить. Вы - не первый, да и пока что не последний, кому я так объясняю. В этом нетрудно убедиться, хотя-бы бегло просмотрев все мои ответы. Я стремлюсь это делать всегда, так уж приучен. А для данного случая - тем более, потому что, несмотря на ответ, как такового его нет, как ни жаль. Я слишком понадеялся на довольно серьезный промах авторов совета и дал в ответ, хотя первоначально писал в минифорум.

текущей в моём случае является ControlSet001

Да, текущая у Вас и у авторов совпали, так вот только теперь можно сказать, что Вы сделали все правильно в этой части.

получается, что у меня «сбойной» просто нет?..

Ну да. Так а откуда ей взяться, если Вы пишете, что недавно восстанавливались?

Ну уж коли «сбойная» не определена, значит её надо создать?

??? Зачем? "Чтобы было"? Не нужно.
Зашел в свой реестр (с которым никогда проблем с NULL не было) и сверил Ваше Приложение к вопросу со своими записями. Один в один. Спрашиваете почему сбрасывается? Снова могу только предположить:

априори обеспечив полный доступ к ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root,

А "назад" кто возвращать доступ будет? У меня к этой ветке полный доступ имеет только SYSTEM, а ВСЕ - "только чтение". Больше нет никого.
Проанализировав Ваше Приложение и свой реестр, я увидел, что отличий нет вообще, за исключением несущественных, как-то: у Вас "@="Non-Plug and Play Drivers" , а у меня - "@="Драйвер устройств не Plug and Play" . Но это как комментарии, поэтому роли не играет.
Поэтому я предлагаю Вам привести все "к одному", т.е. добавить в [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control]
"ActiveService"="Null" Можете внести его сами или взять файл отсюда>> А вот вернув как положено права доступа, посмотрим что получися. Ведь до перезагрузки (второй) все работает как нужно.

Уважаемый Janpit!
Мои действия:
– даю полный доступ в реестре к ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root,
– вношу изменения
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control]
"ActiveService"="Null"
– возвращаю запрет на место,
– удаляю в Диспетчере устройств «NULL»,
– перезагружаюсь,
– обновляю конфигурацию,
– получаю «Мастер установки нового оборудования» с запросом установить драйвер для нового устройства «NULL».

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

Но, как я понимаю, Мастер просит некий файл «*.inf», относящийся так или иначе к этому самому NULL. По логике ведь так? Ежели я указываю Мастеру собственно на Null.sys, он признавать таковой не хочет...

На глаза попалась страничка http://www.dll.ru/dll/N/10.html
Я уж и не знаю, что предпринять!.. Может удалить его и забыть про таковой? Ну не хочет моя система принимать Null, как бы я ни старался ей таковой подсунуть...
На указанной страничке проживают одноимённые (null.dll, например) библиотеки...
Имеют ли таковые какое-либо (прямое или косвенное) отношение к моей проблеме (прошу извинить заранее за, может быть, глупый вопрос)?

Но вот в безопасном (как я понимаю, без подгрузки вторичных драйверов) режиме (под учётной записью «Администратор») с NULL всё в порядке... Я так же отношусь к группе администраторов, поскольку являюсь единственным пользователем своего компьютера. Какой вид имеет реестр в безопасном режиме, я посмотреть ещё не успел(на время написания сообщения), так как на данный момент пока не имею возможности перегрузиться...

С уважением, Бельянинов Е.А.

Что же касается попытки установить консоль восстановления из-под системы, последняя выдаёт предупреждение о невозможности данного действа по причине (о которой я уже говорил выше) того, что версия системы установленной на текущий момент является более свежей, чем та, консоль которой я таким образом пытаюсь установить

Microsoft в таких случаях рекомендует скачать установленный Service Pack и интегрировать его в папку с дистрибутивом (в Вашем случае, как я понимаю, c:\I386\).

Подробнее: kb898594

Бельянинов Е.А.
Ну почему сразу "глупый"? Вопрос - он и в Африке вопрос. Вот только одно меня смущает: у меня в системе нет вообще такой библиотеки. Кроме того, все новые библиотеки для их задействования обязательно нужно регистрировать в системе через regsvr32 *.dll. Только вот я не знаю для чего она и нужна-ли вообще.
На указанной Вами странице версия файла 5.0.0.2, у меня в SP3 файл null.sys - 5.1.2600.0 (мой файл можно взять здесь >> "на случай")

Какой вид имеет реестр в безопасном режиме

Можете не смотреть - точно такой же. Это константа, просто не все задействуется.
Вот попалось на глаза интересное... К Вам не относится, случаем?

Также некоторые программы могут не работать из-за элементов ОС, которые — на первый взгляд — к ним не относятся. Так, Microsoft Visual Studio.Net, Microsoft Visual C++ 6 не будут работать, если в системе отключен NULL-элемент (в Диспетчере устройств в меню Вид выбрать «Показывать скрытые устройства»; в появившемся новом пункте Драйвера устройств не Plug’n’Play проверить, включен ли NULL-элемент и включить, если нет).

Может его отключить, а не удалять? Еще одно мнение >> по этому поводу. Сайт уважаемый, не верить оснований нет. Сложность в том, что я не могу смоделировать Вашу ситуацию и даже в глаза ее не видел, т.е. не сталкивался.

Уважаемый Janpit!
У меня в системе также нет Null-оподобных библиотек. На указанную выше страничку я набёл в процессе сбора информации по драйверу NULL.sys и связанных с ним проблем...

В моём случае файл этого драйвера также имеет версию 5.1.2600.0...
Не знаю, имеет ли это отношение к теме, но должен отметить, что у меня в системе установлен «Microsoft Visual C++2005 Redistributable»,
«Microsoft.NET Framework_v1.1.4322_Rus», «Microsoft.NET Framework_2_Rus» и «Windows Installer_3».

Из перечисленных программных продуктов, кроме «NET Framework_v1.1.4322_Rus», остальные мне-таки пришлось (поневоле) установить, поскольку во время инсталляции «Dr.Web Security Space» был затребован «Windows Installer_3», а остальное из перечисленного – во время установки «Sound Forge 9.0e_441», и плагина к нему «Sony Nouse Reduction 2.0h».

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

На текущий момент я игнорировал факт присутствия в C:\WINDOWS\system32\dllcache и в C:\WINDOWS\system32\drivers файла NULL.sys, оставив ветку [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_NULL\0000\Control] без параметра
"ActiveService"="Null". При этом (после удаления) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root] теперь не имеет даже и «LEGACY_NULL»... Иными словами, я запретил системе «видеть и знать» об этом «злополучном» драйвере...

Интересен тот факт, что после искусственного удаления из означенных директорий файла NULL.sys и последеющего прогона системы SFC /SCANNOW, этот файл вновь прописался на своих местах... Только вот проблема осталась...

С уважением, Бельянинов Е.А.

В личную почту мне прислал сообщение посетитель Евгений Евгеньевич...

Забавно, не правда ли: http://forum.drweb.com/index.php?showtopic=277888

Ежели описываемый баг действительно имеет место, а именно у тех моих знакомых, из числа мною опрошенных на предмет аналогичной проблемы, у которых установлена 5-я версия антивирусного пакета Dr.Web, как раз и наблюдаются «странности» с драйвером NUll.sys, – то единственным выходом из сложившейся ситуации остаётся лишь надежда на скорое разрешение проблемы со стороны разработчиков известного антивирусного продукта...

С уважением, Бельянинов Е.А.

Бельянинов Е.А.
Не мог не ответить.

у меня в системе установлен «Microsoft Visual C++2005 Redistributable», «Microsoft.NET Framework_v1.1.4322_Rus», «Microsoft.NET Framework_2_Rus» и «Windows Installer_3».

Всё означенное имеет место присутствовать и у меня, только по другим причинам и NET Framework присутствует аж всех версий (среде Delphi с поддержкой NET нужна одна, "Контур"-у - другая, еще кое-чему - третья и т.д.). И так же пользуюсь Sound Forge 9, правда без плагина... Напомню, что у меня NULL.SYS имеется только в dllcache, а в system32 - нет.
Различие у нас только в установленном ПО, что весьма трудно сравнивать на расстоянии, не видя. Ну откуда я мог предположить, что у Вас Dr.Web и что именно он - виновник? Как видно по ссылке, посты - сегодняшние (вот почему они нам не попадались).
А Евгений Евгеньевичу - respect! Я уже, если честно, голову "сломал". Тем более, что никогда такого не видел (являюсь поклонником ЛК).

Интересен тот факт, что после искусственного удаления из означенных директорий файла NULL.sys и последеющего прогона системы SFC /SCANNOW, этот файл вновь прописался на своих местах...

Да а чему удивляться: sfc проверяет и восстанавливает поврежденные и отсутствующие системные файлы. А раз "у Данилова" что-то там запрограммировано насчет хоть косвенного использования NULL, то система его "возьмет". Только вот откуда-ж нам, простым смертным, об этом знать, пока не упремся в проблему?
Ну а теперь хоть понятно откуда "ветер дует".
Спасибо за собщение! С наилучшими пожеланиями и уважением.