Digital signatures for binaries in open source projects

Digital signatures provides proof that the file was authored by a trusted entity. They allow to verify the integrity of applications distributed in binary form. On Windows, software authors use Authenticode to sign the application and its setup package so Windows can verify who made the application and it allows IT adminstrators to create policies for running only trusted applications.

Open source applications (for Windows) usually are not signed because the Authenticode certificates are expensive and the learning curve for signing is quite steap.

I chose Certum to get certificate for my open source applications. The Authenticode certificate from Certum costs only around 28 EUR. If you does not have any compatible smart card which would store the certificate private key, you can buy one from Certum, but this makes the certificate a bit expensive (for hobby purposes) – the smart card costs 80 EUR and shipping is 30 EUR.

Ordering the certificate from Certum was a bit complicated and painful process as their website likes to switch to Polish language out of a sudden. Authenticode certificates must be issued to natural persons (or legal entities) so the process is not automated (as with Let's Encrypt domain validation) and you must provide them your ID card and some utility bills or bank statement to verify you identity.

Out of the box, you can use the certificate to sign applications (EXE, DLL and MSI files) with signtool.exe using the default SHA1 algorithms. You must run the proCertum CardManager application so signtool.exe can communicate with the smart card when signing binaries. Each time you are signing a file, CardManager will ask for a PIN to the certificate.

Sign application

To sign application named VCardSplitter.exe using certificate named Open Source Developer, Jozef Izso, use this command:

signtool.exe sign /n "Open Source Developer, Jozef Izso" VCardSplitter.exe

This will just sign the file. You must also add the timestamp to the signature so the signature will remain valid even after certificate expires.

signtool.exe sign /n "Open Source Developer, Jozef Izso" /fd sha1 /t http://timestamp.verisign.com/scripts/timstamp.dll VCardSplitter.exe

Signing using SHA256 algorithm

Microsoft requires new applications to be signed using SHA256 algorithm. When you configure signtool.exe to use SHA256, you will receive error when signing files. To resolve this issue, open proCertum CardManager, click Options, enable EV Code Signing – replace CSP with minidriver library and click Ok. This will reconfigure the system and the SHA256 algorithms will work correctly. Note: the certificate for open source developers from Certum is not the EV (Extended Validation) certificate. It just hapens the CSP method of signing with smart card is only compatible with the old SHA1 signatures.

With minidriver mode enable, you can sign your binaries like this:

signtool.exe sign /n "Open Source Developer, Jozef Izso" /fd sha256 /tr http://timestamp.comodoca.com VCardSplitter.exe

Signing NuGet packages

NuGet 4.6 enables signing of nuget packages. It requires the signature to be SHA256 so make sure you enabled the minidriver mode. Signing is similar to the signtool.exe process:

nuget.exe sign library.1.0.0.nupkg -CertificateSubjectName "Open Source Developer, Jozef Izso" -Timestamper http://timestamp.comodoca.com

Switching the CSP and minidrive mode in proCertum CardManager

The proCertum CardManager uses special app called cryptoCardRegister.exe to switch between the CSP and minidriver modes of signing. This can be change from the proCertum CardManager user interface:

  1. Open proCertum CardManager application
  2. Click Options button
  3. Enable or disable the EV Code Signing – replace CSP with minidriver library checkbox
  4. Click Ok

If you have troubles with using the UI to change the mode, you can execute cryptoCardRegister.exe directly from command prompt.

To enable CSP mode manually, use administrative prompt to run:

"C:\Program Files (x86)\Certum\proCertum CardManager\cryptoCardRegister.exe" csp

To enable minidriver mode manually, use administrative prompt to run:

"C:\Program Files (x86)\Certum\proCertum CardManager\cryptoCardRegister.exe" md

Conclusion

Digital signatures can ensure your Windows binaries can be verified to come from trusted source. As open source developer, you must invest about 100–150 EUR to get the first certificate. The certificate from Certum will be issued to you as a natural person and it will be named Open Source Developer, <Your Name>. After correctly changing the CardManager configuration, you can sign you Windows applications, libraries, installation packages and also nuget packages. Signing cannot be automated as you must enter the PIN each time you sign a file. This prohibits scenarios like automatic signing of build output on continous integrations services like AppVeyor.

I hope code signing certificates will get more available to open source developers and projects and cloud services could be used to automate signing as part of the build process. This would make the ecosystem of open source libraries for Windows more trusted.

Google Tag Manager

Google Tag Manager je zaujímavý nástroj pre spravovanie rôznych analytických a marketingových JavaScriptových kódov. Priamo podporuje Google Analytics a Adwords a vďaka Custom HTML Tags si môžete zadefinovať HTML a JavaScript kód pre iné meracie systémy.

Do stránky vkladáte kód pre Google Tag Manager, ktorý následne stiahne ďalšie meracie kódy, napr. Google Analytics. Google Tag Manager je tak určený pre web stránky, ktoré potrebujú flexibilne meniť meriace kódy na stránkach, ale zmena stránky a jej aktualizácia by si vo firme vyžadovala zdĺhavú birokraciu. Pravidlá v Google Tag Manageri vám umožnia vložiť iné meracie kódy podľa URL adresy web stránky.

TimeCapsule 7.6.3

Jeden z najlepších routerov Time Capsule sa dočkal malej aktualizácie 7.6.3, ktorá zlepšuje možnosti nastavení pre Guest WiFi siete. Niektorí používatelia však reportujú problém s IPv6 tunnelingom s touto verziou, ktorý sa dá odstrániť downgradovaním na staršiu verziu firmware.

Osobne som si obľúbil Time Capsule vďaka jeho fenomenálnej rýchlosti WiFi siete a vstavanému 2TB diskovému priestoru, ktorý slúži ako skvelý záložný priestore pre Mac aj Windows.

Posted in IT

Prípad nefungujúceho Hamachi

Kamoš mal problém s Hamachi na Windows 7 – po nainštalovaní nefungovala Hamachi sieť a Hamachi zobrazovalo chybu „network adapter error“. Najprv som sa pokúšal zistiť, či je správne nastavený firewall a či Hamachi nevyžaduje administrátor­ské práva.

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 🙂

Posted in IT

Microsoft CRM 4

Skúšam si Microsoft CRM 4 pre svoju osobnú potrebu a aj pre školský projekt a samotná implementácia CRM nie je komplikovaná a šlo to aj bez implementačnej príručky. Beží to na Windows Serveri 2008 R2 so SQL Serverom 2008, zatiaľ bez podpory e-mailov a CRM mám v slovenskej lokalizácii. Základná testovacia prevádzka sa dá rozchodiť v pohode, ak dodržíte túto postupnosť:

  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 🙂

Posted in IT

Elektronická zdravotná karta občana a administrátori

Objavil som blog nášho učiteľa Informatickej bezpečnosti a spomenul tam veľmi dôležitý prípad v používaní (budúcej) Elektronickej zdravotnej karty občana (EZKO): lekári by mali mať prístup k EZKO – čo je legitímne pokiaľ je to teda ošetrujúci lekár pacienta, avšak veľkým problémom môžu byť správcovia, ktorí budú udržiavať počítače a softvér u lekárov. Často sú informačné systémy navrhnuté tak, že správcovia majú prístup všade – aj k faktúram na ekonomickom oddelení, aj k návrhom zmlúv z marketingu a tak podobne.

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.

Posted in IT

Netsh: An interface with this name is not registered with the router.

Čítam si knižku Configuring Windows Server 2008 Network Infrastructure a učím sa používať príkaz netsh na správu sieťových rozhraní vo Windowse. Po veľmi dlhej dobe som konečne našiel príkaz ktorým sa dá zmeniť názov sieťového pripojenia. Tie štandardné názvy sú príliš dlhé: Local Area Connection a v laboch preferujem mať popisné názvy ako WAN pre pripojenie do internetu na serveri a Contoso LAN na lokálnych sieťových adaptéroch. Doteraz som to menil len cez Explorera, avšak už môžem zvýšiť svoju produktivitu vďaka netsh:

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.

Posted in IT

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.