Конференция VBStreets

Не так давно стал замечать странный баг в работе механизма отрисовки окон в Windows.

Такое впечатление, что кто-то в определённые момент времени начинает фильтровать WM_PAINT и WM_NCPAINT. Оборачивается, это, естественно, тем, что многие приложения не перерисовывают свои окна и имеют мусор на них.

Пока разбираться и деттально копать нет времени.

Никто не встречался с таким у себя?

На Win7 x64 такое было регулярно, обычно когда над IDE пронесешь другое окно то в окне кода мусор и больше половины символов не видно.

Это баг IDE, я его всю жизнь наблюдаю.

Сейчас речь об XP, а страдают все приложения.

Хакер писал(а):Это баг IDE, я его всю жизнь наблюдаю.

Сейчас речь об XP, а страдают все приложения.

Странно, но сейчас у меня XP и в IDE все в порядке.

Ну он не всегда в IDE проявляется, но часто бывает. Во всяком случае, я его не вчера наблюдать начал.

А то, о чём я пишу, буквально дня 4 назад появилось.

Вижу довольно часто, например, при перекрытии браузером аудиоредактора. XP SP3.

Если только аудиоредактор страдает, то это может быть багом аудиоредактора.

У меня же с недавних пор страдает всё:
FireFox, Skype, виндовый проводник и системные диалоги (например Пуск→Выполнить).

Хакер писал(а):У меня же с недавних пор страдает всё:

Возможно виноват баг в какой-нибудь сервисной утилите, которая цепляется ко всем процессам.
Можно просмотреть HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs, чтобы определиться с кандидатом.

Дело в том, что ничего не инсталлировалось. Абсолютно ничего.
Единственная вещь, которая была скачана и запущена и момент запуска которой совпадает с появления бага, — это игра Майкла.

А смотреть я конечно буду, но немного позже.

Любопытно, но при этом ещё и ломается возможность снимать скриншоты.

Если снимать снималками — то ломаются они.
Например SnagIt:

---------------------------
SnagIt
---------------------------
Unable to capture input.
---------------------------
ОК
---------------------------

Если снимать штатными средствами, то что-то в буфер обмена копируется, но при попытке вставить в Paint:

---------------------------
Paint
---------------------------
Ошибка при чтении данных из буфера обмена.
---------------------------
ОК
---------------------------

Хакер писал(а):Единственная вещь, которая была скачана и запущена и момент запуска которой совпадает с появления бага, — это игра Майкла.

Но там же ничего нет, кроме инициализации D3D в текущем режиме экрана. Если что-то и слетит по какой-то причине, то до перезагрузки системы.
Ты компьютер полноценно перезагружал? (мало ли, вдруг гибернацией пользуешься).
Как вариант - попробуй сменить битность режима экрана на 16 бит, а потом восстановить нормальную.

Компьютер обычно не перезагружается по 2—3 месяца, но в данном случае перезагружался несколько раз вчера.

Ищи живность.

Кстати, если скриншот всего экрана не вставляется, то скриншот одного окна вставляется, но оказывается при этом чёрно-белым (двухцветным).

Я думаю, что это не живность, а какая-то проблема в графической подсистеме. Возможно надо расчехлять memtest86.

Чем дальше в лес, тем больше дров.

До обеда были странные вещи:




Потом я уехал. А после приезда компьютер встретил меня этим:

(простите за смазанную фотографию).

igxprd32 — это как раз Intel Graphics 2D Rotation Driver, то есть отношение к графике самое прямое.

Хакер писал(а):Компьютер обычно не перезагружается по 2—3 месяца

Да, энергетика у вас надежная. У меня бы столько не простоял, энергетики бы выключится обязательно помогли

мож железки умирать уже начинают, кондеры пухнут и проч... у меня похожая чушь была перед смертью видяхи (ладно хоть не мать). Заменил - все норм стало.

Выдалась вчера возможности провести длинное тестированием Memtest'ом.

Итог: 18 циклов полного прогона всех тестов — ни одной ошибки.

Но не без странностей. Первые 4 прогона я наблюдал лично. Они заняли 1 час 24 минуты (или, другими словами — 84 минуты). Путём нехитрых подсчётов было получено, что на один прогон затрачивается 21 минута. Значит, планируемые мной 20 прогонов должны были занять 420 минут (или 7 часов). Я оставил тесты на 3 часа 20 минут, а когда вернулся, ожидал увидеть 9-ый прогон, но увидел 7-ой. Первая мысль — «почему-то тесты стали идти медленнее». Но на самом деле Memtest86+ показывал 100% завершённости прогона и 100% завершённости теста в рамках текущего прогона. И тем не менее, он не переходил к следующему прогону, а продолжал выплять тесты 7-го прогона.

Что это было: собственный баг Memtest'а, или как раз мы наткнулись на глюк памяти, но в этот момент в это области памяти лежал код или данные самого Memtest'а — сложно сказать.

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

Дальше я опять уехал. Вернулся через 11 с лишним часов (после запуска тестов): общее число выполненных прогонов равнялось 18, а ошибок — 0.

_____________

Вообще же я заметил, что описанный в начале глюк проявляется тем интенсивнее, чем больше в данный момент должно быть предположительно создано GDI-объектов. Появились глюки — закрываем чего-нибудь GDI-ресурсоёмкое — глюки отступают (но не обязательно надолго).

_____________

Kroos писал(а):мож железки умирать уже начинают, кондеры пухнут и проч...

Ну, во-первых, несколько рано.

Во-вторых, у меня несколько мониторов, и каждый получает свой сигнал от разных видеокарт. Один — от встроенное видео (встроенного даже не в материнку, а в процессор). Второй — от дискретной карточки nVidia GeForce 6200. Глюкам с непрорисовкой подверженны обе экранных плоскости в равной степени.

igxprd32, фигурирующий в BSOD-е, относится к первому источнику видео.

Складывается впечатление, что по большей части баги провоцирует процесс Скайпа. И момент появления бага тогда удачно совпадает с моментом автообновления скайпа (а такое было — после чего количество рекламы в нём превысило все мыслимые пределы).

А если, в качестве эксперимента, временно удалить Skype ?

Sam777e писал(а):А если, в качестве эксперимента, временно удалить Skype ?

Нельзя, он нужен в работе.

А если не удалять, а просто не запускать? Т.е. связан ли глюк с таким моментом: Запущен скайп или нет? По идее если приложение установлено, но не запущено, то оно никак не должно влиять на систему и остальные приложения, если конечно оно при установке не подменяет системные библиотеки и не инициирует скрытые процессы. А вообще конечно новый версии скайпа просто жуткая шняга. Я с того момента, как перестала работать версия 4.хх, просто перестал им пользоваться.

ger_kar писал(а):А если не удалять, а просто не запускать?

Хакер писал(а):Нельзя, он нужен в работе.

Тем не менее, за последние дни все эпизоды появления бага были при работающем Скайпе (в самом скайпе или совершенно посторонних процессах). В этот момент Скайп выключался и глюки проходили. Через некоторое время Скайп включался. Появления глюков при выключенном Скайпе замеченно не было.

Интересно, а если в процессе протекания глюка снять скрин всего экрана, то там их будет видно (на скрине) ?

В процессе протекания глюка скриншоты не снимаются же.

KVMкой/сфотографировать экран?

Debugger писал(а):KVMкой/сфотографировать экран?

А смысл?

Я так понял, что ger_kar интересуется, останутся ли графические искажения на скриншоте, снятом в момент искажении. В зависимости от того, останутся ли, или скриншот будет без изъянов, можно судить о механизме возникновения бага.

Хакер писал(а):Я так понял, что ger_kar интересуется, останутся ли графические искажения на скриншоте, снятом в момент искажении. В зависимости от того, останутся ли, или скриншот будет без изъянов, можно судить о механизме возникновения бага.

Именно это я и имел ввиду.

ger_kar писал(а):

Хакер писал(а):Я так понял, что ger_kar интересуется, останутся ли графические искажения на скриншоте, снятом в момент искажении. В зависимости от того, останутся ли, или скриншот будет без изъянов, можно судить о механизме возникновения бага.

Именно это я и имел ввиду.

Тогда да, KVM не поможет.

Если же интересно, как баги выглядят и как проявляются, то вот фотосессия.

Skype как раз был запущен.

Одно из характерных проявлений — штатный просмотрщик изображений не может показывать картинки вот с такой формулировкой:


При ресайзе этого окна происходит пересоздание битмапа (под новые габариты), и процентах в 10 это пересоздание оказывается успешным и картинка проявляется. То есть изображение то появляется, то исчезает с изменением размера окна хотя бы на 1 px.

Привычно открываю SnagIt — чтобы снять то, что выше (пришлось сфотографировать). SnagIt, естественно, не может снять скриншот, зато его окно (открывшееся на другом мониторе) просвечивает то, что оказалось под ним:


Словно WM_ERASEBKGND не сработал. Именно так: дело точно не в том, что у окна такой причудливый clip region или что оно слоёное. Весь этот графический мусор, оказавшийся внутри региона окна будет перемещаться вместе с окном при передвижении окна (как это штатно бывает — перетаскивание окна двигает растр).

Разворачиваю окно Скайпа: у него верхушка отрисовалась, а элемент со списком контактов — не отрисовался вообще, а поэтому просвечивает окно браузера и вьювера картинок.


Если водить мышкой над списком контактов, то конечно соответствующие элементы начинают рисоваться. То есть само по себе приложение, реагируя на WM_MOUSEMOVE, какую-то свою оконную графику перерисовывать может. А вот самоотрисовка по WM_PAINT и WM_NCPAINT — хромает.

Например вот:

При проведении над «Echo / Sound Test Service» мышкой этот айтем перерисовался. Белый фон и прочие айтемы, естественно, нет.

Окно SnagIt'а, тем временем, заполняется фрагментами собственной графики и мусором, оставшимся от отрисовки поверх него окна Скайпа:


А окно Скайпа — фрагментами окна SnagIt'а, которые при прокрутке контакт-листа только оставляют за собой шлейф:


Тут следует напомнить, как обычно реализуются скроллируемые контейнеры: при получении WM_MOUSEWHEEL код внутри WindowProc дёргает какую-то общую функцию, ответственную за скроллинг, ту же, которую дёргают обработчики сообщений от скроллбаров. Эта функция вызывает API-функцию ScrollWindow, которая просто сдвигает растр (копированием, вероятно, с помощью BitBlt), а затем — InvalidateRect (или InvalidateRgn), помечая участок, на месте которого должна появиться новая графика (ранее скрытая, но появляющаяся на новом месте в результате скроллинга). В результате вызова InvalidateRect в очередь сообщений прилетает сообщение WM_PAINT, которое заставляет WindowProc окна перерисовать фрагментик, на месте которого должна появиться новая графика.

В нашем случае всё так, но WM_PAINT не обрабатывается успешно. Так что картина вполне ожидаемая и объяснимая.


Баг с недообработкой WM_NCPAINT (когда у вновь появляющихся окон отсутствует синяя полоса заголовка) я поймать в этот раз не смог.