You may need to actually use functions to protect your process. A very powerful function to use to protect you process has to be ObRegisterCallbacks.
The real problem here, is loading the Kernel Driver on x64, as I expect this project to be non-commercial, it is not likely that the driver nor the application will have a Digital Certificate. Therefore it is safe to say there is sometime until you can find a trick to bypass PatchGuard to load a rogue driver. There is no standard method to do perform these sort of bypasses even with administrative elevation.
Few malwares such as TDL4 and Carberp bypassed PatchGuard and managed to load their driver onto the Windows NT kernel. These tricks always involved some level of MBR\VBR level interaction to "switch off" the kernel protection module.
Now, that in mind Microsoft was reluctant to fix (change) the PatchGuard to protect against the similar variants of the Malware. It would be highly unlikely you can exploit PatchGuard again even with high optimization on MBR and Kernel Land by AVs (ex. McAfee). It is pretty straightforward that without having multiple years or 1 centuries of exploit development, there is < 1% chance of you managing to find a bypass methodology in near future.
Anti-Virus softwares such as Avast do not even load Kernel drivers, infact they stick with Userland with x64 libraries to safeguard against malwares.
I know you didn't ask me but I'm a bit suspicious about the byte alignment on the "HookGeneralFunction()" function. You can find out the real value for things like this at runtime so the fact that the author chose to hardcode these values brings their actual understanding of this code into question. That just MHO though.
To assure you Im not making anything malware, you can accept/reject this statement,
As I told earlier, Im not mad/
a bad guy to write viruses,
I will never do that,
and if I made you angry
with my question /waste your time Im sorry,