Windows XP не се стартира след обновяване на McAfee

Posted on | April 21, 2010 | No Comments

Днес стана ясно, че след обновяване на DAT 5958 файл на антивусната програма McAfee разпознава svhost.exe на Windows XP SP3 като вирус w32/wecorl.a. Тревогата е фалшива, но файлът се изтрива или поставя под карантина и създава проблеми при стартиране на операционната система.  Последствията са син екран с безкрайно рестартиране, изключване  след поява на RPC или DCOM грешка. Проблемното обновяване е оправено за по-малко от 4 часа, но е засегнало хиляди компютри по света, включително и такива в болници.

Решението на проблема е преименуване или изтриване на файла с антивирусните дефиници и копиране на svhost.exe.  Примерни стъпки:

1. Стартиране на Windows в Safe Mode (натиска се F8 преди да се покаже анимацията за зареждане на Windows XP).
2. В C:\Program Files\McAfee\VirusScan се изтрива директорията (папката) DAT.
3. Копира се svhost.exe от dllcache в system32. За да се получи през Windows Explorer (или My computer) е нужно в настройките да се укаже да се показват скритите и системни директории. Друга възможност е стратиране на cmd.exe. Най-вероятно това ще е възможно само през Task Manager-a, който се стартира с клавишната комбинация CTR+ALT+DEL или CTR+SHIFT+ESC. След това от менюто се избира File -> New Task (Run).  Въвежда се cmd, след като се стартира се пише следната команда:

copy %systemroot%\system32\dllcache\svchost.exe %systemroot%\system32\

Ако в dllcache не съществува копие на svhost.exe е възможно да е създадено такова от System Restore. Директорията се казва SystemVolume Information и е скрита. Също така за да е достъпна не е достатъчен администраторски, а е нужен системен акаунт. Това може да реши по два начина. Единият е да се ползва ERD Commander (вече е част от пакета Misrosoft Desktop Optimization Pack – накратко MDOP). Другият е да се стартира cmd.exe или explorer.exe със системни привилигии с използването на tool като PSExec от SystemInternals. Друго възможно място, където е вероятно да има копие на C:\WINDOWS\servicepackfiles\i386\.

Стъпка 3 може да се пропусне или ако е неуспешна да се направи проверка интегритета на системнте файлове с командата:

sfc /scannow

Изпълнява се отново в командния интерпретатор (cmd). При липса на файлове в C:\Windows\system32\dllcache e възможно да поиска инсталационен диск с Windows XP SP3.

За корпоративните си клиенти McAfee са създали улеснение: SuperDAT. Стартира се също oт Safe Mode или се следват предписанията на Microsoft за стартиране чрез зареждане през мрежа или от преносим носител. За повече информация – сайта на McAfee.

Защо Intel Light Peak няма да измести USB 3

Posted on | April 18, 2010 | No Comments

Според Intel и много коментари в интернет Light Pеак ще измести USB 3. Има няколко причини, заради които аз се съмнявам това да стане (най-вече в близкото бъдеще).

Преминаването към USB 3 ще стане без допълнителни усложнения. Това е вече наложил се стандарт обратно съвместим с предишните си версии. Устройствата поддържащи го са милиони. Предлага висока скорост за съвременните стандарти от 4.8 Гб/с. От своя страна Light Peak в началото ще предлага над два пъти по-голяма скорост за предаване на информация 10 Гб/с с възможност за следваща версия на стандарта, която да позволява до 100 Гб/с. Доста впечатляващо нали? Но! Light Peak  е оптична технология. За нея са нужни оптични влакна, преобразователи на електрическите сигнали в светлинни и обратно,  също така контролери. Това със сигурност го изпраща в по-висок ценови клас. Поради високата си цена и слабата си разпространеност в началото ще бъде вграждан само по 1 на дънна платка. Масовите съвременни дъна са с 12 и повече USB. Също заради високата си цена и по-високата си сложност за реализация едва ли ще се предпочита в преносимите устройства. Все още не е ясно дали ще може да зарежда такива устройства, защото към момента е невъзможно заради липсата на медни проводници. Вероятно ще бъдат добавени такива, защото Intel вече правят такива опити, но не е ясно кога евентуално ще бъдат добавени в стандарта.

Защо /dev/random не работи?

Posted on | April 18, 2010 | No Comments

/dev/random е файл на знаково устройство за генериране на случайни числа (символи). Получават се чрез т.нар. шум в обкръжението. Това означава, че в компютъра трябва да настъпват случайни събития. Това звучи доста елементарно на човек без достатъчно ИТ знания, но реално е сложно за една компютърна система. Такави случайни събития могат да бъдат трафик на мрежовата карта и работата с клавиатурата и мишката. Макар и да могат да се предвидят или манипулират до някаква степен честота на натискане на клавишите или на трафика се смятат за такива.

Най-често причината за да “не работи” /dev/random е липсата на случайни събития в система. Проверка може да се осъществи с проверка на entropy pool:

$ cat /proc/sys/kernel/random/entropy_avail

При липса решение може да бъде използването на /dev/urandom. Трябва да се отбележи, че тук се генерират псевдослучайни числа и на теория са възможни криптографски атаки. За сметка на това липсва блокирането при random. От тук идва и името на файла u(nlocked)random.

Скоростта на двата метода може да сравним нагледно по следният начин:

$ hexdump /dev/random,

след което изпълняваме:

$ hexdump /dev/urandom.

Доста добре се вижда как в първият случай случайните числа се генерат сравнително бавно, в замисимост от шума. Споменах вече как може да се генерира такъв. Във втория получаваме незабавно  голям брой случайни числа.

Linux е първата операционна система, в която е имплементиран такъв генератор на случайни числа. Във всички останали (*Unix, *BSD, MAC OS, Solaris) към този момент при наличие на /dev/random работи както /dev/urandom в Linux. В почти всички за реализацията се използва Yarrow алгоритъм.

Linux срещу Windows – първа част

Posted on | April 9, 2010 | 2 Comments

Windows и Linux са безспорно най-коментираните операционни системи последните 4-5 години. Тук няма да пиша, за това коя е по-удобна, красива и т.н. По-скоро ще отбележа и коментирам някои технически характеристики.

За начало ще отбележа, че под операционна система (ОС) тук ще приема, че е системният софтуер, който се грижи за управлението на ресурсите в компютърната система. Ресурсите могат да бъдат, както хардуерни (процесор, оперативна памет, шина, порт и т.н.), така и софтуерни (програми). Шелове, компилатори и системни библиотеки ще бъдат съвсем бегло споменати. Друго, което искам да отбележа е, че ще разглеждам ядрата на операционните системи по-често не по имената им, а по номерът им. Например Windows 6.0 отговаря на Windows Vista и Windows Server 2008, Windows 6.1 на Windows 7 и т.н. Когато пиша за Windows ще е предимно за десктоп версии и на места ще отбелязвам разлики със сървърните. Ще разглеждам предимно Windows с ядра 6.0 и 6.1 и Linux след 2.6.28. Когато коментирам други версии ще отбелязвам.

На архитектурно ниво двете ОС са колкото различни, толкова и подобни. Не е голяма грешка да се каже, че двете са с монолитни ядра. Разбира се според Microsoft Windows не е монолитна операционна система, а хибридна и съчетава добрите качества на микроядрата и монолитните. Както Linux, така и Windows осигуряват голяма абстракция от хардуера. Ядрата им са сравнително големи за микроядра, въпреки че позволяват зареждане на модули (драйвери) по време на работа. Въпреки, че всеки модул е отделен, всички се изпълняват в едно пространство – на ядрото. Това е основен недостатък на монолитните ядра – възможно е при грешка на един от модулите да доведе до неработоспособност цялата система. От гледна точка на сигурността на теория микроядрото трябва е много по-сигурно от монолитното. Практиката доказа друго – имплементирането на добър монолитен дизайн може да бъде достатъчно сигурен. Най-големият плюс на монолитните е сравнително по-лесното имплементиране и по-високата производителност. Двете ОС позволяват зареждане на модули от потребителско пространство, но Linux има възможност за зареждане на модули за файлови системи, докато в Windows не ми е известна такава възможност без ползване на външен софтуер.

Твърди се, че Windows е изцяло обектно-ориентирана операционна система. Аз лично не съм напълно убеден в това. Причината е, че не малка част от нея е написа на езикът C, а той не поддържа директно обектно-ориентирани конструкции.

От гледна точка на системни извиквания Linux предоставя около 330 (пиша по памет може да греша). При Windows са с около стотина повече.  Приложно-програмният интерфейс (API) в Linux се нарича Linux, а в Windows се нарича WinAPI или Win32 (разликата с Win16  и Win64 не е голяма).  Обикновено в Linux се говори за системни извиквания докато в Windows за библиотечни. В Linux основната библиотека, изпълняваща функцията на врапер е glibc. При Windows са C runtime, Win32 и Native API. Native в по-голямата си част е недокументирана. Разбира се Windows не поддържа Linux API, но Linux с инсталиран Wine поддържа Windows API. Linux поддържа POSIX API, а в Windows се инсталира допълнително.

Важен критерий при избор на операционна система е подръжката на хардуерни платформи. Windows поддържа единствено x86 и ADM64/x86_64. Linux поддържа почти всички известни. Двете ОС имат възможност за стартиране, както на еднопроцесорни машини, така и на многопроцесорни и многоядрени. Освен това са съвместими както с BIOS, така и с EFI. Единствената разлика е, че при Linux ядрото обикновено е файл с име vmlinuz и няма значение на какъв хардуер се стартира. При Windows не е така. При него  файлът се казва NTOSKRNL.EXE на еднопроцесорна машина без PAE и NTOSKRNLPA.EXE с PAE. Когато системата е многопроцесорна без PAE се казва NTOSKRNLMP.EXE, съответно с PAE – NTOSKRNLPAMP.EXE. Всъщност не е точно така, тъй като в зависимост от лиценза, с който е закупен Windows може да е ограничен в броя на процесорите/ядрата, които използва.

Често се твърди, че силата на GNU/Linux е в конзолата. В първите години от развитието си наистина в Linux графичните среди отстъпваха по развитие и простота на Windows. Това вече не е така. Има поне 2 графични среди, които освен, че не отстъпват по нищо на Windows, а според мен са по-интуитивни и по-напреднали. Това са KDE и GNOME. Какво общо има това с ядрата ли? – Част от графичната система на Windows е в ядрото. Обикновено драйверите в Linux се пишат от общността и при желание се инсталират драйвери със затворен код на самите производители, тъй като те рядко пишат драйвери с отворен код. При Windows положението е съвсем различно – драйверите се пишат от производителите и рядко от ентусиасти.

Как става така, че можем да пускаме по няколко програми едновременно на един компютър? – Постига се с малка измама от страна на многозадачните операционните системи, каквито са Wndows и Linux. За това малко по-надолу. Когато се изпълнява една програма се нарича процес. Освен ресурсите, които притежава този процес в него има най-малко една нишка.  Според дефиницията на Sun нишката не e нищо повече от лек процес. При използване на нишки се пестят много ресурси. Най-вече това са памет (споделят големи пространства памет) и процесорно време (превключването между нишки може да бъде стотици, дори хиляди пъти по-бързо от процесите). В Windows нишката е единицата, за която се разпределя процесорно време. Тъй като Linux различава нишка и процес, но не прави разликa  обикновено се говори за задача (task).  В Linux моделът за реализиране на нишки е 1х1. Това значи, че всяка нишка от потребителското пространство отговаря на такава в пространството на ядрото. В Windows модела е MxN, което значи, че броят на нишките в двете пространства на паметта не съвпадат. Както стана ясно двете операционни системи поддържат нишки на потребителско и на ниво ядро.  Според спецификацията на Microsoft нишките на потребителско ниво се наричат фибри.

Ако все още не сте се досетили как става така, че ползваме много програми едновременно, това става най-просто казано с многократно превключване между тях без да усетим. Това се извършва от т.нар. разпределител на процесорното време (също се нарича планировчик, подсистема за планиране или разпределяне на процесорното време и т.н.).Разпределителя на процесорното време е една от най-важните части на ОС и затова често бива обсъждан и сравняван с такъв на други операционни системи. Основната разлика към момента между подсистемата за планиране на процесора в Linux и Windows, е че първият е замислен за да бъде справедлив, докато втория е мултимедийно ориентиран. Двата са приоритетно ориентирани. Това значи, че една програма може да се изпълнява с по-висок приоритет от друга. Също така различават интерактивните задачи. Кога една задача е интерактивна? – Интерактивна е когато чака много входно-изходни операции, например Word от пакета МС Office, която чака вход от клавиатурата и мишката. Интерактивните задачи получават по-висок приоритет от интензивно натоварващите процесора. Инзивно натоварваща процесора задача може да бъде гледането или конвертирането на филм. Какво значи по-висок приоритет? – Това значи, че задачата ще има по-голям отрязък от време, в което използва процесера, освен това  вероятно ще бъде по-често изпълнявана от по-ниско приоритетните. Целта е да не настъпи т.нар. “процесорен глад” и с горните два примера, ако пуснем едновремено да гледаме филм и да пишем текст, да не стане така, че писането да е невъзможно.

В Windows задачите се изпълняват от висок приоритет към нисък, докато при Linux редът на изпълнение на опашката със задачите е от приоритет означен с малка цифра към приоритет с по-голяма цифра. Приоритетите в Linux са от 0 до 139, а в Windows от 31 до 1 (0 е т.нар. празна нишка). Всяко приоритетно ниво има собствена опашка със задачи. Така не е проблем да има задачи с еднакъв приоритет. Тогава те се изпълняват в кръгова дисциплина и след това се преминава към следващото ниво.

В Linux съществуват 4 класа за планиране нa процесора, докато в Windows са само 2. Първият клас това са задачите с нормален приоритет. Повечето задачи са такива. В двете операционни системи тези приоритети са  динамични. В Windows това са приоритени нива от 1 до 15, а в Linux от 100-139. Вторият е приоритет “реално време”.  По принцип има два типа реално време – меко и твърдо. В Linux и Windows е реализирано единствено меко реално време. Разбира за Linux съществува пач, с който може да се добави поддръжка на твърдо  реално време. При Windows положението е по -сложно. Windows NT независимо десктоп или сървър няма такава възможност – eдинствено Windows CE.

Дебъгване на Windows

Posted on | January 27, 2010 | 2 Comments

Дебъгването не е съвсем тривиален процес. От друга страна за елементарни проблеми не са нужни сериозни познания по операционни системи, хардуер и т.н. Процесът се опростява, колкото може повече с излизането на нови версии на ОС и инструменти.

Ще започна от това какво представлява дебъгването накратко. Всъщност самото име говори достатъчно за значението на процеса, а именно – остраняване на бъгове (грешки).  Възможни са два типа дебъгване – на потребителско ниво (user space) и на ниво ядро на операционната система (kernel space). Тук ще пиша накратко за дебъгване предимно на проблеми с драйвери (kernel space) и по-рядко библиотеки, които водят до нестабилна работа на системата (рестартиране, сини екрани, зависвания и др.).

Първата и най-важна стъпка при проблеми със стабилността на операционната система (в този случай Windows) е проверка на конфигурацията ?, за това, как се държи при такива проблеми. Това може да стане от Control Panel -> System ->Advanced System Settings -> Advanced -> Startup and Recovery ->Settings.

Интерисува ни полето  System failure  и най-вече как ще се записва информацията при възникване на критична грешка.

Възможностите и избора по подразбиране се различават при различните версии на  Windows. Първата възможност е да не се записва никаква информация. Разбира се напредналият потребител никога не я използва.

Втората е Small memory dump (64 KB). При неин избор се записва най-необходимата информация за последващо дебъгване: съобщението за грешка,  списък на драйверите, контекста, процеса и нишката. При настъпване на следваща грешка се записва друг файл. Форматът на името на файла е следният: Mini012610-01.dmp – 26 януари 2010 година, първа грешка. Файловете се записват в %SystemRoot%\Minidump. В повечето случаи това е C:\Windows\Minidump. Разбира се може да се промени, но не винаги е възможно в графичен режим и едва ли човек, способен да промени системни променливи или къде да се записва mini dump ще чете това, затова пропускам обясненията. Важно е да се отбележи, че за да се извърши операцията е нужно наличието на поне 2 MB pagefile на системния логически дял на твърдият диск.

Следващата възможност е Kernel memory dump. Записва се всичко на ниво kernel space, което е в оперативната памет. Паметта, заделена за потребителските програми не се записва. По подразбиране информацията се записва в %SystemRoot%\MEMORY.DMP. Както се вижда на изображението по-горе има възможност при следваща грешка да се презапише върху същия файл. Нужният минимум за pagefile в този случай варира, но в никакъв случай не е повече от 2 GB.  Според мен това е най-подходящият избор в повечето ситуации.

Последната възможност е Complete memory dump. Записва се цялото съдържание на оперативната памет към момента на фаталната грешка. Файлът по подразбиране е същият, както при Kernel memory dump. Необходимият минимум на  pagefile в този случай е обемът на RAM паметта плюс 1 MB. Логично, това е най-добрият избор при дебъгване на големи проблеми. Сравнително често е ненужен. Аз лично го избягвам, защото е доста бавен процес и в повечето случаи съдържа много излишна информация за  нуждите ми.

Изброените настройки могат да се редактират директно в регистрите на Windows. Пътят до тях е: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl.  Горните четири възможности отговарят на следните стойности:

CrashDumpEnabled REG_DWORD 0×0 –> None
CrashDumpEnabled REG_DWORD 0×1 –>  Complete memory dump
CrashDumpEnabled REG_DWORD 0×2  –> Kernel memory dump
CrashDumpEnabled REG_DWORD 0×3 –> Small memory dump (64KB)

След като имаме нужната информация за дебъгване остана само да се сдобием със софтуер, с който се дебъгва. Пакетът се казва Debugging Tools for Windows и съдържа WinDbg, KD, CDB, и NTSD. Би трябвало да  се сетите откъде да си го свалите, ако не – ползвайте “фирменият сайт на фирмата Google”. Нас ни интерисуват WinDbg и KD. WinDbg е графичен аналог на конзолният дебъгер – KD. Разлика във функционалността им няма. Въпрос на предпочитания е изборът между двата. Въпреки, че по принцип предпочитам конзолата по принцип, WinDbg последно време е моят избор.

След като изтеглите и инсталирате Debugging Tools for Windows стартирайте WinDbg. След което е нужна настройка на symbols. Може да стане от File ->Symbol File Path. Ще се появи прозорец, подобен на изображението долу. По принцип се въвежда локална кешираща директория, последвана от symbol сървъра на Microsoft.  Аз ползвам C:\symbols за локално копие. Когато е нужно програмата търси първо там, а след това, ако се наложи сваля от сървъра. Ако решите да изтеглите пълен архив на символите можете  да  посочите само него. Обратното също е възможно. Може да посочите  отдалеченият сървър  без да записвате  локални копия. Синтаксисът е следният: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols.

Вече сме готови за дебъгване. Стартираме WinDbg. Отиваме на File->Open Crash Dump. Aз ползвам WinDbg версия 6.11.0001.404. При нея в момента на отваряне на dump файла автоматично се стартира команда !analyze и единственото, което трябва да направим е да изчакаме малко и да прочетем изхода. По-старите версии, които съм ползвал не изпълнняваха никакви команди, а чакаха да се въведе команда в командното поле в долният край на прозореца.  !analyze е винаги първата команда, която се изпълнява при дебъгване, защото може да е достатъчна.  Аналог на зареждането на дъмп-а на паметта в конзолата е:

kd -y srv*c:\symbols*http://msdl.microsoft.com/download/symbols -i c:\windows\i386 -z c:\windows\minidump\minidump.dmp.

При желание може kd да се замени с WinDbg. Ако изходът от командата ви подсказва грешка в Windows не и вярвайте! Колкото и да се говори, че Windows е “скапана” операционна система, истина е съвсем друга. Тя е една от най-добрите ОС. В над 90 % процента от случайте проблемите идват от външен софтуер. Самата ОС се тества всеки ден от специалисти, до чиито знания и опит простосмъртните никога няма да достигнат.

Няколко насоки:

• aко искате да видите разширен изход (verbose output) от комндата използвайте опция -v;
• ако искате да прочетете грешката и параметрите използвайте !analyze -show;
• за извеждане на заредените модули (драйвери): lm nt;
• разгледайте  lm, !process, !thread и !devstack

Това е от мен. Не очаквах да стане толкова дълго писанието и затова притрупах нещата накрая.

Обновяване на Gentoo

Posted on | January 25, 2010 | No Comments

Дълго време (1-2месеца) не бях си обновявал дистрибуцията. Не за друго, просто не ми остава време. Единствено програмите и библиотеките, които имаха проблеми със сигурността, обнявявах през този период. Това е така, защото съм свикнал всичко да е под мой контрол и да проверявам всичко, за да знам какво става в система, независимо, че не не е важен сървър или работна станция. Всъщност това е основен проблем на начинащите системни и мрежови администратори. Не знаят какво се случва на системата им. В същото време разменят “работещи” конфигурации и скриптове. Обратно към темата… Количеството пакети, които трябваше да обновя беше над 400. Сред тях имаше такива, които бяха блокирани от зависимости с други пакети. Проблемите се решиха лесно, чрез деинсталиране на отпадналите пакети и обновяване на други.

Извод: При внимателно четене на изхода от дадени команди и елементарни познания Gentoo не е толкова сложна ГНУ/Линукс дистрибуция, колкото се твърди в мрежата.

Честит Рожден Ден Линус!

Posted on | December 28, 2009 | No Comments

Днес има Рожден ден, един от най-великите хакери – Линус Торвалдс. Това е човек, за който може да се каже, че е и ще бъде част от историята на ИТ света. Linux Jurnal са написали статия за случая.

Как се стартира Windows

Posted on | December 28, 2009 | No Comments

Разбирането на процеса на стартиране на една операционна сиситема (в лучая Windows) е изключително важно при разрешавана на проблеми, свързани със зареждането й. В последно време ми се налага по-често да дебъгвам проблеми на “Джам” ОС и затова ползвам нещо като  план с елементарните ми познания по въпроса. Пускам го без редакция. Предварително се извинявам за вида, в който го публикувам.

1. mbr
2. boot sector
3. boot loader (ntldr)
*преминава от 16-bit към 32-bit режим и включва paging
*ако съществува зарежда Ntbootldd.sys
-използва се, ако е от SCSI disk
*чете boot.ini
- точки за достъп до зареждащи дялове
- ако има повече от един избор се появява меню с отброяване на време

*ако се избере 64-bit ОС, превключва в 64 битов режим
*F8 за специално меню за зареждане
*Ntdetect.com осъществява BIOS хардуерно откриване
- след това записва (по-късно) в: HKLM\Hardware\Description

*SYSTEM регистрите се зареждат
- зарежда драйвери: критично важни за зареждажият процес (например драйвера за файловата система)

*Ntoskrnl.exe и неговите dll`s
*прехвърля контрола на Ntoskrnl.exe
4. ОС
*splash screen се визуализира
*2 фази на инициализация на ядрото
*зарежда стартиращите драйвери (boot-start drivers)
* чете регистрите и зарежда system-start drivers
* създава процеса за управление на сесиите [Session Manager(Smss.exe)]
??ред на зареждане на драйвеи и сервизи
-дефинирани са с уникални ключове в регистрите
-HKLM\System\CurrentControlSet\Services
type 1 -драйвер
type [друго] – сервиз

0=boot
1=system
2=auto
3=manual
4=disable
повечето plug and play драйвери са на manual
5. Менаджер на сесиите
*стартира BootExecute програмите
-Autochk.exe (проверка на диска)
-тук е мястото, където най-често се стартира malware
*започва процес на отложени премествания и преименувания на файлове (например при updates)
*отваря paging файловете
*инициализира останалите регистри
!!!=>до този момент, ако се получи срив, той няма да се отрази в dump
*зарежда Win32k.sys драйвера
- kernel mode на прозоръчната система (windowing system)
*стартира Csrss.exe процеса
- user mode на прозоръчната система
*стартира Winlogon.exe
-интерактивен процес на влизане в системата (logon)
6. Прозоръчната система
*Csrss.exe инициализира прозоръчната система
*системата преминава към GUI режим
*показва се курсора
7. Идентификация и сървър за сигурност
*Winlogon.exe стартира Lsass.exe
- Local Security Authority
- осъществява идентифициране
*старира GINA.dll
-по подразбиране е Msgina.dll
-показва logon полето
*стартира Services.exe (Servece Control Manager)
??процес на влизане в системата
-Winlogon.exe изпраща потребителското име и парола на Lsass.exe
-създава инициализиращ(и) процес(и)
-по подразбиране Userinit.exe
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\Userinit
8. Стартиране на сервизите
*Services.exe стартира сервизите, които са auto
*повечето user mode процеси
*тук могат да се заредят и някои kernel mode драйвери (за записване на дискове софт.,антивирус.)
*продължава асинхронно зареждане

Това е. При проявен интерес, ще форматирам текста в разбираем вид. В различните версии на операционната система има леки разлики. Например след NT 6.0 (Windows Vista, 7, server 2008 и т.н.) ntldr се заменя от Windows Boot Manager (BOOTMGR) и winload.

Весела Коледа!

Posted on | December 25, 2009 | No Comments

Скъпи приятели и читатели, пожелавам Ви прекрасни и незабравими мигове през Коледните и Новогодишните празници. Нека всички Ваши желания да се сбъднат и всяко Ваше начинание да бъде успешно.

Покани за Google Wave

Posted on | November 25, 2009 | No Comments

Имам 8 покани за Google Wave. Желаещите да пишат тук или в jabber.