Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Отношение 2000 к императиву "MustDie!" 28.01.02 18:26 Штраф: 20 [ZaDNiCa]
Автор: PnD! Статус: Незарегистрированный пользователь
Отредактировано 28.01.02 18:29 Количество правок: 2
|
Короче, неделю назад поставил на один из ~40 компов в сетке 2000 prof rus sp2 + ie55sp2 (остальная сетка под NT4, PDC+1BDC+3StandAlone+xx WS rus). Комп новый (почти), MSI6309LE5+PIII933+256Mb+20Gb+NVidiaVantaLT16_NoName+SMC1244TX+CDRW philips404. Ставил с дистриба от 31.05.2000 (№билда пока не запомнил)
1. Встала на удивление спокойно, в домен прописалась без проблем, кривых мест за неделю не выявил.
2. Сразу огреб оба бага, с которыми столкнулся еще 1.5 года назад, натягивая дома на P166MMX - спонтанная перезагрузка во время работы с M$IE и периодические глюки трея. Причем баги укрываются где-то между драйверами IDE, Video и TCP-Ip от мелкомякгих (где именно пока не смог узнать, но на сей раз проблема вроде как пофиксилась вырубанием аппаратного ускорения видяхи), а дома, натянув сразу на MS6321DPro дрова от Промиса(RAID)+ATI+Creative, никаких багов за год работы не выявил, кроме дергания трея при перерисовке.
3. А вот это улет полный. В пятницу вечером звонит мне юзер и грустно сообщает, что промазал по сидюку и вырубил повер, после чего шел при загрузке генерит ошибку доступа и обрубается (и т.д., вплоть до выхода из шела). Ну, пошел разбираться.
Для разгона воткнул шелом свой любимый фар - завелся. Экспорер вытыкало четко, и похоже что при работе с реестром в части HKLM. Стал на пробу запускать всякие приложения - рубило все административные приблуды, лезшие в Security. При этом мне(!), рутовому юзеру, это чмо сообщало, что я никаких прав не имею.
Ну, в принципе это должно было решиться подъемом Security из Repair, но т.к. под NT4 я к таким фокусам не привык, то и Repair был только на момент установки. Решив с переливом полного бэкапа повременить, стал перенатягивать 2000 по кускам.
1. Перенатягивание SP2 дало ничего - он теперь "умный" стал и заменяет только ту часть, которую считает устаревшей :(
2. Плюнул и переинсталил 2000 поверху (не сливая дистрибов, просто SP0). После этого все завелось, кроме IE, который пришлось снова переставлять на 55.
3. ЕТМ! Если такое будет происходить хотя бы раз в месяц, поддерживать 2000 даже на 20 машинах нереально. Какого хрена эти уроды из мелкомягкого ХР дрочат, когда у них 2000 до сих пор по швам трещит???
P.S. Кто-нить знает способ аутглюк корректно под 2000 удавить, желательно вместе с локом на кастомайзинг установки IE? В местах типа winguides.com пока ничего не встретил. Или все уже смирились с таким уродством?
PS/2. IE тоже неплохо бы зашибить :)
|
|
Кто модерит то ? ( внутри ) 28.01.02 19:02
Автор: babay <Andrey Babkin> Статус: Elderman
|
> 3. А вот это улет полный. В пятницу вечером звонит мне юзер
> и грустно сообщает, что промазал по сидюку и вырубил повер,
> после чего шел при загрузке генерит ошибку доступа и
> обрубается (и т.д., вплоть до выхода из шела). Ну, пошел
> разбираться.
>
> Для разгона воткнул шелом свой любимый фар - завелся.
> Экспорер вытыкало четко, и похоже что при работе с реестром
> в части HKLM. Стал на пробу запускать всякие приложения -
> рубило все административные приблуды, лезшие в Security.
> При этом мне(!), рутовому юзеру, это чмо сообщало, что я
> никаких прав не имею.
Это говно надо лечить через Recovery Console и лучьше под локальным админом которого использовал до завода тачки в домен. Есть подозрения что в ACL к работе с файлами у доменного админа @#$ня творится.
>
> Ну, в принципе это должно было решиться подъемом Security
> из Repair, но т.к. под NT4 я к таким фокусам не привык, то
> и Repair был только на момент установки. Решив с переливом
> полного бэкапа повременить, стал перенатягивать 2000 по
> кускам.
>
> 1. Перенатягивание SP2 дало ничего - он теперь "умный" стал
> и заменяет только ту часть, которую считает устаревшей :(
> 2. Плюнул и переинсталил 2000 поверху (не сливая дистрибов,
> просто SP0). После этого все завелось, кроме IE, который
> пришлось снова переставлять на 55.
> 3. ЕТМ! Если такое будет происходить хотя бы раз в месяц,
> поддерживать 2000 даже на 20 машинах нереально. Какого
> хрена эти уроды из мелкомягкого ХР дрочат, когда у них 2000
> до сих пор по швам трещит???
Если тачек много - делай административную инсталяшку виндов и обливай её всеми фиксами. А если одна тачка - ничего не поделать :-(( или все равно делай инсаляшку и сливай её на небольшой фатовый раздел в конце диска.
Что до аутглюка и осла 5 - поройся в Regedit.com, только какой шелл ты вместо осла поставить хочешь ? Да и то что они в 2000 запихнули поддержку прорисовки окошек в ядро тоже наверняка даёт свои плоды. хоть осел - хоть станд. эксплорер все равно загдючить на одном месте могёт.
|
| |
Штраф - мой... по кнопке промазал.. старею? 29.01.02 15:23
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
|
|
| | |
Зато - от души :) 29.01.02 21:31
Автор: PnD! Статус: Незарегистрированный пользователь
|
|
|
| |
неплохо бы [DistributedModeratorNick]+[Comment] ( внутри ) 28.01.02 21:15
Автор: PnD! Статус: Незарегистрированный пользователь
|
> Это говно надо лечить через Recovery Console и лучьше под
> локальным админом которого использовал до завода тачки в
> домен. Есть подозрения что в ACL к работе с файлами у
> доменного админа @#$ня творится.
Любопытно. Я-то обычно сразу после постановки фиксов меняю "Administrator" на свою запись доменного админа, т.о. на тачке только одна запись для админа. Для наших условий это нормально катит (у "продвинутых" (крышей :) юзеров права режу на корню вместе с сиди и флопом :), даже инструкцию успел написать по давке ламеров :)
BTW, к Rescue-файлам у NT5 остался по умолчанию full access для everyone - это типа чтобы любопытному билли было легче интересоваться содержимым хостов через немеренные дыры в IE, что ли :)? Тут вот IE55 SP2 поглядел - дыры типа возможности из JS писать в реестр вроде как заткнули, а вот возможность тягать содержимое файлов явно осталась :(.
> Если тачек много - делай административную инсталяшку виндов
> и обливай её всеми фиксами. А если одна тачка - ничего не
> поделать :-(( или все равно делай инсnаляшку и сливай её на
> небольшой фатовый раздел в конце диска.
Ты хотел сказать "в начале"? DOS не отдаст нормально раздел >8.4 Gb
> Что до аутглюка и осла 5 - поройся в Regedit.com, только
> какой шелл ты вместо осла поставить хочешь ?
1.такое ощущение, что это подраздел WinGuide
2.а никакой. У меня 8 юзеров работают с голым рабочим столом и возможностью запускать десяток программ, в число которых IE и аутглюк почему-то не входят :)
>Да и то что они в 2000 запихнули поддержку прорисовки окошек в ядро
> тоже наверняка даёт свои плоды. хоть осел - хоть станд.
> эксплорер все равно загдючить на одном месте могёт.
Интересно, каким местом думали разработчики :( Вполне безглючных дров мне не попадалось со времен блаженной памяти Intel 740 :)
|
| | |
Продолжаем разговор ;-))...(если интересно конечно) 12.02.02 17:17
Автор: babay <Andrey Babkin> Статус: Elderman
Отредактировано 12.02.02 17:19 Количество правок: 1
|
> >Да и то что они в 2000 запихнули поддержку прорисовки
> окошек в ядро
> > тоже наверняка даёт свои плоды. хоть осел - хоть
> станд.
> > эксплорер все равно загдючить на одном месте могёт.
> Интересно, каким местом думали разработчики :( Вполне
> безглючных дров мне не попадалось со времен блаженной
> памяти Intel 740 :)
Они руководствовались совершенно другими вещами :
1.И в НТ ClientServerRun-timeSubSystem и планировщик процессов SystemManagementSubSystem частично работали в режиме ядра и частично в пользовательском режиме и обычно любая из ошибок приводила к синему экрану, эта вся хрень происходила по тому что либо CSRSS либо SMSS ждали освобождения описателя процесса и если описатель освобождался - кирдык.
И решили мелко-мягкие перевести эти службы со всей их прорисовкой окошек в ядро чтоб при переходе из юзерского в режим ядра описатель не отлавливать каждый раз.
А потом те-же серверные процессы тоже используют оконные сообщения для контроня состояния, и даже сервер без интерактивных процессов не может пахать без CSRSS, наверно это был еще один плюс при переводе прорисовки окон в ядро.
Да и вообще (ИМХО) это не такой уж и большой риск, ведь даже если подсистема окон и графики пашет в режиме ядра - то там же пашут и дрова сетевыех карт, напр..
Есть негативный момент - дрова стороннего производителя, но на серваке не надо супер графики и поддержки фирменных наворотов производителя софта и можно оставить виндовые драйвера. С W2kProf все сложнее он может пахать и как графическая станция, по этому с дровами проблемы могут возникнуть.
Да и вообще - на эту тему есть масса мнений и спекуляций по поводу изменения в худшую сторону быстродействия системы из-за того, что GDI и диспетчер окон теперь в ядре, можем эту тему обсудить.
(если интересно конечно)
|
| | | |
Продолжаем разговор ;-))...(если интересно конечно) 19.02.02 15:31
Автор: Glory <Mr. Glory> Статус: Elderman
Отредактировано 19.02.02 15:32 Количество правок: 2
|
> ClientServer
> Run-timeSubS
> ;ystem и планировщик процессов
> SystemManagement<b
> >SubSystem частично
SMSS - Session ManagerSubSystem
> И решили мелко-мягкие перевести эти службы со всей их
> прорисовкой окошек в ядро чтоб при переходе из юзерского в
> режим ядра описатель не отлавливать каждый раз.
SMSS - не работает в режиме ядра, это пользовательский процесс. Только от обычных пользовательских процессов его отличает то, что во-первых он является trusted процессом, в связи с чем, он может, например, создавать маркеры защиты. А во-вторых - он использует не подсистему Win32 а NativeAPI, поскольку при его старте Win32 еще не функционирует, и одна из его задач, как раз и есть запуск Win32.
CSRSS - так же работает в пользовательском режиме, как и любой другой сервис, его стартует SMSS. После завершения инициализации SMSS переходит в бесконечный цикл ожидания описателей процессов Winlogon и CSRSS. Так как это критически важные процессы, в случае их сбоя SMSS вызывет BSOD.
|
| | | | |
Теперь ты меня не понял, я сам виноват... 20.02.02 00:42
Автор: babay <Andrey Babkin> Статус: Elderman
Отредактировано 20.02.02 00:45 Количество правок: 1
|
> > И решили мелко-мягкие перевести эти службы со всей их
> > прорисовкой окошек в ядро чтоб при переходе из
> юзерского в
> > режим ядра описатель не отлавливать каждый раз.
> SMSS - не работает в режиме ядра, это пользовательский
> процесс.
Описался я, говоря "эти службы" я забыл добавить что говорю о Win32 USER GDI и поддержке драйверов ввода-вывода графики , а SMSS & CSRSS я привел в качестве служб которые создавали потоки выполнявшие подпрограммы в режиме ядра и из-за потери описателя процесса при взаимодействии этих служб и видеодров система отваливалась, ессно - SMSS является первым процессом пользовательского режима созданным в системе, по сути только процесс System служит носителем потоков которые выполняются в режиме ядра, а Smss порождается системным потоком отвечающим за последний этап инициализации исполнительной системы и ядра. Но он также запусает процессы Winlogon & Csrss. По умолчанию владельцем системных потоков является процесс System, но дрова могут создавать системные потоки в любом процессе, в том числе в процессе подержки системы напрямую работающим с ядром . Просто непонятка вышла из-за того, что Win2k.sys - драйвер режима ядра включает в себя диспетчер окон, и библиотеку функций для устройств вывода графики ( GDI ) а не уточнил ничего, а просто ляпнул "эти службы" :-(, но суть все равно такая : Win32 USER GDI работают в режиме ядра - они прорисовывают форточки и выводят их на железо, раньше часть процессов выполнялась в Csrss, а часть в режиме ядра - теперь все в ядре.
Еще раз извини что неточно выразился упомянув SMSS и CSRSS и сразу написав после этого:
> >И решили мелко-мягкие перевести эти службы со всей их прорисовкой
> >окошек в ядро чтоб при переходе из юзерского в режим ядра описатель
> >не отлавливать каждый раз.
---
Но я написал это об обсуждаемом вопросе :
> >Да и то что они в 2000 запихнули поддержку прорисовки
> окошек в ядро
---
>Только от обычных пользовательских процессов его
> отличает то, что во-первых он является trusted процессом, в
> связи с чем, он может, например, создавать маркеры защиты.
А вот тут ты не прав, маркеры доступа aka access token object дает не Smss, а Lsass который порождается процессом Winlogon.
> А во-вторых - он использует не подсистему Win32 а
> NativeAPI, поскольку при его старте Win32 еще не
> функционирует, и одна из его задач, как раз и есть запуск
> Win32.
> CSRSS - так же работает в пользовательском режиме, как и
> любой другой сервис, его стартует SMSS. После завершения
> инициализации SMSS переходит в бесконечный цикл ожидания
> описателей процессов Winlogon и CSRSS. Так как это
> критически важные процессы, в случае их сбоя SMSS вызывет
> BSOD.
|
| | | | | |
Lsass... 20.02.02 11:10
Автор: Glory <Mr. Glory> Статус: Elderman
|
> :-(, но суть все равно такая : Win32 USER GDI работают в
> режиме ядра - они прорисовывают форточки и выводят их на
> железо, раньше часть процессов выполнялась в Csrss, а
> часть в режиме ядра - теперь все в ядре.
Согласен.
> А вот тут ты не прав, маркеры доступа aka access token
> object дает не Smss, а Lsass который порождается процессом
> Winlogon.
Это да, но ничего не мешает Smss взять на себя часть работы Lsass ;-))), чего не каждый процесс может сделать. В любом сулчае все сводится к процессу System, который заправляет всеми объектами в системе (System Objects Manager).
|
| | | |
Продолжаем разговор ;-))...(если интересно конечно) 12.02.02 21:34
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
> даже если подсистема окон и графики пашет в режиме ядра -
> то там же пашут и дрова сетевыех карт, напр..
Я почему-то думал, что в НТ/2к/хр дрова работают в 1-м кольце, а ядро - в 0-м. Ошибался, однако! :)
|
| | | |
Продолжаем разговор ;-))...(если интересно конечно) 12.02.02 18:14
Автор: PnD! Статус: Незарегистрированный пользователь
|
> Они руководствовались совершенно другими вещами :
> 1.И в НТ
> ClientServer
> Run-timeSubS
> ;ystem и планировщик процессов
> SystemManagement<b
> >SubSystem частично
> работали в режиме ядра и частично в пользовательском режиме
> и обычно любая из ошибок приводила к синему экрану, эта вся
> хрень происходила по тому что либо CSRSS либо SMSS ждали
> освобождения описателя процесса и если описатель
> освобождался - кирдык.
> И решили мелко-мягкие перевести эти службы со всей их
> прорисовкой окошек в ядро чтоб при переходе из юзерского в
> режим ядра описатель не отлавливать каждый раз.
> А потом те-же серверные процессы тоже используют оконные
> сообщения для контроня состояния, и даже сервер без
> интерактивных процессов не может пахать без CSRSS, наверно
> это был еще один плюс при переводе прорисовки окон в ядро.
> Да и вообще (ИМХО) это не такой уж и большой риск, ведь
> даже если подсистема окон и графики пашет в режиме ядра -
> то там же пашут и дрова сетевыех карт, напр..
> Есть негативный момент - дрова стороннего производителя, но
> на серваке не надо супер графики и поддержки фирменных
> наворотов производителя софта и можно оставить виндовые
> драйвера. С W2kProf все сложнее он может пахать и как
> графическая станция, по этому с дровами проблемы могут
> возникнуть.
>
> Да и вообще - на эту тему есть масса мнений и спекуляций по
> поводу изменения в худшую сторону быстродействия системы
> из-за того, что GDI и диспетчер окон теперь в ядре, можем
> эту тему обсудить.
> (если интересно конечно)
1. Ядро должно быть простым. Сложность - прмой путь к глючности, а для ядра - к падению системы. Наиболее навернутый драйвер как правило для видяхи (и наименее отлаженный, что характерно :). Теперь, чтобы мало не казалось, добавляем до кучи прорисовку форточек. И отправляемся в даун :)
2. Прикол в том, что у меня 2000проф падала с РОДНЫМ (из дистриба 2000) драйвером для ванты лт. После установки детонатора трабл исчез. И, что характерно, 1:1 те же грабли были на старом P166 с S3 Trio 64 - тоже драйвер из дистриба и тоже синие экраны и Спонтанные перегрузы - вот с какой радости система улетает в ребут пока не понял - видимо имеют место ошибки переходов (т.е. скорее всего при определенных условиях стек рушится (!-вот это блин ядро! :)
3. А вот дома на 2000 позавчера решил в героев поиграть. 3-е сообщили про битый дистриб (под NT4 он почему-то целый :), а 2-е спокойно встали, но в неустановленные моменты стали вываливаться. При этом вывод на экран под эксплорером затыкается так, что даже диспетчер задач не вызвать, решалось только выходом из шела (ладно хоть не волшебной кнопкой :).
P.S. А вот кстати затык на PCI-шине (в части IDE) как приводил, так и приводит к резету, даже если заткнулось некритичное устройство типа CD-ROM|CD-RW - драйвер IDE, видимо, ждет чего-то там и не шатдаунится, не то что нахрен отцепить глючную часть. А ведь сие для сервака может быть крайне обломно.
|
| | | | |
Продолжаем разговор ;-))...(если интересно конечно) 18.02.02 16:55
Автор: babay <Andrey Babkin> Статус: Elderman
|
> > Да и вообще (ИМХО) это не такой уж и большой риск,
> ведь
> > даже если подсистема окон и графики пашет в режиме
> ядра -
> > то там же пашут и дрова сетевыех карт, напр..
> > Есть негативный момент - дрова стороннего
> производителя, но
> > на серваке не надо супер графики и поддержки фирменных
> > наворотов производителя софта и можно оставить
> виндовые
> > драйвера. С W2kProf все сложнее он может пахать и как
> > графическая станция, по этому с дровами проблемы могут
> > возникнуть.
> >
> > Да и вообще - на эту тему есть масса мнений и
> спекуляций по
> > поводу изменения в худшую сторону быстродействия
> системы
> > из-за того, что GDI и диспетчер окон теперь в ядре,
> можем
> > эту тему обсудить.
> > (если интересно конечно)
>
> 1. Ядро должно быть простым. Сложность - прмой путь к
> глючности, а для ядра - к падению системы. Наиболее
> навернутый драйвер как правило для видяхи (и наименее
> отлаженный, что характерно :). Теперь, чтобы мало не
> казалось, добавляем до кучи прорисовку форточек. И
> отправляемся в даун :)
Если разговор о простоте - я немного с тобой не согласен - не место прорисовке графики в ядре ( если я правильно понял это твое мнение ), ну ладно, тогда по твоему где ей место в SMP системах, что делать с масштабируемостью системы ? Например в NT 3.5 на тачке с 2 процами при интенсивном использовании GDI за процессорное время конкурировало 4 потока : два CSRSS и два в приложении - и хоть в определенный момент работают только два - их рассогласование вприведет к потере локальности ссылок и синхронизации, и произойдет это скорее всего при переключении потоков с одного камня на другой . В 2000 механизм автопривязки потока пытается выпонить поток на одном проце, увеличивая локальность ссылок и минимизируя потребность в синхронизации кэшей процов, и пусть на здоровье себе прорисовывает графику в ядре, сбоев будет только меньше если меньше будет переходов из режима в режим. Это что касается графики. Совсем отречься от нее и выкинуть её из режима ядра разработчики все равно не смогут т.к. как я уже написал : те-же серверные процессы тоже используют оконные сообщения для контроля состояния системы, и даже сервер без интерактивных процессов не может пахать без CSRSS.
Да и наверняка нельзя в 2000 вывести все сообщения об ошибках на консоль, чтоб не использовать перерисовку системных сообщений.
>
> 2. Прикол в том, что у меня 2000проф падала с
> РОДНЫМ (из дистриба 2000) драйвером для
> ванты лт. После установки детонатора трабл исчез. И, что
> характерно, 1:1 те же грабли были на старом P166 с S3 Trio
> 64 - тоже драйвер из дистриба и тоже синие экраны и
> Спонтанные перегрузы - вот с какой
> радости система улетает в ребут пока не понял - видимо
> имеют место ошибки переходов (т.е. скорее всего при
> определенных условиях стек рушится (!-вот это блин ядро! :)
Наверняка твои проблемы из-за видеодров, а тебе легче бы было если ты узнал бы что стек валится из-за например хреновых дров сетевухи ?
Какая разница от каких дров валится ядро, сам факт конечно что валится - но специфика виндов не позволяет сделать так чтоб эти дрова пахали в пользовательском режиме по тому, что при загрузке для инициализации сервисов они нужны системе, так почему не строить их в ядро ?
>
> 3. А вот дома на 2000 позавчера решил в героев поиграть.
> 3-е сообщили про битый дистриб (под NT4 он почему-то целый
> :), а 2-е спокойно встали, но в неустановленные моменты
> стали вываливаться. При этом вывод на экран под эксплорером
> затыкается так, что даже диспетчер задач не вызвать,
> решалось только выходом из шела (ладно хоть не волшебной
> кнопкой :).
Может это проблема инсталера, с длинными путями и именами ? А затыкался вывод понятно почему.
>
> P.S. А вот кстати затык на PCI-шине (в части IDE) как
> приводил, так и приводит к резету, даже если заткнулось
> некритичное устройство типа CD-ROM|CD-RW - драйвер IDE,
> видимо, ждет чего-то там и не шатдаунится, не то что нахрен
> отцепить глючную часть. А ведь сие для сервака может быть
> крайне обломно.
Для фирменных серваков как правило не бывает этих проблем по тому как если контора берется поддерживать ОС - то и дрова под нее свои выкладывает как правило, но если уж сервак самопальный надо перед сборкой HCL для ОС смотреть. Да может быть обломно если не отключать автозапуск для сидюков, сам много раз напарывался когда при смене пользователя система вываливается :-((
Но взмен сколько адреналина ;-))) когда средь бела дня файлсервер сдох ;-)).
|
|
на самом деле.. 28.01.02 18:34
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
не такая она уж и глючная.. и фич у нее поболее чем в НТ4...
а насчет того что торопятся они - это согласен.. но я их понимаю... денег заработать очень хочется ;-))
|
|
|
подробно о проекте
Анализ криптографических сетевых...
