Archive for the ‘Vista’ Category

SQL Server 2012 újdonságok – 4. FORCESEEK, FORCESCAN hintek

Monday, May 7th, 2012

A FORCESEEK hint SQL Server 2008 óta létezik. Ezzel azt lehet súgni a query optimizernek, hogy egy lekérdezés kiértékelése során inkább használjon nonclustered index seeket, table vagy clustered index scan helyett. Ez ekkor hasznos, ha egy paraméterezett lekérdezés a tipikus paraméterekre kevés sort ad vissza, így a nonclustered index seek az optimális adatelérő stratégia, de időnként becsusszannak olyan paraméterek is, amelyek scant igényelnek, mert már nem éri meg a sok indirekt adatelérés, ami a nonclustered index seek velejárója. Ilyenkor a szerver helyesen scant választ, azaz inkább lineáris kereséssel végigmegy az egész táblán. Mivel a szerver eltárolja és újrahasznosítja a végrehajtási terveket, ha pont elsőre egy ilyen terv generálódott, akkor a további lekérdezéseket is ezzel hajtja végre. Ez azonban nem optimális sebességet ad a tipikus, pár sort visszahozó lekérdezésekre. Ezt a bizonytalanságot tudja stabilizálni a FORCESEEK hint. A hint hatására szívesebben használja a nonclustered index seeket az SQL Server. Ez rossz hatással lesz az atipikus, ritkán beeső, de sok sort visszaadó lekérdezésekre, de a tipikus, kevés sort visszaadókra stabilabb tervet és válaszidőket kapunk.
SQL Server 2012-ben a FORCESEEK újdonsága, hogy meg lehet adni egy összetett index oszlopait vagy azok egy részhalmazát, hogy pontosabban specifikáljuk, mely index oszlopokat szeretnénk, ha használná az optimizer.
Nézzünk egy példát. Van egy új akciója az internetes kutyatápboltnak, a Bodri májkonzerv, amely 2-es SpecialOfferID-val fut, és szeretnénk másodpercenként frissítve látni egy 50 colos plazma képernyőn azokat az megrendeléseket, amelyben 10-nél több dobozzal rendeltek. A lekérdezésnek nagyon hatékonynak kell lenni, de nem akarunk új indexet létrehozni a táblákon.
Adott egy ilyen index a SalesOrderDetail táblán:

CREATE NONCLUSTERED INDEX IX_Comp1
ON Sales.SalesOrderDetail (OrderQty, SpecialOfferID, UnitPrice);

A lekérdezés így néz ki:

select * from [Sales].[SalesOrderDetail]
where OrderQty = 10 and SpecialOfferID = 2;

Az SQL Server által választott végrehajtási terv NEM használja a fenti indexet, Clustered Index Scant használ:

A lekérdezés becsült költsége 1.18mp, és 1240 logikai IO művelettel, 8 kByte-os lap olvasásával oldotta meg a szerver (végignézte a teljes táblát).
A FORCESEEK eddig is ismert alakjával rávehetjük az indexünk használatára:

select * from [Sales].[SalesOrderDetail]
with(forceseek)
where OrderQty = 10 and SpecialOfferID = 2;

A Properties ablakban megnézve azonban látszik, hogy az Index Seek műveletben csak az OrderQty oszlopra használta ki az indexet, pedig a lekérdezésben benne van egy másik szűrt oszlop is:

Seek Keys[1]: Prefix: [AdventureWorks2012].[Sales].[SalesOrderDetail].OrderQty = Scalar Operator((10))

Ennek becsült költsége 1.91mp, azaz a FORCESEEK hinttel csak rontottunk a dolgon, az IO is felment 2365-re. Ennek oka, hogy mivel csak az OrderQty-re szűrt az indexben, a szűrés után még elő kell venni az adatsorokat (Key Lookup, 768 sor), és azokat tovább szűrni a SpecialOfferID = 2 feltételre (Filter operátor).

Az SQL Server 2012-ben kibővített FORCESEEK-kel (amúgy 2008R2 SP1-ben is benne van) meg lehet mondani a szervernek, hogy márpedig próbálja meg használni az indexet mindkét oszlop szűrésére:

select * from [Sales].[SalesOrderDetail]
with(forceseek (IX_Comp1 (OrderQty, SpecialOfferID)))
where OrderQty = 10 and SpecialOfferID = 2;

A végrehajtási tervből eltűnt a Filter, ami jó jel, az Index Seek szűrése pedig magában foglalja mindkét oszlopot:

Seek Keys[1]: Prefix: [AdventureWorks2012].[Sales].[SalesOrderDetail].OrderQty, [AdventureWorks2012].[Sales].[SalesOrderDetail].SpecialOfferID = Scalar Operator((10)), Scalar Operator((2))

Az így kapott lekérdezés becsült költsége továbbra is 1.91mp, azonban az IO leesett 4-re! Az eredeti 1240 helyett 4 lett az IO, azaz több mint 300-ad részére csökkent!
A végső verdiktet az mondja ki, hogy ha megmérjük a tényleges végrehajtási időket. 10000 végrehajtás alapján az első, hint nélküli lekérdezés ideje 238mp, az egyszerű hinttel 38mp, az új hinttel 2mp.
120-szoros gyorsulást értünk el az új hint formátummal!

A FORCESCAN teljesen új hint, ezzel scanre vehetjük rá a szervert akkor is, ha seekelne magától. Ennek haszna akkor van, ha tudjuk, hogy a lekérdezés sok sor érint, ezért a seek nem lenne optimális, így mindenképpen scant akarunk. időnként miért választ az SQL Server mégis seeket? Vagy, mert nem frissek a statisztikái, ezért kevés sort vár el, vagy, mert valami oknál fogva nem tudja jól megbecsülni a várható sorok számát. Főleg join-os lekérdezéseknél nehéz a dolga, mert az oszlopszintű eloszlási statisztikáit ilyenkor nem lehet pontosan használni.
Az ilyen eseteket könnyű megismerni, mert ilyenkor Index Seek-et használó Nested Loop Joinokat hajt végre a szerver sok ezer vagy millió soron, Hash Join helyett. Ezekben az esetekben a FORCESCAN hinttel rá lehet venni, hogy inkább ne használjon indexet, ne szaladjon neki sokszor a táblának, hanem inkább egyszer menjen végig az egész táblán, mert a még mindig kisebb költségű.
Nem csak joinos lekérdezéseknél, hanem sima szűréseknél is előfordulhat, hogy rosszul becsüli meg a szerver a feldolgozandó sorok számát, így seekel scan helyett, akkor stabilizálhatjuk a tervet, hogy mindig scant használjon a FORCESCAN hinttel.
Összegezve, ha tudjuk, hogy a seek vagy a scan előnyös a lekérdezésünknek, akkor határozottá tehetjük a várakozásunkat a szerver felé, ezáltal kiszámíthatóbb tervet, így kiszámíthatóbb válaszidőket kapunk.

Update a cikkhez: amikor a fenti demót írtam, akkor még csak RC1 volt. Miután upgradeltem az RTM-re, hirtelen magától is tudta a jó tervet, nem kellett hint. Vagy okosodott, vagy csak nem voltak frissek a statisztikák, amikor a demót írtam. Az elv mindenesetre látszik a cikkből, és örülünk, ha a szerver okos. :)

Windows memóriakezelés – 4. rész – Page File és Working Set

Tuesday, June 9th, 2009

Megjelent ez a rész is, a sorozat talán legfontosabb része. A Page file és a Working Set viselt dolgai.

Deadlock detektálás Vistán

Wednesday, October 22nd, 2008

A cégnek egy hookolós kódot próbálok 64 bitre kibővíteni, de állandóan befagyott tőle a gép, csak a restart segített rajta. Meglehetősen frusztráló. Nagyon. :)
Nyilvánvalóan deadlock gond volt, de mégis, ki-kivel és min akadt össze?
Mivel hookolós a kód, még debugolni se lehet, és még az OutputDebugString is okozhat deadlockot, így még azzal se lehet tracelni. Eléggé fekete doboz így a rendszer.
A megoldást az adta, hogy a Fast User Switching segítségével beléptem egy másik felhasználó nevében, és lefutattam a LockWatchert.
Mivel a programban a várakozások WaitForMultipleObjects-en történtek nem írta ki, hogy deadlock van (írja is a cikk, hogy így viselkedik), de szemre szépen látszik így is az összeakadás.
Jó eszköz, szeretjük. Kár, hogy csak Vistán van hozzá API támogatás. Ebből is látszik egyébként, hogy a Vista nem csak az új shellről szól, mint sokan hiszik, hanem sok belső újítás is van benne.

The requested operation could not be completed due to a file system limitation

Wednesday, August 13th, 2008

Ez egy érdekes hibaüzenet, amit NTFS fájlok írásakor kaphat néha az ember. A GetLastError ilyenkor a 665-ös hibát adja vissza.
SQL Servernél a snapshotok írásakor jöhet ez elő, otthoni felhasználásnál nagyobb fájlok torrentes letöltése esetén, amikor a torrent kliens mint pl. a uTorrent úgy van beállítva, hogy használja az NTFS sparse file funkcióját. Ha egy sparse fájlt nagyon sok kicsi darabban raknak össze, akkor állhat elő ez a hiba, nem lehet folytatni a fájlt.
Aszongya a tudomány:
” When a sparse file (used for snapshot database files) is populated Windows limits the amount of data that may reside in the file. Once the amount of data stored in the sparse file exceeds the limit further data storage in the file may be prevented.

· Windows 2003 – 64GB (Error 1450 returned)
· Windows 2008 and Vista – 16GB (Error 665 returned)

Forrás.
Ilyenkor én az xcopy /Z forrás cél módszert használom, így a másolás leáll ugyan egy idő után hibával, de a fájl jelentős részét (általában az egészet) sikerül visszanyerni. Aztán a torrent kliens majd befoltozza a lukakat. Így sosincs gondom nagyobb SDK vagy egyéb hasznosság torrentes letöltésekor.

Vista aktiválás furcsaság

Tuesday, August 12th, 2008

Van egy kis virtuális masinám, amiben Windows 2008 fut, ezt debugolom éjszakánként kernel módban.
Eljött az ideje, hogy aktiváljam, de az aktiválás azt mondta:
Activation Error – 0x8007232B, DNS name does not exist
Azanyád, rossz a net config? Nem, mert simán lehet böngészni a gépben. Google, kiderül, hogy ha rossz a product key, akkor is ilyet mond az aktiválás. Nem tudom, de szerintem ez van olyan kényes kérdés, amit illett volna jobba kidolgozni az MSnek.

Windows Internals vizsga – tapasztalatok

Tuesday, August 5th, 2008

Voltam, láttam, visszamennék :) Ahogy várható volt ez nem az a vizsga, amit 2 nap tanulással le lehet tenni. A Windows Internals könyvből 3 fejezetet tudtam megemészteni ennyi idő alatt, így az azokkal kapcsolatos kérdésekre tudtam is kb. a válaszokat. Ha valaki elolvassa, megérti és kipróbálja a gyakorlatokat a könyvből, akkor szerintem a kérdések kb. 70%-ára tudni fogja a választ.
A maradék 30-hoz általános API programolási ismeretek, windbg igen alapos ismerete és a device driver programozás egyes részletei szükségesek. Emellett tudni kell kékhalált analizálni, érteni az IO műveleteket kernel módban, IRQ-kkal kapcsolatos debugolásokat, dumpokat elemezni, verifierrel vegzáni drivereket, paged, nonpaged, stb. memóriákat elemezni, heap corruption-öket debugolni, lefagyott vagy lerohadt user módú appokat debugolni, kernelből visszahívni user módba, szervizeket piszkálni, leak-eket analizálni, különböző utilokat ismerni (umdh, procexp, tlist, kernrate, sc, gflags, stb.), 64 biten 32 bites cuccok futtatása, UAC jobbra-balra, DEP, memory mapped files, IO completion portok, named pipe-ok, file-ok kezelése szinkron és aszinkron módon, Credential api, perfmon, pool tagging, kernel profilozás, power események kezelése device driverből, kernel struktúrák debugolása, azokból infók kibányászása (nt!_KWAIT_BLOCK, _DISPATCHER_HEADER, stb.), P&P eszközök debugolása, user és kernel módú szinkronizálás, aszinkron IO programozása driverben, kernel szálak kezelése, IRQL szintek és azok jellemzői, Deferred Procedure Call programozása, DMA kezelés, védett módba lépés különböző processzorokon, kézzel lekreseltetni a lefagyott oprendszert (dump céljából), checked buildű kernel hozzáadása éles géphez, filter driverek problémái, stb, stb. Most több nem jut az eszembe. Kb. 3/4 rész kernel, és 1/4 rész user mód volt benne. A kérdések legalább a fele a WinDbgről szól. Ezzel nem is lett volna baj, ő az új szerelmem már pár hónapja (sokkal többet tud, mint a vs debuggere), de én eddig user módban debugoltam. Igaz, hétvégén összehoztam egy kernel debug sessiont a 64 bites gépen, orgazmushoz közeli érzés CTRL-Break-kel megállítani az oprendszert, és beleesni a kernel debuggerbe. Majd ha e helyett már unalmat érzek, akkor érdemes elmenni erre a vizsgára (ez kicsit kétértelmű lett. :).
Szóval korrekt, de nehéz kérdések voltak.

Feltett szándékom, hogy azért is megértem mi történik a Windowsban, és megcsinálom a vizsgát, majd később, pénzért (ez most ingyenes beta volt). Ami nekem még előnyöm a MVP-ként a Windows forráskód hozzáférés, majd ha a kernelt tudom forrásszinten debugolni, az is egy újabb hőhullámot fog kiváltani. :) User mód már megvolt, az is egy élmény forrásszinten.

A tanuláshoz a következő könyveket és forrásokat szándékozok bevetni:

Első körben ennyi. Már csak pár évnyi éjszaka kell, és túl is vagyok rajtuk. :)

Az IIS7 secu mágia titka: Service SID

Monday, August 4th, 2008

Az IIS7-ben megoldották, hogy hiába egy account alatt fut sok worker processz, akkor SEM tudják egymás védett fájljait olvasni. Így el lehet szigetelni a webappokat annak ELLENÉRE, hogy egy account alatt futnak (még ha nem is a javasolt konfig hosztereknek). De hogy a csudába? Eddig nem tudtam, de most megtaláltam a választ: Service SID.

“Service SIDs protect access to resources owned by a particular service, but by default services still have access to all the objects that the user account in which they run can access. For example, a service running in the Local Service account might not be able to access resources created by another service running as Local Service in a different process that has protected its objects with permissions referencing a service SID, however, it can still read and write any objects to which Local Service (and any groups to which Local Service belongs, like the Service group) has permissions.

Windows Vista therefore introduces a new restricted service type called a write-restricted service that permits a service write access only to objects accessible to its service SID, the Everyone group, and the SID assigned to the logon session. To accomplish this, it uses restricted SIDs, a SID type introduced back in Windows 2000. When the process opening an object is a write-restricted service, the access-check algorithm changes so that a SID that has not been assigned to a process in both restricted and unrestricted forms cannot be used to grant the process write access to an object. ”

Már csak az nem vili, hogy ezt hogyan használják fel az IIS wp-ek esetén, azok ugyanis nem szervizek. Ha egyszer megtalálom a választ, leírom.

ReadyBoost sikerek Vistán?

Monday, August 4th, 2008

Van valakinek jó tapasztalata ezzel az újítással? Ez az, ami USB-s memóriaeszközt használ memóriapótlásra. Nekem még nem volt kulcsom, ami elég gyors lett volna neki.
Gyorsított ez már valakinek? Most, hogy a gépembe nem lehet 2G-nál több RAM-ot rakni és folyton kevés a RAM, elgondolkodtam rajta.

A Windows Integrity Control hétköznapi hatása

Friday, August 1st, 2008

A Windows Integrity Control (WIC) régebbi nevén Mandatory Integrity Control (MIC) az a mechanizmus a Vistában és a Windows 2008-ban, amely miatt egy alacsonyabb szinte besorolt processz nem tud Windows üzeneteket küldeni egy magasabb szinten futó processznek. A klasszikus probléma ami miatt ezt bevezették az interaktív szervizek hekkelése volt. Ha egy System account alatt futó szerviznek van Interact with the Desktop beállítása, akkor ki tud rakni ablakot az interaktívan bejelentkezett felhasználó asztalára. Ez látszólag ártatlan dolog. Azonban a magas jogosultságokkal futó szerviz GUI-nak tudunk mi, kis privilégiumú felhasználók üzeneteket küldeni. Ez azt jelenti, hogy ha pl. a textboxok tartalmát a szerviz nem ellenőrzi jól, egy jól irányzott hosszú szöveggel buffer overrunt okozhatunk a szervizben, megfelelő ügyességgel a szövegben elrejtett bináris kódot végrehajtatva vele. Ez az alapprobléma, ezzel nem lehet mit kezdeni Vista előtt, együtt kell élni vele. Gáz, de ez van. Sokszor mondták, ne írjunk ilyen szervizt, de egyszerűbb volt ezt csinálni, mint külön írni egy szervizt és egy sima userként futó klienst, ami mondjuk named pipe-on vagy egyéb IPC-n keresztül kommunikál egymással, biztonságosan.
Vistában egy szerviz magas integritási szinten fut, míg egy nemadmin felhasználó (aki lehet, hogy admin, de az UAC miatt nem admin, mint én is) az közepesen. (Érdekességképpen, egy protected módban futó IE7 esetén az általa elindított folyamtok alacsony szinten futnak.)
A WIC miatt egy közepes folyamat (sima user, sima app) nem tud üzenetet küldeni egy magas szinten futó folyamatnak (szerviz), így az előbbi hekkelési probléma megoldott.
No, aminek apropóján írom ezt, az a következő. A céges VPN-t egy Citrix Firebox SSL programmal érjük el. Ezt adminként kell futtatni, hogy meg tudja változtatni a hálózati beállításokat. Adminként így ő magas integritási szinten fut. Hogy a jelszót ne kelljen begépelnem előszeretettel használom a KeePass automatikus gépelő szolgáltatását, így CTRL-ALT-A-ra az ablak címe alapján benyom olyan billentyűkombinációt a célablakba, amit megálmodtunk. Ez viszont természetesen nem megy az előbbi helyzetben, mert a KeePass nemadminként, így közepes integritású szinten fut. Az integritási szinteket a process explorer mutatja meg, egy processznél a security fülön.
Ellenpróbaként adminként futtattam KeePasst, így egyből gépelt.
Ugyanez a probléma jött elő, csak rejtettebb módon, amikor proteced módban futó IE alatt fejlesztett AddInból adtam ki OutputDebugString hívást (ezt hívja meg a DefaultTraceListener is .NET-ben). A DebugView elvileg az ilyen hívások kimenetét adja vissza, de nem jött meg bele semmilyen üzenet. Utánanéztem, ilyenkor is üzenetek formájában mennek át a szövegek, ergo megint a WIC köpött a levesbe. A megoldás az volt, hogy alacsony integritási szinten kellett futtatni a DebugView-t. Erre írtam egy kis programocskát (ez alapján), ami egy processzt egy adott integritási szinten indít el. A PsExectől várnék el valami ilyesmit. Ha valaki tud ilyen kész utilt, akkor kérem jelezze.

Update: megválaszolom magamnak, a psexec -l Low Integrity-vel indít el egy processzt. :)

Vista memóriakezelési furcsaság

Monday, July 28th, 2008

Időnként annyira belassul a Vista alatt a munka, hogy néha már veszélyben volt a laptop fizikai léte. :)
2G RAM, DCE kikapcsolva, semmi üveges tekintetű ablak. Amikor ennyire lassú a gép, akkor a következő kép látszik a Task Managerben:

A Task Manager híres arról, hogy a benne látható memóriaértékeket fenntartásokkal kell kezelni, de az ábra alapján azt gondolnám feleslegesen 1 G RAM-ot elrabol cache céljára, cserébe a gép majd szétesik a page-eléstől, mert a 1G-ba tényleg nem fér bele minden futtatott app. Félreérthető a TM által mutatott érték, vagy túlzabálja magát a Vista cache? A Superfetch már ki van kapcsolva, és az indexer is, ezekről írják, hogy szeretik unalmukban szétenni a vinyót.

Update: némi magyarázat. Nem zabája a RAM-ot, hanem használja, cache céljára (hasonlóan, mint a SQL Server). Akkor viszont azért lassú a gép, mert több mint 2 G ramot esznek együtt az appok, így page-elni kell. Erről még nem vagyok meggyőződve, de ebből ez következik.

Update2: semmi furcsaság nincs a dologban, én voltam a tudatlan.
Inside the Windows Vista Kernel: Part 2

Vista folder virtualizáció takarítás – szabad ilyet?

Wednesday, July 23rd, 2008

Nem tudom, mennyire ismert az a tény, hogy az Vista UAC bekapcsolt állapota mellett ha egy butus program egyes védett területekre, úgymint winroot, program files vagy program data akar írni, akkor az írási kérelmet átirányítják a virtualizált megfelelőikbe, amelyek nálam itt laknak:

C:\Users\zsolt.soczo\AppData\Local\VirtualStore\

Eme kedves könyvtár mérete nálam 10 GB. Kicsit szétnézve benne azt találtam, hogy jó sok fájl benne teljesen azonos az eredetivel, azaz teljesen felesleges, hogy a virtualstore-ban fogja a helyet.
Szisztematikusan meg kellene keresni, és kitörölni ezeket.
Nosza, mivel 5 perc guglizással nem találtam erre specializálódott programot, írtam egyet.
Összeveti az eredeti és a virtualizált verziót, és ha kérjük, kitörli a duplikált virtualizáltakat.
Mielőtt kipublikálnám a kódot, és megölnétek, hogy szétcsaptam a gépeteket vele megkérdem: stimmel az elmélet? A tartalomra azonos, de dátumra nem feltétlen azonos duplikált fájlokat a virtual store és az eredeti hely között a virtual store-ból ki lehet törölni büntetlenül?

Hmm?

Update: bátor vagy botor módon takarítottam, nem állt meg tőle az élet, de látom szépen, sorban pakolnak vissza mindent a programok. Szélmalomharc.

Élet 64 biten

Thursday, May 29th, 2008

Látom Józsi is kóstolgatja a 64 bitet, több-kevesebb sikerrel.
Nekem a cégnél most az egyik feladatom az, hogy a natív, low-level Hook-os és COM-os C++ cuccokat nézzem meg, hogyan fognak majd működni 64 biten.
Kaptam egy DELL 3400-ast, 2 procival, 4 G RAM-mal, 2 HDD-vel, amik RAID1-be RAID0-ba vannak kötve az alaplapi vezérlő segítségével.
Vista és VS 2008 van rajta. Először is, a Vista olyan simán felment rá, hogy csuhaj. De tényleg, mire a gyerekek lefürödtek, már fenn is volt. K. semmi bajom nem volt vele, csodálkoztam is, mert sokaknak gondjuk van a driverekkel. Ebből a szempontból hálás a neves gép. Meg csendes is, féltem, hogy lesz egy hangos desktop gépem, de nagyon csendes.
Ami a legélvezetesebb a vele való munkában, az a C++ fordítás. Közismert, hogy ez piszok lassú dolog. De nem ezen a gépen! Eszméletlen gyorsan hasít, gondolom a RAID1 is sokat dob ezen. Élvezet így fordítani és dolgozni rajta.
Menet közben, ha találok érdekes dolgokat majd leírom.

Vége a terminátor kliens /console kapcsolójának

Thursday, April 10th, 2008

Van helyette /admin. Itt leírják, miért?

Vista restore – szeretem

Thursday, April 3rd, 2008

Tegnap szétesett a laptopban a vinyó. Szerencsére volt mentésem, jó, kb. egy hónapos, de volt. Complete backup volt, Vistából indítva egy külső vinyóra, közben nyugodtan dolgoztam, nem zavarta.

Ma a szervizes emberke kihozta az új vinyót, még írta a papírokat már futott is a restore. Nem kérdezett feleslegeseket, egyszerűen csak tette azt, amire terveztetett. Most már a visszaállított oprendszerről írok. Elégedett vagyok, na.

Ami viszont fura, hogy újra kellett aktiválni a Vistát, mert azt mondja már 3 dolog megváltozott a vasban. Az tény, hogy a tápot is kicserélték hétfőn, de azzal együtt is ez csak 2 változtatás (meg persze nem veszi figyelembe a tápot :). Külső hddk, DVD író gondolom nem ér. De akkor mi az anyja kínjáért akart aktiválni?

MSDeployhoz Vista SP1 kell

Tuesday, February 19th, 2008

Mert őkelmét Windows 2008-on tesztelték, ami meg azonos modulokat tartalmaz, mint a Vista SP1. Van motivációm, hogy felrakjam az SP1-et.

Script Elevation PowerToys for Windows Vista

Monday, February 18th, 2008

Hogy én ezt eddig nem láttam. Pedig jó az UAC ellen. :)

Miért nem látja a Windowsom mind a 4 Giga memóriát?

Monday, December 17th, 2007

Ezért.

Vista WIC piszkálgatása

Monday, October 29th, 2007

Aki nem tudja mi ez, itt nézhet utána.

Nézegetni a perzisztált IC-t:
accesschk.exe -v c:\Users\zsolt.soczo\AppData

c:\Users\zsolt.soczo\AppData\Local
Medium Mandatory Level (Default) [No-Write-Up]
c:\Users\zsolt.soczo\AppData\LocalLow
Low Mandatory Level [No-Write-Up]

Látható, hogy a AppData\LocalLow-hoz van joga a Low integrity levelű folyamatoknak is, így az IE protected mode-jában futó Addineknek is.

Registryre egy példa:

accesschk.exe -vk “HKEY_CURRENT_USER\Software\
Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\S-1-5-21-1912844993-3
366795750-3477756003-1000\Software”

HKCU\Software\Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\S-1-5-2
1-1912844993-3366795750-3477756003-1000\Software
Low Mandatory Level [No-Write-Up]

A WIC jogokat fájlrendszerben állítani a icacls képes.
Ennek hibáit küszöböli ki a chml.
Processzek WIC-ét a Process Explorer mutatja meg.
Registry WIC állító warét még nem láttam, ha valaki tud ilyet, please. Addig is, programból állítom.

Regionális jellemzők konfigurálása parancssorból

Tuesday, August 14th, 2007

Vistában már lehetséges, egyes programok tesztelésénél jól jöhet.

Receive Window Auto-Tuning Vistában

Friday, July 6th, 2007

Eddig csak hallottam róla, itt meg is értettem, hogy működik. Nem hosszú, érdemes elolvasni.