RenamedUser_36319756

Проверил на шкурках, все так. Дело вот в чем. Архив скачивается одновременно с основного сервера (dwn.wotsite.net) и с 2-х зеркал (brotanki.ru и file.aces.gg) для распределения нагрузки на серверы. После первой закачки локальному файлу ставится штамп времени файла на сервере (нужно для условных запросов If-Modified-Since). Штамп времени у файла на каждом из серверов, конечно, разная, ведь заливаются они туда в разное время, утилита закачки берет самый новый штамп времени (с того сервера, куда файл заливался в последнюю очередь) и ставит локальному (в нашем случае самый новый штамп у файла на brotanki.ru). Это логично и ошибки тут нет. Все плохое начинается с повторной закачки. Утилита вместо того, чтобы сравнить штамп локального файла со всеми штампами со всех серверов, сравнивает только с файлом с первого указанного сервера, а это dwn.wotsite.net. Разумеется, штамп на dwn.wotsite.net старее и идет перезакачка. Это уже баг утилиты. Генеральному можно посоветовать сделать так: если используются зеркала, то в установщике первой основной ссылкой на файл должна быть ссылка с сервера, куда файл заливался в последнюю очередь, остальные 2 по барабану.

Не совсем так. Клиент (качалка в установщике) посылает серверу условный запрос - мол, у меня есть такой-то файл с такими-то временнЫми атрибутами, посмотри нет ли у тебя такого файла, только новее. Если есть, то сервер говорит клиенту - да, есть, забирай, если нет - не, у тебя тот же файл, расслабься. Если архив на ПК и сервере один и тот же, но перезакачивает все равно, то либо пользователь мацал руками временнЫе атрибуты архива, либо сервер настроен тупым админом и условные запросы игнорируются.

В качестве качалки используется утилита aria2. Изначально в модпаке использовалась версия 1.18.10 и проблем с ней на XP не было. На данный момент Yusha обновил утилиту до версии 1.19.3, только release note к программам никто не читает, верно? Начиная с 1.19.0 автор утилиты добавил поддержку протокола SFTP, где вовсю используется bcrypt.dll, присутствующая только на осях от Vista и выше. Ждите, когда Yusha поправит, а он поправит, честно.

Если подходящих пиров нет, то с чего вдруг модпак качать станет? Вся эта лабуда нужна только лончеру, самой игре - нет. Их не существует, какие бы вы программные решения не нашли.

real_human, если после этих 2 команд ошибка осталась, то выполнить еще одну: regsvr32 %SystemRoot%\SysWOW64\jscript.dll Просто мультипак пока еще не реагирует на поломанную регистрацию библиотеки jscript.dll в системе. winstalll, торрент? По окончании загрузок качалка ждет закрытия всех установленных соединений. Таймаут ожидания - 120 сек, после которого завершение принудительное, ты просто не дождался.

goracio32, все же косяк, сообщение не соответствует возникшей проблеме. Объект MSScriptControl.ScriptControl из msscript.ocx создается, но далее возникает ошибка, не связанная с регистрацией компонента, а с его использованием. Пару слов о том зачем установщику этот объект. Он позволяет в установщике выполнять код, написанный на языках программирования JScript, VBScript и некоторых других, в данном случае JScript. Движок языка JScript реализован в библиотеке jscript.dll, объект MSScriptControl.ScriptControl при первом обращении к ней не может использовать язык из-за поломанной регистрации библиотеки или ее отсутствии, установщик вызывает неверное сообщение про msscript.ocx и досвидос. Код на JScript используется в установщике для получения информации о закачках. В качестве качалки используется консольная утилита aria2c.exe (made in Japan), запущенная в режиме RPC-сервера. Это позволяет установщику общаться с утилитой по протоколу JSON-RPC, посылается запрос о состоянии закачек, в ответ приходят JSON-данные, разбором которых и занимается код в установщике, написанный на JScript. Eliyy, спасибо. На 64-разрядных системах нужно указать путь в System32 для 32-разрядных файлов (она же SysWOW64) прямо: regsvr32 /u %SystemRoot%\SysWOW64\msscript.ocx regsvr32 %SystemRoot%\SysWOW64\msscript.ocx При разрегистрации может ругнуться с ошибкой 0x80004005, даже если консоль запущена от имени Администратора, типа нет прав, ничего страшного, первую команду можно опустить, вторая обязательна.

BSOD на старый win32k.sys, решение уже было - включить службу обновлений и обновить систему и шрифт dynamic. Но перед обновлением вам надо удалить активатор, иначе будет еще один BSOD, уже другой. Что, где, когда - http://forum.ru-board.com/topic.cgi?forum=8&topic=49986&start=0 в первом сообщении. В коде ошибка, обращение к объекту без проверки его на Null.

Можно поставить закачки на паузу и подождать, если видно, что скорости нет, но мысль дельная. Для HTTP(S)-загрузок сделано так, что серверу в запросе отправляется заголовок If-Modified-Since. Если скачиваемый файл уже есть, то качалка сравнивает дату модификации файла с тем, что на сервере. Если файл на сервере не менялся или пользователем в Downloads, то сервер возвратит в ответе 304 Not Modified и файл скачан не будет. Тут уже сервер решает возвращать 304 или нет, практика показывает, что архивы то перезакачиваются, то нет, по крайней мере у меня так.

Значит в установщике выбран компонент ХП на миникарте (XVM) без опции с Alt и маркеры рисуются постоянно, а не по нажатию клавиши, и при загрузке карты при прорисовке миникарты BSOD.

Только не нужно потом торренты закачивать в папку Downloads мультипака, а то при сидировании если пиры тянут, то файлы блокируются. Если в это время ставить мультипак, то выбранные загружаемые моды не будут распакованы. По-русски: подсистема GDI не смогла отрисовать маркеры на миникарте после нажатия на LAlt ввиду того, что: a) драйвер win32k.sys старой версии и содержит критические ошибки; б) XVM-овский шрифт сделан плохо (тут надо проверять на сбойной машине до установки системных обновлений с обновленным шрифтом, что сегодня выложили. Если будет сбой или артефакты на миникарте, то точно еще и шрифт косячит). Клиент обновился, причем по новому, на SD и HD контент. Может теперь графика по-другому рисуется теперь. Вы это все почувствовали по неработающим модам. Ну я ж не могу гарантировать 100% результат, вызвать на моей обновляемой машине такой BSOD проблематично. Ну текущую версию файла win32k.sys можно же посмотреть? Если система обновляется, то KB3045171 от 20 апреля установлен и версия файла 6.1.7601.18834 (для Win 7). И шрифт я не сбрасываю со счетов.

Ладно, разбор полетов, раз других дампов нет, то буду писать вердикт на основе твоих, ghjdthrf241, дампов . Анализ содержимого стека из дампов показал, что на момент смерти система работала со шрифтом (общая цепочка вызовов для всех 3 дампов - win32k!NtGdiGetGlyphOutline, win32k!GreGetGlyphOutlineInternal, win32k!PDEVOBJ::QueryFontData, win32k!ttfdSemQueryFontData, win32k!ttfdQueryFontData, дальше - индивидуально). Т.е. система рисовала глифы шрифта, но не получилось.Также многие пишут, что BSOD вызывается при нажатии клавиши LAlt, таких модов 2 - Предохранитель и ХП на миникарте по Alt (XVM). Если первый хлопот не доставляет, кроме того, что висит на занятом хоткее, то второй в худшем случае вызывает BSOD при попытке отрисовать маркеры при помощи шрифта dynamic, в лучшем вызывает артефакты на миникарте в виде левых линий и закрашенных прямоугольников (скрины выше в теме есть). Можно было бы сказать, что шрифт кривой, я этого не исключаю, но в дампах фигурирует сбойный драйвер устаревшей версии win32k.sys 6.1.7600.16385, система приблизительно не обновлялась с осени 2013 г. За это время вышло несколько обновлений от Microsoft, которые обновляют указанный файл. В декабре 2013 г. вышло обновление https://support.microsoft.com/ru-ru/kb/2908190/ru, которое напрямую связано с данным BSOD. Последняя версия файла win32k.sys 6.1.7601.18834 ставится с обновлением https://support.microsoft.com/ru-ru/kb/3045171/ru, которое тоже связано со шрифтами. В общем, товарищи, которые отключили службу обновлений сами или используют фиговые сборки с правленными графическими ресурсами, а значит также с отключенной службой дабы не обновлялись правленные файлы, вы сами себе буратины. Рекомендую: Включить службу обновлений и обновиться, т.к. установки KB3045171 может оказаться недостаточно. После установки обновлений удалить кэш шрифтов (файл C:\Windows\system32\FNTCACHE.DAT). Удалить шрифт dynamic, используемый в XVM, установить наново. Ссылку на новые шрифты давали уже. Как удалять/устанавливать: http://windows.microsoft.com/ru-ru/windows-vista/install-or-uninstall-fonts Пробовать играть.P.S. Тут день-два назад был пост, где была инфа про такой же старый win32k.sys и xNtKrnl.exe. Так вот, товарищ, не вздумай сразу обновляться, BSOD 0xC00000005 я тебе гарантирую, сначала грохни свой пиратский активатор. Не угадали, я не Дима, и это не твинк, боев действительно всего 5 у меня, даже 1 танк подбил, в танки не играю, сыграл, чтобы была возможность здесь писать. САМИМ тут и не пахнет.

Не кипятись, судя по анализу дампов, ты тоже виноват. За дампы спасибо, ты первый выложил, подожду еще от других участников форума.

Когда будет выложен хотя бы один дамп памяти после BSOD, чтобы подтвердить поставленный, в принципе, диагноз. А лучше несколько. Лежат по умолчанию в C:\Windows\Minidump, создание настраивается в Панель управления - Система - Дополнительные параметры системы - Загрузка и восстановление (Параметры) - Отказ системы (снять Выполнить автоматическую перезагрузку, в Запись отладочной информации выбрать Малый дамп памяти).

В определении причины возникновения BSOD файлы python.log и xvm.log мало чем помогут, ведь во время краха системы какие-либо записи об ошибках туда не успеют занестись, если таковые будут, loginstall.inf как раз нужен для того, чтобы узнать какой набор модов был установлен мультипаком и потом с этим же набором модов попробовать воспроизвести BSOD на другой машине. А еще ни один не прикрепил к сообщению дамп памяти, созданный во время BSOD, по скриншотам понятно разве что BSOD 0x50, что сбой в драйвере win32k.sys, что сбой при операции записи туда, куда не надо. Что предшествовало краху скрин не покажет.

При чем тут конфликтует? Установщик использует этот стандартный ActiveX-компонент и перед его использованием проверят жив ли он. Данное сообщение означает, что файл на машине есть, но регистрация компонента нарушена и использовать его не получится, ну бывает такое от действий всякого рода оптимизаторов, чистильщиков реестра и т.п. Всего-то нужно сделать перерегистрацию компонента, набрав в консоли поочередно 2 команды: regsvr32 /u msscript.ocx regsvr32 msscript.ocx Первая дерегистрирует компонент, из реестра удалятся оставшиеся хвосты, вторая регистрирует его. Разумеется, консоль от имени Администратора запускать, если UAC включен.