SASGIS - SAS.Планета
View Issue Details
0000810SAS.Планета[All Projects] Багpublic20-06-2011 05:2802-08-2012 05:27
Parasite 
Parasite 
highblockrandom
closedno change required 
WindowsServer2003
110427.Beta 
 
0000810: Блокирование системы при долгой работе
При относительно долгой плотной и непрерывной работе с коннектами\скачками - бетка вешает систему.

Начинает проявляться всё с некоторых вкраплений строчек "Недостаточно системных ресурсов для завершения операции" в окне скачек. Со временем эти строчки появляются плотнее и плотнее, и в итоге в один прекрасный момент САС валит винду в pre-DDOS:
.из динамиков раздается повторяющийся звук системного еррора (эдакая "дробь"), при этом самого еррора - не выводится
.все остальные работающие до этого приложения не могут получить доступ к сети (ни к интернету ни к локалке)
.закрыть САС невозможно - он не реагирует ни на какие тычки в ГУЙ
.в системе невозможно запустить новых процессов (даже таскманагера - для прибития САСа)

Помогает лишь прибитие самой винды (кнопкой ресет, или жестким перезапуском вирт.машины).
Глюк резко подкрадывается ближе, если сами тайлы лежат не на винте а на удаленном сетевом хранилище - при этом может выбить винду примерно за 15...20 часов непрерывной работы. При этом строки лога "Недостаточно системных ресурсов для завершения операции" перемежаются множащимися строками "Ошибка - невозможно сохранить файл <\\Server\path\file>" или как-то так.

О точных причинах сказать ничего не могу - на момент его появления ничего запустить\проверить уже не представляется возможным, система просто дохнет.

В сильно-прошлых версиях (например юзаю 100330) - этого глюка ни разу не было. Качает по полгода без остановки - и ничего.
Подозреваю, что где-то что-то не смывается в сокетах, и винде в конце концов сносит башню.
No tags attached.
related to 0000550closed vdemidov Еррор C0000006: блокада операций 
Issue History
20-06-2011 05:28ParasiteNew Issue
20-06-2011 05:31ParasiteNote Added: 0002992
20-06-2011 06:21vdemidovNote Added: 0002995
20-06-2011 06:21vdemidovStatusnew => feedback
20-06-2011 07:04TolikNote Added: 0002997
20-06-2011 07:15vdemidovNote Added: 0002998
20-06-2011 09:27gpsMaxNote Added: 0003000
20-06-2011 09:28gpsMaxNote Edited: 0003000bug_revision_view_page.php?bugnote_id=3000#r1490
20-06-2011 09:29gpsMaxNote Edited: 0003000bug_revision_view_page.php?bugnote_id=3000#r1491
20-06-2011 09:31gpsMaxNote Edited: 0003000bug_revision_view_page.php?bugnote_id=3000#r1492
20-06-2011 10:51ParasiteNote Added: 0003002
20-06-2011 10:51ParasiteStatusfeedback => new
20-06-2011 11:22vdemidovNote Added: 0003004
20-06-2011 11:50vdemidovStatusnew => feedback
20-06-2011 12:33gpsMaxNote Added: 0003007
20-06-2011 12:34gpsMaxNote Edited: 0003007bug_revision_view_page.php?bugnote_id=3007#r1494
20-06-2011 19:00ParasiteNote Added: 0003010
20-06-2011 19:00ParasiteStatusfeedback => new
20-06-2011 19:05ParasiteNote Edited: 0003010bug_revision_view_page.php?bugnote_id=3010#r1500
23-06-2011 14:48ParasiteNote Added: 0003040
23-06-2011 18:58feyaNote Added: 0003043
24-06-2011 10:02gpsMaxNote Edited: 0003043bug_revision_view_page.php?bugnote_id=3043#r1518
28-06-2011 11:35TolikStatusnew => acknowledged
10-07-2011 04:29ParasiteNote Added: 0003133
10-07-2011 19:56gpsMaxNote Added: 0003134
10-07-2011 19:58gpsMaxNote Edited: 0003134bug_revision_view_page.php?bugnote_id=3134#r1577
11-07-2011 07:49ParasiteNote Added: 0003138
11-07-2011 07:59vdemidovNote Added: 0003139
11-07-2011 08:00vdemidovAssigned To => vdemidov
11-07-2011 08:00vdemidovStatusacknowledged => feedback
11-07-2011 08:00vdemidovAssigned Tovdemidov =>
11-07-2011 09:38ParasiteNote Added: 0003140
11-07-2011 09:38ParasiteStatusfeedback => new
11-07-2011 09:49vdemidovNote Added: 0003141
11-07-2011 09:49vdemidovStatusnew => feedback
11-07-2011 11:09ParasiteNote Added: 0003142
11-07-2011 11:09ParasiteStatusfeedback => new
14-07-2011 08:28TolikStatusnew => acknowledged
21-07-2011 05:22vdemidovNote Added: 0003226
21-07-2011 05:22vdemidovStatusacknowledged => feedback
21-07-2011 09:07vdemidovRelationship addedrelated to 0000550
21-07-2011 15:52gpsMaxNote Added: 0003234
02-08-2011 04:11gpsMaxNote Added: 0003290
09-09-2011 20:33vdemidovNote Added: 0003829
12-09-2011 04:57zOnNote Added: 0003870
12-09-2011 04:57zOnNote Edited: 0003870bug_revision_view_page.php?bugnote_id=3870#r1948
12-09-2011 05:05gpsMaxNote Added: 0003873
12-09-2011 05:07zOnNote Added: 0003875
12-09-2011 10:24ParasiteNote Added: 0003889
12-09-2011 10:24ParasiteStatusfeedback => new
12-09-2011 10:26zOnNote Added: 0003890
13-09-2011 04:38gpsMaxNote Added: 0003891
14-09-2011 06:05vdemidovStatusnew => feedback
17-10-2011 04:33gpsMaxNote Added: 0004094
17-10-2011 04:38gpsMaxNote Edited: 0004094bug_revision_view_page.php?bugnote_id=4094#r2076
17-10-2011 04:43gpsMaxNote Edited: 0004094bug_revision_view_page.php?bugnote_id=4094#r2077
17-10-2011 05:55ParasiteNote Added: 0004095
17-10-2011 05:55ParasiteStatusfeedback => new
30-01-2012 06:03ParasiteNote Added: 0005261
30-01-2012 06:19vdemidovNote Added: 0005262
30-01-2012 06:38ParasiteNote Added: 0005264
30-01-2012 07:01ParasiteNote Edited: 0005264bug_revision_view_page.php?bugnote_id=5264#r2642
30-01-2012 10:15vasketsovNote Added: 0005266
30-01-2012 14:04ParasiteNote Added: 0005267
30-01-2012 14:05ParasiteNote Edited: 0005267bug_revision_view_page.php?bugnote_id=5267#r2644
31-01-2012 20:14gpsMaxNote Added: 0005281
01-02-2012 04:58ParasiteNote Added: 0005285
14-02-2012 21:28vdemidovStatusnew => resolved
14-02-2012 21:28vdemidovResolutionopen => no change required
14-02-2012 21:28vdemidovAssigned To => Parasite
17-02-2012 16:14TolikStatusresolved => closed
17-02-2012 16:14TolikAssigned ToParasite =>
17-02-2012 16:14TolikAssigned To => Parasite
02-08-2012 05:27ParasiteNote Added: 0008037

Notes
(0002992)
Parasite   
20-06-2011 05:31   
Возможно, связано с тикетом 434. Не уверен - слово за разработчиками.
(0002995)
vdemidov   
20-06-2011 06:21   
Насилуй дебажную версию. Никаких идей нету.
(0002997)
Tolik   
20-06-2011 07:04   
А ещё интересно, наверное, погонять последний ночной билд. Там какие-то утечки памяти были пофиксены.
(0002998)
vdemidov   
20-06-2011 07:15   
Пофиксены утечки, которые в нем же и добавлены :)
(0003000)
gpsMax   
20-06-2011 09:27   
(edited on: 20-06-2011 09:31)
У меня тут батником качаются некоторые вещи. Так вот, через несколько дней непрерывной работы как раз начинаются ошибки "Ошибка доступа" при записи файлов на диск и приходится перезагружаться - системе сносит башню, работать уже нельзя вообще никак. Какая-то виндовая ошибка, имхо, не связанная с САСом.

Семерка x64 SP1, что самое обидное. Типа последнее поколение майкрософтовских систем.

(0003002)
Parasite   
20-06-2011 10:51   
>Какая-то виндовая ошибка, имхо, не связанная с САСом.
Почему-то эта "виндовая ошибка не связанная с САСом" никак не проявляется с экзешниками прошлых версий (всё остальное - то же самое: карты, хранилища кэша и сам кэш, метки, и даже собственно конфиги практически идентичны).

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

PS: в качестве временного решения откатился назад на 100330. Мониторю тикет. :)
(0003004)
vdemidov   
20-06-2011 11:22   
Мониторь, но толку то? Я даже не подозреваю в чем может быть проблема. Так что без дополнительной инфы 2015 год или позже.
(0003007)
gpsMax   
20-06-2011 12:33   
(edited on: 20-06-2011 12:34)
Подозреваю, что причина не в сокетах, а как раз в дисковых операциях. На это же намекает и упоминание про сетевое хранилище. И причина, уверен, локально виндовая.

(0003010)
Parasite   
20-06-2011 19:00   
(edited on: 20-06-2011 19:05)
>Так что без дополнительной инфы 2015 год или позже.
Как только - так сразу. Не раскачивай лодку - для меня каждое обновление как серпом по...ну, просто серпом. :) Основной порн в том, что оно валит всю систему - а у меня в оной как правило далеко не единственный САС и жестко ребутать дохлую VM и терять данные с соседних задач потом мне не с руки. А отдельную запускать - жирновато будет.... :)
Скачаю дебажную версию, погоняю, отпишуся.

>что причина не в сокетах, а как раз в дисковых операциях.
Какие еще "дисковые операции" при сетевом хранилище? Те же самые сетевые соединения, только порт\протокол другие. Дисковые же операции идут на другой стороне мира, я их не вижу\никогда там не был\отношения к ним вообще не имею, оно просто работает да и все.

И, опять же - повторяю: на версии 100330 всё ок (на том же удаленном хранилище). Вот прямо сейчас в пяткЕ-десятке копий запущено, с десятком процессов в каждой. И еще несколько в задачах висят полгода уже без перекура. Работают себе....
Стоило врубить бетку парой дней назад - и началось шоу.

(0003040)
Parasite   
23-06-2011 14:48   
UPD:
.баг проявляется (и повторяется) на текущей бете + последние (июньские) автоапдейты от винды'2003Serv.
.баг НЕ проявляется на 100330 + последние (июньские) автоапдейты от винды'2003Serv.
.баг НЕ проявляется на текущей бете без последних автоапдейтов от винды'2003Serv.

То ли в последнем автоапдейте что-то отломали от Винды, то ли последняя бета с ним конфликтует.
(0003043)
feya   
23-06-2011 18:58   
(edited on: 24-06-2011 10:02)
Parasite, может попробуешь предыдущие релизные версии, хоть сузим временные рамки.

(0003133)
Parasite   
10-07-2011 04:29   
Проблема в изменении логики KernelPagedPool в последних апдейтах для вин2003серв. При активных многочисленных коннектах [сейчас] выюзываюся все доступные системные хэндлеры, и почему-то не закрываются\не смываются (либо таймауты закрытия у них стали намного выше - не разбрирался). В любом случае, это системный глюк(?) или даже фича, а САС просто вступает в нее всем фейсом при активной работе.

Я специально сделал постороннюю программку, активно выюзывающую хэндлеры. Проблема повторилась. :(

PS: в вин7 тоже эта проблема есть, судя по гуглу: https://media.blackhat.com/bh-dc-11/Mandt/BlackHat_DC_2011_Mandt_kernelpool-wp.pdf и кучка KB's у самого Микрософта (где "Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section" ©).
В общем, кривость винды в своем репертуаре. Отломали даже то, что раньше как-то работало.
(0003134)
gpsMax   
10-07-2011 19:56   
(edited on: 10-07-2011 19:58)
Большое спасибо за раскопки. Таки да, похоже, в Win7 эта проблема наличествует в полный рост, о чём писал выше. Симптомы удивительно точно описаны еще в описании тикета. Поскольку майкрософт патчить это дело не спешит ни в 2003, ни в 7, есть мысли по обходу этой багофичи?

(0003138)
Parasite   
11-07-2011 07:49   
>Таки да, похоже, в Win7 эта проблема наличествует в полный рост, о чём писал выше.
А меня почему-то напрягает то, что на более старой версии глюк таки НЕ ВОСПРОИЗВОДИТСЯ. То ли она просто медленнее работает и всё за ней успевает вовремя подчищаться даже со штатными таймаутами, то ли в новой что-то менялось как минимум в сторону работы с тайлами\сокетами\открытием-закрытием оных.

Кстати, заметил также что при проверке кэша (уже имеющегося) в старой версии лог в окне закачки непрерывно бежит, а в новой - скроллится раз в секунду (при этом кол-во отработанных за секунду тайлов примерно равное в обоих случаях). Оно конечно к хэндлерам не очень близко - но как минимум показывает, что что-то где-то в процедуре скачки\проверки менялось и ВОЗМОЖНО причина сидит где-то рядом со всем этим. Не уверен, обгонять не буду. :)

>есть мысли по обходу этой багофичи?
Мысли-то есть, а вот обходов - пока нету.
Пока суть да дело - ссадил САСа с винды обратно в выня. Неделя - полет пока что нормальный... :)
(0003139)
vdemidov   
11-07-2011 07:59   
Может и в этом дело. Раньше, после закачки тайла, поток закачивалки останавливался и ждал основной GUI-поток, что бы вывести сообщение в лог, а сейчас он просто добавляет его в буфер, а уже GUI-поток по таймеру проверяет этот буфер и выводит новые сообщения на экран.
Так что раньше (это было ну очень давно) получалась естественная пауза после завершения закачки каждого тайла. Попробуй поставь в параметрах карты Sleep=1
(0003140)
Parasite   
11-07-2011 09:38   
>Попробуй поставь в параметрах карты Sleep=1
Так я выше говорил про проверку локального кэша (который уже скачан). Про ситуацию, когда в логе строчка "Тайл уже имеется в кэше". Там же Sleep вроде как уже не работает, какой смысл карту мучать?
(0003141)
vdemidov   
11-07-2011 09:49   
>Так я выше говорил про проверку локального кэша (который уже скачан). Про >ситуацию, когда в логе строчка "Тайл уже имеется в кэше". Там же Sleep вроде как >уже не работает, какой смысл карту мучать?
Определись, проблема при закачке или проявляется и без обращения к http
Если при закачке, то слип поможет. А если и без нее есть, то это совсем другое дело.
(0003142)
Parasite   
11-07-2011 11:09   
>Определись, проблема при закачке или проявляется и без обращения к http
На наст.время нет возможности сказать, вызывается баг на сокетах или на файловых операциях. На сайте Микрософта опять же есть KB и про то и про это (два про переполнения на сокетах и один - на хэндлерах\пуле ядра, все три - нерешаемые при попытке повторения рекомендуемых фиксов там). Записей в логах система при данном баге не оставляет, и какой конкретно из них имеет место быть - наверняка сказать невозможно. Все три детектируются по планке PagedKernelPool выше лимита для юзаемой системы, и это как раз то что у меня и светится при начале глюка.

Обращения к http постараюсь изолировать, но сетевой трафик в моем случае будет _всегда_, увы (вся куча с кэшем - удаленная). Отпишусь позже, как результаты будут.
(0003226)
vdemidov   
21-07-2011 05:22   
Самая простая проверка, которую можно, для начала, сделать, это поставить карте Sleep в 1 милисекунду. На производительности не должно сильно сказаться, и будет эмулироваться работа очень старых версий, которые после скачки каждого тайла синхронизировались с основным GUI потоком.
(0003234)
gpsMax   
21-07-2011 15:52   
А номера статей KB можно озвучить?
(0003290)
gpsMax   
02-08-2011 04:11   
У меня в ивентах вот такая ошибка попадается перед залочиванием системы
http://support.microsoft.com/kb/971905
RAID'ов нет. В инете есть несколько упоминаний, но без решений.
http://social.technet.microsoft.com/Forums/ru-RU/windows7ru/thread/603e0edb-f863-40ce-8115-96c8bb981c06
http://forums.tophardware.ru/viewtopic.php?f=11&t=1628
Дисковые операции всё-таки, как минимум, в данном случае. Как избавиться - хз.
(0003829)
vdemidov   
09-09-2011 20:33   
Ну так как результаты экспериментов? Пробовал качать с задержкой в 1 мс?
(0003870)
zOn   
12-09-2011 04:57   
Parasite, у вас случайно не установлен AnVir Task Manager?
или еще какой монитор трафика.

(0003873)
gpsMax   
12-09-2011 05:05   
Интересный комбайн. Только вот мониторинг трафика он делать всё же не умеет, судя по всему.
(0003875)
zOn   
12-09-2011 05:07   
Умеет, но у меня это приводило к BSOD http://sasgis.org/mantis/view.php?id=805 при длительной сетевой нагрузке. Он мониторит каждый процесс.
(0003889)
Parasite   
12-09-2011 10:24   
>А номера статей KB можно озвучить?
Ну конечно можно.

>Пробовал качать с задержкой в 1 мс?
Пока нет. Оно, зараза, с того времени и не падало (работая в wine), а стопорить ручками и грузить винду как-то повода не было больше. Как упадет - попробую.

>у вас случайно не установлен AnVir Task Manager?
Я даже не знаю что это.

>Он мониторит каждый процесс.
А в чём смысл мониторинга каждого процесса?
(0003890)
zOn   
12-09-2011 10:26   
>А в чём смысл мониторинга каждого процесса?
ну как бы здесь не об этом. мне удобно искать всякую бяку, которая сжирает сетевые ресурсы.
(0003891)
gpsMax   
13-09-2011 04:38   
>>А номера статей KB можно озвучить?
>Ну конечно можно.
:-)
(0004094)
gpsMax   
17-10-2011 04:33   
(edited on: 17-10-2011 04:43)
Апдейт темы.

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

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

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

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

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

(0004095)
Parasite   
17-10-2011 05:55   
>Почитав некоторое время назад журнал событий, увидел там ошибки 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
(0005261)
Parasite   
30-01-2012 06:03   
Итак, продолжаем сабж свежепоявившимися деталями.

Вчера я токи решил поплотнее заняться вопросом, ибо винда под плотной закачкой последней ночнушкой не проживает и 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 - отключение его в дупу першило вопрос.

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

В общем, мониторьте систему - некоторые проблемы в работе САСа могут быть не связаны с багами программы САС напрямую, и как говорится - кто бы мог подумать, что по сути ненужная иконка Анлокера может блокировать запись сасового кэша в сетевое хранилище (см.первый пост).... ;)
(0005262)
vdemidov   
30-01-2012 06:19   
Все равно не понятно, почему наличие запущенного САСа ускоряло процесс утекания ресурсов. И если продолжает утекать, но медленнее, то лечить все равно нужно.
(0005264)
Parasite   
30-01-2012 06:38   
(edited on: 30-01-2012 07:01)
Нужно, но статус тикета можно сменить с радикальной аварии на обычный или даже низкий, бо безболезненно перезапустить САСа гораздо проще, чем перезапустить эксплорера.

А утекание под сасом возможно вызвано большим числом хэндлеров на к.тайл, и медленным их закрытием в системе по таймауту - особенно в случае сетевых операций, упомянутых в первом посте. То есть, это скорей всего даже не утекание, а фича работы оси - бо тайлы качаются быстрее чем таймаутятся, и подкручивание оси на предмет таймаута наверное решит проблему. Имхо.

Помониторю еще, если чего интересного еще найду - доложусь.

(0005266)
vasketsov   
30-01-2012 10:15   
>Unlocker
Вот спасибо за исследование. А то стоит виста без анлокера - работает и качает многосутками. А XP с анлокером на ночь всегда вырубаю, иначе утром ей уже плохо бывает. Хотя изначально я б сделал противоположные ставки на сравнительную усточивость этих двух систем.
(0005267)
Parasite   
30-01-2012 14:04   
(edited on: 30-01-2012 14:05)
>А то стоит виста без анлокера - работает и качает многосутками. А XP с анлокером на ночь всегда вырубаю, иначе утром ей уже плохо бывает.
Ну я описал только сугубо свое ковыряние - в Вашем случае может быть совершенно другая причина. У меня просто был _действительно_ старый Анлокер, от 2005го года если не ошибаюсь.

Попробуйте, ссылка на тулзу выше дана. Запускаете тулзу, ставите ее AlwaysOnTop, и вызываете пару десятков раз правоклик на любом файле. Если число "Bitmap" в процессе Explorer.exe увеличилосбь на число правокликов - то это оно.

Даблкликаете в тулзе на эксплорере - откроется список объектов. Смотрите, какие последние Bitmap - и что в них содержится. Медитируете, материтесь, делаете выводы и телодвижения. :)

(0005281)
gpsMax   
31-01-2012 20:14   
Шаман, однако! Мегареспект за копание в таких глубинах системы.
(0005285)
Parasite   
01-02-2012 04:58   
>копание в таких глубинах системы.
Ну не такие уж и глубины, собсственно. Основы виндоГУЯ, будь он неладен. ХПшным системам уже более 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 обьекта по запросу есть фича оси. :)
(0008037)
Parasite   
02-08-2012 05:27   
>а уж потом не спеша искать утечки в том, что и так работало.
Гадость не спеша токи найдена: причиной был глючный Outpost Firewall, подвешивающий некоторые сокеты со своей стороны при долгой работе и высокой нагрузке (особенно при качании на сетевые шары). Рестарт закачки в сасе просто открывал новый тред, работавший до поры до времени - но старый так и висел, и в определенный момент очередь свободных сокетов выюзывалась до нуля -> извольте ребутаться.

Удаление Outpost Firewall решило проблему - теперь скАчки идут месяцами.