Для успешного обновления до данной версии вам необходимо деинсталировать стороннее антивирусное ПО!
Вопрос: Неактивен пункт "Получение сборок для участников предварительной оценки"
Ответ: Пуск --> Параметры --> Конфиденциальность --> Отзывы и диагностика --> Даннные диагностики и использования --> переключить в "Расширенные сведения" или "Полные сведения"
1. Удалите все стороннее антивирусное ПО. 2. Перезагрузитесь. 3. Пуск --> Параметры --> Обновление и безопасность --> Программа предварительной оценки Windows --> Выберите свой уровень участника программы предварительной оценки --> Ранний доступ
Если метод установки не меняется с Поздний доступ на Ранний доступ - в командной строке с правами Администратора выполните команду:
Код
reg flags HKLM\Software\Microsoft\WindowsSelfHost\Applicability set DONT_VIRTUALIZE
Если обновление не скачивается через Центр обновления Windows или возникает ошибка:
1. Проверьте, чтобы на системном разделе было достаточно свободного места - не менее 20Гб для x64, и не менее 16Гб для x86. 2. Удалите все стороннее антивирусное ПО. 3. Выполните очистку системного диска: Win+R --> cleanmgr --> выбрать системный диск --> OK --> нажать "Очистить системные файлы" (Clean up system files) --> повторно выбрать системный диск --> поставить все галочки --> OK 4. Загрузите, распакуйте и запустите следующее исправление:
Lenchik, вы определенно проявляете свое внимание к моим постам. И я рад этому в душе. Не буду рассказывать всю предисторию запутанности/сбоя меток. Вы владеете английским, посему направляю вас (да и других, кому интересно) за более проясняющей картиной на форум Оракла -> https://forums.virtualbox.org/viewtop....143cdee
MedMeks, друже, это только вы увидели на двух библиотеках. Я вам скажу больше - сбита вся система меток, даты прыгают от 20 века до 22 века. Майкам сказали это и похоже на уровне директора, думаю в большей степени 80-я и 81-я сборки поэтому были остановлены к раздаче. На этом можно этот момент завершить в обсуждении.
netWanderer, Не думаю что задержка с обновлениями из за неверного времени создания файла. Тем более до сегодняшнего дня обновления были полными, не обращая внимания какие файлы были до обновления.
Я всяким утилиткам не верю, поэтому посмотрел заголовки HEX редактором.
Это файл ntdll.dll от 14393. Как видно всё в порядке. Первая рамка смещение. По этому смещению находится заголовок PE вторая рамка , после заголовка со смещением в четыре байта сама дата - время в третьей рамке. Это время в секундах от полуночи 01.01.1970 года по средне тихоокеанскому времени. Я грубо посчитал на калькуляторе, получилось примерно 46 лет. То есть всё правильно.
Это файл ntdll.dll от 14971. Как видно дата - время другая. Точно я не считал, но получилось около 54 лет с первого января 1970.
Тем не менее на работу системы это ни как ни сказывается. Это же не база данных где более свежий файл всегда заменяет более старый.
Lenchik, давайте просто забьем на это дело. Я поделился своими наблюдениями. Это влияет на запуск приложений сторонних производителей. Грамотный/толковый программист создавая свое приложение, экономя на коде - подключает системные ресурсы к своему приложению - в качестве системных библиотек, при этом задействует проверку подключаемого ресурса на подлинность. Как раз временная метка участвует в этой проверке. У ряда производителей не прошли эти проверки при запуске их приложений. Вспоминайте - помните я писал про ЛитРес, как раз они среди наших "попались на этот крючок"... Майки ускорили внедрение платформы UUP, по своей сущности, эта платформа позволит им как раз динамически/быстро/в фоне устранять подобные ляпы.
сбита вся система меток, даты прыгают от 20 века до 22 века.
Ну какую интересную дискуссию Вы затеяли, не поленился, воспользовался утилитой 7z.exe, информации которой ПОЛНОСТЬЮ доверяют ребята из команды создателей декриптеров: они используют ее для выяснения ИМЕННО даты создания NTKERNEL для правильного формирования имени ISO. И вот, что я получил:
<code> E:\Delme\!Projects\BuildsHistory>j:\Decrypt\bin\7z.exe e c:\windows\system32\ntdll.dll .\nt-dll-version.txt
Scanning the drive for archives: 1 file, 1567528 bytes (1531 Ki
Extracting archive: c:\windows\system32\ntdll.dll -- Path = c:\windows\system32\ntdll.dll Type = PE Physical Size = 1567528 CPU = x86 Characteristics = Executable DLL 32-bit Created = 2024-03-04 04:04:27 <<<<<<<<<<<<<<<<<<<<<<<<<<<<< Headers Size = 1024 Checksum = 1627530 Name = ntdll.dll ............................ </code>
Так что в данной дискуссии я присоединяюсь к netWanderer P.S: LENCHIK, я посмотрел выложенный Вами дамп с обведенными 4-байтными полосками. ЭТО НЕ ДАТЫ, вот как выглядят СЕГОДНЯШНИЕ даты в секундах от 01.01.1970: 582E02C0, соответствует 17.11.2016 23:19:28 UTC+04:00
sysprg, Не надо все dll валить в одну кучу. Есть библиотеки к которым обращение задокументировано, например dll от DirectX, а есть внутренние, к которым обращение приложений не предусмотрено. Использовать из конечно то же можно, но только в любой момент они могут измениться, или совсем исчезнуть, что приведет к отказу приложения. Никто же не обещал что они будут неизменными и совместимыми.
Так что надо сначала разобраться, а можно ли эти dll использовать приложениям согласно спецификации microsoft?
Я например только за, когда после очередного обновления нестандартно написанные приложения падают. Это будет приучать программеров писать правильные приложения, без всяких вывертов.
Eisvogel, вы не добавили, как в своем другом посту - что переключились с релиз превью на медленное кольцо - у вас подтянулась сборка из сети с других компов.
Использовать из конечно то же можно, но только в любой момент они могут измениться, или совсем исчезнуть
Есть ОБЪЕКТ DATETIME с помощью методов которого вычисляются даты как в коротком формате секунд от 01.01.1970, так и в длинном формате Filetime, в 100-наносекундных интервалах от 01.01.1601. Для ЛЮБЫХ файлов дата создания записывается именно в формате Filetime, как и время последнего изменения.
Я ежедневно по десятки раз в день смотрю на даты в бинарных форматах и преобразую их в строковый вид, но не с помощью калькулятора, как Вы пытались сделать, а с помощью методов объекта DATETIME/ На PShell это легко и просто. И потому я сразу отреагировал на совершенно не типичный формат 4-х байтных дат, содержащих ДВА ПОСЛЕДНИХ НУЛЯ, которые Вы выложили на картинке. Ну НЕ МОЖЕТ дата в секундах иметь два нулевых байта. P.S: мне не приходилось разбираться в формате хидера PE, но вот после этой дискуссии посмотрю MS-документацию и выясню. Но уверен, что смещение поля, содержащего дату компиляции, ФИКСИРОВАНО и совершенно не зависит от того, кем и зачем используется EXE или DLL и НИКОГДА MS не станет менять смещение этого поля
sysprg, К сожалению меняется. Там не смещение меняется, а начало заголовка PE. Вы справа посмотрите, там где в текстовом виде, на моих скринах. Заголовок начинается с PE в текстовом виде, потом идет два нолевых байта. Даже заголовок PE в разном месте в разных файлах. А дата находится фиксировано по отношению к заголовку. На заголовок PE указатель находится по адресу 3C HEX. И дата создания четыре байта, как всегда начиная с младших байт к старшим. Я не так уж и приблизительно считал, я просто високосные годы не учитывал.
Сразу за заголовком идет тип процессора два байта, следующие два байта не помню что. Во втором примере тип процессора то же неправильный.
Уважаемый sysprg - не берите все сильно в голову. Леонид начал уводить разговор в сторону, защищая майков. То что они облажались с этой 71-й сборкой - это однозначно. Механизм проверки файла на подлинность заключается в следующем - берется Хэш файла по строгому алгоритму из него производится расчет временной метки для этого файла (расчетной), затем расчетная временная метка сравнивается с меткой прописанной в заголовке файла, если метки совпадают - файл считается подлинным. Этот механизм един, стандартизован и автоматизирован. И самими майками был предложен - как изначальный сигнализатор о повреждении файла вирусом, так как вирус при своем воздействии изменяет Хэш файла. Записи временной метки в заголовках файлов в 71-й сборке - не соответствуют расчетным временным меткам из Хэша этих же файлов. Вот и все.
Брандмауэр W10 просит установить tap provider v9 for private tunnel (openvpn) Зачем??
Я бы не стал соглашаться. Это не брэндмауэр просит, а какое то приложение рвётся, а брэндмауэр вас спрашивает, разрешить или нет.
Добавлено (05.12.2016, 09:06) --------------------------------------------- netWanderer, почему я увожу. Я скринами как раз подтвердил вашу правоту, только сделал это вручную, не надеясь на утилиты.
Цифровая подпись как раз и есть зашифрованный хэш файла. Не пересчитать, не подделать, можно только проверить. sfc /scannow и проверяет. Если хэш был сосчитан сразу с неправильной датой, то все проверки будут проходить на ура. Либо sfc /scannow не проверяет эти файлы (он же не тотально все файлы windows проверяет), либо хэш сосчитан сразу с неправильной датой.
Некоторые приложения проверяют правильность заголовка PE, алгоритм в документации описан. Сначала метку MZ в самом начале файла, потом PE заголовок, а потом остальные секции заголовка. Есть там проверка на допустимость значений. Естественно она не пройдет, если дата выходит за разумные пределы.
Но вопрос то остается? А обращение напрямую к этим файлам описано в Windows API?
В связи с введением в действие Постановления Правительства Российской Федерации от 14.11.2023 № 1905 т.н. "о запрете популяризации VPN" с 1 марта 2024 года - любое обсуждение способов обхода блокировок и VPN на портале запрещено!
