TPM (Trusted Platform Module) enabled but the TPM-related info cannot be read

This error started happening after I have removed / added the TPM chip. Parallels displays this error right away after I try to start the VM (it has not even started yet.

I'm running Monterey 12.0.1 and parallels 17.1.0



This VM has been working without any issue with the TPM Chip and Bitlocker, etc for many weeks but for testing purposes today, I removed the TPM Chip and then added it again (to test a procedure for people not having the TPM chip in their VM at work).
After I did this, I could not longer see the TPM Chip in Windows even though it is ion the hardware list of the VM in Parallels and I also get the above error as soon as I start the VM.

I also see this in the parallels logfile

10-28 23:29:36.989 F /LocalDevices:17364:c7377/ [TPM NVS] TVNS - invalid signature
10-28 23:29:36.990 F /vm:17364:c7377/ Sending question = PRL_WARN_TPM_NVRAM_INVALID

It's as if removing / adding the TPM Chip has somewhat corrupted or destroyed the encrypted storage or something or the NVRAM file in some way.

Has anybody ever encountered this ?

Thanks

 

Hello @Pat-NS, please
generate a Technical Report ID following the instructions from this Knowledge base article and provide us the 9 digit technical report ID here for further investigation.
http://kb.parallels.com/9058 . Thanks, Parallels Team

 

Technical report 382327598 has been sent to Parallels.

 

@GampaA@Parallels is there anything else you would like me to test or send while you are analyzing this ? Thanks

 

Ok, so I continued to troubleshoot this myself. I ended uptrying to downgrade to Parallels 16, did not work either. removing/re-adding TPM chip did not solve it either.
Tried deleting NVDRAM.dat, did not not. Tried deleting both NVRAM.dat and NVRAM.tnvs fixed it. I was then able to start the VM again with the above error. TPM chip got detected properly again.
Seems like removing the TPM chip doesn't properly clean up either of the NVRAM files, I support the .tnvs one. Deleting it and starting the VM again re-created it. Not sur if doing this created other issues but it seems to work for me.
In other words, Parallels has a bug that needs fixing. For now, I have (and others now) this workaround.

Now: Can you tell me what those files are for, what they contain and any consequences in deleting them since they get re-created on the start of the VM ?

 

Pat-NS, did you remove any vTPM-related keychain entries during this test?

 

When removing the TPM chip from the VM and re-adding it didn't work and created the above error then yes, I tried to also remove the TPM-related keys from the keychain but it didn't change anything to the error.
Only removing the NVRAM files "fixed" the problem it seems.

 

@GampaA@Parallels any updates ?

 

Pat-NS, isn't your case outdated?
You have broke the original TPM after removed TPM-related keychain entries.
So, when you re-added it to VM new keychain entry was created with a different key.
Original key was stored in removed keychain entries, thus old contents on NVRAM.tnvs is not available anymore.
I assume you removed old NVRAM.tnvs, and now VM will work with new NVRAM.tnvs
If you have Bitlocker active, you need to use recovery key.

 

I understand what removing TPM does and the consequences on the keychain and also on Bitlocker, that's not what I reported in my first post.

What I reported is the bug that comes with the action or removing/re-adding TPM on Parallels itself, which is unrelated to Windows or Bitlocker in the VM. This bug (screenshot and error log above) actually happens even before Windows starts or UEFI boots, it happens when Parallels is setting the VM up to get it ready to boot up. It has not even started the VM yet from the logs I've seen.

The main reason I reported it here is to allow others to be able to fix themselves this issue/bug until the proper fix makes its way into the production release.

I would expect that if you remove and re-add TPM in your VM config that Parallels properly handles the NVRAM files by itself. Right now, I had to manually delete the files, potentially losing other settings that are present in this file (hint: it's not only used for TPM btw) because Parallels doesn't seem to handle removing and re-adding TPM properly. This is not document in any KB article from the searches I've made and is also a new/unknown issue since the implementation of the vTPM in Parallels. In others words, I'm just trying to help others and Parallels here because I don't think that deleting the NVRAM files is the right thing to do or a good solution.

 

Pat-NS, do I understand correctly that reported issue occurred once?
Could you try to remove and re-add TPM again and check the result? You can check it even using some new empty VM.
I believe it won't happen again.
And could you send technical data to Parallels and post its ID here if the issue occurred again.
Thank you.

 

Already did that on post #3 and post #5 of this thread and actually did try the remove and re-add many, many times and that did not fix it.
Please do not suggest troubleshooting steps or informations already present in the current thread.
Parallels already has the Technical report they requested on post #2 of this thread.
I understand you want to help but Parallels already has everything they need to troubleshoot and most likely implement a fix, nothing else seems to be required from you and I. I was merely following on with them in case they need anything else from me and I was curious to know if a fix was on the way.
I already worked around the bug as described in post #5 but this should definitely not be a solution.
Thanks for your help.

 

Hi, kindly confirm if you have followed exact steps from https://kb.parallels.com/en/122702 for adding the TPM chip.

 

I did and it was working very well until I had to do a test with the VM and remove/re-add the TPM chip. That's when I started having issue before the VM even started and I had to delete the NVRAM files. This is all explained in post #1 and #5.
Like I said, I worked around the Parallels software bug by deleting the NVRAM files to get my VM back under control with TPM functioning but I don't think this is a solution and you may want to fix this issue in the software for others in case they hit the same issue that happened to me. You should have all the details and logs required to troubleshoot this in post #3 per the Technical Report I sent when Parallels support requested.

 

You can close/lock this thread since I believe I don't need any more help and Parallels has all the information required in order to issue a fix later on if required. If you believe a fix is not required and I unluckily hit a corner case which should never happen, feel free to ignore this bug report. If anyone hits this issue, it is at least documented somewhere (here) and they can work around the bug like I did.
Thanks.

 

Hi, we appreciate that you have shared your workaround with us. We will check on this issue and fix it as soon as possible.

 

Hi i am having the same issue, By any chance can you provide the location on the NVRAM files so i can try this workaround?

 

Hey NVM I figured it out the location. If anyone is having this issue deleting the NVRAM.DAT and NVRAM.TNVS Fixed the problem as discovered by @Pat-NS. The location of the files are in the folder your VMs are stored in. While in the folder find your VM and right click on it and select "Show Package Contents" you will see the two files there (NVRAM.DAT /NVRAM.TNVS). Just delete them or move them out. Then start your VM with TPM enabled and Windows should boot like normal with TPM.

Cheers!

 

Thank you so much!! That fixed my problem as well. I had called Parallels support but they obviously weren't able to find this post. I did some searching and you helped. Thank you!!!

 

Thank you very much to the 2 that were helpful in this thread! Removing the TPM module in the windows config in Parallels Control Center, quitting Parallels, and then removing the 2 NVRAM files, and re-adding the TPM module fixed for me. Sad that this is still happening and this thread goes back to December or earlier which I have been having the issue for about a year.