time to show popup - 999, and it disappears in about 5 minutes after popping up. So what happens?
W7x64SP1+, MSE4, CIS latest.
Why you just can’t make it stay infinite period of time and some 999 ~ weird 5 minutes in time?
btw process on, whose D+ popup disappeared, still remains “suspended” not giving the API results stolen by the CIS internals. No window, no process running with some predefined behavior, no interaction available until some 999 values elapsed without window and user intervention allowed after about 5 min.
From CIS’s point-of-view a default block will happen.
Because usually there is little point, whatever was asking for something would have either timed-out, terminated, crashed or hung depending on how whatever was coded to deal with being silently denied the something it asked for. The longer the wait period is, the more likely it is that whatever will not complete gracefully.
You’re kind of misunderstand the logic behind these processes of blocking/nonblocking user reaction on events.
If timed out or by user reaction only - surely it will be negative answer by default, but during this period process is blocked / internally handmade “suspended” until infinite or 999 in time. I prefer infinite time to count on user decision only. But the problem is in CIS itself as its popup window just disappears after 5min of ontop. Process still freezed for some unknown -999- period as I should be until user decision of timeout. But I don’t like silent timeouts or timeouts whatsoever, If user is absent no “auto actions should be silently made” policy must be available not only the presence of all the 999 disappeared by some unknown reason popup.
On graceful completion again - you misunderstand logic that completely freezes process, its internal times, ticks etc. that latter user’s decision will not do any changes in flow, thus nothing can harm the process. Just I need a popup at least as declared 999, but better as infinite timeout, zero value “0” can be used for this *hint for devs to implement it through current 1-999 interval. However I can only guess why this hasn’t been done yet - the Sleep states like S3/S4 that can supposedly behave wrong on such infinitely manually “suspended” (not via API) processes. Who knows…
Firstly all alerts are logged, so none are unknown.
Secondly, in the end CIS either blocks (denies) or allows. There is nothing else, silent time-outs or anything. Just block or allow.
If a process has frozen/hung when CIS’s alert disappears, then the process would have done that anyway because that’s how it has been coded (exception handling) and it missed CIS’s default “block” when the alert disappeared. This probably happens because the process didn’t expect to have to wait for resource/device that it had been temporarily denied (silently denied, not to be confused with silent time-outs, etc…) to it by CIS. In short, nothing to do with the alert being visible or not.
If you’re a coder, this is why CIS D+ is extremely useful for exception hardening/testing.
You’re talking to yourself only. reread all above to understand all the points of logic and what’s broken in realization of logic.
This topic made for CIS programmers and reports observed issue and possible improvements on product. You’re talking irrelevant things, obvious to post above and not dealing to any questions mentioned above.
Don’t post irrelevant things, better test described scenario your self and post results.
and btw fyi process is blocked by cis on any d+ popup for user interaction, and again - reread above, maybe all mechanisms of cis working will be clearer to you, to know what’s blocking/nonblocking cis behavior (which is first, thus process is “blocked” until…). No need to comment, accept or test to raise ticked by one.
From the information you have given I am not clear whether this is a bug/issue.
For the moment I will transfer you to help so you can work through this issue with users and mods in this forum and hopefully resolve it. I hope that is OK.
Please ask any mod to move this report back to the bugs forum if it becomes clear that it is a bug/issue.
