0000810: Блокирование системы при долгой работе

Апдейт темы.

Почитав некоторое время назад журнал событий, увидел там ошибки NTFS (спасибо Паразиту за наводку), далее почитал про эту систему в общем и частном. Для меня, кстати, было неприятным открытием, что мелкие файлы она хранит прямо в таблице размещения файлов, которая от этого раздувается и дико тормозит, но это к слову.

Я сделал другой контейнер, отформатировал его в exFAT, новую майкрософтовскую файловую систему. Сразу же порадовался нормальной скорости работы на том же наборе файлов, и огорчился отсутствию сжатия - многое в тот же объём не влезло, увы. Пришлось убрать ещё пару редко используемых карт.

Снова начал качать тайлы пачками. Через несколько дней, как и прежде, словил блокировку системы. Теперь можно утверждать, что это не зависит от файловой системы. В журнале событий пусто.

У меня тут процесса, собственно, два - массовая закачка тайлов САС.Планетой и массовая их обработка скриптами. Первый генерит преимущественно сетевые запросы, второй с сетью работает мало, зато активно дёргает диск. К сожалению, на момент сбоя было запущено и то, и другое. Через некоторое время постараюсь провести более чистый эксперимент.

Номера KB и коды/источники событий при блокировке системы всё-таки были бы полезны.

>Почитав некоторое время назад журнал событий, увидел там ошибки NTFS
Вечером перечитывал пейджер. Много думал...(с) :)
Вышеописанный баг может проявляться в самых разных ипостасях, в первую очередь он бьет в темечко процессам и устройствам, активно юзающим kernel pool (сюда относятся такие "нативные" и "жестко вшитые" для винды операции, как работа с драйверами FS, драйверами оборудования и проч). ntfs.sys, tcpip.sys, extfs.sys и прочие *.sys подвержены в первую очередь, так как работают напрямую с ядром - насколько я знаю архитектуру винды.
Отсюда при появлении бага - он может вылезти где угодно, вероятность появления в вышеуказанных критических местах - соответственно, максимальна и равновероятна. Что мы и наблюдаем: у меня при активной работе с сетевыми дисками - отваливается весь протокол (tcpip.sys), у камрадов при активной работе с дисками - отваливаются FS (ntfs.sys/exfat.sys), и проч.
Баг же - один: переполнение свопа ядра (ну или утечки в чем-то, что приводит к переполнению).
Баг известен Микрософту, работы ведутся © (с 2003 года как минимум - когда я сам лично им писал об этом - и они мне сказали, что это known problem of the Microsoft product).

>Для меня, кстати, было неприятным открытием, что мелкие файлы она хранит прямо в таблице размещения файлов, которая от этого раздувается и дико тормозит, но это к слову.
Еще больше Вам доставит попытка дефрагментации такого диска, ибо оно будет дефрагментировать один непрерывный файл ($Mft) меееелкими кусочками (тайлами внутри оного), и если места на диске будет мегьше чем текузий $Mft - то на середине процесса оно либо скажет что недостаточно памяти для завершения операции, либо тупо схлопнет процесс дефрагментации (а так как он аварийно схлопнется на процедуре модификации именно $Mft - то ничем хорошим это не грозит). В особо циничных случаях подчистую слетает весь раздел диска - винда говорит, что на разделе она нашла ФС "RAW", и еще более цинично предлагает отформатировать. :)

>это не зависит от файловой системы.
Боян.

Вот, собссно, разбор полетов и даже тулзы для воспроизводства бага от гуру ковыряния в винде (лично я нижеприведенную там картинку "Insufficient resources" вижу примерно раз в неделю):
http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx
http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx
...правда на этом и всё, ибо радикального и однозначного решения этому багу пока что нет. "Протекать" может даже не САС и даже не один из его компонентов, а например tcpip.sys или еще что-либо фундаментальное и юзаемое САСом - благо что проблема-то не только с САСом, а и вообще. Например на торрентах - весьма часто ловится (тоже весь протокол отваливается, либо диск). Тоже народ локти кусает, греша на приложение а не на саму винду...
http://forum.utorrent.com/viewtopic.php?pid=167057

Итак, продолжаем сабж свежепоявившимися деталями.

Вчера я токи решил поплотнее заняться вопросом, ибо винда под плотной закачкой последней ночнушкой не проживает и 2х суток(!). И токи занялся.

Выяснилось, что в моей винде с момента ее рестарта и до момента скукоживания - ПОСТОЯННО растет число USER и GDI объектов, причем чем более плотно идет работа - тем более быстро они растут. При достижении дефолтного лимита системы на число этих объектов (10.000 на кадждый, если не ошибаюсь) - получаем глюки, баги, выпадения частей гуя с разных окон, системные бибиканья еррором в динамик, мессаги "Недостаточно системных ресурсов" в лог и прочая прелести описанные в первом посте. Причем замечено, что число этих объектов растет и БЕЗ САСа - просто без него раза в 2-3 медленнее, чем с ним.

Далее была заюзана вот эта тулза для мониторинга GDI/USER pools:
http://www.downloadcrew.com/article/25850-bear
Выяснилось, что респаунит эти объекты не САС, не какая-то стороняя програма - а нащ старый знакомый explorer.exe, широко известный в узких кругах. При холодном старте и начале мониторинга он держит в GDI/USER пулах соответственно 318/254 объекта, при скукоживании винды - около 4х тысяч на каждый, что вкупе с другими программами и переваливало за системный лимит дня через 2-3. Остальные программы более-менее держали свои объекты на постоянном уровне, и при закрытии себя - схлопывали свои объекты и освобождали ресурсы. Эксплорер же в винде просто так не закрыть, кроме как кильнуть через 3 кнопки - что не есть расово верно.

Далее, был помониторен оный же эксплорер в безопасном режиме винды (с отключением всех левых драйверов\сервисов, могущих лезть в адресное пространство explorer.exe). Рост числа объектов не прекратился.

Далее, система была просто загружена в САМОМ минимальном состоянии с убитием всего до чего дотянулись руки - по большому счету осталось только ядро, эксплорер и несколько драйверов и критических сервисов.
Система была оставлена в таком виде в покое на несколько часов - не шевелили даже мышку. Рост числа объектов НЕ наблюдался, счетчик стоял стабильно.

Но с момента начала шевеления мышкой и проверки процессов\итд - счетчик ОПЯТЬ полез вверх, хотя ничего нового не было запущено.

Путем кучки телодвижений, матюков, пива и чьей-то матери пришло понимание того, что в данном конкретном моем случае число объектов GDI:Bitmap росло на +1, а число USER:Menu росло на +3 при КАЖДОМ ПРАВОКЛИКЕ МЫШОЙ В ЭКСПЛОРЕРЕ (и только в нем). То есть, вызов правокликовой менюшки и ее закрытие - получаем +4 объекта, и так далее пока не упремся в системный лимит на оные. Это касалось кликов на файлах, папках и десктопе, короче - Эксплорер во всей его красе.

При помощи всё той же тулзы было просмотрено, что же содержат новосоздаваемые объекты, и в конце концов хвост проблемы был пойман:
* В КАЖДОМ новосозданном GDI:Bitmap обьекте хранилась иконочка от программы Unlocker (махонькая, та самая которая отрисована в правокликовой менюшке эксплорера при установленном анлокере), и не киляется при деструкции меню;
* В КАЖДОМ из трех новосоздаваемых USER:Menu обьекте хранились меню, создаваемые программой TeraCopy из правоклика на файле\папке (Копировать в\Переместить в\Фэворитс...), и не киляются при деструкции меню.

Отключение обоих двух ShellExtension и рестарт эксплорера - решили проблему радикально: уже сутки счетчик GDI\USER практически стоит на месте в чистом эксплорере.

Вопрос с Анлокером решился просто: у меня была старая версия (1.6.0), а в чейнджлоге на версию 1.8.1 видим радующую глаз строчку: "Fixed bug: Unlocker leaked Icon GDI objects". Обновил его до последней версии, включил ShellExtension - пока что полет нормальный, иконка вроде бы больше не утекает.

Вопрос с ТераКопи пока под вопросом: сама программа работоспособна и из нее самой вроде бы ничего не утекает (да и закрывается она полностью после работы, освобождая все свои ресурсы), и проблема ТОЛЬКО с ее модулем встраивания в правоклик. Программа работоспособна и без него, но с оным - намного удобнее в работе.
Наверное отпишусь автору прожки, пускай обратит внимание - авось пофиксит утечку.

PS: при работе САСа счетчик GDI:Bitmap + SystemHandlers также растет вверх, но не очень быстро - и решается просто перезапуском САСа. Возможно, где-то что-то не смывается, и оно тоже в конце концов упиралось в лимит системы - отсюда был и 1й пост. Помониторю еще.

PPS: по этой же методе был помониторен и ноутбук. Тоже нашлась утечка, GDI тикал на +1 и не смывался каждое нажатие левого Шифта. Оказалось, что виноват был режим StickyKeys - отключение его в дупу першило вопрос.

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

В общем, мониторьте систему - некоторые проблемы в работе САСа могут быть не связаны с багами программы САС напрямую, и как говорится - кто бы мог подумать, что по сути ненужная иконка Анлокера может блокировать запись сасового кэша в сетевое хранилище (см.первый пост).... ;)

>копание в таких глубинах системы.
Ну не такие уж и глубины, собсственно. Основы виндоГУЯ, будь он неладен. ХПшным системам уже более 10и лет с момента выпуска, при установке оной - ставятся дефолтовые настройки\оптимизации по состоянию "как оно было юзабельно 10 лет назад" - в время-то идет, и кол-во данных\софта\запросов к ресурсам у пользователя за это время несколько выросло. Да и сегодняшнее среднестатистическое железо отличается от оного же в 2001м году раз так в несколько, и соответственно - может много больше, чем система ставит в настройках по умолчанию и в кои среднестатистический хомяк никогда и не лазит, пока всякие твикеры не начнет ставить.

Посему для начала дохтур рекомендует подкрутить системные лимиты GDI\USER (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\(GDI|USER)ProcessHandleQuota) токи до максимума (лично я себе крутанул с 10К до 30К и тех и других), а уж потом не спеша искать утечки в том, что и так работало.

PS: кстати, а неплохой эксплоит для винды получится - и все антивири пропустят. Мелкая программка или даже быдлоскриптиик, создающий over9999 пустых GDI+USER -обьектов - и Эксплорер гарантированно выйдет отдохнуть (а за ним и вся винда сразу же после первого же запроса на создание GDI\USER - бо без гуя она неработоспособна в принципе). А антивири пропустят потому что деструктивного кода не несет - создание GDI\USER обьекта по запросу есть фича оси. :)