Tag: windows

Az utóbbi időben a processzorok órajele mellett azok energia gazdálkodási funkcióit is jelentősen fejlesztették, ami elég hasznos egy laptop esetén, és nem mindig hasznos pl. valós idejű használat során egy asztali gépben.

Akit nem érdekel a fogyasztás, ellenben konstans performanciát szeretne elérni, érdemes lehet módosítani az alapértelmezett energiagazdálkodási beállításokat (power options).

Ehhez egy jó kiindulási alapot nyújthat az alábbi cikk:

http://www.dozty.com/how-to-unlock-the-hidden-features-of-processor-power-management/

Az újabb Windows verziók kapcsán – kivéve Windows 10 – a Microsoft kiemelt figyelmet fordított az operációs rendszer teljesítménye. Az ez irányú törekvések emlékét őrzik az egyre jobb performancia elemző eszközök, mint pl. a Task Manager (és az onnan elérhető Resource Monitor). Bár ezek továbbra sem váltják ki a jó öreg Process Explorer, Process Monitor-t, de az esetek egy részében a problémák már detektálhatók natív windows-os eszközökkel (is).

A szuper optimalizált windows-om a napokban ismét lehetőséget biztosított, hogy foglalkozzak vele kicsit, mert login előtt megállt, és várt vagy 20 másodpercet, ezután dobott a login képernyőre. Mivel itt még boot fázisról beszélünk, sajnos a fenti eszközök egyike sem használható. Első körben megnéztem az event log-ot, hátha találok benne valami érdekeset (ahogy a mondás tartja, aki keres az talál), de ennek a várakozáshoz sajnos nem volt köze.

Egyéb okokból már telepítve volt a gépen a Windows Assessment and Deployment Kit (Windows ADK) Windows Performance Analyzer komponense, ami lehetőséget biztosít trace-k készítésére, azok elemzésére, akár boot idő alatt is.

A használatához rá kell venni a windows-t, hogy trace fájlt generáljon, melyből majd kideríthetjük, hogy mi is történik a vizsgált időszakban. Régen ehhez pár száz karakterből álló parancssort kellett készíteni (xbootmgr…), de a Microsoftnál is sejthették, hogy ez ebben a formában nem valami jó, és egy szorgalmas fejlesztőnek hála ma már ezt konfigurálhatjuk grafikus felületen is (na jó a felület képességeit nem vitték túlzásba, de hát ki a kicsit nem becsüli…).

wprui.exe

Az ily módon megkeletkezett fájlt (pl.: boot_1.etl) a Windows Performance Analyzer-rel tudjuk alaposabban megvizsgálni. Mivel az én problémám a boot alatt jelentkezett, de még login előtt, az első nézet amit bekapcsoltam a Boot Phases volt. Itt már látszott, hogy a bejelentkezés előtt a Winlogon init 31 másodpercig tartott, ami gombócból is sok, nem hogy boot időből…

A fenti nézethez hozzádobtam még a Processes nézetet, hogy látszódjon milyen alkalmazások indultak el ezen idő alatt.

A processeket vizsgálgatva feltűnt egy alkalmazás ami a login inittel indult, és 29.9 másodpercig futott… Ez az alkalmazás pedig nem volt más, mint az OriginWebHelperService.exe…

Ezután eszembe jutott, hogy nemrég elindítottam az Origin-t, és frissítette magát… A process egyébként service-ként települt, a frissítés rakta fel/kapcsolta be, ott kellett kikapcsolni, és a probléma megszűnt… Ezúton is köszönöm az EA-nak a fejtörőt, szórakoztatóbb volt, mint a legtöbb mostani játékuk 😉

Réges rég elkövettem azt a hibát,  hogy windows alapú gépen kezdtem el zenélni. Aztán hozzászoktam, megszerettem, és bár azóta volt szerencsém más operációs rendszereket is kipróbálni, a végén mindig visszatértem hozzá. A számítógépen történő zenélés nagyon furcsa dolog, ha menet közben bármi megakad, akkor lehet újracsinálni a munka egy részét, és vannak olyan pillanatok, amiket később már nem lehet, vagy nagyon nehéz újracsinálni, tehát ehhez egy elég stabil rendszer kell. Sokan ezen a ponton alapból lemondanak a windows-ról, pedig kitartó munkával (és nem kevés utánajárással) meglepő eredményeket lehet elérni, hozzáállás kérdése az egész. Míg egy debiant szépen lassan épít fel az ember, a windowsnál épp az ellenkezőjét kell csinálni, szépen lassan lebontani a rétegeket.

tl;dr: Az optimalizált windows olyan mint egy jó versenyautó: Gyors, de egyáltalán nem kényelmes. Átlag felhasználóként a driverek frissítése az egyetlen szükséges lépés, a többi beállítás inkább problémát fog okozni, és érezhető előnyt nem jelent.

Mi is az optimalizálás célja: az alkalmazásunk működése és a hw komponensek között a lehető legkisebb késleltetés történjen, és ebbe az operációs rendszer lehetőleg ne keverjen bele.

Hardware:

• lehetőleg dedikált hangkártyát használjunk (pci / firewire)
• az usb eszközök számát minimalizáljuk (ps/2 billentyűzet)
• usb hub-ot semmiképp se használjunk

BIOS:

• kapcsoljuk ki a hyper threadingot
• mindenféle virtualizáció támogatást
• HPET-et
• Integrált videó és hangkártyát

Driverek:

Ha ezzel megvagyunk, akkor állhatunk neki a windows-nak. Alapesetben én azt javaslom, hogy mindenből a legfrissebb drivert rakjuk fel, de a driver-ek minőségének megállapítása során csak a folyamatos mérések nyújthatnak támpontot. A driverek frissítésére kiválló a Snappy Driver Installer, a driverek minőségének ellenőrzésére a LatencyMon alkalmazást tudjuk használni.

Windows komponensek:

Ezek után el kell távolítani a windows összes olyan összetevőjét, amit valószínűleg sosem fogunk használni:

– Internet Exploder
– Windows Location Provider
– Work folders client
– XPS services
– XPS viewer

Én a print services-t is levettem, nem szándékozok papírra nyomtatni a közeljövőben.

Windows:

A főbb alapvetéseket a Focusrite elég jól összefoglalta, érdemes követni a leírásukat. A lényeg kivonatolva:

• Power management -> high performance, cpu minimum és maximuma is 100% legyen
• Rendszerhangok kikapcsolása
• Processzor prioritás: Background services
• Tűzfal, vírusírtó kikapcsolás
• Vizuális effektek

És egy dolog, amit itt nem írnak: fix (min  == max) méretű swap file használata.

Hálózat:

Ha ez megvan, akkor kikapcsolhatjuk az összes olyan dolgot, amire nincs szükségünk a hálózaton (és lássuk be elég kevés dologra van szükségünk valójában):

Az IPV6 kikapcsolásához már a registry-t kell átírnunk: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

new DWORD (32-bit) Value ->  DisabledComponents = 0xff

(forrás)

Amennyiben a hálózat késleltetése számít nekünk, akkor a szükséges optimalizációkat elvégezhetjük a TCPOptimizer nevű alkalmazással, de ez inkább streaming, és játékok esetén lehet hasznos.

Szolgáltatások:

Ezek után már csak azt kell elérnünk, hogy csak azok a programok fussanak, amire tényleg szükségünk van. Mivel a windows a legtöbb komponensét szolgáltatásokon keresztül indítja, itt is kell leállítanunk őket. Ezt a services.msc futtatásával tehetjük meg.

Bizonyos szolgáltatásokat viszont nem nagyon tudunk leállítani (mint pl. a Task Scheduler) mert a windows ezt nem engedi. Ezeket a registry segítségével tudjuk kikapcsolni.

A szolgáltatások kulcsait itt találjuk: HKLM\SYSTEM\CurrentControlSet\Services

A szolgáltatások rövid névvel kerülnek ide elmentésre, de azokat láthatjuk a service listában is, az adott szolgáltatás Properties oldalán (pl. a Task Scheduler neve Schedule)

Az indítás módát a Start tartalmazza, a 4 érték jelenti a Disabled beállítást. (forrás)

A szükséges szolgáltatások:

A többi dolog nem szükséges.

A TCP/IP NetBIOS helper szolgáltatás a SAMBA megosztások eléréséhez szükséges.

Amennyiben fájlokat szeretnénk megosztani, el kell indítani a Server szolgáltatást.

Amennyiben a Windows Update-t szeretnénk használni, akkor előtte el kell indítani az alábbi szolgáltatásokat:

• Network List Service
• Network Location Awareness
• Background Intelligent Transfer Service
• Windows update

Figyelem:

• a BITS az operációs rendszer más dolgaihoz is kellhet (pl. nyelvek telepítése, DISM és SFC javításokhoz), csak akkor állítsuk le, ha ezek már mind rendben vannak.
• a Task Scheduler leállítása után nekünk kell futtatni azokat a dolgokat, amik az operációs rendszer hatékony működését biztosítják, és a Task Scheduler időzítve futtatta őket (pl. a WinSxS könyvtár takarítását).

Alkalmazások:

Bár a fentiek után ezt külön kiemelni nem is érdemes, fontos, hogy a gépen csak az az alkalmazás fusson, amit használni akarunk, ezért a Task Manager Startup szekciójából mindent állítsunk disabled-re. Ez nem csak a rendszer teljesítményére lesz jó hatással, hanem a boot time-ra is (nálam jelenleg 5 másodperc alatti). Amire még szükségünk lehet az a ctfmon alkalmazás (C:\Windows\System32\ctfmon.exe) ami a tray-en a billentyűzet nyelvének állítását teszi lehetővé. De lehetőleg ezt is csak akkor indítsuk el, ha szükségünk van a magyar billentyűzetre, és utána zárjuk is be szépen.

A fentiek után már kész is a szuper munkára fogható windows-unk, ami valahogy így fog kinézni:

Több mint 10 éve linux alapokon működött a szerverem. Akkor azért váltottam Windowsról, mert feltörték a rajta futó IIS szervert egy expolit-on keresztül (szégyen gyalázat), és úgy döntöttem, többet ilyen nem lesz. Az utóbbi pár évben, viszont semmi sem történt… Rájöttem, hogy már nem szórakoztat az ubuntu, minden működik, már a dist upgradek sem a régiek, hogy utána összeomlana a rendszer és újra össze kell rakni darabokból… Szóval egy hirtelen ötlettől vezérelve, arra gondoltam, hogy megpróbálom ugyanezt Microsoft alapon is, mert miért is ne.

A Microsoft azért nem aprózza el ezt a bemutatkozás, és felhasználói élmény dolgot, az első pár nap alatt feltépődtek a régi sebek, jöttek újak, annak ellenére, hogy a Windows 3.1 óta midnig Windowst használtam desktopra…

A szerverem az Raspberry térhódításával majdhogynem csak egy NAS-ra degradálódott, pár extra funkcióval. Gondoltam első körben megosztok pár dolgot, elvégre mégiscsak az Ms találta ki az smb protokollt. Na de az összes meghajtót ami a gépben van, azt viszont nagyon nem terveztem megosztani.  Ez volt az első dolog (a windows 10 update dialógus ablak után) ahol gyökeresen eltért a véleményünk a dolgok menetével kapcsolatban… A Windows szerint nincs is annál jobb dolog, mint az administrative shares (nem tudom ki találta ki, és az IT security hogy hagyhatta ezt produkcióba kerülni, és azóta is miért létezik ez még egyáltalán, de legalább a net send-et kivették… az is valami 🙂

Aki ki szeretné kapcsolni ezen remek funkciót a gépén nem kell mást tennie, mint létrehozni egy AutoShareWKS nevű DWORD(32) kulcsot az alábbi helyre:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Paramerts

Igen, még létre sincs hozva 1 értékkel, hogy csak át kelljen írni, és ezen infók fórumok útján terjednek…  Vannak dolgok, amik nem változnak, ekkor már éreztem, hogy megérkeztem 🙂

És természetesen a network credential-os bug-ot sem sikerült javítani az elmúlt ~20 év alatt. Pedig nem bonyolult reprodukálni. Fogunk egy szervert, ahol pár megosztás bárki számára lekérdezhető. Aztán belerakunk pár olyan megosztást, ami csak adott felhasználók számára elérhetőek. Amikor a windows authentikál először megpróbálja kérdés nélkül a bejelentkezett felhasználó adataival (Ez egyébként megint egy érdekes kérdés, miért történik így. Vajon csak nekem jutott eszembe, hogy egy speciális megosztással, és egy megfelelő rainbow táblával viszonylag egyszerűen megtudható az adott felhasználó jelszava?). Ha a windows egyszer sikeresen azonosította magát egy szerveren, akkor a felhasználó hiába ír be jó azonosító adatokat az idők végtelenségéig a privilegizált megosztáshoz, csak a lenti dialógusablakot fogja látni:

Ilyenkor mindenki elkezdi keresni a szerveren a problémát, hiszen Access is denied, mi más lehet a probléma… Úgy gondolom, hogy az emberek többsége itt adja fel, de nézzük csak meg mi történik, ha ugyanezt tesszük parancssorból?

C:\Users\voji>net use \\192.168.1.10\openhab
The password is invalid for \\192.168.1.10\openhab.

Enter the user name for '192.168.1.10': openhab
Enter the password for 192.168.1.10:
System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, 
using more than one user name, are not allowed. 
Disconnect all previous connections to the server 
or shared resource and try again.

Minderről a GUI annyit mond, hogy Access is denied. Grafikus felületről akarsz csatlakozgatni mindenhova? Akkor úgysem értesz hozzá, minek is terhelne az operációs rendszer ezzel a sok felesleges információval… A “soft” mountokat GUI-ról szintén nem lehet látni, szóval amúgy is mindegy lenne… De ha már itt tartunk, akkor kicsit jobban megnézve, milyen share is van jelenleg “mountolva”:

C:\Users\voji>net use
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
OK \\192.168.1.10\IPC$ Microsoft Windows Network
The command completed successfully.

Bizony, IPC (Inter Proces Communication), amit az RPC (Remote Procedure Call) használ. Egyszerűen hibátlan… És ha tudnátok, hogy az RPC-n belül még mennyi rövidítés van (EPM, COM+, BIT, RPCSS, és még csak a jéghegy csúcsát karcolgatjuk…)

A lényeg, hogy jelen probléma megoldására a bátrak használhatják az alábbi parancsot:

 net use * /d

Kevésbé bátrak beírhatják a * helyére a mount nevét is (ami a fenti példában: \\192.168.1.10\IPC$)

És ezek csak azok a dolgok amik NT4 óta így maradtak… Az újakba, mint pl. a fastboot még bele se mentünk… Pedig…

A microsoft kitalálta, hogy a kernel modulok, és driverek viszonylag ritkán változnak az operációs rendszer élete során, ezért ezeket felesleges is mindig nulláról betöltögetni. Ezért az új windows verziók esetében (8+) bevezették a fastboot-ot, ami annyit tesz, hogy amennyiben kikapcsoljuk a gépet, akkor valójában nem az történik, amire a felhasználó első körben számít. Ugyanis a windows fogja és hasonló dolgot csinál, mint amikor hibernate-t mondunk, egy különbséggel. Nem a teljes memóriát menti, hanem csak a futó szolgáltatások memóriaképét. Zseniális ötlet, akit érdekel, hogy működik, itt olvashat egy felületes cikket a témában: http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

A probléma nem is ezzel van, hisz mivel ez az alapbeállítás, a világ elég nagy részén így kapcsolják ki kedvenc operációs rendszerüket. Ellenben volt a windowsban egy funkció, amit elég gyakran használtam, mégpedig a Group Policy Editorban a startup / shutdown scripts. Ez pont annyit tud(ott), mint amit a neve is mond: megadható neki egy program, amit a rendszer Local System-ként végrehajt a rendszer indulása és leállása során. A fastboot viszont kicsit bekavart a képbe, mert a be/kikapcsolás már nem inicializálja a rendszert a megszokott módon, és ebben az esetben nem is fut le egyik megadott script se. Hogy ebből mit lát a végfelhasználó? Megírja a scriptet, restart, működik. Aztán shutdown, és nem fut az a script, ami az előbb még futott. Aztán előbb utóbb összerakja, hogy hát itt valaki nagyon vicces kedvében volt, mert a startup/shutdown script csak restart esetén fut. A megoldásra két lehetőség van: Vagy kikapcsoljuk a fastboot-ot tokkal-vonóval, és akkor működni fog a startup és shutdown script, vagy továbbra is használjuk a fastboot-ot, de akkor nincs lehetőségünk korrekt módon programokat futtatni a windows indulása/leállítása során (én legalábbis nem találtam, de ha valaki tud ilyet és megosztja velem, akkor jár neki a Mars szelet).

Aztán kipróbáltam még az új Storage Spaces Pool-t (gyk.: mdadm by microsoft). Azt még nem tudom, mi fog történni, ha összeomlik a RAID array, mert ezzel kapcsolatban a Microsoft azt mondja, hogy nem omlik, de ilyen apróságoktól nem szoktam megrettenni. Az mondjuk azért nem annyira bíztató, hogy a disk kivételéről még csak nem is zenélnek a grafikus felületen. A problémára a megoldást természetesen megint egy fórumban lehet megtalálni, vagy jobb esetben, a fórum alapján készült blogbejegyzésben 🙂

És a viccesebbnél viccesebb hibákról még nem is beszéltem. A mostani kedvencem a KB3053711 (user error-nak szoktam hívni). Tessék elolvasni a kapcsolódó knowledge base article-t és a javasolt megoldást… Igazából minden szava arany, csak azt sajnálom, hogy a kapcsolódó forráskódot nem mellékelték, mert ez már az a szint amit minden szakmabelinek látnia kellene…

A Microsoft egyértelműen utolérhetetlen a felhasználói élmény fokozásában… 🙂

A windows 10 frissítés után tudatosult bennem, hogy bár a windows 10-el önmagában semmi probléma nincs, a számítógépes zenélést el is felejthetem mert ott még komoly kompatibilitási problémák vannak. Ez nem új dolog, és nem is csak Windows specifikus, OSX-en is hasonló a helyzet az El Captain kapcsán… Azt hittem ez nem lehet probléma, visszatelepítem a régi windowst (8.1), otthon az érdemi dolgok úgyis külön partíción, vagy dropbox-ban vannak.

A telepítéshez szükséges kulcsokat mindig mentem keepass-ba, így a kulcs is megvolt. Ha valaki esetleg elmulasztotta volna ezt a lépést, és nem tudja, hogy az általa használt windowsnak mi a telepítési kulcsa, akkor azt utólag is kinyerheti a Magical Jelly Bean Keyfinder alkalmazással.

Az első komoly problémát a windows telepítő beszerzése jelentette. A microsoft még mindig egy tucat telepítőt gyárt, amik csak bizonyos kulcsokat fogadnak el. Én azt hittem msdn által telepített windows verzióm van (általában mindig olyat telepítek) de mivel a mostani windowsomat upgradek hada állította elő (win7 -> win8 -> win10) az msdn.es telepítő nem fogadta el a kulcsomat.

Ekkor került képbe Janek által fejlesztett Ultimate PID checker. Az alkalmazás segítségével meg lehet határozni egy megadott windows telepítési kulcs típusát. Az általam használt kulcs RETAIL típusú, amihez természetesen nem volt telepítőm. A megoldást meglepő módon a microsoft szállította, és még csak MSDN subscription sem kell hozzá. A Windows 8.1 Media Creation Tool letöltése után csak ki kell választani a system type-ot, nyelvet, editiont (amit szintén megmond a PID checker) és már tölti is a megfelelő telepítőt, amit közvetlenül pendrive-ra is fel tud rakni (működött, így nem kellett megfutni egy rufus-os plusz kört).

Az újratelepítés során egyetlen dolgot rontottam el. A letörölt windows 10 kulcsát nem mentettem el, mielőtt letöröltem, így az elveszett. Azt visszaszerezni már csak bonyolultan lehet (le kell menteni a Windows 8 lemez képét, azt mountolni egy virtuális gépre, ott bootolni, upgradelni win10-re, lementeni a kulcsot, törölni az egészet). A free upgrade 2016 juliusig él, tehát mindezt még ez előtt lenne célszerű megcsinálni… Majd egyszer, talán…

Mint felhasználó nem tudom, a szivatáson kívül mi értelme van ezeknek a különböző Microsoft telepítőknek, edition-oknak, időhöz kötött upgrade-knek. Jobs a leopárd kapcsán viccelődött is ezzel, egyszer talán majd Nadella is elsüti ezt lenti poént: https://www.youtube.com/watch?v=gtSDlSVDibA

A 10 számú windows esetében a fejlesztők szó szerint értelmezték az automatikus frissítések funkciót. Ugyanis ezen windows verzió óta a frissítések letöltése tényleg felhasználói interakció nélkül (automatikusan) történik. Ezzel egy kábelen lógó asztali gép esetén nincs is baj, de elég kellemetlen meglepetés érheti az embert, amikor a windows öntudatára ébred, és a legfontosabb feladatának a frissítések letöltését tekinti. Mondjuk mobilneten, egy megbeszélés közepén, amikor nagyon kellene egy dokumentum, ami a felhőben van…

A Microsoft által javasolt pol-korrekt megoldás az lenne, hogy minden ilyen jellegű wifi kapcsolat esetén állítsuk be, hogy Metered connection-ről van szó, de nekem semmi kedvem ezt átvezetni az összes elmentett wifi kapcsolatomon, valamint minden új kapcsolatkor, kapcsolódás után, külön. Amúgy sem szerencsés, ha az operációs rendszer akkor töltöget amikor csak kedve támad. Én úgy gondolom, hogy azt csak a felhasználó tudja, mikor nem zavarja, hogy a windows berántja a rendelkezésre álló sávszélességet.

Az automatikus frissítés letöltés kikapcsolására van mód, és jó leírás is:

http://www.thewindowsclub.com/make-windows-10-notify-you-before-downloading-or-installing-windows-updates

Sokat hozzátenni nem is tudok, talán csak annyit, hogy nekem a 2 érték nem működött, az 5 viszont igen, így érdemes azzal próbálkozni elsőre.

A nagy windows 10 upgrade után többen meglepődve tapasztalhatják, hogy nem tudnak Recovery drive-ot létrehozni a megszokott módon. A fórumokban elég nagy a tanácstalanság, de a probléma, nem új keletű, már windows 8.1-ben is jelen volt. Az okokat és a lehetséges megoldást szépen összefoglalja a neosmart csapat wiki oldala: https://neosmart.net/wiki/we-cant-create-a-recovery-drive-on-this-pc/

A lényeg: recovery partíció hiányában (ami upgrade esetén nem jön létre) kénytelenek vagyunk mi megadni egy helyet (a reagentc segítségével), ahol a windows telepítő elérhető.

Aki viszont nem rendelkezik windows 10 telepítővel, vagy egyszerűen csak egy gyorsabb megoldást szeretne, igénybe veheti az EasyRe alkalmazást, ami windows 10 alá ingyenesen letölthető: https://neosmart.net/EasyRE/