It looks like there are some CPU maskings in the vmx file.
The cpuid.0 masking looks unnecessary as leaf 0 is just the "GenuineIntel" string and furthermore the value mask applied to ecx didn't change its value (it's still ntel)
While the cpuid.1.eax entry masks to a Pentium III Katmai desktop processor (family 6 model 7 stepping 6)
From the log, the guestOS seems to be expecting x2APIC and TSC-Deadline capabilities in the CPU while the i7-950 does not seem to have those capabilities.
Try to mask these off from the guestOS by adding this to the vmx file
cpuid.1.ecx = "----:---0:--0-:----:----:----:----:----"
Coincidentally, there are few lines in the log before the CPU error and one line after that shows some APIC thermal monitor vector register operations; although I can't say that these are the direct cause of the problem. APIC is supported by i7-950 processor but not x2APIC.
2017-08-07T23:20:16.498+05:00| vcpu-0| I125: APIC THERMLVT write: 0x10000
2017-08-07T23:20:16.498+05:00| vcpu-2| I125: APIC THERMLVT write: 0x10000
2017-08-07T23:20:16.498+05:00| vcpu-3| I125: APIC THERMLVT write: 0x10000
2017-08-07T23:20:16.498+05:00| vcpu-1| I125: APIC THERMLVT write: 0x10000
I don't know if this new masking will help with your current powering up problem but try it out anyway.
Also since the i7-950 does not support x2APIC, try reducing the number of vCPUs to just 1 (currently the setting is 4) as x2APIC is really designed for multiprocessors. I would think you aren't gonna lose much processing power in the Nougat VM as you are already trying to mask it to a 32-bit only Pentium III.
CPU masking was done after the problem in hope it could resolve it but didn't worked. Now as you mentioned they were unnecessary I removed them and tried again but again no luck, tried again with 1 processor still didn't worked and you quoted APIC is supported by i7-950 processor but not x2APIC. things were going just fine before that power glitch... is there any way I could get data from that VM?
I didn't hold up much hope that the cpuid.1.ecx mask would work as it was working before unless it was some sort of recovery that Nougat OS was going through to recover from sudden power loss that required the use of certain CPU features.
Anyway, maybe it is just plain corruption of file(s) within the VM OS.
I don't know much about data recovery, FreeBSD and Nougat OS and what filesystem it uses. And I dislike the Nougat candy, not that I eat candies these days. I see it as a punishment to be offered Nougat candy; or as sick challenge to not break your teeth while eating one :smileylaugh:
I would suggest backup the VMDKs of the Nougat VM. The way I see it the more times you boot up and modify the virtual disk, the higher the risk the recovery process gets more difficult if not impossible.
I can only suggest create another VM that is capable of reading the Nougat VM filesystem and add a copy of the VMDK of the broken Nougat VM as another drive that you can recover the data/files from.
EDIT: if the Nougat VM uses a filesystem that the Windows host recognises such as FAT32, you could just map a copy of the VMDK as a drive using the "Map virtual disks..." from the File menu.
Made a backup installed the new VM with same name so I don't have to replace any single line in VMX. replaced all VMDKs but still didn't worked man. and I don't like Nougat candy either I prefer KitKat over them. just help with extracting folders from VM hard disk. Tried mounting as Virtual drive on my host PC. but drive is linux based so tried opening with DiskInternal's Linux Reader where it showed Androidx86 folder empty!