How to troubleshoot Windows 11 Failing to boot into Windows.

On Windows 11 if for some reason an exception or bugcheck happens during the boot phase it can be quite challenging to diagnose the issue since you only get the stop code (E.g 0x7E SYSTEM THREAD EXCEPTION NOT HANDLED). After failing for a number of times, Windows should eventuelly let you into a recovery enviroment that either allows you to boot into safe mode or get into the recovery commandline. This allows you access into Windows to perform further diagnosis of the problem. When an exception happens during boot Windows 11 will log relevant information into this directory: 

Windows\SYSTEM32\LogFiles\Srt

 
This directory should contain several files relevant to diagnosing boot issues, but most interesting is the setupmem.dmp file:

This file can then be opened the normal way to get a stack trace and bugcheck code:
12: kd> .bugcheck Bugcheck code 1000007E Arguments ffffffff`c0000005 fffff806`8bf3e20b ffff8304`ec5d5308 ffff8304`ec5d4b10 

 
We see that the bugcheck is 0x7E and the actual exception is c0000005 (Memory access violation) We kan then dump the stack of the failing thread: 

Child-SP RetAddr : Args to Child : Call Site ffff8304`ec5d4298 fffff806`ebccc350 : 00000000`0000007e ffffffff`c0000005 fffff806`8bf3e20b ffff8304`ec5d5308 : nt!KeBugCheckEx ffff8304`ec5d42a0 fffff806`ebafb7df : ffff8304`00000003 ffff8304`ec5d5308 ffff8304`ec5cf000 ffff8304`ec5d6000 : nt!PspSystemThreadStartup$filt$0+0x44 ffff8304`ec5d42e0 fffff806`ebcb42d2 : ffff8304`ec5d5308 ffff8304`ec5d48e0 00000000`00000000 00000000`00000000 : nt!_C_specific_handler+0x9f ffff8304`ec5d4350 fffff806`eb87c492 : ffff8304`ec5d43e0 fffff806`eb600000 fffff806`eba870ba fffff806`eb6fb3f8 : nt!RtlpExecuteHandlerForException+0x12 ffff8304`ec5d4380 fffff806`eb9e866f : ffff8304`ec5d4b10 ffff8304`ec5d5010 ffff8304`ec5d4b10 ffff8304`ec5d51d0 : nt!RtlDispatchException+0x2d2 ffff8304`ec5d4ae0 fffff806`ebcbee45 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x35f ffff8304`ec5d51d0 fffff806`ebcb9f82 : 00000000`00000000 00000000`00000000 00000000`0000ffff ffffe680`e4bc0180 : nt!KiExceptionDispatch+0x145 ffff8304`ec5d53b0 fffff806`8bf3e20b : ffffd382`97010000 00000000`0000ffff 00000000`00000004 fffff806`8bf3a5d2 : nt!KiPageFault+0x442 (TrapFrame @ ffff8304`ec5d53b0) ffff8304`ec5d5540 ffffd382`97010000 : 00000000`0000ffff 00000000`00000004 fffff806`8bf3a5d2 ffffd382`97010000 : mtkwl6ex+0xe20b ffff8304`ec5d5548 00000000`0000ffff : 00000000`00000004 fffff806`8bf3a5d2 ffffd382`97010000 00000000`00000000 : 0xffffd382`97010000 ffff8304`ec5d5550 00000000`00000004 : fffff806`8bf3a5d2 ffffd382`97010000 00000000`00000000 fffff806`8c06b000 : 0xffff ffff8304`ec5d5558 fffff806`8bf3a5d2 : ffffd382`97010000 00000000`00000000 fffff806`8c06b000 fffff806`8c059c58 : 0x4 ffff8304`ec5d5560 ffffd382`97010000 : 00000000`00000000 fffff806`8c06b000 fffff806`8c059c58 ffffd382`97010000 : mtkwl6ex+0xa5d2 ffff8304`ec5d5568 00000000`00000000 : fffff806`8c06b000 fffff806`8c059c58 ffffd382`97010000 fffff806`8bf4c35d : 0xffffd382`97010000 

 
The stack trace reveals a third-party driver, mtkwl6ex, which is a MediaTek Wireless Driver, the driver was quite outdated (Timestamp Jan 2023) and updating it resolved the issue. Knowing the relevant directory of where one could find the dump trace allowed us to very simply diagnose and resolve the issue. Hope this is helpful for anyone else trying to diagnose a Windows 11 system that fails to boot.

Enkel ressurs for å finne identiteten til ukjent maskinvare.

Hvis du har maskinvare som er blitt installert på datamaskinen men som du ikke kjenner identiteten til, (Feks om du har en maskinvare-enhet som bare vises som ukjent enhet i enhetsbehandling)hva vil være den raskeste måten å finne den nøyaktige identiten til maskinvaren?

Ved å bruke http://www.pcidatabase.com/kan du enkelt søke opp Vendor og Device id'en på maskinvaren for å identifisere den. (Denne informasjonen er blitt brent på en ROM chip på maskinvaren og hentet fra plug and play manageren slik at selv om Windows ikke vet hvilken type maskinvare dette er vil denne informasjonen vises i enhetsbehandling.

Du finner Vender og Device ID'en under egenskapene for maskinvaren i enhetsbehahandling.



Her på bildet er maskinvaren allerede identifisert men du kan enkelt søke etter feks device ID'en 94C1 og få opp hvilken type maskinvare dette er:



Enklere kan det vel ikke bli.

Feilsøking av datamaskin med et mystisk oppstartsproblem.

Kom over en litt fiffig sak der brukeren klagde på at datamaskinen ikke ville slå seg på. Når jeg startet opp datamaskinen fikk jeg den normale BIOS-splashscreenen men ble møtt av dette bildet når Windows ble forsøkt lastet:


Dette ga jo ikke særlig mye å gå på men jeg forsøkte å restarte maskinen og trykke F8 under oppstarten av NTLDR. Dette fungerte bra og jeg fikk opp de vante valgene, dette betydde da at BIOS hadde detektert en gyldig MBR på harddisken hvorpå tilsist NTLDR hadde blitt lastet inn i minnet. En svart skjerm tidlig i oppstarten kan ofte bety hardware-problemer men jeg hadde vertfall indikeringer på at BIOS fant harddisken og fikk lastet de første oppstarsfasene av Windows. Spørsmålet ble da: når stoppet lastingen av Windows opp?

En mulig måte å finne mere info om hva som skjer i oppstarten er å starte windows med /SOS bryteren. Dette gir deg litt mer info over hva som skjer og gir blant annet muligheten til å se driverne som blir lastet inn i oppstarten. (Dette gjøres forsåvidt automatisk når du velger sikkermodus.) Når jeg startet Windows med /SOS bryteren fikk jeg se følgende liste:

Lastet driver \WINDOWS\system32\ntoskrnl.exe
Lastet driver \WINDOWS\system32\hal.dll
Lastet driver \WINDOWS\system32\KDCOM.DLL
Lastet driver \WINDOWS\system32\BOOTVID.dll
Lastet driver ACPI.sys
Lastet driver \WINDOWS\system32\DRIVERS\WMILIB.SYS
Lastet driver pci.sys
Lastet driver isapnp.sys

Noe som egentlig ikke forteller så mye da denne listen bare viser hvilke drivere som ble lastet inn med suksess. Driveren som er problemet blir da med andre ord forsøkt lastet etter isapnp.sys, men hvordan kan finne ut hvilken driver dette er? På systinernals finnes det et program kalt LoadOrder som viser hvilken rekkefølge drivere lastes inn i men dette må kjøres i Windows og på denne maskinen er det ikke mulig å komme inn i Windows. Finnes det da noen måte å finne ut hvilken driver som lastes inn etter isapnp?

Det er faktisk bare tre verdier som avgjør prioriteten til driveren i oppstarten (eller senere) disse verdiene er Start, Tag og Group. For enkelhets skyld har jeg valgt å bruke begrepet tjeneste som en fellesbetegnelse for tjenester/drivere. Under følger en forklaring på hva som menes med disse verdiene og hva de kan brukes til.

Start:
Angir hvilket stadie i oppstarten driveren lastes inn i. Vi har 5 mulige verdier som er: SERVICE_BOOT_START (0) - Lastes inn av osloaderen tidlig i oppstarten
SERVICE_SYSTEM_START (1) - Lastess inn av osloaderen etter at samtlige SERVICE_BOOT_START drivere har blitt lastet.
SERVICE_AUTO_START (2)- Startes av Service Control Manageren (SCM) etter at tjenesteprosessen Services.exe har blitt startet.
SERVICE_DEMAND_START (3) Startes av SCM ved behov.
SERVICE_DISABLED (4) Tjenesten vil aldri lastes.

Tag:
Angir prioritet innenfor en gitt gruppe. En tjeneste som er gitt Tag 1 vil starte før en tjenste gitt Tag 2. Tjenester uten Tag vil starte etter Taggede tjenester.

Group:
Samler tjenester med lignende bruksområder innenfor et gitt gruppenavn. Alle tjenestene innenfor en gitt gruppe må startes før Windows går videre til neste gruppe. Prioriteten til gruppene er gitt gjennom registernøkkelen HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List. Her følger et utdrag av denne listen med de 5 første gruppene:

System Reserved
Boot Bus Extender
System Bus Extender
SCSI miniport
Port

Alle tjenster er å finne innunder HKLM\SYSTEM\CurrentControlSet\Services\. En snedig funksjon i registereditering er at du kan importere register-hi fra andre datamaskiner ved å merke HKLM eller HCU og velge Last inn struktur. Jeg kopierte derfor SYSTEM-hiet fra datamaskinen som opplevde problemet og Lastet da inn dette hiet på min lokale datamaskin for å undersøke hvilke data som var gitt for tjenesten isapnp.sys:



Vi ser da at det er snakk om en BOOT driver under Boot Bus Extender gruppen. Siden alle BOOT driverne ikke har blitt lastet kan vi være sikre på at det dreier seg om en BOOT driver og vi kan se av prioriteringene at den enten må ligge i Boot Bus Extender gruppen eller i System Bus Extender gruppen. Ved å søke i registeret etter disse gruppenavnene kunne man søke opp de driverne som lå i disse gruppene og dermed lage seg en tabell over boot-prioriteringer basert på tagging. Jeg fikk da opp følgende liste i prioritert rekkefølge:

Boot Bus Extendere:
ACPI.sys tag - 1
pci.sys tag - 2
isapnp.sy tag - 3
psiksxvv Ikke tagget.

System Bus Extendere:
pcmcia tag 1
Compbatt.sys Tag 2
pciide.sys tag 3
viaidexp.sys tag 4
Partmgr tag 5
ACPIEC.SYS tag - 6
Mountmgr tag 8
ftdisk.sys tag 9
dmload.sys tag 12
dmio.sys tag 13
Volsnap Ikke tagget.

Vi ser da at ifølge vår liste skulle tjenesten med det merkelige navnet psiksxvv skulle være den neste til å starte opp. La oss ta en nærmere kikk på denne:



Dette gir ikke mye mening og vi kan se flere registerverdier som er bare fyllt med nonsens. Vi kan dermed være sikre på at det dreier seg om en korrupt registernøkkel. For å sjekke at det var denne som skapte problemer satte jeg Start verdien fra 0 til 4 noe som vi husker var SERVICE_DISABLED. Den ville med andre ord ikke bli lastet i oppstarten. Jeg kopierte SYSTEM-hiet tilbake til datamaskinen med problemet og nå startet den opp normalt.

Avbrudd og Unntakshåndtering.

Trap Dispatching:
Avbrudd (Interrupts) og unntak (Exceptions) er spesielle hendinger i operativsystemet som dirigerer prossoren utenfor den koden den driver på med. En trap eller felle er rett og slett en mekanisme i prosessoren som sørger for å fange en kjørende tråd når et unntak eller avbrudd forekommer og overfører kontrollen til en bestemt plass i operativsystemet. I Windows overføres kontrollen til en såkalt Trap Handler, som er en funksjon som er spesfikk til det unntaket eller avbruddet som forekom. Definisjonen på et avbrudd er en asynkron hendelse (som kan inntreffe til enhver tid) som ikke er relatert til det prosessoren driver på med. Mens et unntak er synkron hendelese som stammer fra kjøringen av den siste instruksjonen på prosessoren.

Både Hardware og software kan generere avbrudd og unntak. Feks kan er et unntak relatert til en databuss et Hardwareproblem, mens et program som prøver å dele på null skyldes programvarefeil. Videre kan en I/O-enhet generere et avbrudd når den trenger service, eller operativsystemet kan generere et programvare-avbrudd (slik som APC og DPC).

Når et hardware avrudd eller unntak blir generert, vil prosessren sørge for å lagre tilstanden som maskinen er i på kernel-stakken slik at tråden kan returnere til det den drev på med straks avbruddet eller unntaket er håndtert. Hvis tråden kjører i User Mode, vil Windows bytte til kernel-stakken for den tråden. Deretter vil Windows generere et Trap Frame på kernel-stakken som inneholder tilstanden til tråden og dens kontekst.

I de fleste tilfeller vil kjernen sørge for å tilby såkalte front-end trap handlere som sørger for å utføre oppgaver relatert til å overføre kontrollen til andre funksjoner som håndterer fellen direkte. Hvis det feks oppstår et enhets-avbrudd så vil kjernen bruke en hardware interrupt trap handler for å øverføre kontrollen til en såkalt Interrupt Service Routine (ISR) som blir levert av enhetsdriveren for enheten.

Nettverk i Windows.

Windows sin nettverksmodell er bygd opp av følgende hovedkomponenter:

Nettverks API:
Gir applikasjoner en måte å kommunisere over et nettverk uavhengig av protokoller. Nettverks API kan bli implementert i User-Mode eller både User og Kernel-Mode, og i noen tilfeller fungerer de som wrappere rundt andre nettverks-API som implementerer en spesifikk programmerings modell eller tilbyr ekstra enheter.

Transport Driver Interface (TDI) klienter:
Er Kernel-mode enhetsdrivere som vanligvis implementerer kernel-mode delen av et nettverks API. TDI-klienter får navnet på grunn av at IRP-pakkene som de sender til protokoll driverne er formatert etter Windows Transport Driver Interface-standarden. Denne standarden spesifiser et felles programmeringsgrensesnitt for kernel-mode drivere.

TDI transports:
Også kjent som transports, NDIS protokoll drivere og protokoll drivere. Er rett og slett protokoll drivere som kjører i kernel-mode. De mottar IRP-pakker fra TDI-klientene og prosesserer den anmodningen spesifisert i pakkene. Denne prosesseringen trenger muligens nettverkskommunikasjon med en nettversknode, som ber TDI-transporteren om å legge med protokollspesifikke headere, (Slik som TCP, UDP og IP) til dataen i IRP-pakken og å kommunisere med adaptere via NDIS-spesifikasjonen.

Network Driver Interface Specification (NDIS) bibloteket:
Fungerer som en slags innkapsling rundt adapter driverne, slik at adaptere driverne ikke behøver å "se" og interaktere med spesfikke detaljer i Windows Kjernen. NDIS bibloteket tilbyr funksjoner som kan brukes av TDI-transports, så vel som ekstra funksjoner til adapter driverne.

NDIS Miniport Drivere:
Er drivere i kernel-mode som er ansvarlig for å bygge et grenesnitt mellom TDI-transportere og spesifikke nettverks adaptere. NDIS miniport driverne er skrevet slik at de innpakket i NDIS-bibloteket. NDIS miniport drivere behandler ikke IRP-pakker, istedet vil de registrere et såkalt call-table grensesnitt til NDIS-biblotket som inneholder pointere til funksjoner som korresponderer med de som NDIS-biblotektet tilbyr TDI-transports. NDIS miniport drivere kommuniserer med nettverks adaptere gjennom funksjoner i NDIS-bibloteket som igjen ender opp i kall til funksjoner i Hardware Abstraction Layer (HAL)


Windows tilbyr flere forskjellige Nettverks API som har hver sine egne unike egenskaper som inkluderer hvilke protokoller det støtter, måten de kommuniserer på og hvilke andre platformer de er kompatible med. La oss nå ta en titt på noen av disse.


Windows Sockets (Winsock)
Er basert på BSD-sockets som er en gammel UNIX-standard for nettverkskommunikasjon fra 80-tallet. Windows sin oppgraderte versjon har en del ekstra egenskaper som BSD sockets ikke har, slik som:

* Støtte for strø-henting (scatter-gather) og asynkron program I/O.

* Quality of Service(QoS) konvensjoner slik at applikasjoner kan negere latenstid og båndbredde krav så lenge det underliggende nettverkset støtter QoS.

* Mulighet for utviding slik at Winsock kan støtte flere protokoller enn de som følger med Windows.

* Støtte for integrerte navneområder i tilegg til de som er definerte av protokoller eller applikasjoner som bruker Winsock. En serverk kan feks gi ut navnet sitt på Active Directory og ved bruke utvidelser for navneområder, kan en klient finne serverens addresse i Active Directory.

* Støtte for beskjeder som kan sendes fra en kilde til flere mottagere samtidig.

Winsock klient-side:
Det første steget en Winsock applikasjon foretar seg er å installere Winsock API-et ved å kalle på initialiserings funksjonen. Deretter vil applikasjonen lage en socket som fungerer som et slags kommunikasjons endepunkt. På Win XP og Server 2003 vil applikasjonen forsøke å få tak i addressen til serveren ved å bruke getaddrinfo. getaddrinfo returnerer en liste over adresser som er assignert serveren og klienten vil deretter prøve hver enkelt av disse addressene til den får kontakt. Når tilkoblingen er opprettet kan klienten sende og motta data data via socketen sin ved å bruke recv og send. En klient som ikke bruker tilkobling spesifiserer den eksterne adresssen ved å bruke funksjonene sendto og recvfrom.

Winsock server-side:
Etter at serveren har installert Winsock-APIet vil den lage en socket og bruke en bind funksjon for å binde denne til en bestemt lokal addresse. Dette kan feks være en TCP/IP addresse eller TCP/IP med IPv6. Det er mao servern som bestemmer hvilken adresstype kommunikasjonen skal foregå over.
Hvis det er konneksjons-basert server vil den bruke funksjonen listen på socketen den har laget og sjekker om noen klienter prøver å koble seg til. Om den mottar noen forespørseler på denne bruker den accept funksjonen for å fullføre forespørselen. Når Serveren har nådd maks antall koblinger vil den slutte å lytte på socketen sin. Etter at accept funksjonen er utført vil serveren lage en ny socket som deretter data sendes over via send og recv.
En konneksjonsløs server vil kunne sende data ved å spesifisere den eksterne addressen for hver operasjon.

Utvidelse av Winsock:
Winsock har støtte for at tredjeparter kan kan legge til henholdsvis såkalte transport service providers og namespace service providers. Transport Service providers kan fungere som et grensesnitt mellom winsock med nye protokoller eller å bruke eksisterende protokoller for å kunne tilby ekstra funksjonalitet slik som feks proxy funksjoner. En Namespace Service provider kan overstyre bestemte navne-oppslags fra Winsocks sin side. Disse tjenestene bruker da Winsock Service Proverider Interface (SPI). Legg for øvrig merke til at dette grensesnitter støtter en funksjon kalt Layered Service Provider (LSP) som kan da faktisk brukes for å settes inn i TCP/IP-stakken til Winsock og endre hele funksjonaliteten til Winsock. Om disse fjernes uriktig kan man evt miste noe eller hele funksjonaliteten til Winsock og Winsock må tilbakestilles. Netshell tilbyr feks slik funksjonalitet.

Implementering av Winsock:
For at en applikasjon skal kunne benytte seg av Winsock trenger den først Winsock API'et som ligger i Ws2_32.dll. Ws2_32.dll vil da gjøre kall til tjenster som kan gjøre navneoppslag og levere beskjeder. Mscwsock.dll fungerer som en Transport Service Provider for protokollene som Microsoft leverer gjennom Winsock. Winsock bruker også såkalte helper-biblotek som tar seg av kommuniseringen med kernel-mode protokolldrivere. Wshtcpip.dll er feks helper-bibloteket til TCP/IP.

Remote Procedure Call (RPC):
RPC er et nettverks-API som muligjør å lage programmer som har noen prosedyrer som kjører lokalt mens andre kjører eksternt.

Sikkerhet i Windows.

Sikkerheten i Windows XP blir ivaretatt av flere forskjellige komponenter, de viktigste komponentene er:

Security Reference Monitor: (SRM)
Er en komponent i Windows executive som er ansvarlig for å: definere data strukturen til såkalte Access Tokens som reprensenterer et sikkerhetskontekst, utføre sikkerhetssjekker på objekter, manipulere privlegier og generere eventuelle sikkerhets-revisjons beskjeder.

Local Security Authority SubSystem: (LSASS)
En prosess i User-mode som er ansvarlig for bla: sikkerhetspolicyen på det lokale systemet(som feks hvilke brukere som kan logge på maskinen, passord policyer, privlegier som blir gitt brukere og grupper og systemets sikkerhets-revisjons innstillinger), bruker autentikasjon, og å sende sikkerhets-revisjons beskjeder til hendelseslisten. LSA-tjenesten som lastes ved Lsasrv.dll er et biblotek som lastes inn i Lsass og som implementerer mesteparten av funksjonalitetn til LSASS.

Lsass policy database:
En database som inneholder det lokale systemets sikkerhetspolicy innstillinger. Databasen er lagret i et seperat register-hi innunder HKLM\SECURITY. Denne databasen inneholder informasjon slik som hvilke domener som kan autentisere pålogginsforsøk, hvem som har tilgang til systemet og hvordan (interaktiv, nettverks, og tjeneste pålogginger), hvem som får hvilke privlegier og hva slags sikkerhets-revidering som blir utført. Lsass policy databasen lagres også såkalte "hemmeligheter" som inkulderer påloggingsinformasjonen som blir brukt for cachede domene pålogginger og Windows Tjeneste-konto pålogginger.

Security Accounts Manager (SAM) tjensten:
Ett sett med sub-rutiner som er ansvarlige for å håndtere databasen som inneholder brukernavnene og gruppene som er definert på den lokale maskinen. SAM tjenesten er implementert innunder Samsrv.dll og er lastet i Lsass-prosessen.

SAM databasen:
En database som på systemer som ikke fungerer som domene-kontrollere inneholder de definerte lokale brukerne og gruppene i tilegg til passord og andre atributter. På maskiner som fungerer som domene-kontrollere lagrer SAM-databasen kun systemets administrator konto for gjenoppretting, dens definisjon og passord.
Databasen blir lagret i et seperat register-hi innunder. HKLM\SAM.

Active Directory:
En katalog-tjenste som inneholder en database som lagrer informasjon om objekter i et domene. Hvor et domene defineres som en samling pc'er og deres assosierte sikkerhetsgrupper som blir håndtert som en eneste enhet. Active Directory lagrer infromasjonen om objektene i domenet inkludert brukere, grupper og pc'er. Passord informasjon og privlegier for domenebrukere og grupper er lagret i Active Directory og denne informasjonen blir da kopiert over til alle domene-kontrollerne i et domene.
Active Directory Serveren er implementert i Ntdsa.dll og lastes av Lsass-prosessen.

Autentiseringspakker:
Inkluderer DLL'er som kjører både i Lsass og i sine egne klient prosesser og som er ansvarlig for å implentere autentiserings-policyen i Windows. En autentiserings DLL er ansvarlig for å undersøke et gitt passord og brukernavn og, hvis de stemmer overens, returnere Lsass informasjon som inneholder brukerens sikkerhets identitet som Lsass kan bruke for å genere en såkalt Access Token.

Logon prosessen: (Winlogon)
En prosess i user mode som er ansvarlig på å fange og svare på SAS (Secure Attention Sequence, mao Ctrl+Alt+Delete) og som håndterer interaktive pålogginger.

Graphical Identification and Authentication: (GINA)
En user-mode dll som lastes av Winlogon og som brukes av Winlogon for å hente brukernavn og passord eller evt smartcard pin kode. Windows kan håndtere forskjellige tredjeparts GINA'er men standard ginaen heter da msgina.dll

Network Logon Service: (Netlogon)
En windows tjeneste (Netlogon.dll) som setter opp en sikker kanal opp mot domene-kontrolleren slik at sikkerhetsforespørsler slik som interaktiv pålogging eller LAN-manger eller NT-LAN-manager autentisering kan bli sendt over denne kanalen.

Kernel Security Device Driver (KSecDD)
Et biblotek som kjører i kernel-mode som inneholder et biblotek med funksjoner som kan brukes for at andre sikkerhetskomponeter som kjører i kernel-mode kan kommunisere med Lsass i user mode. Dette implementeres da via et LPC-grensesnitt.

Tilgangssjekk:
Vi har tidligere snakket om Objekt-Manageren og om hvordan den bruker SRM for å sjekke om en tråd har tilgang til et objekt eller ei. La oss nå se litt nærmere på denne prosessen. Når Objekt-Manageren åpner et eksisterende objekt med et navn vil det først sjekke i sitt eget Namespace for deretter sjekke i sekundære namespace. (Slik som Configuration Managaren sitt register-namespace eller filsystemdriverens filsystem namespace)

Så lenge som objektet ikke befinner seg i dette sekundære namespacet vil da objekt-manageren kalle på funksjonen ObpCreateHandle som lager en oppføring i prosessens HandleTable som deretter vil bli assosiert med objektet. Dog vil funksjonen ExCreateHandle først bli aktiv straks ObpIncrementHandleCount indikerer at tråden har tilgang til objektet. Deretter vil ObpCreateHandle faktisk kalle ExCreateHandle som lager selve Handelen. ObCheckObjektAccess er ansvarlig for å kalle på de nødvendige rutinene for å utføre selve sikkerhetssjekken og returnerer deretter resultatet til ObpIncrementHandleCount.

ObCheckObjectAccess vil videre motta sikkerhetsakkreditivene til tråden som sendte forespørselen, akksesstypen, og sist en pointer til objektet fra ObpIncrementHandleCount. Deretter vil ObCheckObjectAccess låse objektets sikkerhetsatributter slik at ingen andre tråder kan endre sikkerhetskonteksten til objektet. Deretter vil ObCheckObjectAccess kalle på sikkerhetsmetoden beskrevet i typeobjektet. Den vanligste metoden er da default security som innebærer at sikkerhetsinformasjonen er lagret i objekt-headeren.

Security IDentifiers: (SID)
Istedetfor å bruke navn(som ikke er garantert å være unike) for å beskrive enheter som kan utføre handlinger på systemet. så bruker Windows såkalte SID'er. Både Brukere, lokale grupper, domene grupper, lokale PC'er, domener og domene-medlemmer har sine egne SID-verdier.
En SID er da en numerisk verdi av variabel lengde som består av et SID-struktur revisjons nummer, en 48 bits authorirty-identifier verdi, og et varibelt antall av 32bits subautoritære eller RID verdier(Relative Identifier)

Autoritets-nummeret beskriver agenten som gå ut SID'en, typisk Windows Local System eller et domene. Subautorithy verdiene identifiserer kompontenter som agenten som sendte ut SID'en stoler på, mens RID er bare en måte for Windows å garantere unike SID'er

Her kan vi ta en titt på en SID for min Lokale Brukerkonto:

S-1-5-21-144138694-2277693550-1939834215-1007

Alle SID'er er prefixet med S mens vi kan se at revisjonsnr er 1 og Autoritets-nummeret er 5 (Som betyr at SID'en ble gitt ut av Windows Security Authority) mens de 4 neste verdiene er subautoritæreverdier og den siste verdien er altså en RID på 1007.

Brukerkontoer og grupper har tideles en RID som starter på 1000 og øker deretter med 1 etterhvert som nye SID trenges. Mao betyr en RID på 1007 at minimum 8 SID's har blitt gitt ut på dette systemet)
Windows maskiner har også flere innebygde kontoer hvor bla Administrator kontoen bestandig har en RID på 500 mens gjestekontoen har en RID på 501.

Tokens:
SRM bruker et objekt kalt en token(Access Token) som identifiserer sikkerhetskontekstet til en prosess eller tråd. Et sikkerhetskontekst inneholder informasjonen som beskriver privlegiene, kontoene og grupenne som er assosiert med enten prosessen eller tråden.

Under påloggingsprosessen så lager Winlogon en token som representerer brukeren som logger på og fester denne til de første prosessene som startes via Winlogon (feks Userinit.exe) Siden prosesser arver tokens fra prosessen som lagde den vil alle prosesser i en gjeldende sesjon kjøre innunder brukerens token.

Sikkerhetsmekanismene i Windows bygger opp en token av to grunnleggende komponenter. Den ene komponenten består i en token består av brukerens SID og eventuelle gruppe SID. SRM bruker SID'er for å avgjøre om en prosess eller tråd har mulighet til å få den tilgangen den ber om til et sikkret objekt. (Dette betyr ikke nødvendigvis at den får det, men mer om dette senere.)
Det andre komponenten er et såkalt privlege array som er et sett med privlegier som er assosiert med tokenen.

Det finnes i tilegg to typer tokens -primary og impersonation. Primary Tokens identifiserer sikkerhetskontekstet til en prosess. Mens en impresonantion token lar en tråd midlertidlig bruke et annet sikkerhetskontekst.

Security Descriptorer og tilgangskontroll:
Datastrukturen som inneholder informasjonen over sikkerheten til et objektet kalles en "security descriptor" og består av følgende:

Revision Number: Versjonen av SRM modellen som lagde deskriptoren.
Flag: Valgfrie modifiere som definerer oppførselen eller karakterestikken ved deskriptoren. (Feks SE_DACL_PROTECTED som forbyr deskriptoren å arve sikkerhetsinnstillinger fra et annet objekt.)
Owner SID: Eieren's SID
Group SID: SID'en til hovedgruppen for objektet.
Discretionary Access Control List(DACL): Spesifiserer hvem som har hvilken tilgang til et objekt:
System Access Control List(SACL): Spesifiserer hvilke operasjoner av hvilke brukere som vil bli lagret i sikkerhetsoppføringsloggen.

En ACL er bygd opp av en header og enten ingen eller flere Access Control Entries (ACE). I en DACL så inneholder hver ACE en SID, en aksessmaske og et sett med flagg.
Fire typer ACE's kan forekomme i en DACL: Access Allowed, Access Denied, Allowed Object og Denied Object. Access allowed og Access denied forbyr eller tillater akksessrettighetene som er spesifisert i akksessmasken.

Allowed Object og Denied Object er typer som bare brukes innen Active Directory og disse ACE'ene har en GUID (Globally Unique IDentifier)som spesifiserer ar dette gjelder kun for helt spesielle objekter eller subobjekter som bruker denne GUID'en.
Flaggene i ACE'en brukes til å spesifisere hvilke arveegenskaper denne ACE'en har.

En SACL derimot inneholder to typer av ACE'S: System Audit ACE og en System Audit-Object ACE. En System Audit ACE spesifiserer hvilke operasjoner som blir utført på objektet av spesifikke brukere eller grupper som skal overvåkes. Denne informasjonen blir da lagret i Overvåkningsloggen i systemet. Mens System Audit-Object ACE spesifiser en spesiell GUID som spesifiserer hvilke objekter eller subobjekter det dreier seg om. ( På lik linje med DACL Allowed Object og Denied Object)

Hvordan tilgang beregnes:
To algoritmer brukes for å beregne tilgangen til et objekt:

*En for å beregne det maksimale settetet med rettigheter som kan gis til et objekt.

*En for å finne ut om en spesiell rettighet er tilatt til et objekt.

La oss først se på hvordan man kalkulerer seg frem til det maksimale settet med rettigheter:

1.Først sjekkes det om objektet faktisk har en DACL, Hvis objektet ikke har en DACL har alle brukere alle tilganger til objektet.

2.Hvis enheten som gjorde forspørselen har spesifisert Take-ownership (Bli eier av filer og andre objekter) privlegiet i sin token, vil systemet automatisk automatisk gi write-owner rettigheter til eieren av objektet uavhengig av hva som står i DACL.

3.Hvis enheten som gjorde forespøselen eier objektet vil den automatisk få read-control og write-dacl rettigheter til objektet uavhengig av hva som står i DACL.

4.ACE som er merket som Access Denied kommer først og om den som gjorde forespørselen har en identisk SID med den SID'en som er spesifisert i en av Access Denied ACE'ene så blir aksessmasken i ACE'en trukket ifra aksessmasken over tilatte rettigheter.

5.For hver ACE merket Access Allowed som har en SID som tilsvarer SID'en til den som sendte forespørselen vil aksessmasken i ACE'en bli lagt til i aksessmasken over tilatte rettigheter. (Om ikke disse rettighetene ble forbydd fra før)

Når disse 5 trinnene er utført vil da aksessmasken over de tilatte rettighetene bli returnert til den som gjorde forespørselen. Husk at trinnene 2 og 3 vil overstyre eventuelle rettigheter som er spesifisert i DACL. (Mao om en ACE i DACL'en nekter rettigheten read-control vil brukeren allikavel få rettigheten så lenge den eier objektet.)

La oss deretter se på hvordan man kan finne ut om en spesiell rettighet er tillatt for et objekt:

1.Hvis objektet ikke har noen DACL. Så betyr det at objektet ikke er beskyttet og dermed er alle rettigheter automatisk tillatt.

2.Hvis den som gjorde forespørselen har take-ownership privlegiet vil den automatisk få rettigheten write-owner for deretter å inspisere DACL'en. Hvis den ønskede rettigheten faktisk var write-owner er ingen inspeksjon av DACL nødvendig.

3.Hvis den som gjorde forespørselen eier objektet vil den automatisk få rettighetene read-control og write-DACL for deretter å inspisere DACL'en. Hvis en av disse rettighetene var av de ønskede er ingen inspeksjon av DACL nødvendig.

4.Hver ACE i DACL'en blir undersøkt, men de eneste relevante ACE'ene er de som tilfredstiller en av de følgende kravene:
a. En ACE er av typen Access Denied og SID'en i ACE matcher med en aktivert SID eller en deny-only SID i tokenen til den som gjorde forespørselen.
b. En ACE er av typen Access Allowed og SID'en i ACE matcher med en aktivert SID i tokenen til den som gjorde forespørselene og den ikke er merket som deny-only.
c. Andre undersøkelse sjekker for såkalte restriktve SID'er og undersøker om noen av SID'ene i ACE matcher noen av de restriktive SID'ene spesifisert i tokenen.

5.Hvis ACE'en var av typen Access Allowed og rettigetene i aksessmasken tilsvarte de rettigetene som ble forespurt så vil tilgangen bli godkjent. Hvis ACE'en var av typen Access Denied og aksessmasken dens tilsvarte de rettighetene som ble forespurtså vil tilgangen bli avslått.

6.Hvis man har undersøkt alle ACE i en DACL og den forespurte rettigheten ikke ble funnet vil tilgangen bli avslått.

La oss nå bruke Windbg for å titte på en Access Token:

La oss sjekke ut Access Tokenen til LSASS:
0: kd> !process 8a0e7470
PROCESS 8a0e7470 SessionId: none Cid: 0468 Peb: 7ffde000 ParentCid: 0428
DirBase: 0a9600e0 ObjectTable: e1c746e8 HandleCount: 447.
Image: lsass.exe
VadRoot 8a21e078 Vads 143 Clone 0 Private 724. Modified 4805. Locked 0.
DeviceMap e1009200
Token e245d030
ElapsedTime 01:41:54.234
UserTime 00:00:00.578
KernelTime 00:00:00.687
QuotaPoolUsage[PagedPool] 89180
QuotaPoolUsage[NonPagedPool] 10616
Working Set Sizes (now,min,max) (403, 50, 345) (1612KB, 200KB, 1380KB)
PeakWorkingSetSize 1903
VirtualSize 45 Mb
PeakVirtualSize 46 Mb
PageFaultCount 10664
MemoryPriority BACKGROUND
BasePriority 9
CommitCharge 1235

Som vi ser er Access Tokenen lagret på addresse e245d030 la oss se nærmere på denne ved å bruke !token kommandoen fra debuggeren:

0: kd> !token e245d030
_TOKEN e245d030
TS Session ID: 0
User: S-1-5-18
Groups:
00 S-1-5-32-544
Attributes - Default Enabled Owner
01 S-1-1-0
Attributes - Mandatory Default Enabled
02 S-1-5-11
Attributes - Mandatory Default Enabled
Primary Group: S-1-5-18
Privs:
00 0x000000007 SeTcbPrivilege Attributes - Enabled Default
01 0x000000002 SeCreateTokenPrivilege Attributes - Enabled
02 0x000000009 SeTakeOwnershipPrivilege Attributes -
03 0x00000000f SeCreatePagefilePrivilege Attributes - Enabled Default
04 0x000000004 SeLockMemoryPrivilege Attributes - Enabled Default
05 0x000000003 SeAssignPrimaryTokenPrivilege Attributes -
06 0x000000005 SeIncreaseQuotaPrivilege Attributes -
07 0x00000000e SeIncreaseBasePriorityPrivilege Attributes - Enabled Default
08 0x000000010 SeCreatePermanentPrivilege Attributes - Enabled Default
09 0x000000014 SeDebugPrivilege Attributes - Enabled Default
10 0x000000015 SeAuditPrivilege Attributes - Enabled Default
11 0x000000008 SeSecurityPrivilege Attributes -
12 0x000000016 SeSystemEnvironmentPrivilege Attributes -
13 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default
14 0x000000011 SeBackupPrivilege Attributes -
15 0x000000012 SeRestorePrivilege Attributes -
16 0x000000013 SeShutdownPrivilege Attributes -
17 0x00000000a SeLoadDriverPrivilege Attributes - Enabled
18 0x00000000d SeProfileSingleProcessPrivilege Attributes - Enabled Default
19 0x00000000c SeSystemtimePrivilege Attributes -
20 0x000000019 SeUndockPrivilege Attributes - Enabled
21 0x00000001c SeManageVolumePrivilege Attributes -
22 0x00000001d SeImpersonatePrivilege Attributes - Enabled Default
23 0x00000001e SeCreateGlobalPrivilege Attributes - Enabled Default
Authentication ID: (0,3e7)
Impersonation Level: Anonymous
TokenType: Primary
Source: *SYSTEM* TokenFlags: 0x89 ( Token in use )
Token ID: dcd3 ParentToken ID: 0
Modified ID: (0, 3c67b)
RestrictedSidCount: 0 RestrictedSids: 00000000

Vi kan se da at hovedgruppen som denne kjører innunder er S-1-5-18 som er da SID'en for Systemkontoen og har da alle mulige tenkelige privlegier.

Vi kan videre titte på security descriptoren for prosess objektet for LSASS, men først må vi finne objekt headeren som har ein ponter til security descriptoren:

0: kd> !object 8a0e7470
Object: 8a0e7470 Type: (8a3b8040) Process
ObjectHeader: 8a0e7458 (old version)
HandleCount: 10 PointerCount: 215

0: kd> dt _object_header 8a0e7458
nt!_OBJECT_HEADER
+0x000 PointerCount : 215
+0x004 HandleCount : 10
+0x004 NextToFree : 0x0000000a
+0x008 Type : 0x8a3b8040 _OBJECT_TYPE
+0x00c NameInfoOffset : 0 ''
+0x00d HandleInfoOffset : 0 ''
+0x00e QuotaInfoOffset : 0 ''
+0x00f Flags : 0x20 ' '
+0x010 ObjectCreateInfo : 0x805628c0 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x805628c0
+0x014 SecurityDescriptor : 0xe1001c3d
+0x018 Body : _QUAD

Security Descriptor pointeren i object headeren bruker de tre laveste bitene som flagg så derfor for å få adgang til selve security descritoren må vi fjerne de tre laveste bitene:

0: kd> !sd 0xe1001c3d & -8
->Revision: 0x1
->Sbz1 : 0x0
->Control : 0x8004
SE_DACL_PRESENT
SE_SELF_RELATIVE
->Owner : S-1-5-32-544
->Group : S-1-5-18
->Dacl :
->Dacl : ->AclRevision: 0x2
->Dacl : ->Sbz1 : 0x0
->Dacl : ->AclSize : 0x44
->Dacl : ->AceCount : 0x2
->Dacl : ->Sbz2 : 0x0
->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[0]: ->AceFlags: 0x0
->Dacl : ->Ace[0]: ->AceSize: 0x14
->Dacl : ->Ace[0]: ->Mask : 0x001f0fff
->Dacl : ->Ace[0]: ->SID: S-1-5-18

->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[1]: ->AceFlags: 0x0
->Dacl : ->Ace[1]: ->AceSize: 0x18
->Dacl : ->Ace[1]: ->Mask : 0x00120410
->Dacl : ->Ace[1]: ->SID: S-1-5-32-544

->Sacl : is NULL

Vi ser da at dette objektet er ein av administrator gruppen (S-1-5-32-544) og dette er en gruppe kontrollert innunder systemkontoen. Vi ser også at den har to ACE oppføringer begge av typen Access Allowed. Maskene kan være litt tungvint å dechiffrere men en kjent maske er ihvertfall 0x001f0fff som betyr fullstendig tilgang-noe som ikke er overraskende siden det gjelder Systemkontoen.

La oss nå teste ut et eksperiment hvor vi lager en mappe og nekter alle rettigheter til denne fra administrator gruppen:

La oss deretter legge til alle rettigheter for denne mappen for brukeren HKB som tilhører gruppen administratorer:





Hva skjer da om vi prøver å gi inn på mappen?




Ved å gå inn på de avanserte rettighetene til mappen kan vi få en oversikt over de aktive ACE'ene for denne mappen og også en forståelse hvorfor dette skjer. Som vi ser blir de forbydende ACE oppføringene prioritert først:




Dog er ikke den beste måten for å undersøke den effektive tilgangen en bruker har til et objekt, den eneste sikre måten å vise dette på er ved å trykke på fanen "Gjeldende Tillatelser" og skrive inn brukernavnet:




Vi kan dog se at denne brukeren faktisk har to rettigheter til dette objektet, nemlig å lese og endre tillatelser. Hvor kommer så disse fra? Når DACL spesifiserte ingen tillatelser? Jo det har seg slik at medlemmer av administratorgruppen er utstyrt med privlegiet take-ownership som vi husker ville automatisk gi slik tilgang, vi kan se en oversikt over privlegiene til forskjellige brukere i den Lokale sikkerhetspolicy manageren:




Dette guiden burde gi en fin innføring i de forskjellige komponentene i sikkerhetssystemet i Windows. Dog er det en del ting som jeg ikke har forklart i detalj men dette kan man finne ut mere om andre plasser - men skulle det være noe som er uklart eller noe er det bare å spørre!

Objekt-manageren.

Objekt-manageren er en del av Windows Executive hvis ansvar står i å lage, slette, beskytte og spore objekter. Hovedmålet til Objekt-manageren er å gi en lik, enhetelig mekanisme for bruk av system ressurser.
Internt jobber Windows med to hovedtyper av objekter-Executive og Kernel Objects. Executive Objects brukes av komponenter i Windows Executiven(slik som Memory Manageren, PnP manageren, I/O-mangeren osv.) mens Kernel Objects brukes internt i kjernen. Ofte er det slik at et executive objekt er bygd på et Kernel object og dermed inkapsulerer Executive objektet også et Kernel Object. Her følger en liste over de vanligste typene av Executive Objects:

Symbolic link: En mekanisme for å refere til et objektnavn indirekte.
Process: Det virtuelle adresseområdet og kontrolinformasjonen som er nødvendig for et sett av en eller flere tråd-objekter.
Thread: Den kjørbare enheten i en prosess.
Job: En samling prosesser som håndteres som en enhet via Job-objketet.
Section: En region av minnet som er delt mellom flere prosesser.
File: En instans av en åpen fil eller en I/O enhet.
Access Token: Sikkerhets-profilen(SID,brukrettigheter osv) for en prosess eller tråd.
Event: Et objekt med en fast tilstand (Signaled or Not Signaled) som kan brukes til synkronisering eller varsling.
Semaphore: En teller som sørger for at et kun et bestemt antall tråder har tilgang til resursene beskyttet av en Semaphore.
Mutex: En synkroniseringsmekanisme som kan brukes for å serialisere tilgangen til en ressurs.
Timer: En mekanisme for å gi en tråd beskjed når en viss tidsperiode har gått ut.
IoCompletion: En metode for tråder å stille seg i kø og vente på beskjed om fullføring av I/O-operasjoner. (Også kjent som I/O-Completion Port)
Key: En mekanisme for å refere til registeret.

De resterende Executive Objects kan du finne innunder \ObjectTypes i Object manageren.

Objekt-Struktur:
Hvert Objekt består av en Objekt-Header og en Object-body. Objekt-manageren sørger for å styre og lage Objekt-Headeren mens Object-bodyen blir håndtert av den Executive Komponenten som refererte til objektet. Objekt-bodyen inneholder informasjon som er unik for hvert objekt mens Object-Headeren er lik for alle objekter og inneholder grunnleggende informasjon om objektet.

Attributtene som finnes i Object-Headeren:
Object Name: Gjør at at andre prosesser kan bruke objektet ved å refere til navnet på objektet.
Object Directory: Er en struktur for å lagre Objekt-navn.
Security Descriptor: Bestemmer hvem som kan bruke objektet og hva de kan gjøre med det.
Quota Charges: Lister ressurs omkostningene mot en prosess når den åpner en Handle til objektet.
Open handle count: Antall ganger et Handle har blitt åpnet til Objektet.
Open Handles List: Peker mot en liste med prosesser som har åpnet en handle til objektet.
Object Type: Peker mot type-objektet som inneholder attributter som er felles for alle objekter av denne typen.
Reference Count: Antall ganger objektet har blitt referert til. Mao både antall pointere og antall åpne handles som peker til objektet. (Kjernen referer til objekter via pointere istedet for handles.)

Objekt-Handles:
Når en prosess lager eller åpner et objekt via et navn mottar den et handle som reprensenterer tilgangen til objektet. Ved å refere til objektet via en handle øker man ytelsen på objekt-operasjoner siden objekt-mangaren kan finne objektet direkte istedet for å måtte slå det opp via navn hver gang. En handle er en index til et Handle-Table som allokeres når en prosess startes. Et Handle-Table inneholder pointere til alle objektene som en prosess har åpnet handle til.

Objekt-Sikkerhet:
Når du åpner en fil må du spesifisere om du har tenkt å lese eller skrive til filen. Hvis du prøver å skrive til en fil som du har bedd om å lese vil du støte på en feil. På samme måte må du når du lager et objekt eller åpner en handle til det objektet spesifisere hva du har tenkt å gjøre med det. Security Reference Monitoren sørger for å undersøke Security Descriptoren til objektet og undersøker om dette samsvarer med tilgangsspesifikasjonene til prosessen. Om disse samsvarer så sørger Reference Monitoren å lage et set med "Granted Access Rights" som blir lagret i Object Handelen.

Objekt lagring:
Det finnes to typer objekter: midlertidlige og permanente. De fleste objektene er midlertidlige-mao de blir fjernet når de ikke lenger er i bruk mens permanente objekter blir ikke fjernet før de blir eksplisitt bedt om det. Siden de fleste objekter er midlertidlige er det objekt-managerens oppgave å holde dem i minne så lenge de er i bruk og fjerne dem når ingen prosesser bruker dem. Måten Objekt-manageren holder styr på dette er at for hver gang en prosess åpner en handle til et objekt øker den antallet i Open Handle Count i Object-Headeren. Deretter når prosessen da stenger handelen igjen vil da objekt-mangeren sørge for å minke dette antallet. Når Open Handle Count synker til 0 vil da objekt-manageren fjerne objektet fra det globale namespacet. På denne måten kan ingen prosesser åpne et nytt handle til dette objektet.
Siden operativsystemkjernen referer til objekter med pointere istedet for handles må Object-Manageren også holde styr på hvor mange referanser det er blitt gjort til objektet. Dette antallet lagres da i Reference Count telleren og også prosesser som åpner en handle vil telle som en referanse. Når denne telleren tilslutt når 0 er det da ingen som referer til objektet og det kan trygt fjernes fra minnet.

Objekt-Navn:
Enhver ressurs som er representert som et objekt kan få sitt eget unike navn. Ved å gi navn til en ressurs kan objekt-manageren lagre dette i det Globale Namespacet sitt slik at andre prosesser kan åpne en handle til objektet ved å referere til navnet. Prosesser i user mode har da bare tilgang til \BaseNamedObjects og \GLOBAL?? mappene i Object manageren.

Oversikt over Objekt mappene og hvilke typer objekter som lagres der:
\GLOBAL?? : Ms Dos-enhetsnavn
\BaseNamesObjects : Mutexer, events,semaphores,waitable timers og section objects.
\Callback : Callback Objekter
\Device : Enhetsobjekter.
\Driver : Driverobjekter.
\FileSystem : File system driver objekter og enhetsobjekter for å kjenne igjen filsystem.
\KnownDlls : Section navn og bane til såkalte known DLLs (Mao DLL som blir mappet av systemet ved oppstart)
\Nls : Section navn for national language support tabeller.
\Objecttypes : Navn på Typeobjekter.
\RPC Control : Port Objekter til bruk for RPC (Remote Procedure Call)
\Security : Navn på objekter spesifikke for sikkerhets undersystemet.
\Windows : Windows undersystem porter og Windows Station objekter.

Session Namespace:
Hver enkelt Session har et unikt lokalt namespace for den pågående sesjonen. Mappene \DosDevices \Windows og \BaseNamedObjects blir kopiert slik at hver sesjon kan ha unike objekter for disse. Mappene blir da lagret innunder \Sessions\x hvor x er et tall som identifiserer sesjonen mao blir da \BaseNamedObjects for sesjon 3 lagret innunder \Sessions\3\BaseNamedObjects.

Undersøking av Objekter gjennom Windbg og WinObj:
La oss ta utganspunkt i prosessen LSASS:

PROCESS 8a08e458 SessionId: none Cid: 0468 Peb: 7ffde000 ParentCid: 0428
DirBase: 0a9600e0 ObjectTable: e2428388 HandleCount: 446.
Image: lsass.exe

Vi ser at den har totalt 446 åpne handles la oss dumpe ut disse ved å bruke !handle:

0: kd> !handle 0 7 468
Handle table at e2f8b000 with 446 Entries in use
0000: free handle, Entry address e248b000, Next Entry fffffffe
0004: Object: e10085c8 GrantedAccess: 000f0003 Entry: e248b008
Object: e10085c8 Type: (8a3b4ca0) KeyedEvent
ObjectHeader: e10085b0 (old version)
HandleCount: 40 PointerCount: 41
Directory Object: e1003100 Name: CritSecOutOfMemoryEvent

Vi kan da se at det første objektet er av typen KeyedEvent som er et nytt synkroniseringsobjekt som ble introdusert i Windows XP. Dette brukes da når minnet er lavt og en tråd forsøker å bruke en kritisk seksjon i systemet. Denne eventen gjør det da mulig for en tråd å spesifisere en "nøkkel" som den venter på og våkner igjen når en annen tråd i den samme prosessen signalerer eventen med den samme "nøkkelen". På denne måten kan systemet fremdeles bruke critcal sections når minnet er så lavt at man ikke kan allokere et nytt event objekt for den.

Videre spesifisert ser vi at navnet er CritSecOutOfMemoryEvent, Det er totalt 40 åpne handles til denne rundt om i systemet mens det er 41 referanser. La oss kikke nærmere på object-headeren ved å bruke dt kommandoen (display type)

0: kd> dt _object_header e10085b0
nt!_OBJECT_HEADER
+0x000 PointerCount : 41
+0x004 HandleCount : 40
+0x004 NextToFree : 0x00000028
+0x008 Type : 0x8a3b4ca0 _OBJECT_TYPE
+0x00c NameInfoOffset : 0x10 ''
+0x00d HandleInfoOffset : 0 ''
+0x00e QuotaInfoOffset : 0 ''
+0x00f Flags : 0x32 '2'
+0x010 ObjectCreateInfo : 0x00000001 _OBJECT_CREATE_INFORMATION
+0x010 QuotaBlockCharged : 0x00000001
+0x014 SecurityDescriptor : 0xe100b1ff
+0x018 Body : _QUAD

Vi kan videre kikke nærmere på type-objektet som dette objektet hører innunder:

0: kd> dt _object_type 8a3b4ca0
ntdll!_OBJECT_TYPE
+0x000 Mutex : _ERESOURCE
+0x038 TypeList : _LIST_ENTRY [ 0x8a3b4cd8 - 0x8a3b4cd8 ]
+0x040 Name : _UNICODE_STRING "KeyedEvent"
+0x048 DefaultObject : 0x80561e20
+0x04c Index : 0x10
+0x050 TotalNumberOfObjects : 1
+0x054 TotalNumberOfHandles : 0x28
+0x058 HighWaterNumberOfObjects : 1
+0x05c HighWaterNumberOfHandles : 0x29
+0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0ac Key : 0x6579654b
+0x0b0 ObjectLocks : [4] _ERESOURCE

Og kan videre kikke videre på hvordan dette initsialliseres:

0: kd> dt _object_type_initializer 8a3b4ca0+60
ntdll!_OBJECT_TYPE_INITIALIZER
+0x000 Length : 0x4c
+0x002 UseDefaultObject : 0x1 ''
+0x003 CaseInsensitive : 0 ''
+0x004 InvalidAttributes : 0
+0x008 GenericMapping : _GENERIC_MAPPING
+0x018 ValidAccessMask : 0x1f0003
+0x01c SecurityRequired : 0 ''
+0x01d MaintainHandleCount : 0 ''
+0x01e MaintainTypeList : 0 ''
+0x020 PoolType : 1 ( PagedPool )
+0x024 DefaultPagedPoolCharge : 0x30
+0x028 DefaultNonPagedPoolCharge : 0
+0x02c DumpProcedure : (null)
+0x030 OpenProcedure : (null)
+0x034 CloseProcedure : (null)
+0x038 DeleteProcedure : (null)
+0x03c ParseProcedure : (null)
+0x040 SecurityProcedure : 0x805f6bbc long nt!SeDefaultObjectMethod+0
+0x044 QueryNameProcedure : (null)
+0x048 OkayToCloseProcedure : (null)

Et annet nyttig program for å undersøke Mappene som Object-manageren lager er WinObj som kan hentes fra Microsoft Sysinternals på denne addressen :
http://technet.microsoft.com/en-us/sysinternals/bb896657.aspx

Her er et bilde av WinObj som viser alle Typeobjektene: