PTT/TPM interact with the Cryptographic Service, which is what protects the Credential Vault. So my assumption is, something is happening where the vault's encryption keys are getting lost / corrupted and you're having to make a new one. That's the only explanation I can come up with for there being nothing in credential manager.
But why that circumstance would persist beyond the decryption / reboot is beyond me. The platform should have cleared itself out one last time and stuck. UNLESS, the password on the user account was forcibly reset. That password is your encryption key for the vault, so you can lose it if it's forcibly reset via any other mechanism than the user facing password change mechanism.
3rd party password managers that are part of other system utilities such as Dell's Data Protection suite (now defunct thank heavens), as well as some 3rd party AV also screw with the credential vault from time to time.
I'm also leaning to blaming a rare bug in 2004 as well, but if that were the case I'd assume I'd have one at least going wrong too.
Checking the date / time sync isn't a bad idea, especially if the unit is on a domain. Modem DCs are often guests of hypervisors and it's incredibly common for IT guys to forget to disable time services on the host for the DC guest, and manually configure the DC for appropriate Internet based time servers. All domain members should be using the DC as their time master, which happens by default.
The above leads to a condition where the hypervisor is a member of the domain, and therefore slaved to the DC's clock, but is also configured via HyperV to reconfigure the clock. That's a nasty race condition that causes all sorts of SSL and encryption issues across the network. But if that was what was going on here, other machines would be having other problems too. Though it's not without value to ensure the problematic endpoints have the correct date and time.
