Windows Object Manager od środka – jak Windows zarządza procesami, plikami i zasobami systemu
Windows Object Manager od środka – jak Windows zarządza procesami, plikami i zasobami systemu
Większość użytkowników Windows postrzega system operacyjny przez pryzmat okien, ikon i aplikacji. Administratorzy patrzą trochę głębiej – widzą procesy, usługi, sterowniki i rejestr. Jednak jeszcze niżej znajduje się warstwa, bez której Windows NT nie mógłby działać w obecnej formie.
Jednym z takich elementów jest Object Manager – komponent jądra Windows odpowiedzialny za zarządzanie obiektami systemowymi.
Nazwa może brzmieć abstrakcyjnie, ale w praktyce oznacza coś bardzo konkretnego: niemal wszystko, czym zarządza Windows, jest traktowane jako obiekt.
Proces, wątek, plik, klucz rejestru, mutex, zdarzenie synchronizacji czy urządzenie sprzętowe – dla jądra systemu są to różne typy obiektów posiadające własne właściwości i zasady dostępu.
To właśnie Object Manager sprawia, że Windows może w jednolity sposób kontrolować tysiące różnych elementów działających jednocześnie.
Dlaczego Microsoft stworzył Object Manager?
W starszych systemach operacyjnych wiele komponentów działało według zupełnie różnych mechanizmów.
Pliki były obsługiwane inaczej niż urządzenia.
Procesy miały własne struktury.
Pamięć była zarządzana osobno.
Problem pojawił się wtedy, gdy systemy zaczęły stawać się coraz bardziej złożone.
Windows NT został zaprojektowany inaczej. Microsoft przyjął podejście obiektowe:
Jeżeli coś jest zasobem systemowym, powinno być reprezentowane jako obiekt posiadający jednolity model zarządzania.
Dzięki temu kernel może stosować podobne mechanizmy dla różnych elementów systemu.
Nie oznacza to oczywiście, że plik i proces są tym samym. Mają inne struktury wewnętrzne. Łączy je jednak wspólny sposób obsługi przez jądro.
Czym jest obiekt w Windows?
Obiekt w Windows Kernel Mode to specjalna struktura danych zarządzana przez Object Manager.
Każdy obiekt posiada między innymi:
- typ obiektu,
- nazwę (jeżeli została nadana),
- informacje o zabezpieczeniach,
- licznik odwołań,
- informacje o właścicielu,
- dane specyficzne dla danego typu.
Przykład:
Gdy uruchamiasz program, Windows nie tworzy po prostu „procesu”. Tworzony jest obiekt typu Process Object.
Gdy program otwiera plik, system tworzy odpowiedni obiekt reprezentujący uchwyt do tego zasobu.
Handle – klucz do obiektów Windows
Jednym z najważniejszych pojęć związanych z Object Managerem jest handle.
Użytkownik często nie zdaje sobie sprawy, że aplikacje praktycznie nigdy nie operują bezpośrednio na obiektach systemowych.
Zamiast tego otrzymują uchwyt.
Przykład:
Program chce otworzyć plik.
Nie otrzymuje bezpośredniego dostępu do dysku.
Windows wykonuje mniej więcej taki proces:
- aplikacja wysyła żądanie otwarcia pliku,
- system sprawdza uprawnienia,
- Object Manager tworzy lub odnajduje odpowiedni obiekt,
- aplikacja otrzymuje handle,
- dalsze operacje wykonywane są przez ten uchwyt.
Handle jest więc czymś w rodzaju kontrolowanego „biletu dostępu”.
Program wie, którego zasobu używać, ale nie zna jego wewnętrznej reprezentacji w jądrze.
Dlaczego handle są ważne dla bezpieczeństwa?
Gdyby aplikacje otrzymywały bezpośredni dostęp do zasobów systemowych, jeden błąd programu mógłby całkowicie destabilizować Windows.
Model z uchwytami ogranicza takie ryzyko.
Proces działający w User Mode:
- nie zna adresów struktur kernela,
- nie może dowolnie modyfikować obiektów,
- musi korzystać z kontrolowanych wywołań systemowych.
To jeden z fundamentów separacji User Mode i Kernel Mode.
Object Namespace – ukryty system plików Windows
Jedną z najciekawszych funkcji Object Managera jest Object Namespace.
Windows posiada wewnętrzną przestrzeń nazw obiektów, która przypomina system plików.
Nie jest ona widoczna podczas normalnej pracy użytkownika, ale kernel korzysta z niej cały czas.
Można znaleźć tam między innymi:
\Device
\Driver
\BaseNamedObjects
\Sessions
\KnownDlls
To nie są zwykłe katalogi na dysku.
Są to logiczne przestrzenie nazw obiektów zarządzanych przez jądro.
Przykładowo urządzenie dyskowe może być reprezentowane jako obiekt znajdujący się w przestrzeni:
\Device\HarddiskVolume
Dopiero później system tworzy przyjazne dla użytkownika ścieżki typu:
C:\
Dlaczego C:\ nie jest prawdziwą nazwą dysku?
To ciekawy przykład działania warstw Windows.
Użytkownik widzi:
C:\Windows\System32
Ale kernel operuje na bardziej niskopoziomowych nazwach urządzeń.
Litera dysku C: jest tylko symbolicznym odwołaniem.
Za kulisami Windows korzysta z mechanizmu symbolic links zarządzanego przez Object Manager.
Można powiedzieć, że użytkownik korzysta z uproszczonej warstwy abstrakcji, a kernel pracuje na rzeczywistych obiektach systemowych.
Jak Object Manager kontroluje dostęp?
Sam fakt istnienia obiektu nie oznacza, że każdy może go używać.
Każdy obiekt może posiadać deskryptor zabezpieczeń (Security Descriptor).
Zawiera on między innymi:
- właściciela obiektu,
- listę ACL,
- prawa dostępu.
Przykład:
Zwykły użytkownik może:
- otworzyć dokument,
- uruchomić aplikację.
Ale nie powinien mieć możliwości:
- zatrzymania krytycznej usługi,
- modyfikacji sterownika,
- dostępu do pamięci innego procesu.
Decyzja jest podejmowana właśnie poprzez mechanizmy bezpieczeństwa systemu.
Co dzieje się podczas zamykania programu?
Załóżmy, że zamykasz aplikację.
Proces nie znika natychmiast.
Windows musi sprawdzić:
- czy istnieją jeszcze uchwyty do obiektów,
- czy inne komponenty korzystają z zasobów,
- czy można bezpiecznie zwolnić pamięć.
Object Manager wykorzystuje między innymi mechanizm reference counting.
Każdy obiekt posiada licznik odwołań.
Jeżeli licznik spadnie do zera, system może usunąć obiekt i zwolnić związane zasoby.
To chroni Windows przed sytuacją, w której jeden komponent usunie coś, czego nadal używa inny.

Jakie obiekty zarządza Object Manager?
Lista jest znacznie dłuższa, niż większość użytkowników przypuszcza.
Przykładowe typy obiektów:
| Typ obiektu | Zastosowanie |
|---|---|
| Process | uruchomione programy |
| Thread | wątki wykonywania |
| File | dostęp do plików |
| Token | uprawnienia użytkownika |
| Event | synchronizacja procesów |
| Mutex | blokowanie zasobów |
| Section | współdzielona pamięć |
| Device | urządzenia sprzętowe |
| Driver | sterowniki |
| Symbolic Link | przekierowania nazw |
Dzięki temu wiele mechanizmów Windows korzysta z jednego spójnego modelu.
Object Manager a narzędzia administracyjne
Administratorzy mogą częściowo obserwować działanie Object Managera za pomocą specjalistycznych narzędzi.
Przykładem jest:
- Process Explorer,
- WinDbg,
- Sysinternals Suite.
Pozwalają one zobaczyć:
- otwarte uchwyty procesów,
- obiekty synchronizacji,
- załadowane sterowniki,
- zależności między procesami.
Dla osób zajmujących się diagnostyką systemu są to często znacznie bardziej wartościowe informacje niż sam Menedżer zadań.
Dlaczego Object Manager ma znaczenie dla bezpieczeństwa?
Wiele ataków wykorzystujących Windows próbuje manipulować właśnie obiektami systemowymi.
Przykłady:
- przejęcie uchwytów,
- eskalacja uprawnień,
- manipulacja tokenami bezpieczeństwa,
- wykorzystanie błędów w sterownikach.
Jeżeli atakujący uzyska dostęp do obiektów działających w Kernel Mode, może przejąć znacznie większą kontrolę nad systemem.
Dlatego ochrona jądra Windows jest jednym z najważniejszych elementów współczesnego bezpieczeństwa systemów Microsoft.
Podsumowanie
Windows Object Manager to jeden z tych komponentów, których użytkownik nigdy nie widzi, ale korzysta z niego przy każdej operacji wykonywanej w systemie.
Otwieranie pliku, uruchamianie programu, komunikacja między procesami czy dostęp do urządzenia – wszystkie te działania przechodzą przez model obiektów zarządzanych przez kernel.
Największa zaleta tego rozwiązania polega na spójności. Niezależnie od tego, czy system zarządza plikiem, procesem czy urządzeniem, korzysta z podobnych mechanizmów kontroli dostępu, nazewnictwa i cyklu życia obiektów.
To właśnie takie elementy architektury Windows NT sprawiają, że system może obsługiwać współczesne komputery, serwery i ogromne środowiska firmowe bez utraty stabilności.






