Dela via

  • Artikel

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

System Internals Newsletter Volym 1, Nummer 3

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

19 juni 1999 – I det här problemet:

  1. NYHETER PÅ SYSTEM INTERNALS

    • SDelete v1.1
    • Strängar v2.0
    • Loggad
    • Filemon v4.13
    • FelsökaView/EE v3.1
    • "Inuti NT-nätverk"
    • Juni "NT Internals"
    • Uppdateringsstatus för NTFrob
    • Inte så nya saker

  2. INTERNALS NEWS

    • Numega DriverStudio släppt
    • June Platform SDK tillgänglig
    • Win2K System File Protector (SFP)
    • Stänga filer som öppnats från nätverket

  3. VAD KOMMER UPP

    • En "AWE"-vissa Win2K API

SPONSOR: WINTERNALS SOFTWARE

Nyhetsbrevet System Internals sponsras av Winternals Software, på webben på http://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, ERD Commander (startdiskkapacitet för Windows NT) och NTRecover.

Winternals Software tillkännager lanseringen av Regmon och Filemon Enterprise Editions. Dessa verktyg tillhandahåller alla funktioner i freeware Filemon och Regmon och lägger till dessa kraftfulla funktioner:

  • visa register- och filsystemaktivitet som äger rum på fjärranslutna Win9x/NT-system
  • loggutdata till en fil i realtid
  • kopiera utdatalinjer till Urklipp
  • markera rader som matchar ett filter
  • visa utdata från olika datorer samtidigt
  • skriva ut direkt till en skrivare
  • enkelt återkalla dina senaste 5 filterval

Få beställnings- och prisinformation på http://www.winternals.com.

Hej!

Välkommen till den tredje utgåvan av Systems Internals nyhetsbrev. Nyhetsbrevet har för närvarande 4400 prenumeranter.

I det senaste nyhetsbrevet påpekade jag hur Microsoft har gjort sig av med Blue Screen of Death som vi vet att det går vidare till Windows 2000 (Win2K). Den nya Win2K-blå skärmen har inte den inlästa drivrutinen och stackdumparinformationen som finns på den blå skärmens tidigare versioner av Windows NT. Jag frågade om du tycker att informationen Microsoft har tagit bort användbar och önskar att de hade lämnat saker ensamma. Svaret var praktiskt taget enhälligt, där varje enskild svarande (utom en) undrade varför Microsoft går för den lägsta gemensamma nämnaren. Här är en typisk åsikt, skickas in av Tony Lavinio:

Det här är alltså det kundsvar som Microsoft baserar sitt beslut på:

" Jag förstår det inte, så det måste vara dåligt; få det att försvinna."

Varför tar de inte bort hela skärmen och lägger upp ett meddelande med texten "Pull Plug, Reinsert Plug, Start Over"? Varför tar de bort en av de få ledtrådar vi har om varför saker gick surt?

Åtminstone tidigare, om det var en virusskanner eller defragmenter eller buggy-drivrutin, skulle vi ha en punkt att börja söka från.

Om det här verktyget bara hjälper 1 av 10 000 av oss, med den breda basen för NT-distribution, är det värt det. Speciellt eftersom vi .01% stöder en stor del av de andra 99,99%.

Vem var den ensamme oliktänkande? Det är inte så förvånande att det är någon från Microsoft som fält Blåskärm kraschrapporter. Här är deras vinkling på förändringen, vilket bekräftar Tonys spekulationer om orsaken till det:

Jag arbetar i NT-installationsgruppen i PSS på MS (som hanterar felsökning med blå skärm). Jag kan försäkra er om att de flesta jag pratar med inte vet vad jag ska göra med informationen på en 4,0 blå skärm. Jag är säker på att om du såg ett stopp 0xA med NAIFILTR.SYS över hela stacken du vet att uppdatera ditt antivirusprogram, men de flesta människor inte göra den anslutningen, och egentligen de inte inser att stoppkoden och params är användbara för dem. Personer som förstår hur man tolkar blåskärmsdata kommer förmodligen att bli irriterade, men tyvärr är de en minoritet.

Som jag sa i det senaste nyhetsbrevet känner jag att Microsoft bör bära NT 4.0 Blue Screen framåt, hålla den inlästa drivrutinslistan och stackdumpen. Jag tror också att de skulle kunna göra den blå skärmen bättre genom att ge mer information, inte mindre. Varför kan du till exempel inte visa namnet på den pågående processen vid tidpunkten för kraschen? Eller har fler BugCheck-anrop passerat adressen till felaren, inte bara adressen som felade? En stor anledning till att PSS stötte på så många kunder som är aningslösa om den blå skärmen är att Microsoft aldrig skrev dokumentation om hur man läser den. Åtminstone en del av skulden för användarens okunnighet vilar därför på Microsofts egna axlar.

Om du vill veta mer om hur blå skärmar inträffar och vad som finns på (NT 4.) Blå skärm, se min artikel från december 1997, "Inside the Blue Screen", från Windows NT Magazine (du kan komma till onlineversionen från http://www.sysinternals.com/publ.htm).

Som vanligt skickar du nyhetsbrevet vidare till vänner som du tror kan tycka att det är intressant.

Tack!

-Markera

NYHETER PÅ SYSTEM INTERNALS

SDELETE V1.1

I det senaste nyhetsbrevet introducerade jag SDelete, ett verktyg för säker borttagning som du kan använda för att oåterkalleligen förstöra fildata, samt för att rensa diskens lediga utrymme på tidigare borttagna data. Den första versionen av SDelete kunde inte på ett säkert sätt skriva över namnen på de filer som du tar bort med den. En fils namn avslöjar ofta känslig information, och om du använder SDelete för att ta bort en fil med ett avslöjande namn kan informationen vara tillgänglig. För att åtgärda det här kryphålet har jag uppdaterat SDelete till att inte bara skriva över fildata på ett säkert sätt, utan även filnamn. SDelete tar bort ett filnamn på ett säkert sätt genom att byta namn på filen 26 gånger och ersätta varje bokstav i filens namn med efterföljande bokstäver i alfabetet, från "A" till "Z".

Ladda ned SDelete v1.1 med fullständig källkod på http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Körbara filer och DLL:er har ofta strängar inbäddade i sig som kan visa odokumenterade registervärden och felmeddelanden som antyder odokumenterade funktioner. Tyvärr skrivs de flesta windows NT/2K-system-DLL:er och EXE:er för att använda Unicode-teckensträngar, medan traditionella strängsökningsverktyg som Grep endast extraherar ASCII-strängar. Jag skrev den första versionen av mitt Strings-verktyg för några år sedan för att skanna binära filer för ASCII- eller Unicode-teckensträngar. Jag har använt det många gånger i min forskning av NT interna för att räkna ut saker som Microsoft inte dokumenterar.

Strängar hade dock alltid en stor brist, och det var dess oförmåga att ta ett wild card-uttryck som en filspecificerare så att du kunde skanna flera filer i ett skott. Jag ville ha den här funktionen så att jag, med tanke på ett registervärdes namn till exempel, enkelt kan avgöra vilket system DLL:er som refererar till den.

Äntligen har jag uppdaterat Strängar för att ta fullständiga wild card-filnamn, samt för att recurse kataloger. Om du anger ett jokerteckenuttryck Prefixerar strängar automatiskt utdatarader med namnet på filen som en sträng finns i, så att du kan göra något liknande:

strings *.dll | grep SafeBoot

När du visar utdata för det här uttrycket (en version av Grep är tillgänglig i Windows NT Resource Kit Posix-verktygen) får du information om vilka system-DLL:er som kontrollerar SafeBoot-registernyckeln i Windows 2000. Strängar är också mycket användbara för att se vilka nya registervärden Win2K-system-DLL:er, drivrutiner och körbara filer använder. Till exempel använde jag Strängar för att jämföra registervärdena som refereras i NT 4.0 SP4 TCP/IP-stacken (tcpip.sys) med de som refereras av Windows 2000 TCPIP-stacken. Här är ungefär hälften av de värden som är nya för Win2K:s TCPIP-stack (alla som jag är assum finns under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters):

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

Jag håller inte andan i väntan på att Microsoft ska dokumentera alla stackens nya konfigurationsparametrar.

Du kan ladda ned Strängar v2.0 på http://www.sysinternals.com/misc.htm.

LOGGEDON

Har du någonsin velat veta vem som var inloggad på ett fjärranslutet NT-system? I så fall vill du ladda ned LoggedOn. LoggedOn är ett enkelt verktyg som visar vilka användare som är interaktivt inloggade på den lokala datorn eller en fjärrdator, samt vilka användare som är inloggade via resursanslutningar (t.ex. en fil- eller skrivarresurs). Här är exempel på LoggedOn-utdata:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT och Win2K tillhandahåller inte ett API som program kan använda för att avgöra vem som är inloggad på en dator, men LoggedOn avgör detta genom att titta på registernycklarna som läses in i systemets HKEY\USERS registerträd. Profiler för alla användare som är inloggade interaktivt läses in i den här nyckeln och profiler har namn som identifierar SID (säkerhets-ID) för profilens associerade användarkonto. Om du till exempel öppnar Regedit och tittar under HKEY_USERS ser du något i stil med:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

Här är endast en användare interaktivt inloggad. Du kan ange antingen den lokala administratören eller domänadministratören eftersom RID (relativt ID) är 500, vilket är RID NT-reserverna för administratörskonton.

Genom att använda API:er som gör det möjligt för ett system att titta på registret i ett annat system läser LoggedOn HKEY_USERS-nyckeln för en fjärrdator och konverterar de SID:er som hittas till kontonamn. För att avgöra vem som är inloggad via resursresursen LoggedOn använder du NET-API:et, som dokumenteras i SDK:n. Net-kommandoradsverktyget använder NET-API:et i stor utsträckning. En bieffekt av att LoggedOn kommer åt ett fjärrsystems register är att kontot du kör Loggat in alltid visas som inloggad på ett fjärrsystem via en resursresurs i LoggedOn-utdata.

Du kan ladda ned LoggedOn med fullständig källkod på http://www.sysinternals.com/misc.htm.

FILEMON V4.13

Filemon v4.13 har just släppts, en uppdatering som återspeglar ändringar i Drivrutinen för Windows NT-filer och korrigerar en bugg som jag oavsiktligt introducerade i 4.12-drivrutinen. 4.13-filterdrivrutinen har följande ändringar:

  • den använder resurssynkroniseringstypen för att skydda vissa av dess interna datastrukturer
  • den hanterar den nya Win2K IRP, IRP_MJ_PNP_POWER

Resurssynkroniseringstypen är praktiskt taget odokumenterad i både Windows NT 4.0 och Win2K Device Driver Development Kits (DDK:er). Designguiden nämner inte ens resurser, medan deras funktioner dokumenteras i referensen under avsnittet "Executive Support Routines". Resurser är en användbar mekanism för att skydda datastrukturer som kan läsas samtidigt av olika trådar, men som kräver exklusiv åtkomst av en tråd under en uppdatering. Det innebär att de är läsar-/skrivarlås som förvärvas för delad åtkomst av läsare och exklusiv åtkomst av författare. Filsystemdrivrutiner använder resurser i stor utsträckning, så jag kände att det var lämpligt att uppdatera Filemon för att använda dem när det var lämpligt.

Filemon v4.13 hanterar även den nya IRP_MJ_PNP_POWER IRP så att den är en power and plug-and-play-filterdrivrutin när den körs under Win2K. Det enda kravet för en filsystemfilterdrivrutin vid hantering av IP-adresser av den här typen är att skicka dem till filsystemenheterna som filtret är kopplat till.

Du kan ladda ned Filemon v4.13 med fullständig källkod på http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE är en mångsidig övervakning av felsökningsutdata som du kan använda för att samla in lokala eller fjärranslutna felsökningsutdata som genereras av Win32-program eller enhetsdrivrutiner i kernelläge under Win95, Win98, WinNT och Win2K. Dess användbarhet är dock begränsad i miljöer där en användare upplever en krasch med hjälp av en enhetsdrivrutin – alla felsökningsutdata som DebugView fångar innan en krasch går förlorad. Den senaste versionen av DebugView/EE åtgärdar det här problemet i Windows NT/2K. Om en användare samlar in kernellägesutdata som genereras av en enhetsdrivrutin och användaren har konfigurerat NT för att spara en kraschdump kan DebugView/EE extrahera felsökningsutdata från dumpfilen när systemet startas om. Använda DebugView/EE:s Redigering|Process Crash Dump-menyval för att genomsöka en minnesdump efter felsökningsutdata. Med den här funktionen kan användare skicka tillbaka en textfil som innehåller felsökningsutdata som din drivrutin genererade fram till tidpunkten för kraschen.

Ladda ned DebugView/EE v3.1 på http://www.sysinternals.com/debugview.htm.

"INSIDE NT NETWORKING"

Min windows NT Magazine -kolumn "NT Internals" från mars 1999 är nu online. Lär dig mer om NT:s nätverksarkitektur uppifrån och ned, inklusive vilka API:er som implementeras, hur protokollstaplar samverkar med API:er och hur maskinvaruleverantörer skriver nätverksdrivrutiner för att arbeta med protokolldrivrutiner. Ta också reda på några nya funktioner i Win2K:s nätverk, inklusive deserialiserad NDIS och uttagsautomat support.

Läs "Inside NT Networking" och andra tidigare NT Internals-kolumner online på http://www.sysinternals.com/publ.htm.

JUNI "NT INTERNALS"

Junibetalningen av min Windows NT Magazine-kolumn är "Inside EFS, Part 1". Den här artikeln beskriver arkitekturen i Microsofts EFS (Encrypting File System) och tar dig en detaljerad genomgång av de steg SOM EFS följer när en fil krypteras. EFS tillhandahåller en transparent krypteringsanläggning för Win2K NTFS-enheter och Microsoft har utvecklat den specifikt för att hantera vårt NTFSDOS-verktygs förmåga att läsa NTFS-filer utan hänsyn till deras säkerhet. Den här kolumnen kommer att vara tillgänglig online om tre månader.

För två nyhetsbrev sedan pratade jag om hur DE EFS API:er som krävs för att säkerhetskopiera och återställa krypterade filer är odokumenterade. Tyvärr är dessa API:er fortfarande inte dokumenterade i den aktuella versionen av MSDN. Jag har dock fått information om att Microsoft skickar dokumentationen, som är markerad som "Microsoft Confidential", till sina partner och till leverantörer av säkerhetskopiering av programvara. Dessutom presenterade David Golds, File Systems Program Manager på Microsoft, ett föredrag om filsystemförbättringar för Win2K vid den senaste Microsoft TechEd-konferensen i Dallas. I presentationen, de bilder som du kan visa online på http://www.teched99.com/slides/1-337.ppt, nämner han att API:erna för säkerhetskopiering är odokumenterade, men att du kan fela honom om du vill ha dokumentationen. Tyvärr är hans e-postadress inte listad på bilderna.

Besök http://www.winntmag.com för prenumerationsinformation för Windows NT Magazine.

UPPDATERINGSSTATUS FÖR NTFROB

NTFrob är ett verktyg som jag släppte för ett par år sedan som gör att du exakt kan konfigurera kvantlängderna för förgrunds- och bakgrundsprocesser på NT 4.0. NTFrob ändrar datastrukturerna internt till NT-kerneln, så det är mycket Service Pack-specifikt. Sedan lanseringen av NT 4.0 Service Pack 5 har jag översvämmats av frågor som frågar när jag ska släppa NTFrob v1.5, SP 5-uppdateringen. Svaret är att uppdateringen kommer – Jag väntar på att Microsoft ska förse MSDN-prenumeranter med SP5, inklusive felsökningsinformation. Jag behöver felsökningsinformation för att uppdatera NTFrob för nya Service Packs.

Du kan ladda ned NTFrob för NT 4 SP0-4 på http://www.sysinternals.com/ntfrob.htm.

INTE SÅ NYA SAKER

För några månader sedan släppte jag en Win9x/NT/2K seriell och parallell portövervakare på System Internals. Med Portmon kan du se exakt hur program interagerar med seriella och parallella portar, inklusive vilka data de skickar och tar emot. Du kan använda den för att titta på uppringningssessioner, laplink-serieanslutningar eller skrivaraktivitet. Portmon har varit en stor hit, och den fick nyligen 5 stjärnor från Ziff-Davis Software Library, det högsta möjliga betyget. Andra System Internals-verktyg som har tjänat 5 stjärnor är Regmon, NTFSDOS och BlueSave.

Ladda ned Portmon på http://www.sysinternals.com/portmon.htm.

INTERNALS NEWS

DRIVERSTUDIO SLÄPPT

CompuWares NuMega Labs har släppt DriverStudio, en omfattande verktygslåda för utvecklare av Windows 9x/NT/2K-enhetsdrivrutiner. Den innehåller SoftICE 4.0, BoundsChecker for Drivers, VtoolsD, DriverAgent, DriverWorks, FieldAgent for Drivers och kommer i framtiden att lägga till TrueTime för drivrutiner och TrueCoverage för drivrutiner. Som jag sa i det senaste nyhetsbrevet är detta ett måste-ha utvecklarverktyg. NuMega har också lanserat en utvecklarorienterad webbplats för enhetsdrivrutiner med namnet "Driver Central" – http://www.numega.com/drivercentral/default.asp.

JUNE PLATFORM SDK SLÄPPT

Du kan ladda ned juniversionen av Microsofts Platform SDK nu på http://www.msdn.microsoft.com/developer/sdk/platform.asp.

WIN2K SYSTEM FILE PROTECTOR (SFP)

Ett av NT-systemadministratörernas och användarnas största grepp är NT:s "DLL Hell". DLL hell är resultatet av många program som uppdaterar nyckelsystem-DLL:er med versioner som de paketar. Program gör vanligtvis detta så att de kan garantera att de fungerar korrekt, men när de ersätter en DLL bryter de många gånger andra program genom att installera inkompatibla versioner eller till och med "uppdatera" en DLL till en äldre version.

Microsoft har åtgärdat problem med DLL-versionshantering i Win2K med introduktionen av System File Protector (SFP). Egentligen kommer dess namn snart att ändras till Windows File Protector (WFP), men från och med Beta 3 (build 2031) är det fortfarande SFP. SFP implementeras i en DLL med namnet sfc.dll som Winlogon-processen (winlogon.exe) läser in när systemet startas. SFP innehåller en inbyggd lista över cirka 3 000 standard DLL:er för Win2K-system, körbara filer (.exe), installationsfiler (.inf), drivrutiner (.sys) och teckensnittsfiler (.fon) som är installerade i 30–40 olika kataloger. När SFP initierar den kör en ändrings-meddela katalogåtgärd på varje katalog som innehåller filer som den skyddar. När den identifierar manipulering av en fil visas en dialogruta som informerar den aktuella användaren, skriver en jämn till händelseloggen och ersätter den ändrade filen med en säkerhetskopia lagrad i %systemroot%\system32\dllcache. Om säkerhetskopieringsfilen som SFP söker efter i dllcache saknas eller också har manipulerats, hämtar SFP en ny kopia från Win2K-installationsmediet.

Om du vill se vilka filer som SFP skyddar kan du använda verktyget Strängar som nämns någon annanstans i det här nyhetsbrevet för att dumpa Unicode-strängnamnen inbäddade i %systemroot%\system32\sfc.dll.

De enda verktyg som kan uppdatera systemfiler är hotfix.exe, service pack (update.exe), uppgraderingsinstallationer och Win2K Update-tjänsten. Hur kringgår dessa verktyg SFP? De inaktiverar den tillfälligt genom att anropa den exporterade sfc.dll funktionen SfcTerminateWatcherThread, och de ser till att återspegla uppdateringar i underkatalogen dllcache. Observera att Win2K kräver att alla systemfiler signeras digitalt av Microsoft, så det är i allmänhet inte möjligt att uppdatera en systemfil med en egen godtycklig version.

Win32-program kan se efter ändringar i en katalog med hjälp av API:erna FindFirstChangeNotification och FindNextChangeNotification Win32. Dessa API:er informerar dock bara ett program om att något har ändrats. de berättar inte exakt för programmet vad som har ändrats. Ett program måste därför genomsöka en hel katalog för att avgöra vilka filer eller underkataloger som kan ha ändrats. SFP använder det interna NT-API:et för att utföra en begäran om ändringsmeddelanden där NT anger exakt vilka filer eller underkataloger som ändras i övervakade kataloger. Funktionen SFP använder heter NtNotifyChangeDirectoryFile, och precis som 90 % av NT:s interna API är den odokumenterad. Leta efter en applet på System Internals inom en snar framtid som visar hur du använder NtNotifyChangeDirectoryFile.

I kolumnen "NT Internals" i september, "Inside Win2K Reliability Enhancements, Part 2", beskrivs SFP mer detaljerat.

STÄNGA FILER SOM ÖPPNATS FRÅN NÄTVERKET

En av de vanligaste frågorna jag får från System Internals besökare är "hur stänger jag filer som användare har öppna från nätverket?" Om en användare har en fil eller katalog fjärröppnad går det inte att ta bort, byta namn på eller uppdatera filen eller katalogen lokalt. En liknande fråga är " Hur gör jag för att se vilka filer som användarna har öppnat från nätverket?" Båda dessa frågor besvaras med kommandoradsverktyget Net som medföljer Windows NT/2K. Om du vill se vilka filer som öppnas skriver du helt enkelt "net file". Du får en lista över öppna filnamn, motsvarande filnamnsidentifierare och namnen på de användare som har öppna filer. Om du vill stänga en av de filer som du ser öppna skriver net file <id> /closedu . Om du vill visa filerna som öppnas lokalt kan du använda mina NTHandle- eller HandleEx-verktyg.

DE API:er som ligger till grund för net-kommandots filvisning och stängningsfunktion dokumenteras i Platform SDK och i MSDN-biblioteket. Använd NetFileEnum-API:et för att räkna upp öppna filer och NetFileClose-API:et för att stänga en öppen fil. MED API:erna kan du faktiskt räkna upp de öppna filerna på fjärrservrar, något som Net-kommandot inte tillåter.

NTHandle finns på http://www.sysinternals.com/nthandle.htm. HandleEx finns på http://www.sysinternals.com/handleex.htm.

VAD KOMMER UPP

ETT "AWE"-SOME WIN2K API

Win2K introducerar ett nytt API med namnet AWE (Adressfönstertillägg) som minnesintensiva program kan använda för direkt åtkomst till och hantera stora mängder fysiskt RAM-minne – till och med mer än 3 GB, den övre gränsen för RAM-minne som ett Windows NT-program kan hantera i sitt virtuella adressutrymme. Om ett x86-system har PSE (sidstorlekstillägg) och mer än 4 GB RAM-minne kan ett program använda AWE för att dra nytta av datorns minne. Det här API:et är därför idealiskt för minneskrävande program som webbservrar och databasservrar. Nästa gång ska jag berätta hur du använder API:erna, både från Win32-program och från enhetsdrivrutiner.

Medan jag är på ämnet minneshungriga program, här är ett tips för alla som skriver ett program som cachelagrar filer (som en webbserver). Windows NT Cache Manager delar upp cacheminnet i 256 KB-platser som kallas "vyer". Om en fil som är mindre än 256 KB i storlek cachelagras måste Cachehanteraren fortfarande tilldela filen ett helt 256 KB-fack, vilket innebär att en del av cachens virtuella minne slösas bort. Därför är det vanligtvis mer prestandaeffektivt att cachelagma filer som är mindre än 256 KB i storlek i ditt eget programs virtuella minne och att förlita sig på filsystemet för att cachelagma filer som är större än 256 KB i storlek. IIS 5.0 använder det här tricket.

Tack för att du läser System Internals Newsletter.

Publicerad lördag 19 juni 1999 19:14 av ottoh

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