Patrice Manac'h Web Log : Vista

Survivre à un écran bleu avec BitLocker

pmanach — Wed, 11 Mar 2009 14:20:27 GMT

J’ai un disque qui est crypté avec BitLocker (politique d’entreprise). Lorsque j’ai procédé au cryptage, parmi les options disponibles, j’ai choisi de sauvegarder la clé de secours sur un disque connecté en usb (le disque que j’utilise pour faire mes sauvegardes). Grossière erreur :(

En effet, récemment, en arrivant au bureau, j’ai eu un joli écran bleu lors de l’ouverture de session (registry error). Je me dis, pas de problème, je boote en mode sans échec, je trouve quel service ou driver pose problème, je répare, et hop, plus de problème. Donc, je redémarre le poste, et comme il détecte qu’il s’est crashé, il me propose la liste des options de récupération. Je choisi “Mode sans échec” et là, j’ai un joli message qui m’indique que le disque étant crypté, il me faut fournir la clé de secours pour pouvoir démarrer dans l’un des modes sans échec. Clé qui est bien sur chez moi, à 60 km de là.

j’ai réussi à m’en sortir avec pas mal de chance. Comme le plantage avait lieu lors de l’ouverture d’une session de domaine, j’ai parié sur le fait que cela devait être lié au démarrage d’un service, et que si j’arrivais à ouvrir “très vite” une session, j’aurais peut être le temps d’intervenir. J’ai donc bouté en mode normal, ouvert une session avec un compte local à la machine, et j’ai eu alors le temps de désactiver le cryptage du disque. Au redémarrage suivant, j’ai alors pu ouvrir en mode sans échec, et dans ce mode, j’ai restauré un point de restauration précédent.

Après cette restauration, le poste était effectivement réparé, et j’ai alors pu remettre le cryptage en place.

Moralité : sauvegardez votre clé de façon à ce qu’elle soit toujours facilement accessible (votre webmail par exemple). Et vive les points de restauration :)

Drivers ATI et Vista 64

pmanach — Sun, 25 Jan 2009 12:06:54 GMT

J’ai voulu installé les derniers drivers ATI, mais au lancement de l’outil, ce dernier s’est crashé bien comme il faut :

Avant de passer à la suite, une mise en garde s’impose. A moins que vous n’ayez un problème (bug) censé être corrigé dans une version récente des drivers, ou que vous utilisiez un jeu ou un outil dont les performances sont explicitement améliorées par la mise à jour, remplacer vos drivers comporte plus de risque de se retrouver avec une machine bancale qu’autre chose. Et les manipulations suivantes étant un peu hardcore, si vous avez le moindre doute, ne tentez rien…

Si vous êtes encore là…

En recherchant sur le .Net, j’ai constaté que le problème était assez commun et provenait du fait que l’outil était lié à une version spécifique de librairies systèmes, pas forcément présente sur la machine. Parmi les différentes solutions, dont installer des hotfix, une a retenu mon attention : modifier manuellement la dépendance. Elle est un peu plus complexe mais ne nécessite aucune modification du système…

Pour commencer, lancez l’installation. Elle va se planter et vous laisser un répertoire C:\ATI\SUPPORT\8-12_vista64_dd_72276\Bin64 (certains numéros peuvent changer).

Chez certains personnes, la modification des fichiers manifest semble ne pas être nécessaire. Vous pouvez tester directement l’étape suivante et revenir ici en cas d’échec persistant.

Dans ce répertoire, il va falloir modifier tous les fichiers MANIFEST (7 en tout). Avant de procéder aux modifications, commencez par rechercher quelles versions des dll sont présentes sur votre machine. Pour cela, faîtes une recherche sur le répertoire Windows des tous les fichiers contenant dans le nom Microsoft.VC80 :

Ici, j’ai recherché une version commune pour les quatre fichiers référencés (ATL, CRT, MFC et MFCLOC). J’ai retenu la 8.0.50727.1833. Le résultat pourrait être différent chez vous…

Ensuite, j’ai modifié tous les fichiers pour qu’ils référencient cette version. Par exemple, le contenu du fichier Microsoft.VC80.ATL.manifest devient :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <noInheritable/>
    <assemblyIdentity
        type="win32"
        name="Microsoft.VC80.ATL"
        version="8.0.50727.1833"
        processorArchitecture="amd64"
        publicKeyToken="1fc8b3b9a1e18e3b"
    />
    <file name="ATL80.dll"/>
</assembly>

Une fois les sept fichiers modifiés, lancez une ligne de commande en mode Administrateur :

Et allez dans le répertoire “C:\ATI\SUPPORT\8-12_vista64_dd_72276\Bin64”. Lancez la commande “ATISetup.exe –UNINSTALL –OUTPUT SCREEN” si vous avez déjà des drivers ATI. Et rebootez (l’outil doit supprimer des fichiers en cours d’utilisation, il a vraiment besoin de ce reboot). N’essayez pas d’enchaîner avec la commande suivante, si vous ne rebooter pas, il faudra recommencer de toute façon.

Au reboot, attention aux yeux, c’est en mode VGA 800x600 que cela repart. Ouvrez la session, relancez une ligne de commande en mode administrateur et lancez “ATISetup.exe –INSTALL –OUTPUT SCREEN”. Après un dernier reboot, voila vos drivers à jour.

Vous pouvez maintenant installer le centre de contrôle. Cette fois, pas besoin de modifier les fichiers manifest. Une fois le programme décompressé (oui, il plante aussi), ouvrez une ligne de commande en mode Administrateur, allez dans “C:\ATI\SUPPORT\8-12_vista32-64_ccc_lang2_72277\Bin64” et lancez “ATISetup.exe –INSTALL –OUTPUT SCREEN”.

Quand à l’installation de l’utilitaire HydraVision, je vous laisse deviner ce qu’il faut faire :)

Il faudra que je creuse à l’occasion pour comprendre pourquoi ATI livre ses utilitaires d’installation en les liant à une version spécifique de librairies C++…

CanonScan Toolbox et Vista 64

pmanach — Sat, 17 Jan 2009 12:12:00 GMT

En voulant installer ce programme sur mon poste, je me suis retrouvé avec un message d'erreur de source e Twain invalide. C'est d'autant plus vexant que via d'autres programmes, le scanner marchait parfaitement bien (par WIA, je suppose). Ce n'est pas qu'il me serve souvent, mais je n'aime pas avoir un programme qui ne fonctionne pas sur mon poste :)

Donc, petite rercherche sur le site de Canon France, je récupère la dernière version des logiciels SanGear et Toolbox, je réinstalle, reboote, et pas mieux. Quand j'ouvre le panneau de configuration de Toolbox, aucun scanner listé. Plutôt rageant.

Allez, une petite recherche Internet, et là, je tombe sur différents posts : twain ne fonctionne pas en mode 64 bits, il faut formater le disque système en fat32, etc En bref, rien de pertinent, et je reste poli au vu de certaines suggestions...

A tout hasard, je vais sur le site de Canon US, et là, surprise, dans les drivers, un joli lien Twain Driver Vista 64. Ok, je télécharge les versions us du drivers et de toolbox, ainsi que l'utilitaire deldrv, pour nettoyer l'existant. Je réinstalle tout, je reboote, je lance Toolbox, le scanner est bien listé (joie), je lance un scan, et là, échec : unable to open Twain source.

Nouvelle recherche sur le web et cette fois, c'est plus concluant : il faut en fait rajouter le chemin du pilote Twain dans le path de la machine. En pratique, faîtes propriétés de l'ordinateur, paramètres systèmes avancés, variables d'envirronements (le bouton en bas de la boite de dialogue). Dans les variables systèmes, choisissez Path, Modifier, et ajouter à la fin ";%SYSTEMROOT%\twain_32\CNQ9950". Pensez à changer la dernière partie par le nom du répertoire contenant les drivers de votre scanner dans c:\windows\twain_32 (il peut y avoir plusieurs répertoires si vous avez aussi une webcam ou un appareil photo numérique). Fermer toutes les fenêtres que vous venez d'ouvrir et relancer Toolbox (pour qu'il prenne en compte la modification). Et là, enfin, tout marche :)

Ouf, mais c'était bien compliqué pour un utilitaire comme celui là. Il est dommage que l'outil installant le driver ne fasse pas automatiquement cette modification du path...

Bon scan en 64 bits :)

Canon 20D et Vista

pmanach — Mon, 07 Jul 2008 09:13:00 GMT

J'ai eu récement à connecté un Canon 20D par USB à un portable sous Vista pour récupérer des photos. Et le résultat fut de prime abord assez frustrant : l'appareil n'apparaissait pas dans l'explorateur, et n'ayant pas de lecteur de cartes ou les CD de drivers de l'appareil, les photos me semblaient hors d'atteinte :(

Et autant dire que des recherches rapides sur Internet n'étaient guère encourageante : l'utilitaire EOS Utility y était souvent décrit comme le passage obligé pour regler le problème, mais ce dernier n'était pas présent sur le site du contructeur...

Mais une dernière recherche a fini par porter ses fruits : le menu du 20D propose une option Communication qui par défaut est réglée sur "Normal" mais peut prendre aussi la valeur "PTP". Or Vista communique avec les appareils photos via ce protocole. J'ai donc changé l'option et là, miracle : l'appareil était devenu visible dans l'explorateur. Seul "souci" restant : la carte était vue comme pleine, alors que ce n'était pas le cas. Mais comme tout le reste a fonctionné normalement, ce n'était pas vraiment génant.

Dernier point : j'ai testé la connection aussi avec un portable sous Windows Server 64 bits, et cela a aussi fonctionné du premier coup. Cela devrait donc marcher avec toutes les déclinaisons de Vista :)

Visual Studio 2003, Vista et les Custom Actions

pmanach — Mon, 31 Dec 2007 15:53:00 GMT

toujours dans mes tests de compatibilité du Framework .Net 1.1 avec Vista (version 64 bits, qui plus est), je suis passé aux tests de projets de type setup. Je sais que VS2003 n'est pas supporté sous Vista, mais il faut parfois s'assurer que certains scénarios continuent de fonctionner. Et en l'occurence, le msi produit par VS ne devrait pas avoir de dépendance particulière à l'OS. Sauf que si :(

Je ne parle pas d'une condition triviale dans le projet setup qui testerait que l'os est un XP (version 5.1) au lieu de tester toute version supérieure ou égale à 5.1 pour embarquer les versions 6 et plus dans la foulée. Pour cela, si on a encore le projet, on peut changer le test. Et dans le cas contraire, on peut essayer de jouer avec les modes de compatiblités. Mais dans mon cas de figure, rien de tout cela : lors de l'installation de mon service via le msi généré, je me suis retrouvé avec un échec systématique et un erreur 11708 dans le journal d'événement sans information exploitable. Et l'indice de fiabilité de mon poste dégringolant à toute vitesse :(

En fouillant un peu, je suis tombé sur l'article suivant : http://arnshea.spaces.live.com/blog/cns!32B8884142441255!220.entry

Il semble en fait que dans le msi généré par VS 2003, un flag d'impersonification soit mal positionné au niveau des actions personalisées, ce qui passe sans problème sous XP ou 2003, mais se fait toper par l'UAC sous Vista. A priori, ce problème concernairait aussi les msi généré par Visual Studio 2005 RTM. N'ayant plus que des versions SP1+Vista fix, je n'ai pas pu faire le test. Par contre, j'ai testé les configurations suivantes :

Intégration du manifest dans l'exécutable puis génération du MSI avec VS 2003. Contrairement à ce que laisse entendre l'article, il y a moyen d'automatiser l'opération (cf ThemeMe sur http://www.msjogren.net/dotnet/eng/tools/). Mais pas moyen de passer la protection DEP sous Vista 64 bits. Je suppose donc que cela doit marcher avec un Vista 32 bits mais comme j'ai besoin de toutes les configurations, cela ne me convient pas.
Génération du msi avec un VS 2005+SP1+Vista fix (j'ai un doute sur l'utilité réelle de ce fix pour ce problème spécifique, mais passons). Victoire (de courte durée), le service s'installe bien sous Vista 64, les custom actions sont lancées (elles démarrent le service), et la désinstallation marche bien. Oui mais sur un XP 32 bits sans le Framework 2.0, une agaçante popup apparaît au lancement du msi :(
Idem que précédement mais en modifiant la condition pour demander une v1.1 du Framework (avec ou sans support d'une version ultérieure). Cela marche bien sur mon XP, mais plante sur mon Vista. Grrr....

Bon, je suppose que dans le dernier cas, en jouant avec Orca, on doit pouvoir faire sauter la dépendance, mais comme ce n'est pas automatisable, cela ne m'interesse pas. Autre solution, produire deux setup, un pour chaque plateforme. Les outils de télédistribution savent en général cibler des packages en fonction de variables comme l'OS, ce serait jouable. Mais cela ne me plaisait pas non plus.

Dernière solution, utiliser Wix. Cela ne m'enchantait pas trop car cela me semblait un peu "lourd". Mais comme on va l'intégrer à la prochaine version de VS, ce pouvait être l'occasion d'y jeter enfin un coup d'oeil. Et c'était en fait un bel à priori :

Je suis allé sur le site http://wix.sourceforge.net/index.html récupérer le package (la V2).
Je suis parti de l'exemple SampleFirst que j'ai testé tel quel
Puis je l'ai modifié pour référencer mon service, être par défaut en français (valeur 1036 pour les tag Langages) et cibler la plateforme x86 (tag Platforms='Intel' sur le noeud package).
Et voila :)

Pour référencer le service, j'ai ajouté le composant suivant :

<Component Id='MainService' Guid='04C7E6DD-A2C6-40B6-9069-083DC4A4BD2F'>

<File Id='service1.exe' Name='service1.exe' LongName='service1.exe' src='service1.exe'

DiskId='1' />

<ServiceInstall Id='service1.exe' Name='Service1' DisplayName='Service1'

Type='ownProcess' Interactive='no' Start='auto' Vital='yes' ErrorControl='normal' />

<ServiceControl Id='service1.exe' Name='Service1' Start='install' Stop='both' Remove='uninstall'

Wait='yes' />

<Registry Id='Service1InstallDir' Root='HKLM' Key='Software\Company\Service1'

Name='InstallDir' Action='write' Type='string' Value='[INSTALLDIR]' />

</Component>

avec en bonus pour mon test l'écriture d'une clé de registre. Au final :

Cela fonctionne bien sous XP 32 bits et Vista 64 bits.
Plus de message d'alerte sur une dépendance à une version du Framework.
Les custom actions ne servent plus à rien, le démarrage ou l'arrêt du service sont pris en charge par le msi généré par Wix.
Et donc, lors d'une désinstallation, plus de message d'alerte indiquant que certaines applications tournent encore et peuvent nécessiter un reboot.
Les binaires et clés de registre vont bien au bon endroit (dans HKLM\Software ou HKLM\Software\Wow6432Node pour les clés de registres par exemple).
En suivant le tutoriel et les exemples fournit sur le site de Wix, on a une solution qui marche en à peu près une heure. Ok, pour des tests complémentaires, des interfaces riches et ce genre de chose, c'est peut être plus couteux. Mais cela, ce ser pour une autre fois :)

Bon, le besoin de déployer du .Net 1.1 sur plusieurs plate-formes ne doit pas être très courant mais si cela peut éviter quelques galères et heures perdues inutilement...

Applications 32 bits et registre 64 bits, quelques points à savoir avant de s'arracher les cheveux

pmanach — Sat, 29 Dec 2007 13:45:00 GMT

J’étais tranquillement en train de tester une application .Net 1.1 sur un Vista 64 bits quand je suis tombé sur un point bloquant : mon application ne pouvait lire des clés dans la base de registre, clés que j’avais créé à la main avec regedit. Plutôt surpris, j’ai relancé regedit et vérifié : mes clés étaient bien là.

Un petit test rapide du bout de code incriminé avec Visual Studio 2005 : le même code arrive bien à lire les clés. Après avoir éliminé assez rapidement les questions de sécurité et de droits, j’en suis venu à me demander si ce n’était pas un problème de plate-forme. J’ai alors forcé la compilation de mon bout de code en mode x86 sous VS2005, et là, bingo : les clés n’étaient plus visible. Après quelques tests de confirmation (x86, x64, AnyCPU), cela s’est confirmé.

Après quelques recherches, je suis tombé sur ce post très intéressant : http://207.46.236.188/MSDN/ShowPost.aspx?PostID=2428227&SiteID=1

En particulier :

The rules are pretty straightforward:

.NET app compiled for "x86":

Always 32-bit

On 32-bit platforms, accesses 32-bit registry

On 64-bit platforms, accesses 32-bit registry (inside Wow6432Node)

64-bit registry inaccessible (without doing something weird)

.NET app compiled for "x64":

Always 64 bit

On 32-bit platforms, won't run

On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)

If you want to get to the 32-bit registry, you need to do something weird

.NET app compiled for "AnyCpu"

Either 32 or 64 bit depending on platform

On 32-bit platforms, accesses 32-bit registry

On 64-bit platforms, accesses 64-bit registry (not inside Wow6432Node)

If you want to get to the 32-bit registry, you need to do something weird

"Something weird" technically requires passing a special flag to RegOpenKeyEx to obtain the alternate registry view. .NET doesn't expose any function that will do this nicely, so you'd have to drop to p/invoke to get there.

Alternatively if you want to get to the 32-bit registry from a 64-bit/AnyCpu app, you can hardcode the "Wow6432Node" path in (since the 32 bit registry is visible from 64 bit, but not the reverse), but MS explicitly recommends against this.

En fait, l'utilisation de la fonction ReOpenKeyEx nécessite effectivement de faire du p/invoke en utilisant l'option KEY_WOW64_32KEY (0x200), voir http://msdn2.microsoft.com/en-us/library/ms724878.aspx. Et il faut repasser cette option à chaque ouverture de sous-clé, l'api repassant systématiquement en mode par défaut quelque soit le handle passé en paramètre.

Le second cas marche aussi très bien en pratique, évite de faire appel à du p/invoke mais le fonctionnement n'est pas garanti à terme. L'idéal reste quand même d'avoir un setup qui cible la même plate-forme que l'application qu'elle installe (donc x86 si l'application a une dépendance à cette plate-forme, comme l'utilisation de SQL Ce 3.1) : les clés seront alors automatiquement créées sous le noeud Wow6432Node et visibles par l'application comme étant directement sous HKLM\Software. Ce faisant, que l'application soient déployées sur un XP 32 bits, ou sur un Vista 32 ou 64 bits, il n'y a aucune "bidouille" à faire. Et lors des tests manuels, pendand le dev par exemple, il faut juste ne pas oublier de créer les clés sous HKLM\Software\Wow6432Node sous peine de se poser beaucoup de questions :)

Publication ClickOnce avec Vista

pmanach — Tue, 05 Dec 2006 23:38:00 GMT

Si vous cherchez à tester la fonction de publication de VS 2005 avec Vista, par d"faut, vous allez vous prendre des erreurs de sécurité et une erreur de librairie CAPICOM qui n'existe pas. Pour les erreurs de sécurité, il suffit de lancer VS en mode admin mais pour CAPICOM c'est un peu plus compliqué :

installez le SDK Windows.
Allez dans C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin.
lancez regsvr32 capicom.dll

Bon, ce n'était pas si compliqué que cela :)

Booster Vista sur son portable

pmanach — Sun, 12 Nov 2006 20:03:00 GMT

J'ai en ce moment une machine dont le point faible est clairement le disuqe dur. Je ne l'ai pas encore démonté mais je ne serais pas surpris que ce soit un 4K tours/mn. Ce qui pour un poste de dev (Studio, SQL, VPC, etc) fait mal :(

La gestion de la priorité des IO dans Vista rendait la chose nettement plus utilisable que XP (ou tout autre OS par ailleurs), mais cela restait pénible. Jusqu'à ce que ce week-end, je teste sur un coup de tête l'insertion d'une sd card dans le port interne du portable. Vista m'a alors automatiquement proposé de l'utiliser en mode ReadyBoost, ce que j'ai accepté en octroyant le maximum possible (980 Mo pour une clé d'un Go). Et la différence est vraiment flagrante !

Ce n'est pas que ce portable soit à genoux en CPU (Centrino 1.8 GHz) ou en mémoire (2 Go) : la CPU est rarement au taquet et la mémoire physique utilisée tourne entre 50 % et 100% selon que j'utilise ou pas des VPCs. Mais voila : il y avait en permanence un sentiment de lenteur inexpliquable.

Je me rends compte à postériori que le disque dur était vraiment le point faible de la configuration. Je vais essayer de le remplacer par un 7K2. Et la technologie ReadyBoost m'a en fait permis de dépasser ce problème : une bonne partie des IO qui pénalisait l'OS se fait maintenant sur la SD Card et l'accès disque est ce faisant "réservé" aux vrais besoins. C'est comme si j'avais fait un upgrade de mémoire. Pour un coup incomparable sur un portable : 2 Go de mémoire sur un portable coutent plusieurs centaines d'euros alors qu'une SD Card 1 Go rapide ou un clé 1 Go USB2 rapide tournent dans les 50 € (ReadyBoost compressant les données, la comparaison n'est pas déraisonnable).

Si vous avez un portable avec un port SD interne, faîtes le test avant d'investir, mais le résultat pourraît agréablement vous surprendre :)

Visual Studio US, Vista FR et les extensions pour .Net 3.0

pmanach — Sun, 05 Nov 2006 22:07:00 GMT

Je sais que je cherche un peu les coups à vouloir faire fonctionner ensemble des logiciels beta dans des langues différentes mais pour l'instant, je m'en étais plutôt pas mal tiré. J'ai récement reconfiguré mon poste avec une version récente de Vista en français, j'ai installé Visual Studio en anglais et j'ai installé les extensions pour le Framework 3.0 (Cider, etc). Et là, la mauvaise surprise : en voulant créer un nouveau projet, je n'avais plus le choix que de créer un projet .Net 3.0 (WPF, WF, etc). Mais plus de projet librairie ou console. Hors, avant d'installer les extensions pour le Framework 3.0, j'avais eu l'occasion de constater que cela marchait.

En creusant, je me suis rendu compte que les projets "classiques" étaient tous localisés (dans un répertoire dédié au code pays, ici le 1033) alors que les projets .Net 3.0 étaient dans des répertoires ne dépendant pas de la langue. J'ignore en quoi l'installation des extensions modifie le comportement standard de devenv mais le fait est qu'après, Studio ne permettaient plus que la création de projet non localisés (voir localisées en français mais je n'ai pas creusé).

J'ai trouvé plusieurs solutions basées sur la recopie de fichiers dans des répertoires indépendant de la langue, dans un répertoire correspondant au français ou autre, mais la méthode la plus propre reste de lancer Visual Studio avec un paramètre permettant de fixer la langue : devenv.exe /LCID 1033

Une fois le raccourci modifié, je peux de nouveau charger VS avec tous les projets standards et les projets spécifiques au Framework 3.0...

Support d’APS .Net 1.1 sous Vista

pmanach — Mon, 05 Jun 2006 13:37:00 GMT

Question récurrente s’il en est…

Je suis tombé sur cet article sur le site www.asp.net : http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=993

Ce nouveau site a l’air d’être une vrai mine d’or