RD 'Blocks' without asking

I have the Key HKEY_CURRENT_USER\Control panel\Desktop set to 'Ask User' for the setting of values, yet when I attempted to change the settings for the timing in Display Properties/Screen Saver I could not apply the change because RD automatically blocked it without asking me.

I was able to get round the problem by manually creating an Application Rule allowing Rundll32.exe to set values on the key; but shortly afterwards RD crashed giving me the message:-

"Version mismatch between GUI and the DRIVER

Try rebooting then restarting Ghost Security Suite."

Rebooting got it working again but obviously I don't like the idea of RD ignoring the 'Ask User' setting and blocking without asking, it could cause problems, does anyone know what is going on here?

 

TopperID,
During some events, the Regdefend gui is not able to respond due to the way that Windows works. I have seen instances of that happening in the Desktop key before with the value screensaveactive. I have created an exception for rundll32.exe allowing it to change that value in order to allow it to be set when the Gui is not there or is not able to respond.

You might be running into this behaviour with the other value names you have listed and it would explain the blocking because the GUI is unable to respond so the driver assumes its "default deny" stance to protect against malware making changes when the GUI is not available. If your rule uses a value of * then the other changes could be being blocked because they match that same rule and all happened within a very short period.

There are little windows quirks you can run into when protecting various registry keys, this is one of them. If you have a look in the default RD rules the protected value under Desktop is very specific and protects an important value without encountering this windows quirk

Code:

HKEY_CURRENT_USER\Control panel\Desktop | scrnsave.exe | CREATE KEY, MODIFY KEY, SET VALUE, DELETE VALUE | Ask User, Log to Disk | Special_Registry_Items | 7

 

Thanks gottadoit and understood.

It's the first time I've run into this particular quirk, but I'm pleased to say I've not encountered any further problems since creating permissions for Rundll.exe on the key.

I'm glad to learn it's 'known' behaviour and not specific to my setup.