Nové Visual Studio 2010 a MSDN

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:

Visual Studio 2010     msdn logo

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:

VS 2010 Splash Screen

World of Warcraft patch 3.2.0 na Snow Leopard

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/In­staller.

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

Prípad dlhého vypínania PC s Blue Screenom na nových Windows 7

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

Device Manager

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.

Vista: Set global command failed on WSH

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=di­sabled. 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=nor­mal (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.

Zelená – oranžová – červená


FP: It's Beginning to Look a Lot Like Christmas (HBW)
Originally uploaded by mang maning 

Prípad padajúceho Prieskumníka (aka explorer.exe)

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_vc9ex­tse64.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.

Prípad nefungujúceho Štart menu vo Windows Vista

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\Mi­crosoft\Window­s\CurrentVersi­on\Installer\U­serData\S-1–5–18\Components.

Napríklad Acrobat Reader je uložený pod kľúčom 9579C59FFA311­4E44AB6BD2D1806D835\68AB­67CA7DA71501B7449A010000­0010 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:

  1. Explorer.EXE 3040 ReadFile C:\Program Files\Adobe\Reader 9.0\Reader\AcroR­d32.exe SUCCESS
  2. Explorer.EXE 3040 Process Create C:\Program Files\Adobe\Reader 9.0\Reader\AcroR­d32.exe SUCCESS
  3. AcroRd32.exe 3692 Process Start SUCCESS Parent PID: 3040
  4. 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\sys­tem32\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.

Generovanie dokumentácie k Ajax web službe

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:

  1. Zadefinovanie interface-u,
  2. Implementácia interface-u,
  3. Spustenie služby pomocou ServiceHost a povolenie generovania metadát,
  4. 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.Cre­ateInstance() 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.Cre­ateInstance() 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;
  }
}

Dependency injection v Ajax WCF službe

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.

Gopas Bootcamp

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.