Change system time privileges

Since the last update of CIS, when I double click the time in the task bar (windows XP x64) I get the message “You do not have proper privilege level to change the system time.”
I confirmed that Defense+ was the culprit by disabling it and trying it again - now it worked without a problem.

I want to be able to just double click the time to bring up the dialog that also lets me change the current date/time. What can I do to make sure that Defense+ doesn’t steal my privileges from me?

You said you disabled D+ temporarily and that fixed it. Is it staying fixed after a reboot? If so then you blocked it during the Windows session and denied it access but didn’t let CIS remember the answer.

I think this did indeed solve the problem (though I am still confused about when I can possibly have denied it access - I don’t remember ever being asked). However, I am not entrirely sure as I have had to disable D+ permanently in order to be able to use gdb.

What is gdb.

Please try the workaround described in App. is not working correctly, but does not seem to be s/boxed. What to do? [v5] to see if that makes gdb work.

The GNU Project Debugger.

It’s not just working incorrectly, it’s giving a SIGSEGV, and crashes reporting the source of the error to be in guard32.dll.

Several topics report the same problem without a fix:
https://forums.comodo.com/bug-reports/guard32dll-and-gdb-problems-cfp-3025378-t25287.0.html
https://forums.comodo.com/empty-t47098.0.html

(there are more, but no fix is given anywhere)

Disabling the sandbox does not help, so 1 is out. So is 2. 3 is just not the case. Number 4 sounds logical, but I have tried it without any success, I’ll try again, though. I can’t disprove 5, so I’ll have a look at it, but it doesn’t sound like that’s what’s happening.

Apparently it has been filed as a bug.

You can as a workaround disable the start of the guard32.dll. That will give some more D+ alerts. The autostart can be found under AppInit in Autoruns.

Are you sure it is? I mean, it’s been a problem since CIS 3 according to the topics in question - meaning that even if it was filed as a bug back then, the filing of the bug might be considered “outdated” since it is so old. It’s entirely possible that it’s just not been possible to fix the bug so far, but I wouldn’t blindly assume it’s been filed as a bug.

I read the same thing in one of the referenced topics, however, I also read that none of the people involved knew just what guard32.dll does.
It may be strange, but I prefer just telling D+ to be disabled (permanently) and knowing that D+ just isn’t working, over disabling some part of the software and just not knowing what does and what does not still function.

Having found a way to get both gdb and D+ to run alongside, I can now confirm that this problem no longer exists, even with D+ running. It seems it was indeed me having blocked it for the duration of the session somehow.

The guard32.dll gets injected in each running process. It helps to get less D+ alert. Disabling it will yield some extra D+ alerts.

Since it is a long standing problem you could issue a new bug report. Make sure to follow the guidelines as described in the stickies of the bug report sub forum. These guidelines should be followed strictly.

I basically returned here to report on the fact the change system time privileges were fixed now, I kept the gdb issue in the topic that was actually about that. I will, however, respond to your direct comment here.

I see, thanks for the information.

Now that I both know what disabling guard32.dll does and I have found how to get all to work without even disabling it, I don’t think a bug report is necessary (two programs injecting into a single program is just tricky, it’s likely it’s not even fixable unless you know the gdb code as well). On the other hand, I do think it would be a good idea to add it to the “programs requiring special settings” list.

How did you get it to work without disabling guard32.dll? Did you try gving gdb the updater/installer policy?

No I did not try that. I did try to give it a custom policy with “allowed” wherever possible, but that didn’t help any.

The way it worked was to add the executable I want to debug (rather than gdb itself) to the Image Execution Control exclusion list. This way D+ won’t have any hooks into the program, so gdb can freely have its hooks. It makes sense, but only once you have figured it out…

Thanks for clearing that up.