Long Delay for UAC Prompt to Appear?

Since the last update to 1607 Build 14393.576 on two PCs, it now takes about 30s for the UAC prompt or cmd.exe window to first appear on both PCs. Subsequent UAC prompts appear after a normal delay. Both PCs have Kaspersky Internet Security (KIS) 2017.

I discovered turning the UAC settings down one notch (see below) to avoid the screen dimming solves the problem.
​Attachment 113716

Has anyone else noticed this weird bug/issue issue and is there a fix?

I use various policies, which cause UAC to appear a few secs later but 30 sec, that is a bit too much, though I have seen it. Try a general cleanup (I use WC), maybe even removing all policies, Windows will reset them upon restart.

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies" /f
reg delete "HKCU\Software\Policies" /f
reg delete "HKLM\Software\Policies" /f
reg delete "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies" /f
reg delete "HKLM\Software\WOW6432Node\Microsoft\Policies" /f
reg delete "HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies" /f
reg delete "HKLM\Software\WOW6432Node\Policies" /f

Well, you do not really need to run all of those, I just have them included in the bat.
It would be vague, to try to explain some of it just with just one word, so some links:

fsutil usn deletejournal /d /n c:
Fsutil usn

compact /CompactOs:never
Compact OS - Compress or Uncompress Windows 10 - Windows 10 Tutorials

winmgmt /salvagerepository
WMI: Rebuilding the WMI Repository | Ask the Performance Team Blog

vssadmin delete shadows /for=c: /all /quiet
It removes all system restore points, file history, file backups.

The biggest delay for me is caused by this entry, which shows, what triggered UAC prompt.

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v "ProcessCreationIncludeCmdLine_Enabled" /t REG_DWORD /d "1" /f

I am responding to this ancient thread because it was a key stepping stone in my search for an answer.
I tried all that was here, and still no joy.
It turned out that my problem was with consent.exe.

Using Process Monitor from the sysinternal tool Suite, I monitored the system during the delay. From some posting (maybe this one) I got the hint to look and see what consent was doing.
After discovering the file and URL accesses going on while I was waiting, I identified consent's accessing the network was the problem.

I wondered 1) if consent.exe is a legitimate program, 2) if its use of the network is legit (why does it attempt to connect to an external server), and 3) if there is any reason to allow it.
Some commentary follows; the short answer is that it is OK, and no, you don't want to block it:

1. Assuming that the copy of consent.exe on your system is good, then what is it doing anyway?
   
2. Consent is part of the user access control (UAC) system. Among many other things, before it allows anything to run based on signatures & certificates, it wants to check to see if any certificates have been revoked.
   To check the revocation information consent has to 'phone a friend'. Consent does this for allof your certificates each time that it does not have current, trusted information.
3. Can you block it from network access? Well there are 2 reasons that you may not want to do this:
   

• Going back to a really trusted root gives you a bit more safety. It is of course your choice, but as for me and my machines, we will check the root.
  
• For me, when I did not provide access to all of the Trusted Roots the UAC prompt took almost 30 seconds to come up.
  

This delay was a mystery to me, and might be to you. I was using self-signed machine-specific code-signing certificates rooted from my machines at work. These certificates were being checked via a ROOT that was not accessible. Unfortunately, the internal work network is usually behind a firewall. This means that the revocation check has to timeout.
So in summary:
1. Yes
2. Yes
3. Yes
Happy hunting.
Ah, so what did I do? I removed all of the offending certificates -- my UAC prompt now comes up faster than I can blink.

(I used mmc certlm.msc and certmgr)