Перейти к содержимому


Eugene Muzychenko

Дата рег: 10 Сен 2010
Оффлайн Был(а) онлайн: Янв 20 2020 13:12
-----

Темы пользователя

CureIt не открывает установочный пакет нового VirtualBox

20 Январь 2020 - 13:14

Oracle пакует VirtualBox с версии 6.1 каким-то новым форматом, CureIt не воспринимает его, как контейнер.

 


CureIt! портит свою командную строку

05 Декабрь 2019 - 01:55

Сегодня обнаружил, что основной процесс CureIt! портит командную строку при передаче дочернему процессу.

 

Исходная командная строка:

 

<EXE-файл> /AR c:\tmp

 

Содержимое архивов не проверяется. В отчете - сообщение об ошибке:

 

Command line used:/rpcep:\pipe\36AD888A5C3 /rpcpr:np /sst /scn /ok /spn/ar c:\tmp
Ignore (invalid parameter): spn/ar

 

 

 

Судя по всему, процесс забывает добавить пробел после ключей по умолчанию.

 

Такое поведение весьма опасно - если не просматривать внимательно отчет после каждой проверки, можно не заметить, что какие-то ключи перестали применяться. Хорошо бы не только выводить сообщение в отчет, но и как-то отмечать любые ошибки в окне программы.


Предельная загрузка ЦП при сканировании процессов VM

08 Сентябрь 2019 - 12:58

Давно обратил внимание, что при сканировании памяти процессов виртуальных машин VMware Workstation (vmware-vmx.exe) CureIt! выходит на предельную загрузку всех ядер процессора (6820HK - восемь логических на четырех физических), и сканирует эти процессы очень долго (минут по пять каждый). При этом в хостовой системе (Win7 x64) все начинает очень сильно тормозить - видно, как перерисовываются окна, от клика по элементу GUI до его реакции может проходить до 5-10 секунд.

 

Cам CureIt! (по данным Task Manager и Process Explorer) в это время потребляет всего 15-20%, а все остальное приходится на виртуальные машины (2-3 процесса). В самих машинах при этом никакой явной активности нет - просто загружены разные версии Windows (7, 8.1, 10), и висят пустые рабочие столы. Фоновой активно, за исключением обычной системной, там тоже нет.

 

Памяти у этих процессов не особо много - один-полтора гигабайта у каждого. Параллельно работает 5-10 процессов FireFox, у которых памяти может быть и по два-три гигабайта на процесс, но их CureIt! сканирует за секунды. Вообще, если никаких VM не запущено, сканирование памяти процессов идет быстро, и не создает значительной нагрузки на процессор.

 

Отчего это может быть? Сказываются какие-то особые техники, применяемые CureIt! для чтения памяти процессов, или происходят какие-то коллизии с исполняющей системой VMM?


Куда сообщать о ложном срабатывании CureIt!?

27 Ноябрь 2018 - 22:13

Каким образом нынче принято сообщать о ложном срабатывании CureIt!? На сайте предлагается сообщать только о ложном срабатывании родительского контроля.


Стал регулярно падать Cureit!

27 Май 2011 - 12:32

В последний месяц регулярно (практически через раз) вижу падение разных версий CureIt! (уже штук шесть-семь) в одном и том же месте - в ntdll!RtlpCoalesceFreeBlocks (по адресу 7c911669). Падает исключительно на этапе начальной проверки при запуске - на сканировании файлов по выбору падений не было ни разу.
В CureIt.log ничего, относящегося к ошибке, не выводится, последняя запись перед падением - о дате истечения лицензионного ключа.

Прилагаю два минидампа скачанной сегодня версии (процесс 6968b_xp).

Падает одинаково на десктопе (Q9550) и ноутбуке (T8300). На обоих стоит 32-разрядная XP SP3 Eng, запускаю от имени обычного пользователя (без админских прав), режим повышенной защиты не использую.