Microsoft uvolnil pre MSDN odberateľov Visual Studio 2010 Beta 2. Spolu
s redizajnom hlavnej MSDN stránky prichádza rada nových vecí ako napríklad
fialová, fialová a fialová – logá a stránky majú výraznú zmenu
farebného ladenia oproti doterajšej tehlovo červenej. Bohužiaľ Visual
Studio logo stratilo svoj viacfarebný prúžok.
Pohľad do Subcriber Downloads časti prezrádza, že VS prejde zmenou
v licencovaní a marketing sa zase hrá s názvami: „Express Combo“,
Professional, Premium, Ultimate a niečo čo sa volá „Test Elements“.
Otázne je, či Premium bude niečo viacej ako Professional (Prof + Team
Foundation Server???), ale najskôr to je staré dobré VS Standard
s chytľavejším názvom. Všetky verzie majú vypublikovanú aj Web Installer
verziu.
Aktualizácia: Arstechnica má informácie o nových SKU: Premium
je starý Team System a Ultimate je celý Team System (všetky TS veci,
alebo taktiež Team System Team Suite – nový názov je lepší). Standard
verzia mizne z ponuky.
Ako sa vyjadril Dave Mendlen (zodpovedný za marketing), všetky tieto zmeny
sú symbolizované novým logom:

MSDN
Library má novú Lightweight
tému, ktorá sa stane čoskoro východzím vzhľadom.
A to by bolo na dnes všetko. Veľa marketingu a málo technických
infošiek. Zdroje: Scott Hanselman a Arstechnica.
Úplne na koniec ešte ukážka splash screenu:
October 19th,2009
Osobné |
4 Comments
Skúšam Snow Leopard a nainštaloval som si tam WoWko. Na Leopardovi bežalo
v pohode, zo stránky som stiahol inštalátor, opatchovalo sa to a WoW
fičalo. V Snow Leopardovi som mal k dispozícii iba inštalačné súbory a
patch 3.2.0 som sťahoval cez torrent, pretože to cez uTorrent trvá aj 5×
menej ako cez Blizzard Downloader.
Patch som skúšal spustiť, ale nič sa nedialo. Ani sa neukázala ikonka
v Docku. Akoby systém vôbec nespustil program. WoWko si patch sťahuje do
svojeho priečinku v /Applications/World of Warcraft, tak som patch skopčil tam
a stále to nešlo. Downloader síce súbor skontroloval (a bol správny), potom
sa však nič nedialo.
Tak som spustil Console že či náhodou sa niečo neloguje
a objavil som túto chybu:
10. 12. 2009 18:09:07 com.apple.launchd.peruser.501[76] ([0x0-0x69069].com.blizzard.BNUpdate[1244]) posix_spawn("/Applications/World of Warcraft/WoW-3.2.0-enGB-patch.app/Contents/MacOS/Installer", ...): Permission denied
10. 12. 2009 18:09:07 com.apple.launchd.peruser.501[76] ([0x0-0x69069].com.blizzard.BNUpdate[1244]) Exited with exit code: 1
Inštalátor nemal práva. Na WoW forách som našiel, že skupina
admin by mala mať Read&Write prístup do priečinka
s WoWkom a podpriečinkov. Nasledovala zmena práv, pretože admin mal
nastavený iba Read.
chmod -R g+w /Applications/World\ of\ Warcraft/
Toto nepomohlo a pri ďalšom googlení som objavil, že
WoW-3.2.0-enGB-patch.app nie je súbor, ale priečinok a má
v sebe ďalšie súbory a jedným z nich je aj Contents/MacOS/Installer.
ls -l WoW-3.2.0-enGB-patch.app/Contents/MacOS/Installer
-rw-rw-r-- 1 izsak admin 5947960 Oct 12 17:28 WoW-3.2.0-enGB-patch.app/Contents/MacOS/Installer
Installer je síce aplikácia, ale zrejme tým že bola sťahovaná cez
torrent a patch nebol jeden súbor, ale štruktúra priečinkov a súborov, bol
na disk uložený iba ako obyčajný súbor bez priradených execute práv.
Jeden príkaz a WoWko sa mi patchuje ;)
chmod ug+x WoW-3.2.0-enGB-patch.app/Contents/MacOS/Installer
October 12th,2009
Osobné |
1 Comment
Upgradoval som jeden počítač s Vista Business 32bit na Windows
7 Professional 32bit. Upgrade prebehol v pohode, ale bol problém s jednou
nefunkčnou CD romkou a o pár dní užívateľ vravel, že počítač sa dlho
vypína, dokonca aj spadne do Blue Screenu.
Prvé informácie o BSOD sú v Event Logu:
Chybový sektor 0x9F_4_cdrom_IMAGE_jraid.sys, typ 0
Názov udalosti: BlueScreen
Odozva: Nie je k dispozícii
Identifikácia kabinetu: 0
...
Priložené súbory:
C:\Windows\Minidump\090409-106078-01.dmp
Vďaka tomuto padá prvé podozrenie na ovládač pre JMicron JMB36X
Controller (jraid.sys). Keďže však tento ovládač nie je priamo spomenutý
v zázname a aj pre kontrolu je dobré zanalyzovať Memory Dump ktorý je
v priečinku Minidump.
Analýza výpisu pamäte (Memory Dump)
Súbor 090409–106078–01.dmp som otvoril v 32bitovej
verzii programu WinDbg a spustil som analýzu príkazom
!analyze.
0: kd> !analyze
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 9F, {4, 258, 855ec798, 82f66b24}
Probably caused by : cdrom.sys ( cdrom!DeviceSendPowerProcessRequest+15b )
Followup: MachineOwner
Prvá dôležitá informácie je, že Blue Screen vznikol na základe Bug
Check stavu – kernel zistil, že niečo nie je v poriadku so zariadením
alebo ovládačom a prepol teda na Blue Screen pretože nemôže normálne
pokračovať. Súčasťou Blue Screenu je zaznamenanie stavu pamäte do .dmp
súboru (ak je zapnutá voľba Zápis pamäte pre ladenie > Výpis
pamäte jadra (Kernel memory dump)).
Rozšírené informácie o stave pamäte dostaneme príkazov !analyze
-v:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 00000258, Timeout in seconds.
Arg3: 855ec798, The thread currently holding on to the Pnp lock.
Arg4: 82f66b24
...
Vďaka dostupnosti .pdb symbolov je možné zistiť význam jednotlivých
parametrov Bug
Check 0×9F priamo z analýzy. Prvý parameter Arg1 = 0x04
označuje typ problému pri DRIVER_POWER_STATE_FAILURE. Bohužial
zatiaľ nie je zdokumentovaný na webe MSDN Library ani vo Windows 7 Driver
Kit. Typ 0×04 bol pridaný vo Vista SP2 a Windows 7. Podľa
Melissi Hannah to znamená, že došlo k deadlocku v threadoch a pokiaľ
sa neodblokujú do určitého času (Arg2) bude vyvolaný Bug Check
0×9F s kódom 4.
Dlhé vypínanie
Z druhého parametru Bug Checku sa dá vyčítať, ako dlho bude systém
čakať pri deadlocku threadov pri vypínaní: 0×0258 = 600, údaj je
v sekundách, čiže to je 10 minút, kým systém spadne do Blue Screenu. Čo
korešponduje s popisovaným problémom – že počítač sa dlho vypína.
Neznamená to však, že k BSOD dojde vždy. Je možné, že ovládač sa
niekedy „rozbehne“ a vypne. Bez BSOD by sa to však tak ľahko nepodarilo
zistiť 
Zdroj problému
Tretí argument Bug Checku reportuje adresu threadu, ktorý bol zablokovaný
(The thread currently holding on to the Pnp lock.). Detail si
zobrazíme príkazom !thread 855ec798. V tomto threade je
používaný ovládač cdrom.sys. Aj podľa rozšírenej analýzy
problém nastal vo funkcii volanej týmto ovládačom –
DeviceSendPowerProcessRequest.
...
SYMBOL_NAME: cdrom!DeviceSendPowerProcessRequest+15b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: cdrom
IMAGE_NAME: cdrom.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bbf1c
FAILURE_BUCKET_ID: 0x9F_cdrom!DeviceSendPowerProcessRequest+15b
BUCKET_ID: 0x9F_cdrom!DeviceSendPowerProcessRequest+15b
...
Príkazom lmvm cdrom získame bližšie informácie
o ovládači. Jedná sa o štandardný ovládač dodávaný so systémom.
Z Správcu zariadení (Device Manager) je vidieť, že CD-Romky sú pripojené
cez JMicron JMB36X. Skontrolovanie tohto ovládača cez lmvm jraid
odhalí, že je celkom starý – z novembra 2008.
0: kd> lmvm jraid
start end module name
8b400000 8b418000 jraid T (no symbols)
Loaded symbol image file: jraid.sys
Image path: \SystemRoot\system32\DRIVERS\jraid.sys
Image name: jraid.sys
Timestamp: Fri Nov 21 16:05:38 2008 (4926CE42)
CheckSum: 000215C8
ImageSize: 00018000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Server JMicronu obsahuje novšie ovládače pre ich chip
(R1.17.50 z augusta 2009) na adrese ftp://driver.jmicron.com.tw/…_Vista_Win7/.
Podľa ReleaseNotes.txt
odvtedy opravovali niekoľko problémov s BSOD. Ovládač som nainštaloval a
teraz budem čakať, či sa chyba prejaví a budem môcť analyzovať ďalší
problém, alebo je to vyriešené.
PS: Pre mnohých sú BSOD veľkou pohromou a symbolom nefunkčnosti Windows.
Pre mňa sú vďaka Markovi
Russinovichovi najcennejším zdrojom riešenia problémov.
Celý deň nejde Wowko, tak sa hrám zo sieťou, skúšam latenciu a mením
TCP Autotuning nastavenia. Vypnutie bola hračka: netsh interface tcp
set global autotuninglevel=disabled. Nahodenie auto tuning späť na
hodnotu normal už bolo problematickejšie vďaka chybe:
Set global command failed on WSH Systém nemôže nájsť zadaný
súbor.
Po inštalácii Service Pack 2 na Vistu pribudlo v kontexte netsh
interface tcp nové nastavenie heuristics ktoré pri
hodnote wsh=default robí problém a neumožňuje nastaviť
autotuninglevel=normal (všetky ostatné hodnoty je možné
nastaviť.
Zadal som teda
netsh > int tcp
netsh interface tcp > set heuristics enabled
Ok.
netsh interface tcp > set global autotuninglevel=normal
Ok.
A už to beží. Zatiaľ neviem čo je tá nová heuristika, ale pingy to
veľmi neovplyvňuje. Za to Wowko furt a furt nič. Zrejme si odpočiniem
od raidy.
July 15th,2009
Software |
1 Comment
July 4th,2009
Osobné |
1 Comment
Mám teraz doma nanovo preinštalovanú Vistu Ultimate x64 a keďže veľmi
veľa programujem, mám tu plno nástrojov na vývoj: Visual Studio, WinDbg,
MSDN Library s dokumentáciou, Apache na lokálny SVN server, samozrejme
Tortoise SVN (x86 aj x64 bit verzie, aby kontextové menu fungovalo správne
v Exploreri aj v Total Commanderi, ktorý je len 32bitový). Nesmie chýbať
virtuálna cd-romka – pomocou Virtual CD 9 – a NOD32 Antivirus 4.
Potreboval som nainštalovať Windows SDK, tak som pripojil .iso image a
chvíľu počkal. Autorun sa nespustil, takže som šiel do Štart >
Počítač, pravý klik na cd-romku, chvíľu sa nič nedialo a nasledoval Dr.
Watson, ktorý mi oznámil, že program Prieskumník sa musí reštartovať.
Na to že som ešte nestihoval nainštalovať rôzne bety a iné pofidérne
programy a mám tu len tie o ktorých viem, že sú veľmi stabilné, začal
Prieskumník vo Viste padať celkom rýchlo. Prvé podozrenie padlo na chybný
Tortoise SVN, ktorý je zaregistrovaný do exploreru a Virtual CD ktorý do neho
tiež pridáva vlastné kontextové menu. Stačí sa len dopátrať ku
skutočnej príčine.
Mark Russinovich má vynikajúce články na svojom blogu o možnostiach
hľadania chýb v padajúcich programoch a článok The
Case of the Random IE and WMP Crashes mi naozaj pomohol a konečne som mal
možnosť si skúsiť tento typ troubleshootingu.
Vo WinDbg sa stačí pripojiť na existujúci proces: File >
Attach to a Process… > explorer.exe a debugovanie môže začať.
WinDbg sleduje, čo sa deje v Prieskumníkovi a keď som klikol pravým na
cd-romku, hneď sa zastavil na výnimke:
V Call Stacku bolo vidieť, že Virtual CD DLLka uvoľňovala pämať a
zrejme tam mali chybičku.
Odskúšal som si aj utilitu adplus.vbs, ktorá je súčasťou Windows
Debugging Tools. Tento skript pripojí debugger na existujúci proces (alebo
spustí nový proces) a zaznamenáva 1st a 2nd chance výnimky, ktoré nastanú
v programe, zaloguje ju a vytvorí memory dump z ktorého sa dajú vyčítať
veľmi cenné informácie.
1st chance výnimka je taká, ktorá je v programe odchytená a viacej-menej si
s ňou dokáže poradiť.
2nd chance výnimky sú všetký neodchytené výnimky a teda spôsobujú
ukončenie procesu.
cscript adplus.vbs -crash -pn explorer.exe -o C:\dump
Adplus.vbs zaznamenal do logu 1st chance AccessViolation
exception v <Unloaded_vc9extse64.dll>+0×5f84
a okamžite aj 2nd chance AccessViolation exception čo
znamená, že tam je bug.
--- 2nd chance AccessViolation exception ----
---------------------------------------------------------------
Call Site
<Unloaded_vc9extse64.dll>+0x5f84
0x1`00000000
0x7f24f90
0x4ded7a8
0x360033`00380033
0x7fe`00000037
<Unloaded_vc9extse64.dll>+0xf1c8
Čo s takouto chybnou knižnicou? Virtual CD som používal v staršej
verzii, najnovšia 9.3.0 je opravená. Nie vždy však môže byť opravená
verzia dostupná. V takom prípade treba knižnicu zakázať napríklad pomocou
ShellExView. Veľmi
často podobné padanie spôsobujú staré DivX a xvid kodeky, keď vytvárajú
náhľady.
Pred bedmintonom som sa štandardne zastavil v bývalej robote vyzdvihnúť
kolegov a jeden z nich mal problém s Vistami. Firemný noťas, 32bit Vista
Business a už to bude nejaký ten rok, čo je nainštalovaná. Keďže to je
vývojársky a domáci komp, je tam nainštalovaných veľa rôznych softov.
Dnes sa mi sťažoval, že vo Viste nefunguje Štart menu a nie je vôbec
pokrok oproti Windows 95 kde fungovalo bez problémov. Windows spúšťal
z menu iba niektoré programy. Fungovali z plochy, z rýchleho spustenia a aj
z ponuky Všetky programy. Z úvodného Štart menu alebo s pomocou
vyhľadávania nefungovali.
Hlavne sa jednalo o programy inštalované cez Microsoft Installer – MS
Office, Acrobat, či Cisco VPN klient.
Pomocou Process
Monitoru som zistil, že sa spúšťajú iba obyčajné .lnk odkazy. Štart
menu však obsahuje aj odkazy, ktoré sú uložené v Registroch v časti
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1–5–18\Components.
Napríklad Acrobat Reader je uložený pod kľúčom
9579C59FFA3114E44AB6BD2D1806D835\68AB67CA7DA71501B7449A0100000010 kde má
záznam typu REG_SZ s uvedeným cestou k AcroRd32.exe.
(Screenshot je z XPéčok, lebo na nich píšem tento zápisok :) )
Explorer už vie, kde sa odkaz na program náchadza a teda za normálnych
okolností by File Monitor zobrazil tieto udalosti:
- Explorer.EXE 3040 ReadFile C:\Program Files\Adobe\Reader
9.0\Reader\AcroRd32.exe SUCCESS
- Explorer.EXE 3040 Process Create C:\Program
Files\Adobe\Reader 9.0\Reader\AcroRd32.exe SUCCESS
- AcroRd32.exe 3692 Process Start SUCCESS Parent
PID: 3040
- AcroRd32.exe 3692 Thread Create SUCCESS Thread
ID: 2604
Explorer však ani nezačal načítavať Acrobat z disku, ani vytvárať
nový proces.
Po chvíľke googlenia som našiel zmienku o nefungujúcom menu vo Viste
s podobnými symptómami na Winmatrix fóre – Vista Start
Menu Broken?. Bola tam zmienka o utilitke ShellExView, ktorá vie
zobraziť všetky COM+ rozšírenia zaregistrované do Exploreru (a že tých
rozšírení je veľa – čistá inštalácia Windows XP SP3 ich má
okolo 250),
Kolega mal v počítači rôzne rozšírenia do kontextového menu, na
vytváranie náhľadov a iných vecí. Niektoré sa dali identifikovať podľa
výrobcu (Real Networks, RAR Labs, Tortoise SVN), jedna .dllka bola no-name. Po
vypnutí všetkých neštandardných dlliek Štart menu začalo fungovať.
Postupným skúšaním sme zistili, že problém spôsobovala práve komponenta
AdCntxtM.dll s názvom AdCtxtM Dynamic Link Library, ktorá
má neznámeho výrobcu. V systéme je zaregistrovaná pod GUID
{AA6639D1-CE2B-11D5-AB4D-006097A79E23} a nachádza sa v System32 priečinku:
C:\Windows\system32\AdCntxtM.dll.
Prípad niekoľko dní nefungujúceho Štart menu sa mi nakoniec podarilo
opraviť bez formátovania, reinštalácie a iných zdĺhavých procedúr ;) Za
hodinku sa to dá opraviť, stačí však poznať správne nástroje.
Webové služby využívajúce formát SOAP sa s pomocou WCF programujú
veľmi ľahko hlavne vďaka tomu, že programátor sa môže sústrediť na
biznis logiku, ktorú potrebuje implementovať. Na vytvorenie služby a
rozchodenie komunikácie stačia štyri kroky:
- Zadefinovanie interface-u,
- Implementácia interface-u,
- Spustenie služby pomocou ServiceHost a povolenie generovania metadát,
- Zo schémy sa vytvorí proxy trieda pre prístup k službe.
[ServiceContract(Namespace="WebApplication1.Services")]
public interface IPublicApi
{
[OperationContract]
[WebGet]
IList<TaskGroup> GetTaskGroups();
[OperationContract]
[WebGet]
Guid CreateTaskGroup(string taskGroupName);
}
Utilitka svcutil.exe vie na základe XML schémy SOAP
služby vygenerovať strongly-typed triedu pre .NET. Keď sa zmení rozhranie
služby, stačí pregenerovať triedu a prípadne refektorovať kód.
S webovými službami pre Ajax to tiež nie je ťažké. WCF 3.5 podporuje
Json a stačí použiť triedu WebScriptHostFactory ktorá vytvorí
WebServiceHost s WebScriptEnablingBehavior. Ten pridáva podporu
pre formát Json a XML a mapuje cestu /js na generátor
JavaScript-ového proxy súbory. Vygenerovaný JavaScript je určený pre
ASP.NET AJAX framework a generátor zatiaľ nie je plug-able, čiže sa nedá
vymeniť za nejaký iný.
http://localhost/WebApplication1/PublicApi.svc/js
Objavil som však WCF REST
Starter Kit (zdrojový kód je na Codeplex.com) – je to ukážka
rozšíriteľnosti WCF stacku a záreveň implementácia podpory pre REST.
Tento kit obsahuje triedu HelpPageInvoker, ktorá si registruje url
/help na ktorej sa zobrazí jednoduchý popis dostupných
metód, ktoré HTTP príkazy (GET, POST, PUT, DELETE…) sa dajú použiť a
taktiež odkazy na ukážkový request alebo response pre metódu.
http://localhost/WebApplication1/PublicApi.svc/help
REST Starter Kit je určený hlavne pre zjednodušenie práce so službou,
ktorá používa POX a HTTP príkazy. Umožňuje použiť Json formát, ale
cieľovou skupinou tohto kitu nie sú prímarne Ajax rozhrania.
Ak používate dependency injection
v Ajax službách, tak zrejme budete potrebovať vlastnú implementáciu
triedy HelpPageInvoker aby v nej správne fungovalo generovanie ukážkových
hodnôt pre request alebo reponse. HelpPageInvoker si zistí návratový typ
metódy, alebo jej parametre, tieto typy inštanciuje cez
Activator.CreateInstance() a objekt serializuje do XML alebo Json. Ak sú
však tieto typy definované ako rozhrania (napr. GetTaskGroups() vracia
IList<TaskGroup>) tak Activator ich samozrejme nevie ako
vytvoriť.
Tu prichádza napomoc dependency injection. Do triedy HelpPageInvoker stačí
poslať referenciu na kontajner z DI frameworku, ktorý využívate a nahradiť
štyri volania Activator.CreateInstance() za kontajner a jeho príslušné
metódy.
Nasleduje kód, ako principiálne funguje vytvorenie ukážky návratovej
hodnoty pre nejakú operáciu:
class HelpPageInvoker
{
public Message GetResponseExample(OperationDescription od)
{
// z popisu operácie získa dátový typ návratovej hodnoty
// a vytvorí objekt
Type body = GetResponseBodyType(od);
object instance = UnityContainer.Resolve(body);
// vytvori Message serializovanu do Json
Message result = Message.CreateMessage(MessageVersion.None, null,
new JsonBodyWriter(instance, body));
return result;
}
}
February 25th,2009
Osobné |
No Comments
Mám možnosť sa hrať s WCF službami v ASP.NET MVC projekte. Z MVC som
mal po pár projektov v práci zimomriavky na chrbte a Web Forms zostávali
u mňa tým skvelým prostriedkom, ako spraviť webovú aplikáciu bez toho,
aby som šiel na psychiatriu pre programátorov kvôli neustálemu
implementovaniu nejakých rozhraní cez 7 vrstiev enterprise aplikácie.
Musím povedať že ASP.NET MVC vo verzii RC1 je skvelý framework, ktorý
umožňuje nevídané testovanie kódu (pri štýle vývoja pre Web Forms to je
snáď nemožné).
Píšem si teda projektík, kde je web robený pomocou MVC modelu, vrstvy pre
služby a dáta sú definované pomocou rozhraní a využívajú Dependency
Injection v podobe Unity Application
Block. API webovej aplikácie je dostupné vďaka WCF službe s podporou
pre Json formát.
ASP.NET MVC je priamo pripravený na to, že sa v ňom bude používať
Dependency Injection. Horšie je to s WCF. Je potrebné si napísať vlastný
IInstanceProvider
pre konkrétny DI framework. Ja som využil tento návod: Using
Unity with a WCF Service, ktorý vychádza z ukážky pre Spring.NET: WCF
Service Dependency Injection. Kód sa trochu zväčší, ale môžeme si
užívať výhody DI, testovania a pri návrhu API pre Ajax službu nemusíme
rozmýšlať nad tým, ako bude vyzerať prístup do databázy. Keď je API
vyladené, stačí zmeniť objekty v DI nastaveniach a služba môže fičať
s databázou.
Bootcamp je skvelý spôsob, ako si oddýchnuť, vyškoliť sa v novej
technológii a spoznať nových odborníkov.
Témou zimného bootcampu bol Office SharePoint Portal 2007. Úžasnou vecou
na bootcampe je, že ráno si môžete dať perličkový kúpeľ, potom je
klasické školenie, obed, školenie a večera a potom vlastný program –
takže nejaký ten bowling, prípadne zase perličkový kúpeľ, či sauna a
rôzne iné aktivity.
February 23rd,2008
Osobné |
No Comments