I did find this line in the log file:
Code: Select all
00:15:08.685 PSN - Processor Serial Number = 0 (0)
Code: Select all
vboxmanage setextradata MyVM PSNKey
Code: Select all
00:15:08.685 PSN - Processor Serial Number = 0 (0)
Code: Select all
vboxmanage setextradata MyVM PSNKey
Nope, Windows Vista Business on an Intel Core 2 CPU.In case this is a Linux host...
I may have confused the issue. The program is attempting to obtain the processor id using WMI, not the processor serial number. I found the following information at some place called eggheadcafe:Though PSN 0 (0) means that even your host seems to have a disabled processor serial number.
I can use this program without problems on the host machine, and in a virtual machine running Windows XP Pro SP3 in Virtual PC. For reference, the value I get for processorId on my host machine is BFEBFBFF000006F2. I'm not all that familiar with WMI or this CPUID business.I think you guys are missing a key point... the ProcessorID that is returned in WMI is NOT the 64-bit processor serial number !!
The ProcessorID is the return of the CPUID, EAX=1 function (that returns the family, model, stepping, etc). They are by no means unique! The 64-bit portion of the 96-bit PSN is the result of CPUID, EAX=3.
There is a provision in WMI for UniqueID which could be used for this purpose, however I don't know of any WMI provider that currently uses this field. (But that's doesn't mean you can't roll your own).
So I guess I'm not sure why the guest OS does not have access to this information if the host CPU supports the instruction? Is it because of the dual cores? Is this a bug in VirtualBox?ProcessorId
Data type: string
Access type: Read-only
Processor information that describes the processor features. For an x86 class CPU, the field format depends on the processor support of the CPUID instruction. If the instruction is supported, the property contains 2 (two) DWORD formatted values. The first is an offset of 08h-0Bh, which is the EAX value that a CPUID instruction returns with input EAX set to 1. The second is an offset of 0Ch-0Fh, which is the EDX value that the instruction returns. Only the first two bytes of the property are significant and contain the contents of the DX register at CPU reset—all others are set to 0 (zero), and the contents are in DWORD format.
Has there ever been a official bug report done concerning this?Frank Mehnert wrote:No, there is currently no way. Please open a bug report for this issue. Though PSN 0 (0) means that even your host seems to have a disabled processor serial number. In case this is a Linux host I assume that Linux disables the serial number for privacy reasons (not sure about that).
Unfortunately, I never got around to posting a bug report myself, and I do not know if anyone else ever posted a bug report. My company decided to switch to VMWare (not sure why, as I was not a part of the decision making process) and I never had a chance to come back to this issue and play with it on my own time.Has there ever been a official bug report done concerning this?