Les services du NT Executive tournent aussi en mode noyau. Ce sont donc des parties importantes, indispensables au système d'exploitation. Leur rôle est de fournir les services de base aux sous-systèmes d'environnement.

• l'Object Manager, ou Gestionnaire d'Objets
  Sous Windows NT, tout est représenté sous forme d'objet : un processus, une thread, un périphérique quelconque sont des objets. Chaque objet contient une ACL : Access Control List, Liste de Contrôle d'Accès, une liste définissant les droits que les autres objets ont sur lui. Pour travailler avec un objet, on utilise un handle. Ce handle est une référence représentant l'objet. Il contient notamment un pointeur sur l'objet ainsi que les droits que l'on possède sur cet objet. C'est le gestionnaire d'objets qui fournit tous les handles que les autres objets lui demandent.
  Les objets sont créés, modifiés et supprimés par le gestionnaire d'objets.
  Le gestionnaire d'objets supprime les objets orphelins. Un objet ne doit exister que s'il est utilisé. Le gestionnaire d'objet compte le nombre d'objets utilisant chaque objet. Quand ce nombre arrive à zéro, l'objet n'est plus utilisé, donc supprimé.
  Le gestionnaire d'objet veille à ce que chaque objet ne consomme pas trop de ressources.
• le Process Manager, ou Gestionnaire de processus
  Son rôle est de créer, modifier l'état et supprimer les threads. Il renseigne sur l'état de chaque thread. Son rôle n'est pas de cadencer les threads. Tout processus contient au moins une thread initiale, dans laquelle tourne effectivement le programme.
• le Virtual Memory Manager, ou gestionnaire de mémoire virtuelle
  Son rôle est d'allouer 4 Go d'espace mémoire à chaque processus, indépendamment de l'espace mémoire effectivement disponible sur le système. Sur ces 4 Go, 2Go seront réservés au système, les deux restants seront à la disposition du programmeur. Sur les systèmes contenant suffisamment de mémoire, il sera possible d'allouer plus d'espace pour la partie applicative (donc moins pour le système).
  Il s'assure que chaque application reste dans son espace d'adressage attribué.
  C'est le gestionnaire de mémoire virtuelle qui gère le swap. Les programmes demandent des pages mémoire au gestionnaire. Le gestionnaire leurs fournit, qu'elles soient en mémoire vive ou swappées. Le programmeur n'a pas à s'en soucier (manquerait plus que ca ! )
• le LPC : LPC : Local Procedure Call, ou Appel de Procédure Locale. Dans un système d'exploitation tournent en permanence un certain nombre de threads. Tous les services systèmes par exemple sont des threads ; les sous-environnements aussi. Viennent ensuite les applications utilisateur. Toutes ces threads dialoguent en permanence entre elles, les applications vers le sous-système d'environnement, le sous-système d'environnement vers les services système, les services système entre eux. Tout ces dialogues passent par le LPC qui gère la communication entre threads. C'est un programme spécifiquement développé pour optimiser les communications locales entre processus.
• le SRM : Security Ressource Manager, ou gestionnaire de sécurité des ressources; Son rôle est de gérer la sécurité en local sur la machine. Il sécurise l'accès à tout objet du système. Quand un utilisateur veut utiliser un objet, il fait une demande de handle auprès du gestionnaire d'objet. Le gestionnaire d'objet demande au SRM quels droits l'utilisateur a effectivement sur l'objet demandé. Le SRM compare le SAT (Secure Access Tocken, Jeton d'accès sécurité) de l'utilisateur, contenant les droits de l'utilisateur (appartenance aux groupes donc héritage), à l'ACL de l'objet demandé et en déduit le niveau d'accès de l'utilisateur sur l'objet. Ce niveau d'accès sera stocké dans le handle.
• le I/O Manager, ou Gestionnaire d'Entrées-Sorties
  C'est une grosse partie du système d'exploitation. Il est divisé lui-même en plusieurs couches de manière à être le plus modulaire possible. Il est constitué de telle manière que lorsque l'on veut ajouter ou changer un driver quelconque (disque dur, carte réseau) on ait le moins de code possible à développer. Il faudra simplement ajouter la couche qui va bien au bon endroit. Celle-ci s'appuiera sur ses couches supérieures et inférieures, qui n'auront pas à être modifiées. Plus les couches sont hautes, moins elles connaissent le système physique.
  Le gestionnaire d'entrées-sorties, coordonne, gère les communications entre drivers. Ces communications se font avec des messages spéciaux appelés I/O Request Packets.
  Le gestionnaire d'entrées-sorties gère notamment les systèmes de fichiers et les redirecteurs réseau (c'est grâce à lui que peuvent cohabiter plusieurs systèmes de fichier, par redirection des packets vers la bonne couche suivant leur type). Un redirecteur réseau n'est en fait rien d'autre qu'un système de fichier spécial. Pour une application, la méthode pour aller chercher une information sur le serveur ou sur un map réseau est strictement identique. Le gestionnaire d'entrées-sorties gèrant les systèmes de fichier, il est normal qu'il gère aussi le cache disque. Au lieu de diriger les requêtes disques directement vers le disque, il regarde d'abord dans le cache. S'il ne trouve pas le bloc demandé, il va alors transmettre la requête au disque. La réponse repassera forcément par le cache, qui cette fois ci stockera l'information.
• le Graphic Manager, ou gestionnaire graphique
  Il regroupe les deux sous-modules GDI et USER, correspondant respectivement à l'interface graphique et au gestionnaire de fenêtres. Ce module n'était pas présent dans le NT Executive sur Windows NT3, c'est une nouveauté NT4. Sous Windows NT3, GDI et USER se trouvaient dans le sous-environnement Win32. Leur choix, contesté par certains, a été justifié pour la raison suivante : Sous Windows NT3, quand le sous-environnement Win32 plantait, on ne pouvait absolument plus rien faire, le système était bloqué. En le mettant dans le NT Executive, lorsque le sous-environnement Win32 plante, Le noyau est capable de repeindre votre écran en bleu et vous afficher des informations succeptibles de vous aider à résoudre, du moins comprendre, le problème. De plus, par la fameuse commande CTRL-ALT-SUPPR, il décharge le système d'exploitation "proprement" (disent-ils...). Les non-partisans de cette solution argumentent que mettre ce module dans le NT Executive fragilise le système (et si c'étaient USER et GDI qui étaient boguées ?...Grave ! ) en l'alourdissant. Plus de code il y a, plus de bogues il y aura... .