30 november 2000 – I det här problemet:

  1. REDAKTIONELLA

  2. VAD ÄR NYTT PÅ SYSINTERNALS

    • PsLoggedOn v1.2
    • PsShutdown v1.0
    • PsTools v1.1
    • BgInfo v1.1
    • Tokenmon v1.0
    • Filemon v4.32
    • Regmon v4.32
    • Inuti Windows 2000, 3:e Ed.
    • November och Windows 2000 Magazine
    • Sysinternals på Microsoft
    • Sysinternals-licensiering
  3. INFORMATION OM INTERNT

    • NFI
    • Dolda Win9x-registernycklar
  4. VAD ÄR PÅ GÅNG

    • Nya System-anrop

SPONSOR: UNDERTIDSPROGRAMVARA

Sysinternals Newsletter är sponsrat av Fallnals Software, på webben på www.winternals.com. Taraa Software är den ledande utvecklaren och leverantören av avancerade systemverktyg för Windows NT/2K. Bland software-produkterna finns FAT32 för Windows NT 4.0, NTFSDOS Professional Edition (en NTFS-drivrutin för DOS) och Remote Recover.

Kommandot netstat, som medföljer alla versioner av Windows 9x och Windows NT/2000, visar vilka TCP/IP-portar som är öppna i systemet, men den visar inte vilken process som har porten öppen. TCPView Pro, Som är Det senaste övervakningsverktyget, har inte bara ett netstat-likvärdigt kommandoradsverktyg, Tcpvstat, som visar vilken process som har varje port öppen, utan även ett grafiskt användargränssnitt som visar samma information plus en realtidsspårning av TCP/IP-aktivitet. Realtidsspårningen visar programmet som gör en nätverksåtkomst, de lokala och fjärranslutna IP-adresserna för åtkomsten med valfri DNS-namnmatchning, typ av åtkomst, åtkomstens framgång och mängden data som överförs. TCPView Pro är bara $69. Ladda ned den 14-dagars fullt funktionella utvärderingsversionen av TCPView Pro i dag på www.winternals.com/products/monitoringtools/tcpviewpro.shtml.

Hej!

Välkommen till Sysinternals nyhetsbrev. Nyhetsbrevet har för närvarande 28 000 prenumeranter.

En av fördelarna med att flytta från Windows NT till Windows 2000 är den avsevärt förbättrade tillförlitligheten. Jag har skrivit om orsakerna till förbättringarna i flera artiklar och de är främst resultatet av ett verktyg som heter Drivrutinsverifierare. Du kan konfigurera verifieraren, som du startar genom att skriva "verifierare" i dialogrutan Kör i Start-menyn för att noggrant övervaka körningen av specifika enhetsdrivrutiner och leta efter överträdelser av någon av de olika programmeringsreglerna för drivrutiner. Verifieraren går ett steg längre än passiv övervakning, men den exacerbats också potential; feltillstånd genom att till exempel allokera minnesblock för drivrutinen som är straddled med ogiltiga regioner och nollställa specifika fält i datastrukturer som skickas till drivrutinen. Om du verkligen vill bli svår kan du använda verifieraren för att simulera låga minnesförhållanden för drivrutinen.

Microsoft använder verifieraren via sitt program för drivrutinssignering, vilket kräver att alla drivrutiner som har signerats digitalt av Microsoft klarar strikt testning av drivrutinsverifieraren. När en drivrutin installeras kontrollerar maskinvaruguiden om drivrutinen är signerad. Om inte varnar den dig eller misslyckas med att installera drivrutinen, beroende på vilka inställningar du har angett i dialogrutan Alternativ för drivrutinssignering, som är tillgängliga från sidan Maskinvara i system appleten i Kontrollpanelen.

Det faktum att standardprincipen för drivrutinssignering varnar slutanvändare om osignerade drivrutiner är tillräckligt för att de flesta maskinvaruleverantörer ska hamna i problem med att göra sina drivrutiner robusta och få dem signerade. Enhetsdrivrutiner kan dock inte identifieras i systemet av principen för förarsignering. Endast drivrutiner som installeras med INF-filer (drivrutinsinstallationsfiler som slutar med tillägget .inf) kontrolleras för signaturer. Installationsprogram kan manuellt installera drivrutiner antingen med hjälp av installations-API:er direkt eller genom att manuellt konfigurera drivrutinens registerinställningar. Sysinternals-program är bra exempel på detta: Filemon, Regmon och andra Sysinternals-verktyg där drivrutinskomponenter installerar sina drivrutiner manuellt, vilket är orsaken till att du inte får en varning om att de inte har signerats av Microsoft.

Drivrutiner som inte installeras ofta med INF-filer är bland annat virusskannrar, krypteringsprogram och CD-ROM-programvara. Detta utesluter dock inte att maskinvarurelaterade drivrutiner klipps ut genom. Sysinternals Ctrl2cap-drivrutinen för Windows 2000 (www.sysinternals.com/ctrl2cap.htm är ett exempel på en maskinvarurelaterad drivrutin som installeras på ett sätt som kringgår kontroller av drivrutinssignering. Det här kryphålet leder till att det finns drivrutiner i systemet som inte har verifierats, vilket kan äventyra systemets stabilitet (jag verifierar alla Sysinternals-drivrutiner i de högsta inställningarna). Microsoft bör tvinga alla drivrutiner, inte bara de som installeras med INF-filer, att gå igenom signeringskontrollen.

Varför använder jag den här ranten? Min CD-ROM-programvara, som är den mest populära av den typen av programvara på marknaden, har en drivrutin som kan återskapa krascha mitt Windows 2000 SP1-system. Om jag konfigurerar drivrutinsverifieraren för att kontrollera den slutförs inte ens starten av systemet innan verifieraren identifierar drivrutinens första överträdelse och kraschar systemet. Drivrutinen installerades utan en INF-fil så jag fick ingen varning om att den var osignerad. Jag garanterar att om Microsofts policy var striktare än den här leverantören skulle tänka två gånger innan en osignerad (och buggig) drivrutin levereras.

Skicka nyhetsbrevet till vänner som du tror kan vara intresserade av innehållet.

Tack!

-Mark

VAD ÄR NYTT PÅ SYSINTERNALS

PSLOGGEDON V1.2

Förutom en uppenbar namnändring från LoggedOn till PsLoggedOn har det här kommandoradsverktyget, som har möjlighet att visa vem som är inloggad lokalt och via resursresurser på det lokala systemet eller ett fjärrsystem, vissa nya funktioner. Den första är kommandoradsväxeln "-l" som är resultatet av användarfeedback. Många använder PsLoggedOn för att se om något konto är lokalt loggat in på deras servrar. Det kan till exempel finnas användare som är inloggade via filresurser, men det är inte relevant när du fattar ett beslut om när ett konto kan uppdateras eller om servern kan fjärradministreras.

PsLoggedOn:s andra nya funktion visar inte bara vem som är inloggad, utan även när inloggningen ägde rum. PsLoggedOn hämtar inloggningstider för inloggningar från resursresurser kostnadsfritt när ett Win32-API, NetSessionEnum, används för att räkna upp resursresursinloggningar (kommandoradskommandot Net använder även NetSessionEnum för att räkna upp sessioner). Det finns dock inget Win32-API som anger vem som är inloggad på ett system lokalt, mycket mindre vid vilken tidpunkt de loggade in.

För att avgöra vem som är inloggad på ett system lokalt räknar PsLoggedOn upp säkerhets-ID:n (SID) som finns under en dators HKEY_USERS registernyckel. När någon loggar in på en dator lokalt, antingen i -konsolen eller via en tjänst, läses hans eller hennes profil in i HKEY_USERS nyckeln. Program kan komma åt profilens registerinställningar via nyckeln eftersom systemet behandlar nyckeln som en symbolisk länk till HKEY_CURRENT_USER deras specifika profil under HKEY_USERS . PsLoggedOn kan därför veta vem som är inloggad lokalt genom att översätta de SID:er som hittas i en dators nyckel till HKEY_USERS motsvarande användarnamn. PsLoggedOn använder för att ansluta till en fjärrdators register när du dirigerar den till att lista användare som RegConnectKey är inloggade på ett fjärrsystem.

Att ta reda på när en användare är inloggad fungerar med ett liknande trick. När WinLogon-processen läser in en användares profil till efter inloggningen skapar WinLogon en beständig undernyckel (sparas inte till profilen på disken) i sin profil med namnet , tillräckligt beständig HKEY_USERS miljö. Registret lagrar senast ändrade tidsstämplar för registernycklar och eftersom systemet inte ändrar ej beständiga miljöundernycklar efter att de har skapats, kan PsLoggedOn avgöra när en användare har loggat in genom att hämta tidsstämpeln för sin ej beständiga miljöundernyckel.

Ladda ned PsLoggedOn v1.2 med fullständig källa på
www.sysinternals.com/psloggedon.htm.

PSSHUTDOWN V1.0

Om du någon gång har behövt stänga av eller starta om ett lokalt eller fjärranslutet NT/2000 Windows system måste du ladda ned PsShutdown. PsShutdown är en klon av verktyget Shutdown Windows NT/2000 Resource Kit. Den tar samma kommandoradsargument som gör att du kan ange en fördröjning före avstängningen, om du vill starta om, ett valfritt meddelande som ska visas för alla användare som är inloggade på systemet och namnet på den dator som ska stängas av eller startas om.

Ladda ned PsShutdown v1.0 www.sysinternals.com/psshutdn.htm.

PSTOOLS V1.1

Du har förmodligen märkt det ökande antalet verktyg på Sysinternals som börjar med prefixet "Ps". Den första var PsList, ett kommandoradsverktyg som visar information om aktiva processer på den lokala eller en fjärrdator Windows NT/2000-systemet. Jag gav PsList dess namn eftersom standardverktyget UNIX information om kommandoradsprocessen heter "ps". Nästa verktyg för att hämta prefixet var PsKill, ett kommandoradsverktyg som gör att du kan avsluta processer som körs på lokala eller fjärranslutna Windows NT/2000-system. Jag gav PsKill prefixet "Ps" eftersom det är ett perfekt komplement till PsList.

Med tiden har jag utvecklat andra verktyg som har samma definierande egenskaper som PsList och PsKill: de är kommandoradsbaserade och fungerar på det lokala eller en fjärransluten Windows NT/2000-system. Med ElogList kan du till exempel dumpa innehållet i ett systems händelseloggar och GetSid visade SID för en dator eller ett visst konto. Nyligen bestämde jag mig för att koppla ihop alla dessa verktyg genom att ge dem prefixet "Ps" och göra dem nedladdningsbara som ett enda paket med namnet PsTools.

PsTools, som innehåller PsList, PsKill, samt de omdöpta PsLogList och PsGetSid, består av totalt sju verktyg. Om du ser ett Sysinternals-verktyg med prefixet "Ps" vet du automatiskt att det är ett kommandoradsverktyg som fungerar lokalt och fjärranslutet.

Ladda ned PsTools v1.1 www.sysinternals.com/pstools.htm.

BGINFO V1.1

Bryce har uppdaterat BgInfo, ett verktyg som ställer in skrivbordsunderlägg för att visa anpassningsbar information om systemets konfiguration, till följd av den användarfeedback som han fått. Som standard räknar BgInfo ned i 10 sekunder innan inställningarna som anges i dialogrutan tillämpas, men med ett nytt kommandoradsalternativ, , kan du ändra eller eliminera nedräkningen helt /timer och hållet. Det gör det enklare att inkludera BgInfo i ett inloggningsskript eller som en genväg i en profils startmapp.

Version 1.1 innehåller andra nya funktioner, till exempel möjligheten att visa godtycklig text som du definierar och mer fördefinierade informationskategorier. Skrivbordsmappen BgInfo v1.1 skapar också i allmänhet mindre, vilket minimerar BgInfo-skrivbordets minnesfotavtryck.

Ladda ned BgInfo v1.1 www.sysinternals.com/bginfo.htm.

TOKENMON V1.0

Tokenmon är det senaste tillägget i den varierande sviten med övervakningsverktyg som du kan ladda ned från Sysinternals. Tokenmon, som delar samma användargränssnitt som dess fötter som Regmon och Filemon, övervakar betydande säkerhetsrelaterade aktiviteter i ett Windows NT/2000-system. Vad är "betydande" säkerhetsrelaterad aktivitet? I hjärtat av Windows NT/2000-säkerhet är token-objektet, en datastruktur som innehåller ett konto-SID, grupp-SID och behörigheter. När en process försöker komma åt ett skyddat objekt använder säkerhetsreferensövervakaren SID:erna i sin token som en del av åtkomstvalideringen. Om en process försöker utföra en begränsad åtgärd, till exempel starta om systemet, kontrollerar systemet lämplig behörighet i processens token.

En av de kraftfulla (och patenterade) funktionerna i säkerhetsmodellen Windows NT/2000 är personifiering. Personifiering gör att en tråd tillfälligt kan åsidosätta sin processbaserade identitet och införa en alternativ identitet med hjälp av en personifieringstoken. Serverprogram utnyttjar personifiering vid åtkomst till resurser för en klients räkning när de inför klientens identitet under hela åtkomsten.

Tokenmon installerar systemanrops hookar på samma sätt som Regmon gör för register-API:er, för att övervaka skapande och borttagning av token, aktivering och inaktivering av privilegier samt personifiering. Tokenmon använder också hookar för processskapande som tillhandahålls av NT/2000-kerneln för att övervaka skapande och borttagning av processer och andra API:er för att avgöra när en användare loggar in och när de loggar ut.

Den fullständiga källkoden till Tokenmon publiceras och det är värt att diskutera några av de intressanta tekniker som koden visar. Tokenmon identifierar en inloggningshändelse genom att koppla systemanropet NtCreateToken, som används av inloggningskoordinatorer som WinLogon för att skapa en inledande token för den första processen i en ny inloggningssession. Processer som skapats av den första processen ärver en kopia av den första token. För att identifiera utloggning registreras Tokenmon för utloggningsavisering via funktionen SeRegisterLogonSessionTerminatedRoutine i kernelläge, ett API som finns till förmån för filsystemdrivrutiner, som kallas nätverksomdirigeringar, som cachelagrar inloggningssessionsdata och vill rensa när en användare loggar ut. Nätverksomdirigeringar implementerar klientsidan för fildelningsklient-/serveranslutningar.

En annan intressant implementeringsdetalj för Tokenmon är hur Tokenmon ansluter de API:er som övervakas. Några av de API:er som Tokenmon-hookar inte exporteras för användning av enhetsdrivrutiner, men som exporteras i användarlägets NTDLL.DLL-bibliotek för användning av program som använder sina Win32-motsvarigheter. Alla Register-API:er som Regmon-hookar exporteras i kernelläge, vilket gör det möjligt för Regmon-enhetsdrivrutinen att hämta sina systemanropsnummer och koppla systemanropstabellen på rätt sätt. För API:er som inte exporteras för användning av drivrutiner måste tokenmon-gränssnittet hämta anropsnumren med hjälp av exporterna i NTDLL.DLL och sedan skicka numren till drivrutinen så att drivrutinen kan koppla systemanropstabellen. Tokenmon visar därför hur du ansluter systemanrop som inte exporteras i kernelläge.

Ladda ned Tokenmon v1.0 med fullständig källa www.sysinternals.com/tokenmon.htm.

FILEMON V4.32

Den senaste Filemon-uppdateringen introducerar mer intuitiv och fullständig filtrering, visning av fullständiga UNC-sökvägsnamn för Windows 9x/Me-nätverksfilåtkomst och visning av NTFS-metadatafilnamn.

Tidigare versioner av Filemon krävde att du anger filter med obligatoriska jokertecken. Om du till exempel vill övervaka åtkomsten till Temp-katalogen på enheten var du tvungen att ange C: ett filter så här: " c:\temp\* ". Med den nya filtreringssyntaxen är jokertecken valfria, så medan exempelfiltret skulle fungera skulle c:\temp " " " uppnå samma effekt. Dessutom tillämpar Filemon nu de filter som du anger mot alla fält i visningen, inklusive processnamn, typ av begäran, sökväg och "annan"-kolumn. Med den här flexibiliteten kan du hålla utkik efter specifika typer av begäranden eller begäranden med vissa data i den andra kolumnen, något som inte tidigare var möjligt.

Användare av Filemon på Windows 9x/Me-system ser nu Visningssökvägsnamn för Filemon med fullständig UNC-syntax när de använder fjärrresurser. Filemon visade tidigare inte server- eller resursnamnet för sådan åtkomst, vilket resulterade i ofullständiga sökvägsnamn.

Slutligen, om du har använt Filemon på Windows NT/2000 har du säkerligen sett texten "DASD" i sökvägskolumnen för många åtkomster ("DASD" kommer från "Direct Access Storage Device", en term som Microsoft använder för att beskriva åtkomst till en volym som kringgår filsystemstrukturer). För de flesta aktiviteter på NTFS-volymer är DASD nu något av det förflutna. I stället visas namnen på NTFS-metadatafilerna som läses och skrivs. Till exempel skulle en uppdatering av en MFT-post ha resulterat i en DASD-utdatarad tidigare, men nu ser du den som en åtkomst till "$Mft", MFT:s interna metadatafilnamn.

Varför visade inte Filemon metadatafilnamn tidigare och hur hämtar den dessa namn nu? Filobjekten som representerar NTFS-metadatafiler lagrar inget filnamn, så Filemon kan inte extrahera namnet från filobjektet. Filemons alternativa metod för att hämta en fils namn, fråga filsystemdrivrutinen, fungerar inte heller för NTFS-metadatafiler. Medan NTFS svarar med namnen på metadatafiler orsakar NTFS på NT 4 slumpmässigt krascher, och NTFS på Win2k låser sig ibland när den svarar på sådana frågor.

Filemon måste därför tillgripa ett trick för att hämta metadatafilnamnen. När en begäran som riktas mot ett filobjekt på en NTFS-volym utan namn visas skickar NTFS en fråga om filens index. Det här är samma index som Win32-funktionen GetFileInformationByHandle returnerar, och för filer på NTFS-volymer är indexet filens MFT-index. De första 16 posterna i MFT är reserverade för specifika metadatafiler, så med ett index i det intervallet letar Filemon bara upp metadatafilnamnet i en egen tabell.

Tyvärr ser du fortfarande DASD för katalogmetadata och FAT-åtkomst (File Allocation Table) på FAT-volymer, eftersom FAT inte lagrar namn för katalogmetadatafiler eller FAT. Du kommer att bli överraskande över hur ofta NTFS-loggfilen ($LogFile) används. NTFS på Engström lagrar namn på metadatafiler, så tricket är onödigt på Engström.

Den slutliga Filemon-förbättringen gör det möjligt för Filemon att visa tidsstämplar för tid på dagen med en millisekunders upplösning. Det här stödet krävde fula hack i Windows 9x/Me Filemon-drivrutinen på grund av buggar i en tidsfunktion i Windows 9x/Me-kerneln. Mer information finns i källkoden.

Ladda ned Filemon v4.32 med källkod på www.sysinternals.com/filemon.htm.

REGMON V4.32

Regmons ändringar är inte lika stora som för Filemon, men Regmon stöder nu samma mer intuitiva filtreringssyntax som Filemon, och precis som Filemon tillämpar filtren på alla fält. Den kan också visa millisekunders upplösning på tidsstämplar.

De av er som har börjat leka med Görr (efterföljaren till Windows 2000) Beta 1 kanske har märkt att tidigare versioner av Regmon kraschar Med Enr när du startade. Det beror på att Microsoft har placerat systemanropstabellen, som Regmon ändrar för att infoga sina hookar, i skrivskyddat minne. Regmon v4.32 kan användas för att komma runt detta med hjälp av en teknik som jag inte har angett källkod för på begäran av Microsoft, eftersom tekniken kan brytas i den slutliga versionen av Vsr och Microsoft utforskar olika sätt att stödja systemanrops hooking. Windows NT har inte utformats för att stödja systemanrops hooking, vilket är något som vi kom fram till i den första versionen av Regmon i mitten av 1996.

Här är ett odokumenterat Filemon/Regmon-tips. Jag får ofta e-postmeddelanden som frågar hur man kör Regmon eller Filemon från ett icke-administrativt konto på Windows NT/2000 Det finns många fall när ett visst program fungerar korrekt när det körs från administratörskontot, men inte från en användare utan privilegier, där Regmon och Filemon kan vara användbara för att avgöra varför programmet misslyckas (det är vanligtvis ett problem som rör säkerhetsinställningar för en fil eller registernyckel). Men att köra Regmon och Filemon från ett konto utan privilegier misslyckas eftersom både Filemon och Regmon installerar enhetsdrivrutiner, något som kräver administratörsbehörighet.

Det finns dock ett trick som gör att du kan komma runt detta: Om du loggar in som administratör och startar Filemon eller Regmon kan du senare köra dem från konton utan privilegier. Det beror på att Filemon och Regmon installerar en drivrutin vid den första körningen och i följande körningar får du åtkomst till den drivrutin som redan har lästs in. Eftersom jag inte implementerar någon säkerhet i drivrutinen kan en användare utan privilegier köra verktygen när drivrutinen har lästs in. Säkerhetsproblem? Ja, men Filemon och Regmon är avsedda att vara felsökningsverktyg, så jag och de personer som frågar om att köra verktygen från icke-privilegierade konton kan se detta som en funktion.

Ladda ned Regmon v4.32 med fullständig källkod på www.sysinternals.com/regmon.htm.

DEBUGVIEW V4.02

Ett av de program som jag har fått mest användarfeedback för är, något överraskande, DebugView. Den här nya versionen har några betydande förbättringar som tar upp många av de funktionsförfrågningar som jag har fått och gör DebugView kraftfullare än någonsin.

DebugView har nu stöd för upp till fem olika markeringsfilter, var och en med egna anpassningsbara färger. På så sätt kan du samtidigt använda olika nyckelord i dina felsökningsutdata och enkelt särskilja dem. Dessutom implementerar DebugView samma nya filtreringssyntax som Filemon och Regmon, vilket gör jokertecken valfria för matchning av delsträngar.

Ett klagomål som jag fick om tidigare versioner av DebugView är att även om du bara vill samla in Win32-felsökningsutdata, behöver du fortfarande administratörsbehörighet för att köra DebugView, eftersom DebugView inte skulle köras om det inte gick att installera dess enhetsdrivrutin. Den här nya versionen körs även från konton som inte har några särskilda privilegier. Om den inte kan installera eller komma åt drivrutinen inaktiverar den helt enkelt sina avinstallationsrelaterade menyalternativ i kernelläge.

Två funktioner som gör det enklare att få DebugView att börja samla in utdata automatiskt när du loggar in är alternativet minimera till fack och stöd för kommandoradsväxlar. Med hjälp av kommandoradsväxlar kan du ha DebugView starta i systemfältet och logga utdata som avbildas till en fil, och när du har startat DebugView kan du använda ett menyalternativ för att växla dess minimera knappbeteende mellan att minimera normalt och minimera till systemfältet.

För användare som kör DebugView i fjärrsessioner på Windows 2000-terminaltjänster samlar DebugView nu in Win32-utdata som genereras av program som körs i fjärrsessionen och eventuellt från konsolsessionen. Detta är användbart vid fjärrfelsökning av COM-servrar och Win32-tjänster, eftersom dessa typer av program körs i konsolsessionen.

Slutligen fungerar Nu fungerar DebugView på Gör betaversion 1, med stöd för att samla in utdata från flera nya Varianter i Kernel-läge DbgPrint-funktionen.

Ladda ned DebugView v4.02 www.sysinternals.com/dbgview.htm.

INUTI WINDOWS 2000, TREDJE UTGÅVAN

Den officiella boken om internt i Windows 2000 är nu tillgänglig! Den här utgåvan, som är medhord av David Edition (www.solsem.com) och Mark Russinovich, är över 40 % större än tidigare, med ny täckning av nätverk, plug-and-play, energispartjänster, tjänster, registret, WMI, start och avstängning samt lagring. Den innehåller också en CD med flera kraftfulla verktyg, som inte är tillgängliga någon annanstans, för att undersöka Windows 2000 internt.

Ett av de verktyg som jag har skrivit specifikt för boken är LiveKd, ett program där du kan köra både Microsofts kernelfelsökare, i386kd och WinDbg, på ett live-system som om du tittade på en kraschdump. Många av experimenten som presenteras i boken fungerar på ett live-system när de körs med LiveKd. LiveKd fungerar genom att installera en filterdrivrutin för filsystemet som visar datorns fysiska minne för Microsoft-felsökaren som om det vore en kraschdumpfil. LiveKd skapar en pseudodumpfil med längden 0, och när felsökaren läser från filen returnerar LiveKd data från det fysiska minnet. Kolla in bokens felsida och uppdateringssida för en LiveKd-korrigering som korrigerar en inkompatibilitet mellan LiveKd v1.0 och flera virusskannrar med åtkomst.

Se bokens innehållsförteckning och beställ nu via www.sysinternals.com/insidew2k.htm.

NOVEMBER OCH WINDOWS 2000 MAGAZINE

Undrar du vad som har ändrats exakt mellan NTFS v4 och NTFS v5? I så fall kan du kolla in min serie i två delar i november- och Windows 2000-bladet. Del 1 beskriverparspunkter, katalogförgreningar, volymmonteringspunkter, kvotstöd och konsoliderade säkerhetsinställningar. Del 2 avslutas med en närmare titt på kryptering, strömmar, spårning av distribuerade länkar och ändringsjournalen. Båda artiklarna tar dig djupare än andra och presenterar ändringarna på disken och det interna beteendet för dessa nya funktioner.

En sak jag inte pratar om i artiklarna är hur NTFS för Windows NT 4 egentligen inte är version

Du hittar länkar till alla våra publikationer på www.sysinternals.com/publ.htm.

SYSINTERNALS AT WWW.MICROSOFT.COM

Sysinternals har gjort ett framträdande i flera nya Microsoft Knowledge Base-artiklar (KB) sedan det senaste nyhetsbrevet, och jag har också spårat några äldre KB-artiklar som refererar till Sysinternals.

  • Q260513 PRB: Ett fel uppstår när du installerar Visual Studio produkter
    http://support.microsoft.com/support/kb/articles/Q260/5/13.ASP
    Den här artikeln rekommenderar läsarna att använda Filemon och Regmon för att felsöka Visual Studio microsoft-installationsproblem.

  • Q202258 XADM: Systemet kan inte hitta den angivna sökvägen – ID nej: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    Microsoft går faktiskt igenom hur användare använder Filemon för att felsöka problem med Exchange 5.0 service pack-uppgradering, komplett med ett exempel på en Filemon-utdatarad och rekommendationer för att konfigurera filter.

  • Q269383 PRB: "Fel vid åtkomst till systemregistret"-meddelande när VB/VBA-referenser visas
    http://support.microsoft.com/support/kb/articles/Q269/3/83.ASP
    Regmon hämtar referensen från den här artikeln, som beskriver hur du använder den för att avgöra varför dialogrutan Referenser i Visual Basic IDE rapporterar när den inte kan komma åt en registernyckel på grund av en bugg i Seagate Crystal Reports som tillämpar felaktiga behörigheter på flera nycklar.

  • Bugg för Q269251: Automatisering av Windows installationsprogram kan stanna upp när produkter räknas upp
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Regmon markeras igen här, där det används för att visa ett fel Windows installationsprogrammet för automatisering.

  • Q276525 Datorn kan sluta svara när du övervakar öppna referenser
    http://support.microsoft.com/support/kb/articles/Q276/5/25.asp
    NtHandle ansvarar för att avslöja en bugg i Windows NT 4 SP6a, där kerneln låser sig under vissa villkor när ntHandle används. Microsoft har arbetat med mig för att lösa problemet och de har utfärdat en snabbkorrigering. Om NT 4-systemet låser sig när du använder NtHandle bör du följa länken till den här artikeln.

  • Q160660 Ntregmon.exe orsakar STOP 0x0000001E med nytt Service Pack
    http://support.microsoft.com/support/kb/articles/Q160/6/60.asp
    Den sista är en gammal, men god vän. Den första versionen av Regmon använde hårdkodade systemanropsnummer för att korrigera systemtjänsttabellen för att koppla register-API:er. Eftersom systemanropsnumren ibland ändras mellan service pack är den här tekniken ganska sårbar och jag hade inte kodat på ett försvarligt sätt för att skydda detta (mot råd från Andrew Organisationsman, som var orolig att Regmon skulle bryta). Sp3 introducerade några nya systemanrop och Regmon kraschade systemet när fel systemanrop kopplades till. Även om detta säkert retade upp några personer fick jag ut min egen KB-artikel av den!

SYSINTERNALS-LICENSIERING

Även om den programvara som du laddar ned från Sysinternals är freeware, vilket innebär att du kan använda den utan att betala en avgift, har du inte behörighet att distribuera om den eller härleda produkter som du distribuerar från Källkoden sysinternals. Om du till exempel arbetar på ett företag där flera användare tycker att vissa Sysinternals-verktyg är användbara kan du inte publicera verktygen på en intern resurs eller webbplats. Placera i stället en länk på webbplatsen till varje verktygs hem på Sysinternals. Det hjälper också till att se till att dina medarbetare alltid laddar ned de senaste versionerna.

Om du vill distribuera sysinternals-verktyg internt, med en kommersiell produkt eller på en shareware-CD, eller om du vill basera en kommersiell produkt eller ett omistbart program på Sysinternals källkod, skickar du ett e-postmeddelande med information om din önskade användning för licensing@....

INFORMATION OM INTERNT

NFI

I några nyhetsbrev visade jag att det finns verktyget DiskEdit som Microsoft oavsiktligt levererade på NT 4 SP4 CD. DiskEdit är ett mycket kraftfullt, men egendomligt, visningsprogram för filsystemstruktur som du kan använda för att undersöka NTFS och FAT (även om det är DET NTFS-stöd som är intressant) datastrukturer på disk. Om du missade NT 4 SP 4 CD och är intresserad av att utforska NTFS-strukturer på disk är du dock inte helt ute i det mörka. Microsoft har lanserat ett kostnadsfritt verktyg med namnet NFI (NTFS Information) som förstår och kan dumpa de interna strukturerna för NTFS-volymer. Även om dess utdata inte är alls lika detaljerade som DiskEdit, är det intressant och avslöjande.

Du kan ladda ned NFI som en del av OEM-supportverktygen på http://support.microsoft.com/support/kb/articles/q253/0/66.asp. Om du kör NFI med ett filnamn dumpas NTFS MFT-posten för filen. I följande exempel visas NFI dumpa MFT-posten för metadatafilen, en fil som bara finns om du har $Quota aktiverat kvothantering på en volym:

C:\nfi c:\$extend\$quota
File 24
\$Extend\$Quota
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $O (resident)
$INDEX_ROOT $Q (resident)

Utdata visar att filen upptar den 24:e posten i MFT (dess filindex är 24) och att den innehåller fyra attribut, inklusive standardinformation, filnamn och två indexrötter (och index är i princip en sorterad lista med poster, t.ex. en katalog). Jag beskriver hur NTFS använder $Quota indexen i min senaste Windows 2000 Magazine-serien på NTFS v5.

Om du vill dumpa alla filer på en volym anger du enhetsbeteckningen på NFI:s kommandorad utan filnamn, t.ex. nfi c: . Du ser en lista över varje MFT-post, inklusive alla metadatafiler.

NFI har några andra förmågor, till exempel möjligheten att översätta ett sektornummer till filen där det finns. Vill du veta vilken filsektor 2345 på enheten C: som finns på? Använd kommandot nfi c: 2345 . Observera att detta misslyckas på programvaru-RAID-volymer som volymuppsättningar och stripe-uppsättningar. NFI fungerar på både NT 4 och Windows 2000.

DOLDA WIN9X-REGISTERNYCKLAR

För två problem sedan sa jag att jag skulle ta upp "dolda Win9x-registernycklar" i följande nyhetsbrev, och flera av er påminner mig om att jag har glömt. Så den här månaden ska jag berätta om dolda registernycklar i Windows 9x.

För flera år sedan upptäckte jag ett sätt att skapa dolda registernycklar i Windows NT. Med dolda menar jag att även om du kan se att nycklarna används av programmet som skapar dem med Regmon, kan du inte skriva ett Win32-program för att titta på nyckelns värden, och du kan inte heller titta på nycklarna med Regedit- eller Regedt32-registereditorn. Dolda nycklar är användbara för att lagra data som du inte vill att slutanvändarna ska kunna ändra, till exempel en utvärderingsprodukts tidsgränsdatum.

Tricket med att skapa en dold registernyckel var min insikt att det inbyggda NT API:et, som är systemgränssnittet där Win32-API:et har skapats, kräver att registernycklar anges som räknade Unicode-strängar. En räknad Unicode-sträng är en vars längd anges av ett längdfält, inte förekomsten av en null-terminator. Med hjälp av det interna API:et kan du därför skapa registernycklar som innehåller ett null-tecken, till exempel "test\0test" . Eftersom API:et för Win32-API:et registernyckel baseras på null-avslutade strängar går det inte att öppna en registernyckel som innehåller en null-avslutning med hjälp av Win32-API:et. Om du försöker skicka det föregående exempelnyckelnamnet till eller behandlas det som , med RegOpenKeyRegCreateKey"test" strängen trunkerad vid null-tecknet. Eftersom alla befintliga registereditorer, inklusive de som paketeras med Windows NT och Windows 2000, använder win32-API:et, gör ett program som använder det interna API:et för att skapa null-tecken-inbäddade namn i praktiken dolda nycklar.

Den här metoden fungerar på Windows NT, men hur är det med Windows 9x? Jag trodde inte att det fanns något sätt att göra dolda registernycklar på Windows 9x förrän någon e-postade mig med en Regmon-loggfil som visar Internet Explorer (IE) som har åtkomst till nycklar som inte visas i Regedit. Om du vill se detta själv startar du Regmon och anger följande include-filter: "policydata". Starta sedan IE (detta fungerar för alla versioner av IE 4 och IE 5) och besök en webbplats. Om du inte ser några utdata i Regmon går du till dialogrutan för konfiguration av IE-alternativ och ser till att Content Advisor är aktiverad.

Om Content Advisor har aktiverats eller någonsin har aktiverats i systemet visas åtkomsten till en HKLM\PolicyDat nyckel och dess undernycklar. Du hittar dock inte en PolicyData-nyckel under när HKEY_LOCAL_MACHINE du tittar i Regedit. Ta en minut och se om du kan ta reda på vad som händer.

Svaret är att IE dynamiskt läser in en registreringsdatafil med hjälp av RegLoadKey Win32-API:et, läser de värden som behövs och sedan tar bort registreringsdatafilen med RegUnloadKey . Registreringsdatafilen heter C:\Winows\System\Ratings.pol – filen är dold och skrivskyddad, men du kan visa den genom att skriva attrib –r –h c:\windows\system\ratings.pol .

De spårningar som visas i Regmon visar den information som Innehållsrådgivaren letar efter i registreringsdatafilen. Om du vill utforska innehållet själv laddar du ned mitt Regload-verktyg från www.sysinternals.com/regload.zip kör det med följande syntax: regload test c:\windows\system\ratings.pol . Öppna sedan Regedit och HKLM\test bläddra. De värden som du hittar motsvarar de inställningar som du anger i Content Advisor och är relaterade till konfigurationsfilen med namnet Users\FileName0 i värdet i registreringsdatafilen. Värdet pekar vanligtvis på C:\Windows\System\RSACi.rat , den klassificeringsfil som definierats av Internet Content Rating Association. Du kanske ser ett värde med det något annorlunda namnet "PleaseMom" i Content Advisors registerinställningar, till exempel under HKLM\Test\Users\Default . Det här värdet härleds från kryssrutan "Övervakare kan ange ett lösenord för att tillåta användare att visa begränsat innehåll" på sidan Allmänt i dialogrutan Inställningar för Innehållskontroll.

Anledningen till att Microsoft skulle fördr bort förekomsten av dessa registervärden bör vara uppenbar. Det finns dock en ganska allvarlig svaghet i designen. Observera att när du aktiverar Content Advisor måste du ange ett lösenord som skyddar dialogrutan inställningar för Innehållsrådgivare. Det här lösenordet lagras i HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key . Ta bort det värdet och du kan komma åt inställningarna för Content Advisor utan att ange något lösenord! Om IE-utvecklarna nu hade problem med att fördröj inställningarna för Content Advisor, varför lämnar de den här bakdörren öppen? Typisk Microsoft-säkerhetsdesign, antar jag. För att ta bort nyckeln som du läst in med Regload skriver regload test du .

DET HÄR ÄR VAD SOM HÄNDER

NYA SYSTEMANROP

Ther är en inkrementell utveckling av Windows 2000-operativsystemet med fokus på ökad tillförlitlighet och enkel migrering av användare från Windows 9x operativsystem. Den innehåller dock vissa kerneländringar. De mest synliga är antalet nya systemanrop och exporterade kernelfunktioner (som kan användas av enhetsdrivrutiner). Nästa gång ger jag dig en förhandsgranskning av dessa nya kernel-API:er.


Tack för att du läser Sysinternals Nyhetsbrev.

Publicerad torsdag 30 november 2000 19:05 av pm

[Newsletters Archive ^][ Volume 2, Number 4][Volume 3, Number 1 ]

[Newsletters Archive ^][ Volume 2, Number 4][Volume 3, Number 1 ]

Systems Internals Newsletter, volym 2, nummer 5

www.sysinternals.com
Copyright (c) 2000 Mark Russinovich