Soci (Soczó Zsolt) szakmai blogja

2007.04.20.

Diagnosztika a Vistában

Filed under: Szakmai élet,Vista — Soczó Zsolt @ 09:04

Vannak dolgok egyes programokban, amelyeket csak állandóan kerülgetek, de sose veszem a fáradságot, hogy megnézzem a doksit, miről is szól. Aztán utólag rendszeresen kiderül, hogy valami okos, hasznos kis szolgáltatás mellett mentem el.
Így jártam a Vista Event View-erével is. Az előző verzió gondolom ismert mindenkinek, volt 3 fő ág, Application, System és Security. A programok ide ömlesztették a logjaikat, aztán lehetett vadászni a nagy zajban a valóban értékes infók után. Persze, bolt Event Source és társaik, amivel lehetett szűrni.
No, Vistában van egy új rész, Applications and Services Log. Ezekbe külön tudnak a programok írogatni, mindnek van saját log fájlja, nem a nagy masszába kerülnek be a bejegyzések.

Vista Event Log Viewer, benne az új Applications and Services Logs

Alapban nincs minden logolás bekapcsolva, és még az összes log forrás se látszik egyszerre. Az Applications and Services Log node-on jobb gombra be lehet kapcsolni a a diagnosztikai logokat is, így még sokkal több logforrás kapcsolható be. Figyelem, a GUI beteg, csak akkor jön fel a View context menü, és benne a diagnosztikai logos opció, ha az Applications and Services Log node a kiválasztott. Azaz ha egy másik kiválasztott, de csak rákattintasz jobb gombbal, akkor nem ez a menü jön fel! Gratula a szerzőnek.

A doksiból:
“Applications and Services Logs
Applications and Services logs are a new category of event logs. These logs store events from a single application or component rather than events that might have systemwide impact.

This category of logs includes four subtypes: Admin, Operational, Analytic, and Debug logs. Events in Admin logs are of particular interest to IT Professionals using the Event Viewer to troubleshoot problems. Events in the Admin log should provide you with guidance about how to respond to them. Events in the Operational log are also useful for IT Professionals, but they are likely to require more interpretation.

Admin and Debug logs are not as user friendly. Analytic logs store events that trace an issue and, often, a high volume of events are logged. Debug logs are used by developers when debugging applications. Both Analytic and Debug logs are hidden and disabled by default.

Az egész azért merült fel, mert nem sikerül működésre bírni az ActiveX Installer Service-t. A forráskódját böngészve láttam, hogy rengeteg trace-t rakott bele a szerző, de azt hittem azt csak az MS tudja használni debugolás közben. Mivel ott volt a szerző neve a forráskódok fejlécében, írtam neki. 1 óra múlva válaszolt. :) Ő írta azt, hogy az előbb kifejtett új Event Log részben be lehet kapcsolni az ő logolását is, így elvileg sokkal több infóm lesz, hol akad el a certificate ellenőrzés. Majd kiderül.

A teljesség kedvéért még pár infó. A logokat lehet parancssorból is adminisztrálni és lekérdezni a wevtutil.exe segítségével. A lekérdezések kapcsán egyből a logparser jutott az eszembe, de ez nem úgy működik, nem sql, hanem XPath formátumban lehet megfogalmazni a lekérdezéseket.

Pl. logforrások listázása:
wevtutil el

Az AxInstallService log teljes kidumpolása:
wevtutil qe Microsoft-Windows-AxInstallService/Log

Kimenet:
[source:xml]



7
0
4
0
0
0x4000000000000008

0


Microsoft-Windows-AxInstallService/Log
socivista



Exiting Policy Watch Thread


[/source]

A lekérdezéseknél az EvtQuery API függvényt használják a háttérben. A query nyelv nem teljes XPath implementáció, a // operátorra például rögtön böfögött, hogy ő azt ugyan nem ismeri. A nyelv leírása itt található.

2007.04.19.

TLS 1.0 kikapcsolása IIS alatt

Filed under: IIS,Szakmai élet — Soczó Zsolt @ 15:32

Ha a webszerver bepróbálkozna a régi TLS használatával, itt le van írva, hogy lehet lebeszélni róla. Ez akkor állhat elő, ha nincs kikényszerítve az SSL, de mégis https-sel hivatkoznak egy oldalra.

2007.04.18.

Apró körültekintés a Vista forráskódban

Filed under: Szakmai élet,Vista — Soczó Zsolt @ 09:20

Kb. két hete felrakták a forráskódokat tartalmazó szerverre a Vista forráskódját is (az MVP-séghez lehet kérni a hozzáférést, én éltem vele, használom is rendszeresen). Pont jól jött, mert az ActiveX Installer Service nem hallgat rám, pedig a munkámhoz ezt be kell konfigurálni majd az ügyfeleknek.
Debugolni lenne a legegyszerűbb ilyenkor, de egyelőre még nincs Vista kompatibilis kártyaolvasó driver, így marad az XP alóli kódböngészés (nyilván marha nagy secu van, nem csak jelszó alapú a hozzáférés).
Természetesen a kódokról nem beszélhetek direktben, főleg nem pasztázhatok be ide a blogba belőlük, de egy apróságot megosztok veletek, tetszett.
A Debugging Windows Applications könyv óta nagy szerelmese vagyok az Asserteknek. Az az igazság, míg nem olvastam a könyvet nem értettem, mire is való az assert? Azért nem értettem, mert ha úgyis van pl. egy függvényben paraméter ellenőrzés, ami exceptiont dob, vagy E_INVALIDARG-ot ad vissza, ha nem stimmel valami, akkor minek duplikálni az ellenőrzést még ASSERT-ekkel is? Nos, azért, mert az assert kiváltódása esetén egy gombnyomásra elindul a debugger, és benn vagyok a hibás részben, abban a kódrészletben, ahol nem teljesül az általam elvárt feltétel (invariáns, a tudományos neve? :). Mésként lehet, hogy csak 5 szinttel feljebb derülne fény a hibára, amikor már nem ismertek a mélyebben hibázó metódus lokális változó értékei, hisz a verem lebomlott. Tképpen az assertekkel a követelmények egy részét kódolja az ember a kódba, és egyúttal önvédelmet épít be a saját hibái ellen.

No, vissza a forráskódhoz. Az ieinstal.exe forrását nézegetem, hátha rájövök, miért nem úgy működik, ahogy szeretném. A forrás C++-ban íródott, nem C-ben. (Az oprendszer vegyesen asm, C és C++ kódokból épül fel.)
COM alapú, ezért tele van HRESULT kezeléssel. Ugye ez a hagyományos, status kód alapú hibakezelés, ami, ha csak if-elseket használunk nagyon mélyen betolt kódblokkokkat eredményezne. Ezt megelőzendő vagy exceptionkezelést használunk, vagy gotokat. Az első megoldás C++-ban nem annyira elterjedt, inkább managed és script környezetben használják elterjedtebben (de lehet, hogy csak nem értek hozzá). C++ kódokban gyakoribb a goto használata. if (FAILED(hr)) goto ErrorExit. Így sík lesz a kód, nem agyonindentált.
Az tárgyalt forráskódban szinte minden metódusban van két kijárat, egy sikeres és egy sikertelen, ahová gotoval ugrik be a szerző. Érdekes a következő. A sikeres kijáratnál vagy egy ilyen sor: ASSERT(SUCCEDED(hr)). A hibás ágnál: ASSERT(FAILED(hr)). Azaz a debug kód ellenőrzni, hogy ha egyszer a sikeres ágra engedtük a kódot, akkor ne adjunk már vissza véletlenül hibára utaló HRESULT-ot, és fordítva.
Apró, de szellemes trükk.
Mellesleg én sokáig legacynek éreztem a statuskód alapú hibakezelést, ez volt a .NET-es tankönyvekben is. Zoxigen annak idején adott egy linket, ahol Raymond barátunk rendberakta a fejemben a kérdést. Kötelező olvasmány. Van utójáték is a témához.
Mióta ezt olvastam mindig írok az if-ek mellé else-t még akkor is, ha abban nem csinálok semmit. Ilyenkor egy commentben odaírom, hogy ebben az ágban nincs teendő, de legalább látom, hogy nem feledkeztem meg róla.

2007.04.12.

The Art of Label Placement

Filed under: Szakmai élet,UI Design — Soczó Zsolt @ 21:53

Három érdekes link arról, hogyan érdemes összerakni a GUI-n a labeleket és az input elemeket.
A harmadik linket kiemelem, annyira ügyes: szemmozgás detektorral nézték, mennyit és hogyan mozog a szem egy form értelmezésekor, illetve hol, mennyi időt töltenek el. Nagyon jó cikk, ajánlom átfutni, 3 perc.

Lehet Ruby-val nagyteljesítményű appokat írni?

Filed under: Szakmai élet — Soczó Zsolt @ 21:29

A jelek szerint igen, a twitert elviszi, másodpercenként 11ezer kéréssel 16 proci (nem írja, ez hány gép, gondolom nem 1).

« Older Posts

Powered by WordPress