I have updated multiple dozens of print servers and do not recall ever encountering the scenario you are describing. The 1064 error is a licensing error. Check to verify that you have not exceeded the number of active printers assigned to your license. Another possibility for a 1064 error is incorrect version numbers being installed (e.g. an 8.4 hotfix on an 8.3 or 9.0 server). You might consider looking in the Pharos\Bin folder, going into detailed view, and then enabling the file version column to see if one or more of your major components (executables such as your license server, print server, etc...) are of different versions. Follow the instructions in the hotfix to confirm the version numbers for the SecureRelease service. The print service is dependent on the SRS, so if it won't start, neither will the print server. I do not expect that to be the case here simply because you are getting a license check error.
Please ensure that either the ZIP from which you extracted the PServer.exe update, or the updated EXE itself, is not "blocked". This is a "feature" of the Windows operating system that tags files copied from "wild" or restricted zones such that they cannot be immediately used without explicit user action. To see if it is, simply go to the Properties page of the suspect file and look at the General tab. If you see a button like the one here:
outlined in red, simply click that button to restore common access to the file and carry on.
Thanks for the replies, the issue has been identified. It's actually due to a bug in the software (8.4 rev94) where it does not write a needed key to the registry, so it can't find itself. This has been reported to support.
For anyone else who hits this, the problem is that the MachineName string value is not written under the parent Pharos key. This must match the value in Pharos Administrator under Server Configuration -> Host Name, which must be the aname of the system in DNS or it's IP (it can NOT be a cname). By default this is set to the machine name, but to work properly cross subnet (historically) this needs to be set to a FQDN. Because of the bug however, changing this breaks the print server service unless you also update the registry value.
Under 8.1 this could be a cname, apparently that was removed for some reason. Using a cname will not stop the print server from starting as having these values mismatched will, but it will cause the system to be unable to find the print drivers for some reason. I'm guessing at some level this may be due to the replacement of Windows printing with Secure Release.
Also noted was that if the print server service is stopped, Pharos Administrator lists almost all services as stopped even though they are started.