Za normálnych okolností Hamachi nainštaluje do systému sieťový adaptér, jednu Windows službu spúšťanú s Local System právami a GUI klienta, ktorý beží s práva bežného používateľa a využíva nainštalovanú službu. Sieťový adaptér je nastavený tak, aby poskytoval routovanie na sieť 5.0.0.1/8. Zistili sme, že sieťový adaptér nebol nainštalovaný a teda Hamachi malo problémy so správnym nainštalovaním siete. Hamachi inštaluje sieťový adaptér iba počas inštalácie – nie pri reinštalovaní – a bolo potrebné ho teda najprv odinštalovať a znovu nainštalovať. Tento postup však u kamoša nepomohol.

Inštalačný log

Najprv som sa teda pokúsil získať log z inštalácie Hamachi, či tam nie je nič podozrivé.

msiexec /log hamachi.log /i hamachi.msi

...
Action 18:30:17: InstallDriver. Installing network driver
Action 18:30:18: InstallServices. Installing new services
...

Žiadna chyba, tak som sa rozhodol vyskúšať nainštalovať ovládač pre Hamachi manuálne.

Manuálna inštalácia ovládača

Cez Device Manager kamoš dal manuálne nainštalovať sieťový adaptér s Hamachi ovládačom (%PROGRAMFILE%\LogMeIn Hamachi\hamachi.inf). Táto inštalácia však skončila veľmi divnou chybou: 0×5AA ERROR_NO_SYSTEM_RE­SOURCES – Insufficient system resources exist to complete the requested service. Na prvý pohľad sa zdá, že počítač nemá dostatok zdrojov a v tomto prípade človek najprv zisťuje, či má dosť voľného miesta na disku, alebo voľnej operačnej pamäte. Problém však bol inde a skúsili sme zapnúť v msconfig.exe diagnostické spustenie systému s iba základnými službami, aby sme vylúčili problém s nejakou inou aplikáciou. Tak isto bezúspešne a s rovnakým výsledkom.

Vďaka Process Monitoru som zistil, že inštalácia ovládačov vo Windowse je podrobne zaznamenávaná do súboru %WINDIR%\inf\setupapi.dev.log. Vyžiadal som si ho teda a nasledovala podrobná analýza a porovnanie jeho obsahu voči systému, kde sa Hamachi ovládač bezproblémov nainštaloval.

.    dvi:           {DIF_INSTALLDEVICE} 23:43:46.036
     dvi:                CoInstaller 1: Enter 23:43:46.036
     cci:                     [NdisCoinst: Enter NcipHandleInstallPreProcessing]
     cci:                     NdisCoinst: NetCfgInstanceId does not exist
     cci:                     NdisCoinst: Guid of the adapter is {DEFD4A42-3C78-4F11-AAC6-D798EF311363}
     inf:                     Opened PNF: 'C:\Windows\INF\oem2.inf' ([strings])
     cci:                     NdisCoinst: IfType from registry is 1
     cci:                     NdisCoinst: IfType 1, Characteristics 0x1, IsIrdaDevice 0, PhysicalMediaType -1, MediaType -1, IsBridge 0, FoundGuidInDownlevel 0, EnableDhcp 2
     cci:                     NdisCoinst: Connection name is Local Area Connection 35
     cci:                     NdisCoinst: NetLuidIndex does not exist
!!!  cci:                     NdisCoinst: NcipAllocateNetLuidIndex failed with error 0x5aa
     cci:                     [NdisCoinst: Exit NcipHandleInstallPreProcessing]
!!!  dvi:                CoInstaller 1: failed(0x000005aa)!
!!!  dvi:                Error 1450: Insufficient system resources exist to complete the requested service.
     dvi:           {DIF_INSTALLDEVICE - exit(0x000005aa)} 23:43:46.504

Z logu bolo vidieť, že inštalátor pri vytváraní nového sieťového adaptéru volá funkciu NcipAllocateNetLuidIndex ktorá skončí chybou. Získať informácie o tejto funkcii bolo jednoduché a zložité zároveň. Našťastie o nej existuje záznam na Internete, ale použiteľné informácie sú skryté vo veľkej kope textu zmeišaného so záznamami log súboru na fóre OSR Online.

Jeffrey Tippet z Microsoftu tam opisuje ako funkcia NcipAllocateNetLuidIndex funguje.

I don't have a good guess as to what's gone wrong, but here's some background info that might help you figure it out. (This info is an implementation detail, subject to change, but may come in handy for troubleshooting):

NDIS must allocate a (locally) unique number for each network interface, the NET_LUID. The NET_LUID consists of the ifType, paired with a unique ID number. To generate that unique ID, we keep track of the IDs that have already been assigned in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\[ifType] ! IfUsedNetLuidIndices (REG_BINARY) for each ifType. For example, look in \6 if your NIC is Ethernet (ifType=3D=6).

In there, there is IfUsedNetLuidIn­dices, which is (IIRC) a bitmap of the unique IDs that have been assigned to other network interfaces. Make sure this value is present and not damaged (e.g., a huge number of 0×FF's). Typically, its value will be something like 0×FF 0×01, if you have 9 NICs. Note that you can't just whack this value and replace it with something else, since then NDIS will incorrectly assign the same NET_LUID to two interfaces, and all sorts of things will break when that happens.

NcipAllocateNetLuidIndex teda pre daný typ sieťového adaptéru (v prípade Hamachi to je ifType=1) potrebuje získať LUID – Local Unique Identifier, ktorého aktuálna hodnota sa nachádza v uvedenom kľúči v Registroch. Problém môže nastať, keď je hodnota IfUsedNetLuidIndices nastavená na veľmi vysoké číslo – systém potom nemôže vytvoriť ďalšie LUID a skončí chybou 0x5AA ERROR_NO_SYSTEM_RESOURCES.

Nasledovala teda analýza tohto kľúča a dopracovanie sa (našťastie a konečne) k zdroju problému:

reg query HKLM\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\1 /v IfUsedNetLuidIndices


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDIS\IfTypes\1
    IfUsedNetLuidIndices    REG_BINARY    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Hodnota IfUsedNetLuidIndices sa z neznámich príčin poškodila a keďže kamoš nemal v počítači nejaké špeciálne sieťové adaptéry (ifType = 1 = IF_TYPE_OTHER) tak bolo bezpečné nastaviť IfUsedNetLuidIndices na 0×00. Potom však treba reštartovať počítač. Windows si totiž načítajú pomocné LUID čísla pri štarte systému a nenačítavajú ich počas inštalácie zariadenia (overené pomocou Process Monitoru :) ). Nasledovalo už len nainštalovanie Hamachi – tento raz úspešne a bez problémov.

Po približne 24 hodinách som úspešne našiel príčinu problému, opravil chybu a získal cenné skúsenosti. A aj v tomto prípade nebolo potrebné na odstránenie problému načisto inštalovať Windows – k čomu by sa asi mnohí iní uchýlili. Samotné riešenie problému však trvalo iba pár hodín, natiahlo sa však kvôli poctivej dochádzke do školy :)

1. Základom je Windows Server 2008 R2 Standard, stačí bežná inštalácia a vytvorenie domény – inak CRM inštalácia vyhodí hnusnú chybu.
2. Treba povoliť .NET Framework 3.5.1 feature, nainštalovať Web Server rolu s podporou ASP.NET a samozrejme zvoliť aj IIS 6 Management Compatibility nástroje.
3. CRM 4 ešte vyžaduje mať nainštalovanú Indexing Services, takže z role File Services treba nainštalovať Windows Server 2003 Compatibility nástroje. Inak bude CRM inštalátoru úplne pri konci vadiť, že služba cisvc nie je nainštalovaná.
4. Nasleduje SQL Server 2008, treba nainštalovať databázový engine a Reporting Services. Pre každú službu je vhodné vytvoriť samostatné konto v doméne. Po nainštalovaní treba aplikovať SP1, aby bol SQL Server kompatibilný s R2 verziou Windowsov. Reporting Services stačí nastaviť s predvolenými hodnotami.
5. V tejto fáze už nie je problém nainštalovať CRM 4 na predvolený IIS Web Site, pri nastavovaní URL pre Reporting Service si treba dať pozor a použiť URL pre Reporting Service, nie pre Reporting Manager. Pri otázke na adresu e-mailového serveru som vynechal jeho nastavenie, pretože potom sa CRM tvárilo, že nevie nájsť Exchange server. V testovacej prevádzke sa dá zaobísť aj bez podpory e-mailov.
6. Slovenský jazykový balíček pre CRM nájdete v Microsoft Download centre: Jazykový balík k aplikácii Microsoft Dynamics CRM 4.0
7. CRM sa samo neaktualizuje a je potrebné zohnať si Update Rollup 10, v prípade použitia Windows Serveru 2008 R2 samozrejme treba použiť aktualizácie určené pre amd64 architektúru. Aktualizácie treba nainštalovať v českej aj slovenskej verzii.
8. Správca CRM musí v časti Nastavení > Správa > Jazyky povoliť slovenský jazykový balíček, čo bude trvať dlhšiu dobu – SQL Server po tejto akcii začne pekne vyťažovať procesor.
9. Používatelia si môžu pomocou odkazu Nástroje na hlavnej lište zobraziť Možnosti a tam si na karte Jazyky zmeniť jazykovú mutáciu.

A už sa stačí len zabávať s CRM a zlepšovať si vzťahy so zákazníkmi :)

Pevne verím že EZKO nebude nepodarok a prístup administrátorov do systému bude vyriešený tak, že síce budú mať možnosť riešiť problémy v ňom, ale v žiadnom prípade nebudú môcť pristupovať k údajom o pacientoch.

netsh>interface
netsh interface>set interface ?
...
Examples:
      set interface name="Local Area Connection" newname="Connection 1"

netsh interface>set int name="Local Area Connection" newname="Contoso LAN"
An interface with this name is not registered with the router.

netsh>

Dosť nečakaná chyba An interface with this name is not registered with the router. prekazila moje plány na zmenu názvu tak som radšej rýchlo prešiel na nastavovanie IPv6 adries, aby som sa nezdržoval v takúto neskorú hodinu.

netsh interface ipv6>set add "Local Area Connection" fd00::2/64
The requested operation requires elevation (Run as administrator).

Príčina chyby bola hneď jasná: nie som administrátor a Windows 7. Pred chvíľou som nastavoval IPv6 adresu na Windows 2008 R2 Serveri kde tento príkaz zbehol v pohode. User Account Control je po nainštalovaní Windowsu zapnuté pre všetkých administrátorov okrem štandardného konta Administrator. Je tu ale rozdiel medzi serverovým a klientským Windowsom:

• Serverový OS: počas inštalácie nastavíte heslo a prihlasujete sa pod Administrator
• Klientský OS: počas inštalácie zadáte názov konta a heslo a prihlasujete sa pod ním

Príkazový riadok som samozrejme zabudol spustiť s administrátor­skými právami a bohužial vo Windowse normálne nie je príkaz sudo :( Spustenie novéhopríkazového riadku s riadnymi právami umožnilo používať netsh na konfiguráciu Windowsu a zmena mena adaptéru zbehla v pohode. Škoda len, že niekto v MS si nedal tú námahu naprogramovať do všetkých častí netshu, ktoré upravujú systém, kontrolu práv.

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

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.

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.

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.

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.