Dela via


[Nyhetsbrev arkiv ^][< Volym 2, nummer 4][Volym 3, nummer 1 >]

System Internals Newsletter Volym 2, Nummer 5

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


30 november 2000 – I det här problemet:

  1. REDAKTIONELLA

  2. NYHETER 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, 3rd Ed.
    • November och vintern Windows 2000 Magazine
    • Sysinternals på Microsoft
    • Sysinternals-licensiering
  3. INTERN INFORMATION

    • NFI
    • Dolda Win9x-registernycklar
  4. VAD KOMMER UPP

    • Nya Whistler System-samtal

SPONSOR: WINTERNALS SOFTWARE

Sysinternals Nyhetsbrev sponsras av Winternals Software, på webben på www.winternals.com. Winternals Software är den ledande utvecklaren och leverantören av avancerade systemverktyg för Windows NT/2K. Winternals Software-produkter inkluderar FAT32 för Windows NT 4.0, NTFSDOS Professional Edition (en läs-/skriv-NTFS-drivrutin för DOS) och Remote Recover.

Netstat-kommandot, som levereras med alla versioner av Windows 9x och Windows NT/2000, visar vilka TCP/IP-portar som är öppna i systemet, men det visar inte vilken process som har porten öppen. TCPView Pro, Winternals senaste övervakningsverktyg, levereras inte bara med ett netstat-motsvarande kommandoradsverktyg, Tcpvstat, som visar vilken process som har varje port öppen, utan innehåller ett GUI 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, lyckad åtkomst och mängden data som överförs. TCPView Pro är bara $69. Ladda ned den 14 dagar långa fullt fungerande utvärderingsversionen av TCPView Pro idag 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 kallas drivrutinsverifieraren. Du kan konfigurera verifieraren, som du startar genom att skriva "verifier" i dialogrutan Start-menyn Kör, för att noga övervaka körningen av specifika enhetsdrivrutiner och leta efter brott mot någon av flera regler för drivrutinsprogrammering. Kontrollanten går ett steg längre än passiv övervakning, men – det förvärrar också potentialen; felvillkor genom att till exempel allokera minnesblock för drivrutinen som är överspedd med ogiltiga regioner och nollställa specifika fält i datastrukturer som skickas till drivrutinen. Om du verkligen vill bli tuff kan du låta kontrollanten simulera låg minnesanvändning för drivrutinen.

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

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

Drivrutiner som inte ofta installeras med INF-filer är virusskannrar, krypteringsprogram och CD-ROM-brinnande programvara. Det hindrar dock inte maskinvarurelaterade drivrutiner från att glida igenom. 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 signeringskontroller för drivrutiner. Detta kryphål leder till förekomsten av drivrutiner i systemet som inte har verifierats, vilket kan äventyra systemets stabilitet (jag verifierar alla Sysinternals-drivrutiner på 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 är jag på denna rant? Min CD-ROM brinnande programvara, som är den mest populära av den typen av programvara på marknaden, har en drivrutin som reproducibly kraschar min Windows 2000 SP1 system. Om jag konfigurerar drivrutinsverifieraren för att kontrollera den slutför systemet inte ens starten innan verifieraren identifierar förarens första överträdelse och kraschar systemet. Drivrutinen installerades utan en INF-fil så jag blev inte varnad om att den var osignerad. Jag garanterar att om Microsofts policy var striktare att denna leverantör skulle tänka två gånger innan leverans av en osignerad (och buggy) drivrutin.

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

Tack!

-Markera

NYHETER PÅ SYSINTERNALS

PSLOGGEDON V1.2

Förutom ett uppenbart namnbyte från LoggedOn till PsLoggedOn har det här kommandoradsverktyget, som har möjlighet att visa dig vem som är inloggad lokalt och via resursresurser på det lokala eller ett fjärrsystem, några nya funktioner. Den första är kommandoradsväxeln "-l" som har resulterat i användarfeedback. Många använder PsLoggedOn för att se om något konto är inloggad lokalt 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 andra nya funktionen visar dig inte bara vem som är inloggad, men den tid då inloggningen ägde rum. PsLoggedOn hämtar inloggningstider för inloggningar från resursresurser kostnadsfritt när det använder ett Win32 API, NetSessionEnum, för att räkna upp resursresursinloggningar (kommandoradskommandot Net använder också NetSessionEnum för att räkna upp sessioner). Det finns dock inget Win32-API som talar om för dig 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:erna (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 profilen HKEY_USERS in i nyckeln. Program kan komma åt profilens registerinställningar via HKEY_CURRENT_USER nyckeln eftersom systemet behandlar den nyckeln som en symbolisk länk till deras specifika profil under HKEY_USERS. PsLoggedOn kan alltså veta vem som är inloggad lokalt genom att översätta de SID:er som hittas i en dators HKEY_USERS nyckel till motsvarande användarnamn. PsLoggedOn använder RegConnectKey för att ansluta till en fjärrdators register när du dirigerar det till en lista över användare som är inloggade på ett fjärrsystem.

Att ta reda på vilken tid en användare loggade in fungerar med ett liknande trick. När WinLogon-processen läser in en användares profil efter HKEY_USERS inloggningen skapar WinLogon en flyktig (inte sparad i profilen på disken) i sin profil med namnet, lämpligt nog, Volatile Environment. Registret lagrar senast ändrade tidsstämplar för registernycklar och eftersom systemet inte ändrar undernycklar för flyktiga miljöer 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 undernyckeln Volatile Environment.

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

PSSHUTDOWN V1.0

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

Ladda ned PsShutdown v1.0 på 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 de aktiva processerna i det lokala eller fjärranslutna Windows NT/2000-systemet. Jag gav PsList dess namn eftersom unix-standardverktyget för processinformation med kommandoraden 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 gjorde en perfekt följeslagare 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 fjärranslutna Windows NT/2000-systemet. 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 knyta ihop alla dessa verktyg genom att ge dem alla "Ps"-prefixet och göra dem nedladdningsbara som ett enda paket med namnet PsTools.

PsTools, som innehåller PsList, PsKill, samt det 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 både lokalt och via fjärranslutning.

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

BGINFO V1.1

Som ett resultat av en enorm användarfeedback har Bryce uppdaterat BgInfo, ett verktyg som ställer in skrivbordsunderlägg för att visa anpassningsbar information om ett systems konfiguration, som ett resultat av den användarfeedback han har 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 /timerdu ändra eller eliminera nedräkningen helt 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. Skrivbordsbitmappen BgInfo v1.1 som skapas är också generellt mindre, vilket minimerar BgInfos fotavtryck för skrivbordsminnet.

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

TOKENMON V1.0

Tokenmon är det senaste tillägget till den varierade sviten med övervakningsverktyg som du kan ladda ned från Sysinternals. Tokenmon, som delar samma användargränssnitt som för sina kusiner som Regmon och Filemon, övervakar betydande säkerhetsrelaterad aktivitet i ett Windows NT/2000-system. Vad är "betydande" säkerhetsrelaterad aktivitet? Kärnan i Windows NT/2000-säkerheten är tokenobjektet, en datastruktur som innehåller ett konto-SID, grupp-SID:er 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 åtkomstverifieringen. Om en process försöker utföra en begränsad åtgärd, till exempel starta om systemet, kontrollerar systemet rätt behörighet i processens token.

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

Tokenmon installerar systemanropskrokar på samma sätt som Regmon gör för register-API:er, för att övervaka skapandet och borttagningen av token, aktivering och inaktivering av behörigheter och personifiering. Tokenmon använder också processskapandekrokar som tillhandahålls av NT/2000-kerneln för att övervaka skapandet och borttagningen 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 NtCreateToken-systemanropet, som är det som används av inloggningskoordinatorer som WinLogon för att skapa en första token för den första processen i en ny inloggningssession. Processer som skapas av den första processen ärver en kopia av den första token. För att identifiera utloggning registrerar Tokenmon för utloggningsmeddelanden 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ätverksomdirigering implementerar klientsidan för fildelningsklient-/serveranslutningar.

En annan intressant information om tokenmonimplementering är hur Tokenmon kopplar de API:er som övervakas. Några av de API:er som Tokenmon-krokar inte exporteras för användning av enhetsdrivrutiner, utan 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-krokar exporteras i kernelläge, vilket gör det möjligt för Regmon-enhetsdrivrutinen att hämta sina systemanropsnummer och att koppla systemanropstabellen på rätt sätt. För API:er som inte exporteras för användning av drivrutiner måste Tokenmon GUI 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 kopplar systemanrop som inte exporteras i kernelläge.

Ladda ned Tokenmon v1.0 med full källkod på 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 åtkomster till temp-katalogen på enheten C:måste du ange ett filter som det här: "c:\temp\*". Med de nya jokertecken för filtreringssyntax är valfria, så även om 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 processnamnet, begärandetypen, sökvägen och kolumnen "annan". Med den här flexibiliteten kan du titta 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 kommer nu att se Filmons visningssökvägsnamn med fullständig UNC-syntax när de kommer åt fjärrresurser. Filemon visade tidigare inte server- eller resursnamnet för sådana åtkomster, vilket resulterade i ofullständiga sökvägsnamn.

Slutligen, om du har använt Filemon på Windows NT/2000 har du utan tvekan 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 ett exempel på det förflutna. I stället visas namnen på de NTFS-metadatafiler som läs- och skrivs. En uppdatering av en MFT-post skulle till exempel 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 inte ett 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 de 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 riktas mot ett filobjekt på en NTFS-volym utan namn skickar den en fråga till NTFS för 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 tanke på ett index i det intervallet letar Filemon helt enkelt upp metadatafilnamnet i sin egen tabell.

Tyvärr ser du fortfarande DASD för åtkomst till katalogmetadata och filallokeringstabell (FAT) på FAT-volymer, eftersom FAT inte lagrar namn för katalogmetadatafiler eller FAT. Du kommer att bli förvånad över hur ofta NTFS-loggfilen ($LogFile) används. För övrigt lagrar NTFS på Whistler namnen på metadatafiler, så tricket är onödigt på Whistler.

Den slutliga Filemon-förbättringen gör det möjligt för Filemon att visa tidsstämplar med 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 Filemons, men Regmon har nu stöd för samma mer intuitiva filtreringssyntax som Filemon, och likt 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 spela med Whistler (efterföljaren till Windows 2000) Beta 1 kanske har märkt att tidigare versioner av Regmon krasch Whistler när den startades. Detta beror på att Microsoft har placerat systemanropstabellen, som Regmon ändrar för att infoga sina krokar, i skrivskyddat minne. Regmon v4.32 fungerar runt detta genom att använda en teknik som jag inte har angett källkod för på begäran av Microsoft, eftersom tekniken kan bryta i den slutliga versionen av Whistler, och Microsoft utforskar sätt att stödja systemsamtalskrokning. Windows NT var inte utformat för att stödja systemsamtalskrok, vilket är något som vi var pionjärer med den första versionen av Regmon i mitten av 1996.

Här är ett odokumenterad Filmon/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 icke-privilegierad användare, där Regmon och Filemon skulle vara användbara för att avgöra varför programmet misslyckas (det är vanligtvis ett problem som rör säkerhetsinställningar på en fil eller registernyckel). Att köra Regmon och Filemon från ett konto som inte är privilegierat misslyckas dock 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 kringgå detta: Om du loggar in som administratör och startar Filemon eller Regmon kan du sedan köra dem från konton som inte är privilegierade. 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 redan inlästa drivrutinen. Eftersom jag inte implementerar någon säkerhet i drivrutinen kan en oprivilegierad användare köra verktygen när drivrutinen har lästs in. Säkerhetsproblem? Ja, men Filemon och Regmon är avsedda att felsöka verktyg så jag, och de personer som frågar hur man kör verktygen från icke-privilegierade konton, ser 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 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 hanterar många av de funktionsförfrågningar som jag har fått och gör DebugView mer kraftfullt än någonsin.

Mest synligt stöder DebugView nu upp till fem olika markeringsfilter, var och en med sina egna anpassningsbara färger. På så sätt kan du samtidigt använda olika nyckelord i felsökningsutdata och enkelt skilja dem åt. Dessutom implementerar DebugView samma nya filtreringssyntax som Filemon och Regmon, vilket gör jokertecken valfria för delsträngsmatchning.

Ett klagomål som jag fick om tidigare versioner av DebugView är att även om du bara ville samla in Win32-felsökningsutdata behövde du fortfarande administratörsbehörighet för att köra DebugView, eftersom DebugView inte skulle köras om det inte kunde 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 kernel-mode capture-relaterade menyalternativ.

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 bricka och stöd för kommandoradsväxlar. Med hjälp av kommandoradsväxlar kan du låta DebugView starta i systemfältet och loggutdata som den samlar in 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 i Windows 2000-terminaltjänster samlar DebugView nu in Win32-utdata som genererats av program som körs i fjärrsessionen och eventuellt från konsolsessionen. Detta är användbart för att felsöka COM-servrar och Win32-tjänster via fjärranslutning, eftersom dessa typer av program körs i konsolsessionen.

Slutligen fungerar DebugView nu på Whistler Beta 1, med stöd för att samla in utdata från flera nya Whistler-varianter på dbgPrint-funktionen i kernelläge.

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

INUTI WINDOWS 2000, 3RD EDITION

Den officiella boken om det interna i Windows 2000 är nu tillgänglig! Denna utgåva, som är medförfattare av David Solomon (www.solsem.com) och Mark Russinovich, är över 40% större än den tidigare, med ny täckning av nätverk, plug-and-play, energisparfunktioner, tjänster, registret, WMI, start och avstängning och lagring. Den innehåller även en CD med flera kraftfulla verktyg, som inte är tillgängliga någon annanstans, för att undersöka interna Windows 2000-enheter.

Ett av de verktyg som jag skrev specifikt för boken är LiveKd, ett program som låter dig köra båda Microsoft Kernel-felsökarna, i386kd och WinDbg, på ett livesystem som om du tittade på en kraschdump. Många av experimenten som presenteras i boken fungerar på ett livesystem 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ökningsprogrammet som om det vore en kraschdumpfil. LiveKd skapar en pseudodumpfil med 0 längd och när felsökningsprogrammet läser från filen returnerar LiveKd data från fysiskt minne. Kolla in bokens sida för fel och uppdateringar för en LiveKd-korrigering som korrigerar en inkompatibilitet mellan LiveKd v1.0 och flera virusskannrar med åtkomst.

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

NOVEMBER OCH VINTERN WINDOWS 2000 MAGAZINE

Vill du veta exakt vad som har ändrats mellan NTFS v4 och NTFS v5? I så fall kan du kolla in min serie i två delar i november- och vinterproblemen i windows 2000-tidningen. Del 1 beskriver referenspunkter, katalogkorsningar, 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 gör, presenterar ändringar på disk och internt beteende för dessa nya funktioner.

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

Hitta 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 (KB) artiklar sedan det senaste nyhetsbrevet, och jag har också spårat några äldre KB artiklar som hänvisar 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 att läsarna använder Filemon och Regmon för att felsöka installationsproblem i Microsoft Visual Studio.

  • Q202258 XADM: Systemet kan inte hitta den angivna sökvägen – ID nr: 0cx002003
    http://support.microsoft.com/support/kb/articles/Q202/2/58.ASP
    Microsoft vägleder faktiskt användarna genom att använda Filemon för att felsöka uppgraderingsproblem med Exchange 5.0 Service Pack, komplett med en Filemon-exempelutdatarad och rekommendationer om hur du konfigurerar 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 hänvisningen 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-rapporter när den inte kan komma åt en registernyckel till följd av en bugg i Seagate Crystal Reports som tillämpar felaktiga behörigheter på flera nycklar.

  • Q269251 BUGG: Automatisera Windows Installer kan hänga sig när produkter räknas upp
    http://support.microsoft.com/support/kb/articles/q269/2/51.asp
    Regmon är markerat igen här, där det används för att avslöja en Windows Installer automation bugg.

  • 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 skulle hänga sig under vissa förhållanden när NtHandle används. Microsoft arbetade 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 se 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 oldie, men goodie. 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 systemsamtalsnummer ibland ändras mellan servicepaket är denna teknik ganska bräcklig, och jag hade inte kodat defensivt i väntan på detta (mot råd från Andrew Schulman, som var rädd att Regmon skulle bryta). Visst, SP3 introducerade några nya systemanrop, och Regmon skulle krascha systemet när det hooked felaktiga systemanrop. Även om detta säkert irriterade några personer, fick jag min egen KB-artikel av det!

SYSINTERNALS-LICENSIERING

Även om programvaran du laddar ned från Sysinternals är gratisprogram, vilket innebär att du kan använda den utan att betala en avgift, får du inte omdistribuera den eller härleda produkter som du distribuerar från Sysinternals källkod. Om du till exempel arbetar på ett företag där flera användare tycker att särskilda Sysinternals-verktyg är användbara kanske du inte publicerar verktygen på en intern resurs eller webbplats. Placera i stället en länk på din webbplats till varje verktygs hem på Sysinternals. Detta hjälper också till att se till att dina medarbetare alltid laddar ned de senaste versionerna.

Om du vill omdistribuera Sysinternals-verktyg internt, med en kommersiell produkt eller på en shareware-CD, eller om du vill basera en kommersiell produkt eller omdistribuerbart program på Sysinternals källkod, skickar du ett e-postmeddelande som förklarar informationen om din önskade användning för att licensing@....

INTERN INFORMATION

NFI

Några nyhetsbrev tillbaka jag avslöjade förekomsten av DiskEdit verktyg som Microsoft oavsiktligt levereras på NT 4 SP4 CD. DiskEdit är ett mycket kraftfullt, men udda, visningsprogram för filsystemets struktur som du kan använda för att undersöka NTFS och FAT (även om det är NTFS-stödet som är intressant) datastrukturer på disk. Om du missade NT 4 SP 4 CD och är intresserad av att utforska NTFS på diskstrukturer är du dock inte helt ute i mörkret. Microsoft har släppt 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 alls är 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 som dumpar MFT-posten för $Quota metadatafilen, en fil som bara finns om du har kvothantering aktiverat 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 huvudsak en sorterad lista med poster, till exempel en katalog). Jag beskriver hur NTFS använder indexen $Quota i min senaste Windows 2000 Magazine-serie 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 talanger, som möjligheten att översätta ett sektornummer till filen där det finns. Vill du veta vilken filsektor 2345 på enheten C: som finns i? 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

Två frågor sedan jag sa att jag skulle täcka "dolda Win9x Registernycklar" i följande nyhetsbrev, och flera av er påminde mig om att jag hade 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 nycklarna som 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 Registry-redigerare. 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 om att det interna NT-API:et, som är det systemanropsgränssnitt som Win32 API:et bygger på, kräver att registernycklar anges som räknade Unicode-strängar. En räknad Unicode-sträng är en vars längd indikeras av ett längdfält, inte förekomsten av en null-terminator. Med 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:ets registernyckel baseras på null-avslutade strängar går det inte att öppna en registernyckel som innehåller en null-avslutning med win32-API:et. Om du försökte skicka föregående exempelnyckelnamn till RegOpenKey eller RegCreateKey om det skulle behandlas som "test" , med strängen trunkerad vid null-tecknet. Eftersom alla befintliga registerredigerare, 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-character-embedded-namn effektivt dolda nycklar.

Den här metoden fungerar i Windows NT, men hur är det med Windows 9x? Jag trodde inte att det fanns ett sätt att göra dolda registernycklar på Windows 9x tills någon e-postade mig med en Regmon-loggfil som visar Internet Explorer (IE) åtkomst till nycklar som inte visas i Regedit. Om du vill se detta själv startar du Regmon och anger följande inkluderingsfilter: "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 konfigurationsdialogrutan för IE-alternativ och ser till att Content Advisor är aktiverat.

Om Innehållsrådgivaren är aktiverad eller om den någonsin har aktiverats i systemet visas åtkomster till HKLM\PolicyDaten nyckel och dess undernycklar. Du hittar dock ingen PolicyData-nyckel under HKEY_LOCAL_MACHINE när du tittar i Regedit. Ta en minut och se om du kan ta reda på vad som händer.

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

Spårningarna som du ser 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 och kör det med följande syntax: regload test c:\windows\system\ratings.pol. Öppna sedan Regedit och bläddra HKLM\testi . De värden som du hittar motsvarar de inställningar som du anger i Innehållsrådgivaren och är relaterade till konfigurationsfilen med namnet i Users\FileName0 värdet i registreringsdatafilen. Värdet pekar vanligtvis på C:\Windows\System\RSACi.rat, klassificeringsfilen som definieras av Internet Content Rating Association. För övrigt kan du se ett värde med det något humoristiska namnet "PleaseMom" i Innehållsrådgivarens registerinställningar, till exempel under HKLM\Test\Users\Default. Det här värdet härleds från kryssrutan "Övervakaren kan skriva ett lösenord så att användare kan visa begränsat innehåll" på sidan Allmänt i dialogrutan Innehållsrådgivareinställningar.

Anledningen till att Microsoft skulle dölja förekomsten av dessa registervärden bör vara uppenbar. Det finns dock en ganska allvarlig svaghet i deras design. Observera att när du aktiverar Innehållsrådgivaren måste du ange ett lösenord som skyddar innehållsrådgivarens inställningsdialogruta. Det här lösenordet lagras i HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Ratings\Key. Ta bort det värdet och, före, du kan komma åt Content Advisor-inställningarna utan att ange ett lösenord! Om IE-utvecklarna nu har problem med att dölja Content Advisor-inställningarna, varför lämnar de den här bakdörren hängande i det öppna? Typisk Microsoft-säkerhetsdesign, antar jag. Förresten, för att ta bort nyckeln som du läste in med Regload skriver regload testdu bara .

VAD KOMMER UPP

NYA WHISTLER-SYSTEMANROP

Whistler är en inkrementell utveckling av operativsystemet Windows 2000 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 de få nya systemanropen och exporterade (tillgängliga för användning av enhetsdrivrutiner) kernelfunktioner. Nästa gång ska jag ge dig en förhandsversion av dessa nya kernel-API:er.


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

Publicerad torsdag 30 november 2000 19:05 av ottoh

[Nyhetsbrev arkiv ^][< Volym 2, nummer 4][Volym 3, nummer 1 >]