Unfortunately, there's a conceptual problem here. VNC works by rendering your desktop on the local machine, and then effectively taking pictures of the desktop and sending them across the network. This means that what VNC sends must be rendered on the serving computer.
While Windows has the capability of hosting multiple interactive sessions at once, it is disabled in non-server editions and seldom used anyway. This means that in practice a VNC server must send what is being rendered by the interactive session at the local console - so what you see in your VNC session must also be what's sent to the display.
There are two potential workarounds:
- A display driver shim that sits between Windows and your graphics card and replaces the video data with something else, like a blank screen. This is the method that LogMeIn uses if you enable Display Blanking - while a LogMeIn session is active, it uses a display driver it installs to effectively disconnect the monitor.
- Use RDP, since RDP sessions are a native interface to Windows, and not just a 'remote desktop' protocol - there is a significant conceptual difference between RDP and VNC. (in fact, since non-server Windows editions only permit one session at a time, logging in to a computer by RDP will forcibly lock the console session if someone is logged in there).
As for option 1, I'm not aware of any VNC servers that implement this feature, but I suspect they must exist. If nothing else, LMI does implement it as I mentioned.
As for option 2, I'd say there's a high chance that this is what you really should be doing. In most cases RDP is a superior option performance, security, and feature-wise. The exception would be if you have a Home edition of windows, since only Professional and above allow you to enable the RDP server (although it is installed in Home editions, just disabled).