Problème Registre. Impossible d'ouvrir une clé.

Dans : news:mn.db207d7801af83c6.76535@enfrance.net.invalid,
Sabrem JORAM disait :

A la condition que ce ne soit pas la partie émergée de l'iceberg...

Absolument !

C'est pour cela que je répondais à ton post car tu as peut-être
connaissance d'outils qui permettent d'élaguer une branche malade dans
le registre (à part le CHKDSK et non CHDSK comme mon clavier s'est
permis de l'écrire :-) ).
Je reprécise donc, pour Augustin, que ma manip ne récupère pas le
contenu de la branche défectueuse mais constitue juste un moyen de
pouvoir utiliser à nouveau OE.

Et effectivement, cela ne garantit pas que d'autres problèmes ne vont
pas se manifester.
J'ai pris connaissance de vos messages (fred et Sabrem) D'abord merci à

vous.

Avant de tenter la manip, je vous précise bien que :

1/ j'ai tenté au départ une restauration avec un point de restauration
antérieur à l'incident qui a avorté...
2/ Je n'ai plus de points de restauration antérieur disponibles dans
"restauration du système".
3/ J'ai lancé plusieurs CHKDSK avec divers commutateurs F P et R ce qui
n'a rien changé...
Noter que je suis en NTFS. Windows SP1 Home.

4/ A part OE tout fonctionne bien. Dans le journal des évènements rien
n'est apparu après l'incident...

Ceci rappelé, il convient que je comprenne bien comment procéder ;-)

Le mal semble provenir du registre sur :
HKEY_CURRENT_USERIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software


Dans Identities j'ai 2 sous clés {.......} C'est la 1° qui est en cause.

Dans l'éditeur de Registre si je clique "Droite" sur ce 1° {....} j'ai
"autorisation : Tout le monde." J'ai pu y ajouter Nom (ordinateur) et
administrateur mais SYSTEM et RESTRITED sont refusés.

Si je clique G sur Software j'ai le message : "....erreur lors de
l'ouverture de la clé."
Si je clique D ..........................................: ..... Vous
n'avez pas les autorisations... mais vous pouvez modifier ces
autorisations... OK

La fenêtre d'inscription s'ouvre et je peux y inscrire Nom,
Administrateur...mais à l'enregistrement s'ouvre la fenêtre : ...Accès
refusé.

************************/

J'ai lu http://fspsa.free.fr/cdr-svi.htm . Mais c'est très dense et
j'aimerais compte tenu de mes explication précédentes savoir précisément
par quoi commencer.

D'autre part ai-je besoin d'ERUNT pour sauvegarder le Registre. Une
exportation de celui-ci sur une autre partition ne suffit-elle pas à le
sauvegarder ?

Autre question : Les anciens point de restauration existe-t-ils encore
car depuis j'ai effectué plusieurs nettoyage du disque et n'ai
présentement à disposition que 3 restaurations postérieures dans le
dossier SVI..

Je rappelle qu'il n'y a pas urgence. OE ne m'est pas indispensable et la
réparation du Registre, si elle est possible sans risques, présente
surtout un intérêt technique pour moi.

La manip :

<< Si j'ai bien compris, c'est seulement la sous-clé de
HKCUIdentities{GUID identité} qui est endommagée.
Si Augustin ne crains pas de paramétrer à nouveau son OE (comptes,
règles), il peut essayer de simplement renommer la clé Identities en
Identities.bak et relancer son OE.
S'il a d'autres identités sous OE que celle en défaut, il suffira
d'exporter au préalable les différentes sous-clé {GUID identité valide}
pour le réimporter dans la nouvelle clé Identities qui sera recréée
automatiquement au lancement de OE. >>

Me semble séduisante pour un début ?

@+ si vous le voulez bien.
Amical salut A.FB
--

* Bonjour augustin * !
<news:OBnoMrL6HHA.4584@TK2MSFTNGP03.phx.gbl>
Salut Fred, salut Pascal.

Première chose à faire, utiliser ERUNT.
J'insiste.

1/ j'ai tenté au départ une restauration avec un point de restauration
antérieur à l'incident qui a avorté...

Faudra réparer ça. Mais pas tout de suite, afin de ne pas prendre le
risque d'effacer les points de restauration actuels.

2/ Je n'ai plus de points de restauration antérieur disponibles dans
"restauration du système".

Ce qui ne veut pas dire que les points sont effacés.

3/ J'ai lancé plusieurs CHKDSK avec divers commutateurs F P et R ce qui n'a
rien changé...

Merci de l'info.

Noter que je suis en NTFS. Windows SP1 Home.

Tu restes en SP1 ?

4/ A part OE tout fonctionne bien. Dans le journal des évènements rien n'est
apparu après l'incident...

C'est cool.

Ceci rappelé, il convient que je comprenne bien comment procéder ;-)

Le mal semble provenir du registre sur :
HKEY_CURRENT_USERIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software

Ah, c'est bien d'avoir clairement désigné la clef.

Dans Identities j'ai 2 sous clés {.......} C'est la 1° qui est en cause.

HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software
On est d'accord ?

Dans l'éditeur de Registre si je clique "Droite" sur ce 1° {....} j'ai
"autorisation : Tout le monde." J'ai pu y ajouter Nom (ordinateur) et
administrateur mais SYSTEM et RESTRITED sont refusés.

Même avec l'administrateur du mode sans échec ?
Essayer : dans Autorisations, bouton Paramètres avancés, cocher "Hérite
de l'objet parent ..."
Peux-tu renommer la clé comme Fred l'a suggéré ?

Si je clique G sur Software j'ai le message : "....erreur lors de l'ouverture
de la clé."

Et je suppose qu'elle ne va pas se laisser renommer.

Si je clique D ..........................................: ..... Vous n'avez
pas les autorisations... mais vous pouvez modifier ces autorisations... OK

La fenêtre d'inscription s'ouvre et je peux y inscrire Nom,
Administrateur...mais à l'enregistrement s'ouvre la fenêtre : ...Accès
refusé.

Essayer "Hérite de l'objet parent ..." comme explicité ci-dessus.
Autre manoeuvre possible, à partir de la clé en amont
{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93} :
Cocher :
"Remplacer les entrées d'autorisations de tous les objets enfants..."

************************/

J'ai lu http://fspsa.free.fr/cdr-svi.htm . Mais c'est très dense et
j'aimerais compte tenu de mes explication précédentes savoir précisément par
quoi commencer.

Je n'avais pas pensé en faisant cet article au cas du registre
utilisateur, car il n'empêche pas un démarrage en mode sans échec.
Remarquer que erunt le traite, et j'ai récemment amendé la page erunt
sur le sujet des ruches utilisateur.
La branche HKCU est consignée dans la ruche Ntuser.dat ==>
C:Documents and SettingsAUGUSTINntuser.dat
Et les points de restauration sauvegarde nomment cette ruche en
utilisant le SID de l'utilisateur, ce qui complique un peu la manip
Voir les ..._NTUSER_S-1-21-... dans l'image :
http://fspsa.free.fr/images/cdr-svi/cdr-svi-snapshot.png
Il va donc falloir que tu identifies ton SID utilisateur avant de
commencer la manip. De toute façon, ne rien entreprendre tans que ERUNT
n'aura pas été utilisé.

Pour identifier ton SID, je te propose cet outil
www.bellamyjc.org/fr/vbsdownload.html#name2sid

D'autre part ai-je besoin d'ERUNT pour sauvegarder le Registre. Une
exportation de celui-ci sur une autre partition ne suffit-elle pas à le
sauvegarder ?

Lire http://fspsa.free.fr/registre-sauvegarde.htm
J'y rappelle pourquoi exporter le registre n'est pas une sécurité
absolue. Surtout dans ton cas où la clé qui nous intéresse est
justement refusée d'accès.
Autre raison d'utiliser ERUNT :
Il permet, même en cas de maladresse grave avec regedit (le chat qui
passe sur le clavier par exemple) de redémarre le système même si
celui-ci ne veut plus rien entendre à cause d'une ruche endommagée.
Installe ERUNT, s'il-te-plaît :)

Autre question : Les anciens point de restauration existe-t-ils encore car
depuis j'ai effectué plusieurs nettoyage du disque et n'ai présentement à
disposition que 3 restaurations postérieures dans le dossier SVI..

Ah tu t'es donné accès au SVI et il ne reste que trois points RP... ?
Tu peux déterminer facilement leurs dates, dans les propriétés des
fichiers, et dans fifo.log
Te paraissent-ils assez anciens pour servir à retrouver un registre
d'avant la fausse manip ?

Je rappelle qu'il n'y a pas urgence. OE ne m'est pas indispensable et la
réparation du Registre, si elle est possible sans risques, présente surtout
un intérêt technique pour moi.

Il suffirait, après sauvegarde manuelle du fichier
C:Documents and SettingsAUGUSTINntuser.dat
de remplacer celui-ci par son équivalent récupéré dans le SVI.
Il n'est pas besoin d'opérer depuis la Console de récupération, il
suffit de faire la manip depuis un autre compte.
Laisse-moi le temps de faire un essai.
Il faut peut-être traiter en même temps UsrClass.dat pour plus de
cohésion.

La manip :

<< Si j'ai bien compris, c'est seulement la sous-clé de HKCUIdentities{GUID
identité} qui est endommagée.
Si Augustin ne crains pas de paramétrer à nouveau son OE (comptes, règles),
il peut essayer de simplement renommer la clé Identities en Identities.bak et
relancer son OE.
S'il a d'autres identités sous OE que celle en défaut, il suffira d'exporter
au préalable les différentes sous-clé {GUID identité valide} pour le
réimporter dans la nouvelle clé Identities qui sera recréée automatiquement
au lancement de OE. >>

Me semble séduisante pour un début ?

Mais oui, si la clé se laisse renommer, ce dont je doute.

@+ si vous le voulez bien.
Amical salut A.FB

Installe ERUNT et trouve ton SID.
Essaie les manips sur les héritages des droits vues plus hauts.
Éventuellement avec le compte admin du mode sans échec.
Je teste la manip des ruches utilisateur.
Pascal va sûrement, tel que je le connait, en faire autant de son côté.
Alors à tout de suite.

--
Salutations, Jean-François
Index du site de PN : www.d2i.ch/pn/az
Outlook Express : Suivez vos fils avec [CTL+H]
Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm

Dans : news:Oxk2PbM6HHA.5268@TK2MSFTNGP02.phx.gbl,
JF écrivait :

* Bonjour augustin * !
<news:OBnoMrL6HHA.4584@TK2MSFTNGP03.phx.gbl>
Salut Fred, salut Pascal.

Salut JF,

Dans l'éditeur de Registre si je clique "Droite" sur ce 1° {....}
j'ai "autorisation : Tout le monde." J'ai pu y ajouter Nom
(ordinateur) et administrateur mais SYSTEM et RESTRITED sont refusés.

Je croyais qu'aucun accès nétait possible ! Dans ce cas ce devrait être
possible de réattribuer des droits.

Même avec l'administrateur du mode sans échec ?

Dans ce cas, si je ne m'abuse, il faudra charger la ruche de
l'utilisateur.
Dans regedit, se positionner sur HKEY_USERS par exemple, puis Fichier,
Charger la ruche et aller chercher le fichier NTUSER.DAT dans le profil
utilisateur (Document and SettingsUtilisateur)

Essayer : dans Autorisations, bouton Paramètres avancés, cocher
"Hérite de l'objet parent ..."
Peux-tu renommer la clé comme Fred l'a suggéré ?

Si c'est juste un problème de droits, alors ce ne sera peut-être pas
nécessaire.



--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

* Bonjour Fred * !
<news:ufTFlSO6HHA.5984@TK2MSFTNGP04.phx.gbl>

Dans l'éditeur de Registre si je clique "Droite" sur ce 1° {....}
j'ai "autorisation : Tout le monde." J'ai pu y ajouter Nom
(ordinateur) et administrateur mais SYSTEM et RESTRITED sont refusés.

Je croyais qu'aucun accès nétait possible ! Dans ce cas ce devrait être
possible de réattribuer des droits.

Augustin arrive à afficher l'arborescence jusqu'à
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software
mais il ne peut pas entrer dans ce Software, ni modifier les
autorisations comme nécessaire.

Même avec l'administrateur du mode sans échec ?

Dans ce cas, si je ne m'abuse, il faudra charger la ruche de l'utilisateur.
Dans regedit, se positionner sur HKEY_USERS par exemple, puis Fichier,
Charger la ruche et aller chercher le fichier NTUSER.DAT dans le profil
utilisateur (Document and SettingsUtilisateur)

Oui, tu as raison, merci de le rappeler :
- Exécuter>regedit
- Sélectionner la branche HKU
- Menu Fichier>Charger la ruche
- Sélectionner le fichier NTUSER.DAT désiré
(différent du compte en cours, évidemment)
- Donner un nom "xxxxxxx" (arbitraire)
- On peut alors naviguer dans HKUxxxxxxx
- Une fois qu'on a fini, Menu Fichier>Décharger la ruche

Essayer : dans Autorisations, bouton Paramètres avancés, cocher
"Hérite de l'objet parent ..."
Peux-tu renommer la clé comme Fred l'a suggéré ?

Si c'est juste un problème de droits, alors ce ne sera peut-être pas
nécessaire.

C'est justement la question débattue : Augustin n'arrive pas à se
donner les permissions sur F04BE5A1DB93}Software, ni à ouvrir cette
clé, depuis "une manip avec RegSeeker".

J'en viens au test annoncé :
REMPLACMENT DE NTUSER.DAT DEPUIS SVI
=================================== Il faut d'abord identifier le SID
www.bellamyjc.org/fr/vbsdownload.html#name2sid
Si on a un seul compte, il n'y aura pas d'ambiguité.
Le nom du NTUSER.DAT du SVI se termine par 1003 ou 1004 (par ex).


Exemple :
_REGISTRY_USER_NTUSER_S-1-5-21-1234567890-1234567890-123456789-1003
Chemin complet :
C:System Volume
Information_restore{77A7A5BB-21CC-4F85-A1D5-DDF160C5E18C}RP264snapshot_REGISTRY_USER_NTUSER_S-1-5-21-1234567890-1234567890-123456789-1003

J'ai fait le test sur un XPHOME-SP2
Par rapport à un XPPRO, s'ajoute alors la difficulté de l'absence de
l'Onglet Sécurité nécessaire pour accéder au SVI. Mais ce n'est pas un
problème, il suffit de démarrer en Mode sans échec (F8 au démarrage).
L'onglet est alors disponible quel que soit l'utilisateur (dont l'ADMIN
de secours, bien sûr).

Autre difficulté rencontrée :
Ce PC démarrait directement sur le compte principal.
Ceci semble être à l'origine d'une impossibilité de renommer son
NTUSER.DAT
Avec la commande control userpasswords2 j'ai forcé à nouveau les
utilisateurs à entrer un mot de passe, ce qui semble avoir débloqué la
situation. Je dis ce qui semble, car en voulant reproduire la chose, je
n'ai plus eu de difficulté, si ce n'est qu'après avoir utilisé
userpasswords2, le système démarre en mode sans échec directement sur
le compte qui a été désigné, ce qui amène a fermer la session pour
enfin arriver à l'Administrateur de secours.

J'en termine avec ce préambule,
pour passer au remplacement de NTUSER.DAT:
Nom du profil supposé = AUGUSTIN
Démarrer en mode sans échec sur le compte "Administrateur"
Renommer par sécurité C:Documents and SettingsAUGUSTINntuser.dat
(par exemple en 20070828-ntuser.dat)

Accéder au SVI :
Se donner les droits en faisant un clic droit dessus, Propriétés,
Onglet Sécurité, Bouton ajouter, AUGUSTIN, OK.

Naviguer jusqu'au point de restauration (PR) voulu et copier le bon
NTUSER.DAT ==>
C:System Volume
Information_restore{77A7A5BB-21CC-4F85-A1D5-DDF160C5E18C}RP123snapshot_REGISTRY_USER_NTUSER_S-1-5-21-123456789-1234567890-123456789-1003
- ces numéros sont bidons, adapter en conséquence
- choisir le bon RP123 (Restoration Point) - voir dates des fichiers

Une fois copié ce fichier, le coller dans
C:Documents and SettingsAUGUSTIN
et le renommer NTUSER.DAT

Normalement il faut faire de même avec
C:Documents and SettingsAUGUSTINLocal SettingsApplication
DataMicrosoftWindowsUsrClass.dat
http://fspsa.free.fr/erunt.htm#erdnt.inf

J'ai fait l'impasse sur UsrClass.dat pour ce test.
Mais il conviendrait de le traiter de la même façon.

C'est terminé.
Après redémarrage j'ai retrouvé le bureau tel que je l'avais modifié
avant de faire ce point de restauration qui a servi au test (j'avais
mis un fond d'écran rouge).

Il ne reste qu'à renormaliser l'accès au SVI en supprimant
l'utilisateur ajouté, il ne doit rester que SYSTEM, c'est une sécurité.



Voilà, Augustin a donc un moyen de récupérer les fichiers NTUSER.DAT et
UsrClass.dat qui je l'espère redonneront accès à la clef.
Essayer bien sûr avant cela les histoires d'héritage dont j'ai parlé
précédemment (mais je n'y crois pas beaucoup).

J'espère que la manip ne paraitra pas trop compliquée.
En tout cas il n'y a pas à utiliser la CDR.
La méthode pourra être retenue pour d'autres cas de profil corrompu
avec impossibilité d'utiliser, comme c'est le cas ici, la restauration
système. Des PR doivent cependant être disponibles.
Ceci évite de créer un nouveau compte
http://support.microsoft.com/kb/326688/fr
http://support.microsoft.com/kb/811151/fr




--
Salutations, Jean-François
Index du site de PN : www.d2i.ch/pn/az
Outlook Express : Suivez vos fils avec [CTL+H]
Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm

Je croyais qu'aucun accès nétait possible ! Dans ce cas ce devrait
être possible de réattribuer des droits.

Augustin arrive à afficher l'arborescence jusqu'à
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software
mais il ne peut pas entrer dans ce Software, ni modifier les
autorisations comme nécessaire.
Exact...

Même avec l'administrateur du mode sans échec ?
Oui, accès toujours refusé, je viens d'essayer...

Dans ce cas, si je ne m'abuse, il faudra charger la ruche de
l'utilisateur.
Dans regedit, se positionner sur HKEY_USERS par exemple, puis
Fichier, Charger la ruche et aller chercher le fichier NTUSER.DAT
dans le profil utilisateur (Document and SettingsUtilisateur)
J'ai fait une recherche sur NTUSER.DAT .

Est présent dans (Document and SettingsUtilisateur) qu'un fichier qui
date de 2004, mise en route initiale du PC.
Il y en a d'autres dans des dossiers "Nom" , "local service" et "default
user" mais ils sont datés "modifiés aujourd'hui".

Peux-tu renommer la clé comme Fred l'a suggéré ?
Pas essayé. Il faut renommer quelle clé ? Comment procéder exactement

pour éviter une fausse manoeuvre ?
Je voudrais bien essayer...

J'en viens au test annoncé :
REMPLACMENT DE NTUSER.DAT DEPUIS SVI
=================================== > Il faut d'abord identifier le SID
www.bellamyjc.org/fr/vbsdownload.html#name2sid
Si on a un seul compte, il n'y aura pas d'ambiguité.
Le nom du NTUSER.DAT du SVI se termine par 1003 ou 1004 (par ex).
Je n'ai qu'un compte à mon nom.

J'ai l'onglet de sécurité que j'ai installé dès la mise en route
de ce PC en 2004.
J'ai tous les accès système possibles...

Mais dans SVI comme déjà indiqué précédemment je n'ai que des RPxxx
postérieurs au problème.
Avant de supprimer les anciens j'avais essayé plusieurs restaurations
qui avait avortées because le pb du Registre je suppose.

Ce qui suit ci dessous reste-t-il valable ? Me dire oui ou non simplement.
Si c'est oui, je poserai les questions éventuelles...Mais pris en compte :

La méthode pourra être retenue pour d'autres cas de profil corrompu
avec impossibilité d'utiliser, comme c'est le cas ici, la restauration

système. Des PR doivent cependant être >disponibles.

Ce doit être non... Alors que faire s'il y a quue chose à faire ?
Si non, je me passerai d'OE . Tout le reste fonctionne parfaitement.

@+. Encore merci pour votre gentillesse à tous.

Amical salut. A.FB
--

* Bonjour augustin * !
<news:#eFYLUX6HHA.5984@TK2MSFTNGP04.phx.gbl>

Augustin arrive à afficher l'arborescence jusqu'à
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software
mais il ne peut pas entrer dans ce Software, ni modifier les autorisations
comme nécessaire.
Exact...

Merci de la confirmation.

Même avec l'administrateur du mode sans échec ?
Oui, accès toujours refusé, je viens d'essayer...

En chargeant la ruche etc ...
OK. Tant pis.

Dans ce cas, si je ne m'abuse, il faudra charger la ruche de
l'utilisateur.
Dans regedit, se positionner sur HKEY_USERS par exemple, puis Fichier,
Charger la ruche et aller chercher le fichier NTUSER.DAT dans le profil
utilisateur (Document and SettingsUtilisateur)
J'ai fait une recherche sur NTUSER.DAT .

Est présent dans (Document and SettingsUtilisateur) qu'un fichier qui date
de 2004, mise en route initiale du PC.

Ce ne peut être celui-là.

Il y en a d'autres dans des dossiers "Nom" , "local service" et "default
user" mais ils sont datés "modifiés aujourd'hui".

Le Profil pour l'utilisateur Augustin doit donc être Docs&SettingsNom
Vérifier en modifiant un fichier sur le bureau et en allant voir si on
le retrouve bien dans Docs&SettingsNomBureau

Peux-tu renommer la clé comme Fred l'a suggéré ?
Pas essayé. Il faut renommer quelle clé ?

CELLE-CI ! ==>
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software

Comment procéder exactement pour éviter une fausse manoeuvre ?
Je voudrais bien essayer...

J'ai pas dit d'utiliser ERUNT ?
Alors si tu as installé ERUNT tu ne risques rien.
Ceci dit le risque est vraiment limité.
On procède exactement comme pour un fichier.
Dans la clé
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software
tu renommes avec un clic droit Software en SoftwareTEST
Il est probable que ce soit refusé.
Essaie aussi les histoires d'héritages des droits.
Si tu n'as pas compris de quoi il s'agit, dis-le.

J'en viens au test annoncé :
REMPLACMENT DE NTUSER.DAT DEPUIS SVI
=================================== >> Il faut d'abord identifier le SID
www.bellamyjc.org/fr/vbsdownload.html#name2sid
Si on a un seul compte, il n'y aura pas d'ambiguité.
Le nom du NTUSER.DAT du SVI se termine par 1003 ou 1004 (par ex).
Je n'ai qu'un compte à mon nom.

Résumons :
Compte = Augustin
Profil = Docs&SettingsAugustin
C'est bien ça ? Cela clarifierait les échanges de se mettre d'accord
sur les appellations.

J'ai l'onglet de sécurité que j'ai installé dès la mise en route de ce
PC en 2004.
J'ai tous les accès système possibles...

Cool.

Mais dans SVI comme déjà indiqué précédemment je n'ai que des RPxxx
postérieurs au problème.

Zut. Alors c'est rapé.

Avant de supprimer les anciens j'avais essayé plusieurs restaurations qui
avait avortées because le pb du Registre je suppose.

On n'en sait rien. Mais on sait maintenant pourquoi il n'y a plus de RP
antérieurs au pb.

Ce qui suit ci dessous reste-t-il valable ?

Non, c'est foutu. Il fallait un RP valable, antérieur à l'apparition de
l'erreur.

Me dire oui ou non simplement.

NON.

Si c'est oui, je poserai les questions éventuelles...Mais pris en compte :

La méthode pourra être retenue pour d'autres cas de profil corrompu
avec impossibilité d'utiliser, comme c'est le cas ici, la restauration

système. Des PR doivent cependant être >disponibles.

Ce doit être non... Alors que faire s'il y a quue chose à faire ?
Si non, je me passerai d'OE . Tout le reste fonctionne parfaitement.

@+. Encore merci pour votre gentillesse à tous.

Amical salut. A.FB

On va réfléchir encore un peu ...

--
Salutations, Jean-François
Index du site de PN : www.d2i.ch/pn/az
Outlook Express : Suivez vos fils avec [CTL+H]
Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm

Dans : news:udqbwli6HHA.5160@TK2MSFTNGP05.phx.gbl,
JF disait :

Peux-tu renommer la clé comme Fred l'a suggéré ?
Pas essayé. Il faut renommer quelle clé ?

CELLE-CI ! ==>
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software

Pas celle-ci, elle est inaccessible, mais celle ci :
HKCUIdentities

Avant cela, exporter la clé :
HKCUIdentities{celle qui n'est pas abimée}

Puis, après renommage de Identities et lancement de OE (qui devrait
retomber en marche), réimporter.

Bien sûr, tous les paramètrages de l'autre identité seront perdus
(règles, signatures, comptes) : mais pas les éventuelles bases de
données de messages (fichiers dbx) qu'il suffira de recopier dans le
nouveau répertoire de données, OE fermé bien entendu.
Les anciens fichiers sont par défaut ici :
C:Documents and SettingsUtilisateurLocal SettingsApplication
DataIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}MicrosoftOutlook
Express

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

* Bonjour Fred * !
<news:e0lsWGj6HHA.4436@TK2MSFTNGP03.phx.gbl>

Dans : news:udqbwli6HHA.5160@TK2MSFTNGP05.phx.gbl,
JF disait :

Peux-tu renommer la clé comme Fred l'a suggéré ?
Pas essayé. Il faut renommer quelle clé ?

CELLE-CI ! ==>
HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software

Pas celle-ci, elle est inaccessible, mais celle ci :
HKCUIdentities

Oui, si software ne peut être renommé tenter une clé en amont, et comme
{123456...} est une identité, il faut procéder comme tu dis.

Avant cela, exporter la clé :
HKCUIdentities{celle qui n'est pas abimée}

Logique.

Puis, après renommage de Identities et lancement de OE (qui devrait retomber
en marche), réimporter.

J'ai compris ! (miracle).

Bien sûr, tous les paramètrages de l'autre identité seront perdus (règles,
signatures, comptes) : mais pas les éventuelles bases de données de messages
(fichiers dbx) qu'il suffira de recopier dans le nouveau répertoire de
données, OE fermé bien entendu.
Les anciens fichiers sont par défaut ici :
C:Documents and SettingsUtilisateurLocal SettingsApplication
DataIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}MicrosoftOutlook
Express

Une bonne idée est de faire une copie de ce dossier, on a vite fait
d'effacer son contenu dans la manip.

J'aimerais bien qu'Augustin fasse ces essais d'héritage des droits
enfants/parents.

Pour info je viens de tomber là-dessus :
www.libellules.ch/dotclear/index.php?2007/08/27/2098-regassassin
... pas testé

--
Salutations, Jean-François
Index du site de PN : www.d2i.ch/pn/az
Outlook Express : Suivez vos fils avec [CTL+H]
Montrez-nous ce que vous voyez : http://fspsa.free.fr/copiecran.htm

Dans : news:%23z6y35j6HHA.4252@TK2MSFTNGP05.phx.gbl,
JF disait :

* Bonjour Fred * !

Hello JF,

Une bonne idée est de faire une copie de ce dossier, on a vite fait
d'effacer son contenu dans la manip.

Oui.

J'aimerais bien qu'Augustin fasse ces essais d'héritage des droits
enfants/parents.

J'ai du mal à suivre ses manipulations.
Pour moi deux solutions :
- problème de droits et alors ça se règle en administrateur (mode sans
échec sous XP Home) en chargeant la ruche. Mais je n'ai rien compris aux
résultats de recherche de NTUSER.dat.
- registre endommagé et il ne reste que le renommage en laissant le bout
de registre abimé. À moins de connaître un outil de réparation du
registre. Mais là, je laisse la main. Je ne sais si je ne connais pas
ces outils parce que je n'ai jamais eu de problèmes de registre ou
l'inverse :-)

Pour info je viens de tomber là-dessus :
www.libellules.ch/dotclear/index.php?2007/08/27/2098-regassassin
... pas testé

Peut-être une solution.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)

Fred et JF ont écrit : ***/

Bonjour à vous deux.

Pris en compte vos diverses propositions, je vais essayer :

1/ De répondre à vos questions.
2/ De formuler les miennes afin de clarifier la situation.

***************************/
1/

Même avec l'administrateur du mode sans échec ?
Oui, accès toujours refusé, je viens d'essayer...

En chargeant la ruche etc ...
OK. Tant pis.

Non, je n'ai pas chargé de ruche. J'y reviens dans le 2/ ci dessous...

Il y en a d'autres dans des dossiers "Nom" , "local service" et
"default user" mais ils sont datés "modifiés aujourd'hui".

Le Profil pour l'utilisateur Augustin doit donc être Docs&SettingsNom
Vérifier en modifiant un fichier sur le bureau et en allant voir si
on le retrouve bien dans Docs&SettingsNomBureau

Dans ...Nom : Je trouve bien tout les raccourcis présents sur le
bureau. Je n'y ai pas autre chose.
Si je place un nouveau fichier dans le bureau, il y apparaît bien lui
aussi... RAS de ce côté là.

Peux-tu renommer la clé comme Fred l'a suggéré
Pas essayé. Il faut renommer quelle clé
CELLE-CI ! ==>

HKCUIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}Software

OK, Essayé mais refusé par Regedit.

Essaie aussi les histoires d'héritages des droits.
Si tu n'as pas compris de quoi il s'agit, dis-le.

Pas compris je l'avoue ;-) On en reparle éventuellement.

***/
Résumons :
Compte = Augustin
Profil = Docs&SettingsAugustin
C'est bien ça ? Cela clarifierait les échanges de se mettre d'accord
sur les appellations.

C'est exactement ça !
Je précise que je suis seul sur ma machine. Dans les autorisations les
noms d'utilisateurs présents sont :

Administrateur (ORDINATEURAdministrateur)
Augustin (ORDINATEURAugustin)
RESTRITED
SYSTEM

Et aussi qque fois : Tout le monde.

***/

Pas celle-ci, elle est inaccessible, mais celle ci :
HKCUIdentities

Dans HKCUIdentities j'ai deux sous clés {.......}
La première est celle qui bloque sur Software ce qui n'a aucune
conséquence au delà de OE

La suivante qui se déroule sur de très longues chaînes de sous/sous/
sous... clés intéressant I.E. et O.E.

Et celle là il vaut mieux je pense ne pas l'abîmer ;-))

Puis, après renommage de Identities et lancement de OE (qui devrait
retomber en marche), réimporter.

Bien sûr, tous les paramétrages de l'autre identité seront perdus
(règles, signatures, comptes) : mais pas les éventuelles bases de

données de messages (fichiers dbx) qu'il suffira de recopier dans le
nouveau répertoire de données, OE fermé bien entendu.

Aucune importance, je sais, à peu près, comment tout récupérer.

Les anciens fichiers sont par défaut ici :
C:Documents and SettingsUtilisateurLocal SettingsApplication
DataIdentities{2921D1D7-45F4-4B50-A9C4-F04BE5A1DB93}MicrosoftOutlook

Express

OK.

2/

- Pour tenter en Mode F8 de réparer le Software, que dois je faire
exactement pour les ruches ?
Si échec :

- La manip qui passe par renommer la clé consiste bien en :

- Exporter HKCU entier dans l'état actuel comme sauvegarde avec l'éditeur.

- Renommer Identities en Identitiesback

- Lancer OE par msimn.exe

- Remettre en place l'HKCU précédemment sauvegardé ?
Là qque chose m'échappe ? Ne vais-je pas rétablir le Software défectueux ?

Enfin : Qu'entendez vous par <<... histoires d'héritages des droits.>>

OUF ! J'espère avoir clarifié un peu... ?

Vous êtes très patients avec moi, soyez encore une fois remerciés.
@+
--
A.FB