Windows numéro de série (a: Arriver MachineGuid de Registre)
Je suis en train de chercher MachineGuid
à partir du registre, créer un certain niveau de la liaison avec le système d'exploitation pour mon système de licence. À partir de la documentation que je peux utiliser
string key = "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography";
string r = (string)Registry.GetValue(key, "MachineGuid", (object)"default");
pour l'obtenir. Aussi, les docs me disent que je reçois des "default"
lorsque le nom n'est pas trouvé, ou null
si la clé n'existe pas. Je devrais recevoir une exception de sécurité si je n'ai pas accès.
Le code ci-dessus me donne "default"
, ce qui signifie que le nom n'est pas trouvé. Cependant, si je regarde dans la base de registre avec RegEdit, il est là. Comment puis-je obtenir le MachineGuid
valeur à partir d'une application sans privilèges d'administrateur?
Mise à jour: lors de l'utilisation de reg.exe
je n'ai pas de problèmes pour obtenir la valeur.
Mise à jour: j'ai mis à jour le titre, afin que les gens vous cherchez une façon unique de détermination de l'installation de Windows, obtenir ici.
Vous exécutez un processus 32 bits sur une machine 64 bit?
quel système d'exploitation utilisez-vous? si sa version de l'OP, il pourrait y avoir une bonne raison pour cela de travailler pour vous et pas lui
L'exécution de Win7/32 bits.
quel système d'exploitation utilisez-vous? était-il le même que Clemens?
OriginalL'auteur Bart Friederichs | 2013-01-08
Vous devez vous connecter pour publier un commentaire.
Que d'autres personnes l'ont déjà signalé, vous n'êtes pas censé pour obtenir cette valeur directement à partir de la base de registre (ce qui est probablement pourquoi il ne fonctionne pas de manière fiable entre les différentes versions de Windows).
Un peu de recherche m'a conduit à la
Win32_OperatingSystem
Classe WMI. À l'aide de cette classe, vous pouvez réellement obtenir la Windows numéro de série. Il m'a fallu un peu de recherche et d'expérimentation pour obtenir la droite, mais c'est la façon de l'utiliser en C#.Assurez-vous que vous avez la
System.Management.dll
référence dans votre projet:À l'aide de la
[]
opérateur, vous pouvez obtenir des biens dans la classe.si j'ai l'outil de clonage comme Ghost, est-ce le numéro de série de changements à chaque fois que je le déploiement de cette Windows Syspreped clone de l'image? C'est un identifiant unique pour la copie de Windows?
Après une enquête plus approfondie, ID du Produit Windows n'est pas unique par Windows clone.
Vous dites "vous n'êtes pas censé pour obtenir cette valeur directement à partir du registre ".... Selon l'oms? Il existe toute une série de classes .NET pour travailler avec la base de registre....
cette méthode n'est pas appropriée lorsque vous utilisez l'image FANTÔME de l'OS , il ne vous donnera jamais le système d'exploitation Numéro de Série.
OriginalL'auteur Bart Friederichs
Non, ce n'est pas la raison. Ce problème est provoqué par la plate-forme de la sélection de la cible pour votre projet EXE. Projet + Propriétés, onglet créer, une Plate-forme cible zone de liste déroulante. Vous l'avez configuré pour x86 au lieu de AnyCPU. Sur VS2012, le "Préfèrent 32 bits" case à cocher questions. Ce paramètre force de votre programme s'exécute en mode 32 bits sur une version 64 bits de Windows. Qui a un certain nombre d'effets secondaires, le seul qui importe ici, c'est que l'accès aux clés de registre sont redirigés. Votre programme est en fait la lecture de la valeur de la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptographie\MachineGuid. Qui n'existe pas.
Le x86 sélection est la valeur par défaut pour VS2010 et, auparavant AnyCPU a la valeur par défaut. Microsoft préfère x86, Visual Studio fonctionne mieux avec le mode 32-bit processus. En particulier lorsque le débogage, la VS est un processus 32 bits lui-même l'exige le débogueur distant si votre programme s'exécute en mode 64 bits. Qui a quelques restrictions, comme pas pris en charge en mode mixte de débogage. Et de le Modifier + Continuer de fonctionnalité fonctionne uniquement pour les 32 bits de code. Votre programme en lui-même fonctionne cependant "mieux" si vous avez la mise à AnyCPU, y compris de ne pas se faire piquer par le système de fichiers et du registre de redirection appcompat fonctionnalités intégrées à Windows.
Si vous êtes vraiment coincé avec x86 mode, généralement parce que vous avez une dépendance de 32 bits en code natif que vous ne pouvez pas mettre à jour puis la prochaine solution de contournement consiste à utiliser l' .NET 4+ RegistryKey.OpenBaseKey() la méthode. Qui vous permet de passer RegistryView.Registry64, en s'assurant que vous aurez lu le non-clés redirigés.
Assurer, à l'aide de WMI est une solution de contournement. Il suffit de garder à l'esprit que vous êtes pas lire les mêmes informations lorsque vous utilisez Win32_OperatingSystem.SerialNumber. À ce degré que la clé est fiable aléatoire sur des machines différentes, n'est-ce pas clair pour moi, disons simplement que cette valeur est une jolie cible intéressante pour les utilisateurs qui ne sont pas très intéressés à payer les frais de licence pour votre produit.
Dernier mais non le moindre, ne considèrent qu'il est assez facile de générer votre propre identifiant unique qui ne dépend pas du tout sur Windows. Avec l'avantage considérable de ne pas s'emmerder votre client lorsqu'il met à jour de Windows sur sa machine. Utilisez simplement Guid.NewGuid() une fois, et de stocker la valeur dans un fichier. Qui seront perdus lorsque le disque va mal, mais qui prend habituellement votre produit.
Eh bien, je l'ai fait essayer à souligner que les différentes machines ont des Windows, numéros de série n'est pas exactement de la garantie. Peut-être que vous n'avez pas le faire à la fin de la réponse? Mais ouais, il vient un point où vous en aurez marre de vouloir traiter cette question. Et puis vous venez d'acheter un dongle.
La différence de Windows, numéros de série ne sera pas un énorme problème. Si deux personnes ont le même numéro de série, et en savoir eachother et sont prêts à pirater un morceau de l'industrie, logiciels de qualité, alors ainsi soit-il. Mon système de licence est juste pour contrecarrer la base de la copie et de la licence d'édition de fichier. (Le fichier de licence détient également certaines limites d'utilisation.) À un certain point, c'est juste pas la peine de dépenser de je-ne-sais-comment-beaucoup-de temps en protégeant le logiciel, où peut-être 1 ou 5% des clients sont prêts à le pirater.
OriginalL'auteur Hans Passant
Mon humble avis, aucune réponse ne répond à la question; est assez simple de demander une façon de lire le MachineGuid à partir de la base de registre... voici donc ma réponse: Vous devez ajouter une référence à "Microsoft.Win32". Ce code a été écrit pour des fins de démonstration et devrait être adaptée en conséquence.
EDIT: Quelqu'un a déclaré à tort que le code x64 est inutile. En 64 bits du système d'exploitation qui est l'endroit où la correcty clé est trouvée. Si cette réponse est le seul qui répond à la question.
Espère que cela aide certains.
C'est juste le code de démonstration, de sorte que n'importe qui peut voir ce qui est outputed à la fois 32 et 64 bits. C'est pourquoi j'ai précisé qu'il doit être adapté en conséquence. Mais merci pour cette remarque.
Aussi juste pour souligner que les autres réponses n'ont pas de code d'exemple; ou ne pas l'obtenir directement à partir de la base de registre. Donc, à mon avis c'est la seule réponse qui répond à la question à portée de main.
Romil est faux, Registry64 est nécessaire pour 64bits processus. Je suis dans la situation où resultObjX86 est par défaut, et resultObjX64 est le droit GUID de la chaîne.
Pourquoi ne pas publier votre propre réponse? Votre modification est un changement radical à partir du code original.
OriginalL'auteur Darkonekt