вы входите в систему как администратор?

Какой сценарий Вы имеете в виду, который у пользователя? Ну это да, только вот системные приложения не скрываются у всех при проставленной галке. И нет дополнительного предупреждения о том, чтобы дважды подумали перед таким действием.

Ну так это же "очень маловероятный сценарий" 🙂 Нет я не спорю, он действительно такой, но тем не менее. Кстати, а полный сброс настроек не помогает?

@Вова Есть большая вероятность, что обычным способом не получится войти в среду восстановления, чтобы запустить безопасный режим. Тогда воспользуйтесь способом с тремя сбоями загрузки, в этой статье он самый последний в списке (Дополнительные способы запустить безопасный режим, 2). Только не на второй, а именно на третий сбой загрузки ОС запустится восстановление с возможностью запуска БР. У меня по крайней мере, именно так приходится делать. Других способов вернуть настройки продукта в норму я не нашел.

Об этом уже давно сообщал, и не только я, пока новостей нет. На бете 24 то же самое.

We have raised a ticket on this case and investigated the root case and solved . For identifying root cause, we have collected Netagent traces , wireshark packets from KSC and problematic endpoints and gsilogs and shared to Kaspersky support. Root Cause of the Issue: From NET trace (left = client, right=KSC) we see that the client device connects to KSC by TCP:13000 and starts a TLS handshake by sending TLS Client Hello - Client-Hello.png. Which is received by the KSC server. Then KSC replied by Server hello packet - Server-Hello.png, but the client device did not receive this packet, also, you can see that KSC sent packet with size = 2475 bytes, but the client received packet only = 1015 bytes what means that some device between the KSC server and the client device changed the traffic, so the problem is the customer network infrastructure. Solution: Since the standard Ethernet frame size, including headers and trailers, is approximately 1518 bytes, the 2475-byte packet effectively behaved like a jumbo frame. Because the network path was not configured to support jumbo frames end-to-end, the oversized packets could not pass through cleanly, which resulted in incomplete delivery to the client device. To address this, we configured ,maximum segment size (mss) or payload size to 1360 bytes on the router. By lowering the maximum segment size, TCP packets are now kept within a size that remains safely below the MTU limit across the entire network path and ensures that packets are delivered intact from the server to the client.

Получается еще "баг фильтра" - скрывать системные приложения.:

Багу отправили коллегам.