Reprise du message précédent :

Salut, merci pour ton message. J'avais effectivement déjà ouvert TrueCrypt et coché les cases qui vont bien. J'ai le fichier de config. Par contreva savoir si ce qu'il contient est bon...
La documentation, je devrais pouvoir la retrouver au bureau si ça t'intéresse. Je regarderai pourquoi j'ai mis ces arguments

Ok le fichier existe, donc autre cause.
Comme on parle de démontage automatique qui ne se fait pas, je présume que TC est installé et pas en version mobile.
Win10.
Ca te le fait sur un seul PC ou sur plusieurs ?
L'utilisateur est-il admin ?
As-tu des programmes installés dans le conteneur ou juste des documents ?
 
Au fait tes conteneurs sont sans mot de passe ?
Je ne vois pas le /p.
 
Tes conteneur sont-ils dans la liste des favoris ?
Fait des tests sans le /a
 
Autre "solution" un script de fermeture de session avec /q /s pour forcer la fermeture des conteneurs.

merci pour ta réponse !
mes réponses dans ton texte :

Mon script lancé via gpedit.msc :

J'ai même rajouté une ligne pour supprimer un fichier simple sur mon bureau. Après redémarrage le fichier a disparu, mais les conteneurs sont toujours là...

Le /p est justement pour mettre le mot de passe.
Dans TC en version "graphique" tu peux gérer une liste de conteneur favoris.
Il n'y a que des documents donc pas de programmes restant lancé et qui bloquerait la fermeture du conteneur.
Valable aussi pour les documents : tous doivent être fermés sauf si la fermeture est forcée avec /s.
 
Quel est ton script de fermeture ?

Et si c'était un bug de Win10 ?
Pourrais-tu tester avec un pc sous Win7/8.1 ?

Et si c'était justement le genre de bug dont VeraCrypt, maintenu et plus récent, tient compte et TC pas du tout ?
Enfin je dis ça je dis rien

mon script de fermeture est celui 3 posts plus haut, lancé avec gpedit :

je vais tester avec /s pour forcer la fermeture des documents (même si en général je ferme tout avant d'éteindre)
 

Quand j'étais sous win7, aucun soucis. J'ai testé avec plusieurs PCs win10, installés de manières différentes (mise à jour, natif, pro et home...)
 

Peut être... mais suis-je le seul à utiliser TC sous win10 ici ?  

Et pour ceux que ça intéresse, voilà le guide utilisateur de TrueCrypt 7.1a : https://we.tl/7fAJbBaPFS

Merci pour le manuel, j'avais oublié de le récupérer à l'époque.
Mais la documentation en ligne était mieux maintenue, je me rappel une partie sur les header et la structure d'un conteneur (octets 0 à 3 pour x octets 4 à 8 pour y ...) qui semble absent du manuel.
 
 
En effet totalrecall tu as absolument raison avec ta proposition.
Il est probable que TC ait quelques bug avec Win10 que VC à corrigés.
 
Cyril13, désolé j'avais pas compris que c'était ton script de fermeture.
Non, je ne suis pas encore sous win10 sur mes pc utilisant TC.

ce qui est bizarre c'est que le script de fermeture ne fonctionne qu'à moitié (quand je mets une ligne del ctoto.txt après la ligne TC, le fichier est bien supprimé, sine que la commande TC est bien lancée, mais sans effet.. et surtout que ce soit aléatoire, une fois oui, une fois non, sans raison aucune)

si tu essai de mettre le chemin complet de tc plutot qu'un appel à tc directement ?

genre :
cd c:\
cd program files
cd truecrypt
truecrypt param

ou alors c:\program\tc\truecrypt param

le batch est directement dans le dossier TC, et lorsque je clique sur l'icône, le batch fonctionne bien. C'est lorsque je lance le batch (le même) depuis gpedit que ça ne fonctionne qu'à moitié.. donc je ne pense pas que les CD c:... change vraiment la donne

essai toujours..

autant gpedit lance le batch depuis la racine..

ta pas de log ?

edit : le batch a les bonnes autorisations ?

alors, je viens d'essayer sans redémarrer, juste en lancant le batch :
C:\Program Files\TrueCrypt\truecrypt.exe /d /q /f
-> ne fonctionne pas.
 
C:\Program Files\TrueCrypt\truecrypt /d /q /f
-> idem
 
cd C:\Program Files\TrueCrypt
truecrypt /d /q /f
-> Fonctionne en lançant le batch depuis le bureau (mais revient au même que de le lancer depuis le dossier TC, sans la première ligne)
 

C'est pas faut, si c'est par gpedit il peu y avoir des différences de droits.

N'aurais-tu pas oublié des "" dans ton script ?
 
"C:\Program Files\TrueCrypt\truecrypt.exe" /d /q /f
 
A cause de l'espace dans "program files"

non pas de log (ou je ne sais pas où le trouver)
gpedit lance le batch depuis un dossier au choix ("parcourir" permet de choisir le dossier qu'on veut) mais de base propose "C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown"

Je vais tester de mettre le batch dans ce dossier pour voir

effectivement ça fonctionne.
 
mais bon, ça fonctionne aussi très bien depuis le répertoire directement avec la commande truecrypt /d /q /f..... donc je doute que cela vienne de la commande mais je vais tester

je viens de comprendre ta remarque !
mes conteneurs ont un mot de passe, mais je le rentre à la main, lorsque la commande est lancée, une fenêtre TC apparaît pour que je saisisse mon mot de passe.
Je ne vais pas le mettre en clair dans le batch, ce serait une grosse faille

le /m est pour les options de montage /m + rm permet de monter le volume considéré comme media amovible.
je monte les 2 conteneurs de façon différente pour voir si cela affecte le démontage à la fermeture de windows... et non, ça ne change rien
ils sont tous les deux démontés ou montés au démarrage, jamais un seul.

Pour le /p tu peux le mettre sans mettre le mot de passe en clair dans le batch.
Ton batch te demande le mot de passe que tu passe en argument via une variable.
 
Ton test de faire varier les arguments envoyé à TC pour monter ou démonter différemment les volumes est intéressants.
Pour moi il indique que cela ne vient pas des arguments donnés à TC ou du script.
Mais bel est bien de TC lui même.
Donc soit un bug de compatibilité avec Win10, soit une option dans le fichier de configuration de TC qui est dans le profil.
Mais laquelle ?
Il faudrait ouvrir l'interface graphique, regarder/modifier les options relatif au montage/démontage et voir.
Tester avec un pc sous Win7 aiderait à savoir si c'est un bug de compatibilité (et donc dans ce cas wouhalou pour TC) et donc tester VeraCrypt ou pas.

en fait j'utilise les même batch que j'utilisais avant de migrer de windows 7 à windows 10. donc le bug ne vient pas de la commande.
le batch fonctionne en le lançant à la main : donc le bug ne vient pas de la commande
seule solution qui me vient à l'esprit : la commande lancée par gpedit est lancée trop tard, à un stade de fermeture de windows auquel truecrypt ne peut plus être lancé et exécuter la commande de démontage des conteneurs. Ce serait possible ??
 
Reste l'aspect aléatoire, qui me dépasse un peu (beaucoup)

Sous 7 tout est ok ?
Donc c'est bien un pb entre Win10 et TC.
Il y a de belles différences sous les capots de Win7 et Win10 je le vois sur mes ordinateurs à la rapidité d'ouverture et fermeture.
Il ne serait pas étonnant que certaines optimisation changent l'ordre d'arrêt de process ou que certains process qui avant s'arrêtaient dans un certain ordre se fassent maintenant en parallèle (et donc un aléa en fonction des temps d'accès mémoire, du réagencement fait par le proc etc etc...) entrainant un problème avec l'arrêt de TC propre qui peut alors faire appel à des process qui sont alors un coup stoppé un coup encore présents.

Ton batch est lancé en fermeture de session ou en arrêt de l'ordi ?
Il faudrait le lancer en fermeture de session et non d'ordi.

sous win7 je n'avais même pas à lancer de batch à la fermeture de windows, les conteneurs se fermaient automatiquement avec windows.
Cela dit, lancé à la main le batch fonctionnait quand même, mais je m'en servait que très peu vu que le démontage était automatique.
 

En arrêt de windows.
 
Pour l'instant je teste en mettant le batch dans le dossier "C:\Windows\System32\GroupPolicy\Machine\Scripts\Shutdown", voir si ça joue.
Ensuite, et surtout si ça ne fonctionne pas, je testerai de lancer ça en fermeture de session à la place.
 
D'ailleurs, dans gpedit, les scripts lancés à l'arrêt ou démarrage de windows se paramètrent à partir de l'onglet "configuration ordinateur";
Pour la fermeture de session c'est "configuration utilisateur".
Si on est plusieurs utilisateurs sur le PC, faut-il faire ça pour chaque utilisateur ou c'est global et à chaque fermeture de session ?
 
Dernière question, est-ce que la mise en veille est considérée comme fermeture de session ?
(et du coup faudrait faire gaffe à ne pas laisser de doc ouvert à la mise en veille)

et si tu le mets au démarrage ça marche ? plutôt qu'à l'arrêt

Je vais tester. Mais d'un point de vue sécurité, je préfèrerai que ce soit fermé à l'extinction plutôt qu'au démarrage... mais je vais tester !

C'est juste pour tester, si ça marche pas je dirais que les droits sont pas les bons..

je ne vois pas pourquoi ce serait une question de droits, vu que je n'ai qu'un seul compte sur le PC de test, que ce compte est admin et que lorsque je lance le batch, il ne me demande aucun mot de passe ni confirmation de droits d'admin..

entre toi qui le lance et le système y'as peut-etre une différence non ?
 
je lance des trucs complètement au hasard pour essayer de trouver hein

Bah théoriquement système est sensé avoir plus de droits qu'admin.

Impossible de monter un (autre) volume système durant le boot (même pass)?

Durant le boot ?
Via un script au démarrage de l'ordi ou via les tâches planifiée oui, mais pas directement "au boot".
Je fais la différence entre les script de démarrage et les scripts d'ouverture de session.

Bon! Je suis dans la merde (1ère).. C'est incompréhensible : J'étais en train de déchiffrer un Windows (se trouvant sur HD2), je reboot sur HD1 (mon système principal, chiffré) et là.. "Missing Operating System" Je reboot sur le HD2 et teste le montage de la partition : pas de soucis. Je met son "Rescue Disk" sur un clé usb et reboot dessus, et là.. Incorrect password Dans le doute (après avoir testé tout mes pass), j'installe un autre Rescue Disk et incorrect password à nouveau!! Alors que j'utilise ce même pass sur les deux.. Help please Pour info, le déchiffrage du système sur HD2 c'est bien passé et je boot dessus sans soucis..

EDIT: Je viens de tester les autres Rescue Disk sur leur machine respective et j'ai droit à la même erreur partout.. WTF?!

Ce n'est pas parce-que tu utilise le même mot de passe partout que la clef de chiffrement est la même partout.
 
La clef de chiffrement est réalisée lors de la création du volume elle est sensée être unique même avec des mots de passe identiques.
Ensuite cette clef est chiffrée avec le mot de passe.
Cela permet de changer le mot de passe sans avoir à déchiffrer et rechiffrer tout le volume mais seulement quelques champs de l'en-tête.
Je pense que tu le savais mais il est bon de le rappeler.
Cela à l'avantage de pouvoir garder un "passe de sécurité" en cas de changement de mot de passe par l'utilisateur tu ressort la sauvegarde de l'entête et tu écrase son mot de passe par celui sauvegardé.
 
Ce que je ne comprend pas c'est ton déchiffrement.
Déjà de mémoire si le chiffrement d'un système Windows se fait depuis ce Windows, pour le déchiffrer il faut le faire depuis le rescue CD.
On pourrait suppose un mélange entre les HDD mais normalement l'opération se fait après vérification du mot de passe et donc de la clef.
 
 
Je commence en fait à me dire que c'est peut-être un problème de boot et de mbr.
 
Je voudrai savoir, quand cela fonctionnait, comment tu passait de l'un à l'autre de tes systèmes.
Test disques sont-ils dans des rack ?
Tu changeais l'ordre de boot dans le bios ?
 
Je crains en fait que ton ordi bootait tout le temps sur le même hdd pour accéder au mbr et qu'ensuite il était redirigé vers l'autre hdd en cas de besoin via un menu type grub.
Et donc lors du déchiffrement du premier le mbr est changé et il a "perdu" le lien vers le second hdd.
 
Je prcise que cela peut être le mbr ou le secteur de boot dnt l'adresse est dans le mbr.
voir http://www.futura-sciences.com/mag [...] -mbr-5167/

Je change via F12 lors du démarrage, donc il n'y a pas de redirection entre hd1 et hd2. Par contre lors du déchiffrage du hd2 (on fait bien ça dans windows "permanently decrypt system..." ), une fois finit, lors du reboot pour changer le mbr, il a du booter sur le hd1 et c'est Peut-être ça le soucis (parceque bon, au final le hd2 est bien déchiffré et boot normalement.. Ça n'explique par contre pas le bon fonctionnement des rescue disk.. Que faire maintenant? Je dois récupérer ce mbr..

Toujours débrancher les autres hdd quand on fait des manipulations de chiffrement, clonage, formatage, gestion des partitions, installation d'OS...
 
Ton hd2 est déchiffré et boot normalement.
Ton hd1 est toujours chiffré et ne boot plus.
Mais est-ce que tu peut le monter et voir son contenu depuis hd2 ?
Si oui alors fait une copie/image du contenu (je te conseille drive image xml).
Ensuite tente de déchiffrer ton hd1 pour que le rescue cd remettre le mbr et secteur de boot d'origine.
Sinon il reste à tenter d'effacer le hd1 remettre les données sauvegardée et de faire un fixmbr depuis un cd Windows
 
 
C'est le pb avec le chiffrement : quand ça fois/plante récupérer les données ou réparer le système devient très difficile car le chiffrement empêche tout les autres logiciels de fonctionner.

Vais faire une image, y avais pas pensé.. Merci! Sinon déchiffrer mais comment vu que je me tape "incorrect  password" à chaque fois?

J'avais oublié ce point...
Il faudrait avant de déchiffrer faire une restauration des entêtes du volume de hd1.
Je ne me rappel plus si c'est possible avec le rescue cd.
Peut-tu le faire depuis hd2 ?
Depuis hd2 pouvais-tu voir le contenu de hd1 avant ton pb ?

Suis pas sur de suivre là.. Pourquoi n'aurai pas pu voir le contenu avant si je peux après?! Je monte ça en tant que partition système..

Au cas où l'option de restauration de l'entête ne soit pas disponible depuis le rescue cd sur hd1 pour pouvoir le faire sous windows depuis hd2